Recently, I’ve been tweeting about trying to put together a ‘crash course’ on project management. I’m seeing and hearing about a lot of people who are being asked to take over project management tasks and roles to try and cut costs. Not surprisingly, I think this is a false economy by any business (I would say that, I’m a project manager…) but figured if you’ve been put in that position, you just want to try and do your best to make it work. You want to get hold of the tools and techniques that can help you deliver the project successfully. Hence the crash course.

But this post isn’t about that course – I’m still trying to polish that, and decide what to do with it when it is finished! (And I’ll make sure to let you all know too.)

No, this is about what else I started thinking about while putting that course together. You see, the crash course is focused on the tools and techniques we use as project managers, what we use to get our job done. But it occurred to me that by just showing these, I was giving people a false understanding of what project management is, and how to do it well.

I’ve been guilty of this on this blog as well. I’ve been writing it to try and help new project managers, and to help myself refresh and retain the project management knowledge I have. But again, I have only been displaying the tools, not the whole picture.

Of course, it’s easy to understand why I have been doing this – the tools are pretty simple to teach. Oh sure, they may be complicated to use, it may take a lot of information to show how, but it’s a simple process – you are just moving information from one brain to another.

But that’s missing the most important part of what project managers need to have – they need to have an understanding of the concepts behind these tools.

Put it this way – it is easy to describe a hammer. You can talk about the handle, the head, the materials it is made of. You can describe the process of using it, how you place a nail, strike it to drive it into a material. All of this you can do in great detail, with great precision and accuracy.

But if you don’t explain the reason you’d want to hammer a nail, the person you are teaching knows how to use a tool, but not why. They are capable of doing a task (putting a nail into a wall) but not of understanding why it is useful (to hang a picture). Knowing why you are doing the tasks allows you to make better judgements – suddenly you know to position the nail so the picture gets good light, and so on. The concept informs the task.

And that’s what I want to get to. By only teaching the tools, I run the risk of creating project management automata – able to carry out the tasks, but with no understanding of why they are carried out. In other words, the very paint by numbers type of project manager I talked about the other week.

I suspect that gaining an understanding of the concepts behind project management goes hand in hand with the changing perception over time of what a project manager is, as set out by Cinda Voegtli at Project Connections in Evolution of a Project Manager (hat tip at Raven Young).

So, that means I need to try to teach the concepts behind project management too. That’s a bit scary. Concepts are hard to teach. Learning them, really learning them, takes effort, experience, reflection, and a whole load of coaching. And even that isn’t guaranteed to work – concepts require understanding, and understanding can’t be given, it can only be gained.

Not that that is any reason not to try, of course. So over the next week or so I’m going to be knocking around a few ideas about what the key concepts are over on Twitter (you can follow along too), then I’m actually going to try to explain them.

Wish me luck…

Recently I’ve been looking through a few TED talks, thanks to the iPhone TED app. I came across this great talk by Barry Schwartz, and wanted to share it with you. What I think is very interesting for us as project managers is the recognition that sometimes rules don’t work, and incentives can skew behaviour – not always in the way you want.

It is quite long, but believe me, it is more than worth it. Let me know what you think!

One of the favourite sayings of my father is “Wisdom is not in not making mistakes, but in not making the same mistake twice”. This is an important lesson for all of us as project managers. Learning from our mistakes helps us to become better project managers – experience is always a good teacher.

But what we should all be trying to do is make sure we are not the only ones to learn from our mistakes. Making sure others in our organisation, or even our profession, get the benefit of our experience is an important part of our professional lives.

So how do we go about this? Well, first of all, we need to recognise when we have made mistakes, when we have not taken the best action in a given situation. This needs a certain amount of honesty, and to be done well, it needs time to really consider the project as a whole.

The best way of doing this is to analyse the project when it comes to an end. Hopefully, the project will come to an end successfully, with the end result we wanted delivered. But it may be that the project has been stopped early, for whatever reason. Regardless, at this point we need to evaluate a number of things:

• Exactly how successful was the project really?
• What actions did we take that helped?
• What actions did we take that didn’t?
• What problems occurred?
• How did we deal with them?
• Were there things we could have done better?
• Were there things we didn’t do that could have helped?

