In this video, the lead author of the 2009 refresh of PRINCE2, Andy Murray, talks us through the new Directing guide for PRINCE2. This guide is aimed at project board / Executive level project members.

Tom Wujec talks about how we understand ideas. He discusses the different ways our brain interprets what we see around us, and how this builds up into a mental map of what is happening.

This is a good video, but what I found particularly interesting was the look at how Autodesk work to create strategic plans. They make sure they get everyone involved, on their feet, and putting information up on the wall. This is a great way of enabling everyone to see how they fit into the big picture, and to understand the way it all hangs together.

This is similar to the technique I use when building up a project plan and schedule. Get the team involved, use their expertise, and put the information up on the wall, so everyone can see. I wrote about it a little in What happens now? – Scheduling a project.

Enjoy the video!

(From TED.)

If you look at pretty much any contract job board online, you’ll see an awful lot of the project management roles call for someone with the ability to ‘handle senior stakeholders’.  I think this is a pretty revealing request in a job advert.

For a start, while I don’t deny this should be part of any project manager’s job, the main work of handling senior stakeholders should be done by the Executive.  This is, after all, part of why they are in position – not only to give authorisation for the project to go ahead, but to gain support from senior stakeholders.

When I see a job advert asking for someone who can ‘handle’ senior stakeholders, it makes me think that the organisation as a whole probably doesn’t really embrace project management.  The Executive probably doesn’t understand, or doesn’t carry out, the responsibilities their role brings.  Project managers are probably engaged in a perpetual struggle to get support for their projects.

Unfortunately, this type of organisation isn’t unusual.  The situation described above is one I have often gone into as a contract project manager.  Part of me even kind of enjoys it – even though it certainly makes life more difficult.  But it does give an opportunity to transfer some project management knowledge to the organisation as a whole, and hopefully leave them in a stronger position for the next project!

What about you?  Have you come across this problem?

The folks at Best Management Practice have now put up the footage from the PRINCE2:2009 launch event. Enjoy!

There are three broad types of project manager – the Courier, the Facilitator, and the Thinker.

The Courier is, I am afraid, the worst type of manager.  He doesn’t actually add value to his team, and in fact often gets in the way.  But what does he do?

Well, the Courier just acts as the communication point between the project team and the senior management.  But he adds no value to that communication.  For example, if senior management puts pressure on him to deliver the project sooner, all he will do is pass the message on.  If he then gets pressure back from the team that what he is asking for just isn’t possible, he just passes that information back to the senior management.

In other words, he doesn’t make a decision.  When he is pressured from above, he doesn’t try and negotiate to get, say, more resources to enable a shorter timescale.  When he is pressured from below, he doesn’t try to explore different options with the team.

The Courier could be replaced by a telephone – it would be quicker, and cheaper.

The Facilitator is a big step up from the Courier.  While he may still sometimes get in the way, in general he is good at helping the team.  How does he do this?

The Facilitator is great at solving problems.  When an issue hits the project, he works with the team to find a solution, and implements it.  For example, if a supplier falls behind, he will work with the team to see how the tasks can be juggled to lessen the impact.  He would also go to the supplier and either help or chide them along.

In other words, he is a fire-fighter.  When problems crop up, he is excellent at solving them – but not so good at avoiding them in the first place.

The Facilitator tends to be appreciated by his team, and by management, but they sometimes wonder if life shouldn’t be a little less stressful.

The Thinker is another step up from the Facilitator.  He doesn’t seem to swoop in and solve as many problems as the Facilitator, but oddly there don’t seem to be as many problems either.  Why is that?

The Thinker spends considerable time thinking about the project.  He works with his team to identify potential problems, and also uses his own experience to identify possible issues.  Then he works to prevent these issues occurring.  For example, if he knows from previous experience that procurement takes longer than it should, then he will start that process earlier.

In other words, he removes problems before anyone else sees them.  He uses the project management tools, such as the project plan, the work breakdown structure, and lessons learned from previous projects, to gain foresight of the project.  He uses this foresight to make the whole process smoother.

The Thinker tends to be seen as unnecessary by his team, and by senior management – until they don’t have him anymore.

Of course, these are just the broad types, there are many sub-types for each one.  Do you know of some more?

(Image courtesy of gerlos. Some rights reserved.)

The refresh of PRINCE2, the internationally used project management methodology, is now complete. The updated PRINCE2 was launched this Wednesday, the 16th of June. The event was streamed live from the Best Management Practice website, and the slides from the presentation are still available. (That page also says you can watch the footage of the event, but I’m getting nothing. Maybe later?)

It may be a bit geeky to be excited about the launch of an update to a project management methodology, but I am. I’ve always liked PRINCE2, no doubt because it was how I learned project management in the first place. But as I’ve moved from big, technical projects in a bureaucratic organisation to smaller, people-based projects in more relaxed organisations, I’ve seen a lot of people feel exasperated that PRINCE2 is too prescriptive, and obsessed with the paperwork rather than the project.

