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.