As you can see, there is a lot of ground to cover. You will also note that a lot of this involves honestly looking at your own work. Now, this can be tough, especially when looking at places where we messed up. But it is only by examining our mistakes that we can learn from them.

However, to help us out in this area, it is always useful to have help in doing this analysis. Your Executive is a prime example to examine your work, but don’t neglect your project team members. Your team will have a different perspective than your Executive, and as they are closer to the nitty gritty work of the project, may have valuable insights into areas that went wrong.

But I don’t want you to go overboard on only focusing on the mistakes. It is equally important to learn from the successes, so that these can be replicated in the future.

All of this analysis should be formally presented as a report, an evaluation of the project as a whole, a set of lessons to be learned. This report should be the final part of your project, where you look back at the work that was done. It can form a valuable tool for future project managers working on a similar project – your experiences can inform their work.

This means that hopefully not only won’t you make the same mistakes again, nor will anyone else in your organisation!

Oh, and that saying my father likes? I don’t know who said it first, because a similar message is attributed to numerous people. Which kind of demonstrates the benefits of spreading good messages too – lots of people can learn from it!

1. The Social Media Project Manager – Blogs
2. The Social Media Project Manager – Twitter
3. The Social Media Project Manager – FriendFeed
4. The Social Media Project Manager – More Twittering
5. The Social Media Project Manager – Social networking
6. The Social Media Project Manager – An Example
7. The Social Media Project Manager – Wikis
8. The Social Media Project Manager – Blogging Community
9. Edit: I have also put together a slideshow for this series, The Social Media Project Manager – The Movie! Hope you like it!

Over the past few weeks, I have been highlighting some of the tools that can loosely be described as social media. The tools can be of use to a project manager in a variety of ways. Some of them can be directly used to help manage your projects, some of them to help you learn and develop, and some of them can be used for both.

As the series has gone on, my use of some of these technologies has also increased, as I have started to find them more and more useful. Of particular note to me are Twitter and FriendFeed, both of which I have found exceptionally useful. These two tools have helped me become more involved in the online project management community, both by seeing what others are doing, and by trying to contribute!

My resolutions moving forward are to continue to play a part in the project management community, most especially through Twitter and the Project Management Guide FriendFeed Room. I will also continue to search for new ways and new tools of social media to use in project management.

What about you? Which of the tools have you found most useful, or most interesting? What are you going to do to use social media in project management? Or are you going to steer well clear? Let me know your views!

I had a very strange conversation with a friend the other day. It started off simply enough: he has recently started working in a project management role in a public body, and was wondering what the preferred format for risk logs was. He knew I have worked in that area before, so asked me what it was.

But what came out from the conversation was that he was only asking now as someone from the head office was coming to take a look at the project. Previously, my friend had been getting along without knowing the preferred format by simply not having a risk log!

I imagine you’re as surprised as I was. But it got worse – apparently my friend wasn’t using a risk log because his new boss didn’t believe they were necessary. So as there was no call for a risk log from above, my friend just didn’t bother with one.

By this point, I was horrified. It was bad enough that he was running his project without a risk log. But his reasoning for this, that his boss hadn’t asked for one, betrayed something even more worrying. It suggested to me that he would only normally have a risk log because someone else expected it, because it was another box he needed to tick.

Now that’s worrying. I could forgive him not having a risk log if he had thought about it and decided the project wasn’t complex enough to need one, though I’m having trouble imagining I could come to that decision myself. Unfortunately, it sounds like he hadn’t thought about what was needed for this particular project, and was only now putting in place a risk log as a paper exercise.

That betrays a lack of understanding about project management. The techniques and tools that we learn as project managers aren’t there so we can tick the boxes. The techniques and tools are there because they help us to run projects well!

But they can only help. To get value out of them, we have to understand the principles behind them. We have to know why we are doing the things we do, not just how.

What my friend appeared to be doing was painting by numbers – project management by numbers, if you will. He knew the things that had to be done, and when, so he just got on and did them. But he didn’t seem to be showing any understanding of why he was doing these things.

All this got me thinking – how many more of these “project management by numbers” project managers are there? Has the popularity of some project management courses led to us churning out project managers who know what to do, but not why? Is this why we see so much bad project management?

What do you think?