Now, I’ve always thought that was the sign of a poor project manager, not the fault of the methodology, which has always seemed to me to be a toolkit you can dip into as and when it is needed, not a mould you have to try and force every project to fit into. The great thing about this update is that it is much less prescriptive, and much more about the quality of what we produce, and lessons we can learn through the project.

In other words, the flexibility I thought was always there in PRINCE2 has been made much more obvious, and brought to the forefront of the methodology!

You can get more information on the latest version of PRINCE2 from Andy Murray, who was the lead author of the refresh. There’s a great post by Elizabeth Harrin on PM Tips about the launch of PRINCE2:2009, and she also has a video she made at the launch event (which includes the all-important look at the goodie bag!) on her own site, A Girl’s Guide to Project Management.

(Image courtesy of Port of San Diego. Some rights reserved.)

Project management isn’t just about project managers. We are just part of a team that works on the project. Our job is to help the rest of the team to be successful at their job. So what are some of the signs of a project team that successfully works together?

I’ve come up with ten different characteristics of a team which I think will be successful:

1. Pride in their work – no project is perfect, but that’s no reason not to try. The team is committed to producing the best output they can, and are willing to put the case for the right decisions to get there.
2. Members support each other – they really are a team, not a group of individuals. Team members trust in the skills of the other members, and support them in tough situations.
3. Understanding – the team knows what they are doing, and why.
4. Competent and confident – the team members are all able to do their work, and confident in their abilities.
5. Communicate openly – the team understands that project management thrives on good communication.
6. Accepts final decisions – the team understands that the people making decisions for the project are doing so in good faith, and while they may make a decision the team disagrees with, they have a good reason for doing so.
7. Solve the problems they can, and deal with the ones they can’t – the team understands that problems will occur, no matter what. There is no point in complaining about them, all the team can do is handle them.
8. Clear direction – the team knows where the project has come from, where it is now, and where it is going.
9. Embrace project management – the team understands that project management is about helping them achieve success, not blocking it!
10. Loyalty – members are loyal to the project, to the business, to the team, and to themselves.

What do you think? What have I missed? Which of these aren’t important? Let me know!

Following on from the previous video on the PRINCE2:2009 refresh (New Publications), here is a video in which the PRINCE2 chief examiner, Emma Jones, explains the impact of the refresh on the examinations. The video is from Best Management Practice.

On Wednesday, I told you all how wonderful risk is. Yesterday, I talked about the two different types of risk a project can face, and why a business should be happy to embrace one of them. But should project managers be happy about this type of risk?

Well… it depends. As I said yesterday, the competency type of risk, that involved with making sure you and others have done their job, should be ruthlessly fought. But the other type of risk, the business risk that any project will face, needs to be balanced against the possible rewards.

For a business, this is simple, even if it isn’t easy. You look at the likely rewards if the project is successful, the cost of doing the project, and the chance of the project being successful or, in other words, the riskiness of it. Then, you use a simple calculation to get the expected value – multiply the likely rewards by the probability of success, and if the answer is greater than the cost of the project, go out and do it!

That’s all well and good for the overall business, but what about you, one project manager inside it? This is where it becomes more complicated. And it becomes more complicated because people are much more complex than a business.

As a project manager, you are naturally going to want your project to be a success. But the reasons for wanting the project to be a success are a lot more complicated than the reason a business wants the project to be a success.

A business gets (usually) a clear and obvious financial reward from a successful project. A certain amount of money goes into running the project, and at the end of it, hopefully a larger amount of money comes out as a result. This is pretty much the only concern of the business.

For a project manager, though, it goes beyond that. Yes, you will want to deliver value, and profit, for the business. But you will have other reasons for wanting the project to be a success.

You will want the people on the project to do well in their careers, and a successful project helps that. You will want to do well in your own career! You will have an emotional attachment to the project. There are many reasons why you want the project to be a success.

But there is another side to a project manager’s connection to the project. Yes, we will want it to be a success. But we will also fear it being a failure. And fear of failure can be a very dangerous thing.

We fear having a failed project on our record. We fear a history of failure could hold us back in the future. We fear a loss of prestige. And, worst of all, we fear losing our jobs due to a project failure.

The problem is that we, as people, rather than project managers, have to deal with two risks. There are the project risks, and there are the personal risks. We know how to deal with the project risks, how to evaluate them, mitigate them, remove them, or accept them. But personal risks are a lot more complicated, a lot more difficult for us to deal with.

Let’s face it, no matter how confident we are, the personal costs of a failed project can seem huge. When we fear for our jobs or our future careers if a project fails, is it any wonder we shy away from risky projects? Even if we did the same evaluation as a business, the project manager personally seems to have so much to lose from a failure, and relatively little to gain from a success.

And that makes it rational for us to stay away from risky projects – even though they may be of great benefit to the business!

Now, this is a problem which has to be tackled by the business. After all, they have the most to gain from running riskier projects. So what can be done?

Well, as we’ve seen, the risk versus reward needs to be rebalanced. The project manager fears losing so much, but gains so little from a successful project. This leaves two obvious solutions.

The first one is to greatly increase the possible rewards. Offer huge bonuses, promote a successful project manager, give him or her a share of all the profits.