Oh, and in my friend’s defence, this is his first project management role! He quickly saw the value of risk logs, and I have no doubt he’ll use them well. All he needs is more experience. Do other “by the numbers” project managers have that excuse?

All of your certainties are under attack. You thought you were on safe ground, a stable platform to start from. But now that ground is moving beneath you, an earthquake shaking everything you have built, threatening to bring it all down. The landscape is changing, and you’re the one who has to try and survive.

Oh, alright, I admit it, that’s just a tad melodramatic. But when you have been working hard to deliver a project, having the goalposts moved can feel almost like a natural disaster, an earthquake knocking you down. This is only to be expected – we all like to think we have control of our work, so it can come as a genuine shock when circumstances prove us wrong.

But, as I have written before, project management can be described as being about managing change effectively. Normally, the change is what the project is trying to achieve, bringing about a beneficial change. A consequence of working with change, though, is that a project itself is almost guaranteed to undergo changes.

This doesn’t have to be a bad thing. Nor, of course, is it necessarily a good thing. But it is something that is going to happen, whether you want it to or not. There’s no point in pretending it doesn’t, or resisting it when it comes along. Far better to deal with the requests for change that crop up – you never know, they may actually make your project better.

So how can we handle these requests for change? Well, now that we have accepted they will occur, we need to make sure we capture them. A change request that comes in should be recorded. You must capture these requests, and make sure they are dealt with. But how they are dealt with can vary.

The first thing to check is – is this really a change? Has the person asking for this change misunderstood or misread the project requirements? Are we actually already doing this? Believe me, this happens far more than you’d imagine…

Now, if it really is a change, you need to prioritise the importance of it. This can vary from an absolutely vital change, to something which is a purely cosmetic change. Try to have a set of different levels. I’ve used a system of four levels before, those being:

• Vital – the output of the project will fail if the change isn’t made
• Important – not having it causes problems, but it could be put up with or worked around for a short period
• Desirable – the change would be beneficial, but the output can still be successful without it
• Cosmetic – unimportant, has no effect on the usefulness of the output

So, you’ve worked out the priority. Now you need to figure out what impact making the change would have. Obviously this is going to vary massively depending on the change, the project, the environment, and so on. But the best place to start from is by analysing what would actually have to change. By this, I mean analysing the change to understand which parts of the project work would have to be done differently, or again:

• What has to change?
• How much effort will this require from the project team?
• How much will it cost?
• Will something else in the project, or linked projects, have to be dropped or altered to make the change?
• What effect will it have on your project schedule?
• Will the change introduce new risks, or get rid of old ones?
• And, importantly, what effect does it have on the Business Case?

Now we have a judgement of the priority and impact of the change, we can start to make an educated decision about whether to make the change or not. But remember, you are working on behalf of the Executive – ultimately, any decision about change is their responsibility.

In general, if the priority is Desirable or Cosmetic, and the impact is low (i.e. can be done well within the tolerances you have been set) then I’d probably just go ahead and make the change, though I would make sure it was flagged up to the Executive. If the priority is higher, or if the impact is higher, I’d refer the decision up to the Executive, unless they have already put some other mechanism in place for approving change.

You may have realised that means I would refer up a decision that was of Vital priority, but very low impact. Why? Why would I not just go ahead and do it? Well, two reasons.

Firstly, if I believe a given change is very low impact but Vital priority, that suggests to me I may have missed something – I want to make sure I take advantage of the Executive’s knowledge of the environment and organisation to confirm my thinking before I go ahead with any Vital change.

Secondly, if the project has managed to get approved with what may be a major flaw like that, I want it to get a good looking at. Has the change request come about because of a dramatic change in the external environment? Has this environment change been factored in to the rest of the project? Did we capture this on the risk log? Do we need to re-evaluate the whole Business Case?

Basically, if there is a change request that is Vital, I want to make sure that we haven’t just been struck by an earthquake, that the ground we have been building our project on really is stable enough to carry on. And that’s a decision that needs the expertise and wisdom of the Executive – after all, it is their neck on the line if it all goes wrong!

What about you? How do you deal with changes? What tricks have I missed?

(Image courtesy of videocrab / Kevin Simpson. Some rights reserved.)