On the whole, I suspect businesses are unlikely to go this route.

The second one is to greatly reduce the possible losses. Now, this has, I think, more mileage in it. There are simple and inexpensive ways for a business to do this. Here are five examples:

• Don’t just praise success – praise failure. We learn more from failure than success. If the project team has done their job well, but didn’t quite make it, praise them for their efforts.
• Stop saying a project has failed when it hasn’t. If the project team did their job well, but the project still didn’t give the hoped-for result, then praise the project team. The project team can control the output of a project – what is actually produced – but they can’t control the outcome – how that output is received. In other words, if they created the new product that everyone thought the market wanted, but it didn’t sell, they still did their job!
• Stop pointing the finger. Given we know there are risks we can’t control, the business risks that can’t be got rid of, businesses, and the people in them, should stop working so hard to assign blame. Not everything is someone’s fault. Quite often, bad things happen without anyone causing it. Accept it.
• Support project managers. Accept that some things are outside of the control of even the best project managers. If the project has shown areas they are weak in, help them get better. Stop using the result of one complicated, difficult and unique project to predict how the project manager will do in another complicated, difficult and unique project.
• Judge a project manager by project management success, not the project success. Be fair, and only evaluate a project manager based on what is actually in their control.

By taking these and other steps, by working hard to change the culture of the business, they can change the personal risk versus reward calculation for a project manager. Reduce those risks, and get good project managers excited about doing risky projects.

Because risky projects worth doing offer the best reward for businesses, and, in my experience, are a lot more fun to work on for project managers. So, I ask again the question that started all this, I ask it both of project managers and of businesses that run projects – don’t you wish you had riskier projects?

(Image courtesy of afanc. Some rights reserved.)

Yesterday, I told you all how wonderful risk is. But it is fair to say that most of us work very hard to get rid of risk from our projects. Why this difference?

Well, I think it is because there are two broad types of risks in a project. The first type is one that we all should try to reduce. It’s to do with competence, with doing our job well, with checking we are putting the project in the best position to be a success.

The second type of risk is the one I like. It’s to do with the change we are trying to bring about, the effect we are trying to have on the world outside our project. It’s the risks that you can’t get rid of, because they are part of why you are doing the project.

But because as project managers we have to deal with so many risks of the first type, we seem to get stuck in the mindset that risk is bad, that risk must be removed, that we have to play it safe. But trying to play it safe may be the most dangerous thing you can do.

Let’s look at these two types of risk. The first type are risks that we can and should get rid of. If you are creating a new product, of course you’d do market research to find out if there is demand for it. If you are putting in place a new business process, of course you’d talk with users to find out what they want from it.

To put it bluntly, of course you’d do your job. A lot of the risks we can easily get rid of in a project are really around making sure we’ve done our job correctly, and around making sure others in the business have done theirs. So of course we need to be interested in getting rid of these risks.

It’s like climbing Mount Everest. Before you go, you do your research and decide that it’s probably best to pack warm clothes. You may even investigate further and decide a few bottles of oxygen will come in handy. You make the preparations that get rid of the risks that can be got rid of.

But that still leaves the second type of risks. We may know there is a market demand for a new product – but will your product actually be successful? We may know what the users have told us they want from a new process – but will they actually use it?

These are the risks we can’t get rid of. Yes, we can do everything we can to create a product that meets the apparent needs of the marketplace, but we can’t know people will buy it. We can do everything we can to produce a process that is simple and easy to use, but we can’t know users will switch to that from what they already know.

Going back to our Everest metaphor, you can wear cold weather gear, carry oxygen, and make sure all the equipment you could need is available. But at some point you actually have to go out and climb the mountain, facing the dangers of the cold, the thin air, the strong winds, and the avalanches.

In other words, before you set off on your adventure, you make sure you have taken all the sensible precautions – and then you set off to face the danger anyway.

And there’s actually a good reason for that. Setting off to face the danger only makes sense if the rewards for overcoming it are significant. Those rewards, whether they are financial, social, personal, whatever, are the reason for facing the danger – the value of that payoff is weighed against the danger in achieving it.

In the same way, we weigh up the possible rewards of a successful project – be it increased profit, reduced costs, and so on – against what we are risking if the project fails – wasted money and time, lost opportunities, and so on.

So risk is good – at least, the right type of risk is. If there is a high risk project that we can do cheaply, then we definitely should. The concept of expected value (here’s an example of expected value in poker) comes into play here – though the probabilities involved with success and failure of projects tend to be harder to estimate!

For a business running a lot of projects, they can almost treat their projects as a gamble – they will stake a certain amount of ‘value’ (money and time) to try and achieve a larger amount of ‘value’. If the probability stacks up that you are making a profit, then do the project – accept the risk, embrace it.

Now, all of this makes sense if we are a business looking at risk, and trying to find a sensible way to deal with it. But what about just us, as project managers? It’s all very well knowing the second type of risk is different for the business, but is it different for us? Well, it all depends – and that’s what I’ll talk about tomorrow.

(Image courtesy of psd. Some rights reserved.)