Throughout this series, we’ve been looking at ways you can turn the tools of social media into tools of project management. But there is a much simpler way that social media can help us as project managers. Already there are project managers out there who are sharing their expertise through blogging, and that means there are many places we can go to develop ourselves as project managers.

Today, I would like to share with you some of the best project management blogs and resources that are out there. Now, this list isn’t designed to be comprehensive, but it will point you at some of the places I go.

First up, we have PM Hut. This site is a large collection of categorized project management articles, gathered from all over the web. There are many different project managers appearing here as authors, and a wide range of different views from them.

Next, we have PM Student. This site is primarily the work of Josh Nankivel, who you may recall I recommend you follow way back when we covered Twitter. As well as Josh, there are a few guest authors, and a lively group of commenters to keep you entertained!

Project Shrink is a blog by Bas de Baar, a software project manager. the blog has the tagline “Projects Are About Humans. We Help You Deal With That.” The site has a variety of posts that can help you be a more flexible and people-focused project manager. Take a look!

PM Tips is a collaborative blog that covers not only project management, but also “collaboration, knowledge management and all other work 2.0 concepts present in today’s web 2.0 world”! It offers practical tips and advice to help you be a better project manager.

Finally, do take a look at Pawel Brodinski on Software Project Management. This blog is more personal than the others I have mentioned here, and covers a lot of ground.

There are many more high quality blogs out there as well – I haven’t mentioned Jurgen Appelo’s Noop, Elizabeth Harrin’s PM4Girls, or John Reiling’s PM Crunch, all of which deserve a look.

Don’t forget, however, that if you join the Project Management Guide FriendFeed room the feeds from these blogs, and more, are pulled together into one handy place. Join in, and get commenting!

As I say, these are just a few of the blogs I go to. What blogs do you recommend? Which ones have you found to be most useful? And why? Let me know!

Part of The Social Media Project Manager Series.

As project managers, we’ve all had times when our attention is being pulled from many different directions at once. As well as our day to day tasks, sometimes problems pop up that mean we need to firefight, stakeholders can demand new reports, and team members can seek new direction. All of this can happen despite our best efforts to keep the project on an even keel.

Now, the ability to jump from task to task like this and still be effective is important for a project manager, but I don’t want to talk about that today. No, today I want to talk about the benefit of behaving in the opposite manner, about the benefits of focus.

All of us have had times where we have had to jump from task to task. And I imagine a lot of us have been left feeling that at least some of those tasks were short-changed by us – the pressure we put ourselves under to swap to the next job meant we didn’t spend enough time on the task in hand.

We all know that we should recognise the difference between things that are urgent, and things that are important. But while we all know it, I’m sure many of us still fall into the trap of chasing the urgent, without looking at how important it is.

Sometimes, the best thing we can do is to resist the demands to switch from task to task. By focusing on one task, you gain the ability to really get to grips with it. You will be able to look deeper into the cause of any problems, and come up with more considered solutions.

So, let’s put these two ideas together: deciding on what is urgent and what is important; and the benefits of focus. So how do we merge them?

Well, when you have a lot of issues clamouring for your attention, take the time to focus on one task first – the task of deciding which of those issues are important, and which are urgent.

Once you’ve done that, you are in a better position to focus on those issues that are important and urgent. Those that are important but not urgent can wait until these are done. Those which are not important, but urgent, can be delegated or renegotiated. Those which are neither important or urgent, well, they can just wait!

One of the ways to think about this is to remember that your time is precious. You are being paid (hopefully well…) to use your time for the benefit of the project. So take just a little of that time to make sure the rest of it is spent in the most effective manner, in the best way to benefit the project.

Of course, this is easy in theory, not so easy in practice. How do you deal with these sort of whirlwind days? Do you end up running around firefighting, or do you manage to find the time to focus on what is important? Let me know!

Today on Project Management Guide we are going to look at quality. In a project, quality has an important and specific role. So, for those beginning project management, what do we need to know?

As we have learned, a project exists to produce certain outputs, and part of the process of gathering requirements for what those outputs are must include information about what counts as an acceptable level of quality.

It is an understandable desire to only ever produce outputs of the highest quality. However, this level of quality is likely to take a lot of time, money, and effort. We don’t need our outputs to be the best, but late and expensive, we need them to be good enough, and on time and on budget.

So how do we go about making sure what we produce is of an acceptable quality? Well, you’ll remember from our post on project plans that one of the areas we need to cover in the plan is quality criteria.

What this means is that at the time of creating the project plan you will have agreed what criteria the output needs to meet, and how this will be measured. This will have been agreed with, at a minimum, the Executive and a representative of the end user, and hopefully with a representative of the people doing the work too!

Remember, quality criteria can be influenced by many things. Your business, or your customer’s, may have specific quality systems in place. Certain recognised standards of quality, such as ISO standards, may be mandated by contract. And, of course, the final use of the output will dictate what is needed – the quality required of a component in a washing machine is significantly different from an equivalent component in a nuclear submarine!

Now, these criteria, once agreed, tell you what success is, what completion of the project is. They need to be SMART:

• Specific – Clearly defined and precise
• Measurable – e.g. not “new computers”, but “computers with 2Gb of memory”, etc.
• Attainable – Don’t ask for the impossible
• Relevant – Is the criterion actually related to the aim of the project?
• Time-based – Enough time to achieve this. There is no point expecting a year’s worth of work in one week!

You will also need to decide who has the final say over the quality of the outputs. Hopefully your work on defining the quality criteria will mean there are no arguments over the quality (i.e. no qualitative judgements, only quantitative).

But quality isn’t something that you worry about only at the end of the project. The quality of what you are producing should be monitored throughout the project. Intermediate steps on the way to the final output, or separate, discrete pieces of that output should be quality checked as the project is carried out.

That’s a very quick overview of quality in a project. What tips do you have about quality in a project? How do you make sure you’re meeting the customer’s expectations, while also meeting your business needs? Let me know!

Project management does not exist in a vacuum. We have embraced the various new methods of communication to encourage better collaboration and team-work. It is now practically inconceivable for a project not to be using email, tele-conferences, even video-conferencing to maintain contact with the participants.

But are we embracing the new technologies available now? Are we making best use of the tools we now have? With project teams becoming even more spread out over the globe, are we making best use of our new communication methods?

This series will look at the various new social media tools available to us, and how we can start to use them in our projects. Some of you will already be using some of these tools. I’d love to hear your stories about how they have worked for you – many of the uses are only now developing, so I’d love to hear your best practices!

Wikis are websites that allow the people who access it to contribute to it, or to change and update the information that is already there. The most famous example of a wiki has to be, of course, Wikipedia, which has harnessed the efforts of individuals around the world to build a resource with a remarkable breadth, though with sometimes variable quality!

But can a similar system be of use to us as project managers? We’ve already looked at the benefits of FriendFeed, most notably that as all the ‘conversational’ information is being captured, it generates a searchable resource of this information. However, sometimes we need to make things more formal.

While we can use blogs to share formal documents, they are primarily a one to many communication tool, in that the person writing the posts has the most control over putting information out. In other words, while a blog is useful for gathering comments on the information, it is not good at allowing collaboration in the creation of it.

When all of your team are close by, this may not be a problem – you can walk over and talk to them! Unfortunately, this is increasingly often not the case, and this is where a wiki can come into its own.

By putting up a wiki page, you enable the people viewing it to add information, to modify what is there, and to improve the usefulness of it. This means you can gather the knowledge and expertise from all of your team members, who can contribute to the generation of this resource.

This is useful when you are looking not only at the documentation around running the project, such as risk logs, but also when you are looking to create the documentation about the product – in other words, the documentation about using the product, which should be part of the output of the project.

A wiki isn’t the perfect answer, of course. While, hopefully, the documentation produced on the wiki will be good, it still needs to go through a quality process before release, and this may uncover problems. And, of course, actually getting your team to contribute needs discipline on both your and their parts. There may be a temptation to set up a wiki and leave it alone, assuming that the documentation will magically now get written. This works about as well as you would expect.

But while a wiki brings some challenges, the benefits of using one can be great. Having the accumulated knowledge and expertise of the project team around this project put down in an organised manner is incredibly valuable. And if it is done throughout the life of the project, it is likely to be much more successful than when tacked on the end.

Have you used a wiki in project management? Was it useful? Or did it just mean another thing that had to be monitored? What do you think? Let me know!

Part of The Social Media Project Manager Series.