Something big is going to happen with PRINCE2 very soon now. The old version is undergoing an update, or as those responsible call it, a “radical evolution”. And it looks like this could be very interesting.

PRINCE2 is often attacked for being overly bureaucratic, or too complicated, or needing too much documentation. This update, which will be release on 16th June 2009, is tackling these complaints head on.

The biggest change has to be the introduction of a set of seven principles for PRINCE2:

• Business justification – A PRINCE2 project has continued business justification
• Learn from experience – PRINCE2 project teams learn from previous experience (lessons are sought, recorded and acted upon throughout the life of the project)
• Roles & responsibilities – A PRINCE2 project has defined and agreed roles and responsibilities with an organisation structure that engages the business, user and supplier stakeholder interests
• Manage by stages – A PRINCE2 project is planned, monitored and controlled on a stage by stage basis
• Manage by exception – A PRINCE2 project has defined tolerances for each project objective to establish limits of delegated authority
• Product focus – A PRINCE2 project focuses on the definition and delivery of products, in particular their quality requirements
• Tailor – PRINCE2 is tailored to suit the project’s size, environment,
  complexity, importance, capability and risk

This is an important development for PRINCE2. Not because the principles are new – they’re not. They’re the same principles that good PRINCE2 Practitioners have been using all along. But this is the first time that they have been set down and expressed as part of the methodology.

There is more information in Andy Murray’s presentation on the PRINCE2 update. Andy is the Lead Author for the update, and you can read more on the PRINCE2: 2009 Author Blog.

We all know that the purpose of a project is to deliver some sort of benefit to the business. For many projects, the real benefit is that the end result is being sold. But what about projects that are purely internal? What about projects that are trying to change the business?

I’ve run across a few of these in my time. One thing they all seem to have in common is that they are driven from the top – they are designed to deliver a benefit to the senior management. That’s not surprising – senior management are the only ones who can commit to spending money on them!

But that also causes problems for a project manager. When the project is being put together, it’s always a good idea to make sure that there are also benefits to the people who are going to be affected by the changes. Without their support, the project is very unlikely to be successful.

Let’s look at an example. Quite a while ago, I was working at a fairly large and bureaucratic public body. Their whole reason for existing was to pay for and support projects to support and grow the local economy – business support, infrastructure building, that sort of thing.

Naturally, this meant they needed a lot of information. This information was going to be particularly useful to the senior management who had to report upwards to government. But getting this information could be difficult. So naturally, a knowledge management solution was proposed.

Now, this solution was going to use simple techniques – tagging of all documents with keywords, imposing a defined directory structure, and so on. For the senior management, the promised benefits were great: they would be able to drill down into any area, and all the information would naturally flow into a dashboard view.

But the benefits for the other users were minimal, at best. They already had developed their own directory structures. They knew where all the information was. The problem senior management had simply wasn’t a problem for them.

But senior management’s solution, well, that became a huge problem for the staff! Suddenly they had to start adding keywords before they could save their files, they had to try and fit their documents into a structure they couldn’t control, and so on. There was now a new barrier to them doing their work, without any benefit to them!

When the poor soul put in charge of this project ran the concept past me, I was sceptical. It seemed fairly clear the project was going to be horrendously unpopular, and difficult to get finished due to the resistance it would encounter. But my colleague didn’t want to say anything to senior management – he believed that the staff could be made to use the system through coercion, rather than choice.

Maybe he’s right – but you’re not going to get the real benefits out of a system people don’t want to use. Keywords would be selected poorly, missing out a number of useful ones. The directory structure would get filled with files in the wrong places. The expected benefits wouldn’t be delivered.

Not surprisingly, the project hit difficulties almost as soon as it was started, with resistance from all sides, and pressure from above to get it implemented quickly. It dragged on for far too long, before finally it was scaled back, and the business actually talked to staff about what they wanted to get out of the system.

Always remember that to implement an internal change project, you need to make sure you deliver benefit to everyone affected, if possible. If it isn’t possible, minimise the pain as much as it can be, and realise it is going to cause you problems and delay.

What do you think? What barriers do you run across when implementing change? How do you get the buy-in of the various groups? Let me know!

So, the latest Standish Report is out. The figures in it are depressingly familiar. More projects are failing. Only about a third of projects are succeeding – on time, on budget, on scope.

Now, there are a lot of reasons to be dubious about the CHAOS report statistics. The categories are fairly vague, and don’t appear to look in any depth about whether (for example) a project being cancelled was a good project management decision or not. The methodology they have chosen for the study is unclear. So as an absolute measure, they’re not up to much.

But because the report has been produced for a number of years now, with, presumably, the same methodology, we can get some value from using them as a relative measure – are things getting worse, or are they getting better?

Well, in fact, the figures for project success seem to be holding roughly level over the past few years. There has been an improvement from the original report back in 1994, which suggested a success rate of 16%, but we seem to have been hovering around the 30% mark for many years now.

And this is worrying, considering the amount of effort that has gone into developing better and stronger project management methodologies, techniques, tools and so forth. Taken at face value, the CHAOS report would suggest that we needn’t have bothered!

That suggests a couple of possibilities. The first one is that as a group, project managers have simply got it wrong. Perhaps the tools we are using to manage projects, the methodologies and techniques, simply have no effect. All we have done is made our own lives harder, but at least we haven’t damaged the projects we work on.

I’m not really inclined to believe this possibility. (Though, of course, as a project manager, I have a vested interest in saying a methodology is needed…) The reason I’m not convinced is that the methodologies have been developed from the experiences of many project managers. They are finding new ideas that work for them in their projects – they are seeing an improvement in the project management process by using these techniques.

The other possibility is the one I am interested in. It’s loosely based on the Red Queen Hypothesis. What if project management is getting better, but projects are also getting more complicated? What if we’re running just to keep still?

Think about the IT projects you’ve been involved with over the years. Have they become more complicated? Have our ideas of what we can achieve become bigger? Do projects now pull in many more aspects of the business than they used to?

I’m not even entirely sure how you would test this idea. (Always a hallmark of a less than perfect hypothesis…) It would require some way of evaluating the complexity of a project against a baseline – a baseline that needs to stay steady as the world changes around it, and as new technologies may make some of the assumptions in the baseline wildly incorrect. Now that would be a study worth doing.

I genuinely don’t know. My personal feeling is that, yes, IT departments are willing to take on more complicated projects these days. But I’m wary of drawing a conclusion from my own, purely anecdotal, experience. Others may have had very different experiences.

But certainly when we think of how much more we can do with IT than we used to be able, of the added complexities of what it can achieve, there is a certain attraction to the Red Queen idea. But maybe it’s just wishful thinking and self-justification on the part of a project manager…

What do you think? Are we getting better? Are projects getting more complicated? Or have we just overloaded ourselves with methodologies we should dump? Let me know!

Projects are temporary, by their very nature. That means all of us are going to have to close down our projects. But this is part of project management that is too often neglected. So what are we actually trying to achieve?

When a project approaches the end of its work (or when a decision is made that it should be ended early) we need to begin preparing to close it down. The basic idea is that every project, and the business, benefits from having a controlled and organised shut down.

By this point, the project will have delivered on its objectives. The products that were supposed to be produced should be finished, and ready to go. The aims of the project should have been met.

This means we need to:

• Confirm we have actually met the project’s objectives
• Alert those areas we drew resource from that their people are coming back
• Formally hand the product over to the business (or whoever is using it)
• Set out any follow-on actions to be carried out by the business after the project is complete (e.g. measure the benefits after a period of time to see if they meet expectations)
• Get confirmation from the Executive that the project can finish
• Archive the project documents

I also like to make sure the team as a whole gets together and identifies any lessons the business can learn from the project – what went well, what didn’t, and so on.

That’s a quick look at project closure – what else do you do? Do you have a formal closure at all, or do you just turn out the lights as you leave? Let me know!

I’ve been giving some thought recently as to what lies behind the work we do as project managers. Too often we get caught up in the tools and techniques, the how of what we do, without looking at the concepts and ideas behind it, the why of what we do.

So far, I’ve suggested that:

• The primary aim of every project is to benefit the business.
• Project management is about making the project environment as stable as possible. What is possible varies.
• Project management needs both awareness and control of the project. Control is impossible without awareness.
• The project manager can control time taken, money spent, and scope fulfilled – but only within set limits.
• The project team is a project’s most important resource. Guard them well, to allow them to get one with their tasks.

Today I want to look at something related to the last concept. We already know we need to protect the project team, and make sure they can get on with the tasks assigned to them. But this also means we need to get on with the tasks assigned to us, the job of project management. The concept I am looking at today is: The project manager doesn’t do the project work. The project manager does the project managing.

Project management is hard work. On all but very small projects, it is a full-time job. And that means you really shouldn’t be being pulled off to do project work.

I’m not saying that project managers don’t have the skills to do some of the project work. Many of us will have worked our way up to project management through project work – we are used to it, and we understand it.

But if a project manager is doing the work, then he isn’t managing the project! We need to remember where our skills lie. Often we will get dragged into doing the project work, but this is a failure of project management (usually on the organisation’s behalf, not the project manager’s), not an essential part of it.

Make sure you are using appropriate resources to get the work done. The project manager is rarely an appropriate resource! And that gives us a project management concept: The project manager doesn’t do the project work. The project manager does the project managing.

(Having said that, I have ended up doing project work for the vast majority of projects I have worked on. This isn’t a good thing, but it is the real world. You should aim to avoid this if at all possible.)

Those of you who follow me on Twitter will know this already, but yesterday I passed my PRINCE2 Practitioner Re-registration exam. PRINCE2 has two levels of qualification, Foundation and Practitioner. A Foundation pass lasts forever, and you need to have one before you can take the Practitioner exam. A Practitioner pass needs to be renewed every five years if you want to keep describing yourself as, well, a PRINCE2 Practitioner.

Given that here in the UK PRINCE2 is the de facto standard for project management qualifications, I’m happy to have passed the re-registration exam – it means I can still compete for contract jobs!

But… I have to admit, I wasn’t that thrilled with the exam. More particularly, I wasn’t pleased with the format of it, because I think it reflects a worrying trend from the owners of PRINCE2.

Way back in the mists of time, when I first got qualified, the Foundation exam was a multiple choice exam, which it still is, and the Practitioner exam was essay based, which it no longer is. Now, the Practitioner exam is an “objective testing examination”. Which, as far as I can tell, means it is multiple choice. Complicated multiple choice, granted, but multiple choice all the same.

I’ll admit it, I have a terrible prejudice against multiple choice exams. The last one I had done was the PRINCE2 Foundation exam. Essentially, this was just a memory exercise – it checked you knew what the various PRINCE2 terms were. Which was fine, given the level it was aimed at – it was a first step on the qualifications ladder for project support staff, and others who needed to show they had a basic knowledge of PRINCE2.

But I’ve always thought that to test real understanding of a subject, you need to send someone off with little guidance, to navigate their own way to the solution. And that’s why I liked the essay style Practitioner exam I originally took – the demonstration of understanding was all in your own hands.

That’s not to say that the re-registration exam I took didn’t test understanding. The format of the questions was such that it did require you to have both a knowledge of the PRINCE2 methodology, and an understanding of the processes within it.

However, what it didn’t test was an understanding of the principles of project management, of when it was appropriate to use the various processes the methodology uses, and even more importantly, when it was appropriate not to.

Now, a lot of you will probably be thinking, and quite reasonably, that PRINCE2 is a methodology, so an exam to be registered as a Practitioner of it should only test understanding of the methodology itself. It’s a persuasive argument, but not one I accept.

PRINCE2 is in the interesting position of being the de facto project management standard in the UK and much of Europe. This means, I believe, that it not only should try to spread itself as a methodology, but also to spread an understanding of what project management is, the principles behind it. In my experience, PMI just isn’t well established enough over here to do that job.

To me, the key to working with and using PRINCE2 effectively is a thorough understanding of the principles behind in. Maybe I was lucky in the way I was taught it originally, but the emphasis of the trainers was very much on why certain processes and procedures were used, not how to use them. And the reason for this was that they continually stressed the need to ensure you were applying PRINCE2 in a flexible and light touch way.

I can practically hear the howls from the Agileists out there at the suggestion PRINCE2 can ever be light touch or even flexible. But it really can. If you just took the PRINCE2 manual and tried to apply everything in there to a project, you’d kill all but the largest projects straight away. But PRINCE2 is designed to be scalable – and that’s where it gets tricky.

Because the only way a methodology can be scalable is by using the judgement of the people applying it, by using the experience, understanding, and plain common sense of the project manager to decide what is needed for any particular project. And the ability to do that is something that is very hard to test.

I’d also say it is impossible to test in any sort of multiple choice exam.

And that’s why I preferred the essay based exam. By having the ability to write an open-ended answer, the person being tested can not only demonstrate an understanding of the processes, but also explain how he would apply it in the specific scenario given. He can, in short, demonstrate his abilities as a project manager, not as a PRINCE2 regurgitation tool.

Now, I can understand why the people who look after PRINCE2 would want to move to this “objective testing” exam format. If nothing else, it’s an awful lot cheaper to grade a paper when all you have to do is scan the answer sheet for the right marks in the right places (or, in my case, just have it all done online). And it moves it towards the style used in many other qualification exams.

But I think they are ultimately storing up a huge problem for themselves. There is already a body of opinion out there which thinks PRINCE2 is simply awful, too heavyweight, too inflexible, too much of a pain. I’d argue the real problem these people have come up against is poor project management, poor project managers, where a methodology has been applied without much understanding of the principles behind it.

Worryingly, this style of examination seems, to me, to be encouraging more of this type of project manager. All it will produce is someone who understands the processes very well, but doesn’t really understand the reasons for them. Essay based exams are much harder to grade, but the reason for that is that they need to have a real live human being doing it. And that ‘problem’, of needing a human being, seems to me to be, in fact, the greatest strength of them.

Because a human being is able to read the essay and get a real feel for whether the person writing has understood what is actually happening in the scenario, has understood more than the right cookie cutter to pick up from the PRINCE2 tool box. And being able to assess that seems to me to be incredibly valuable.

If it becomes the common view that all a Practitioner qualified project manager brings you is someone who will blindly apply a methodology with no thought as to whether it is appropriate, all qualified Practitioners will suffer. In short, I worry that this style of exam is, ultimately, going to devalue the PRINCE2 Practitioner qualification.

What do you think? Am I just being snobbish about multiple choice? Am I wrong in thinking a PRINCE2 Practitioner qualification should be about more than memorising the PRINCE2 manual? Is PRINCE2 already seen as too heavy-handed a methodology to ever use? Do you think PMI is in a position in Europe to take up the mantle of spreading awareness of the principles of project management?

I’ve been giving some thought recently as to what lies behind the work we do as project managers. Too often we get caught up in the tools and techniques, the how of what we do, without looking at the concepts and ideas behind it, the why of what we do.

So far, I’ve suggested that:

• The primary aim of every project is to benefit the business.
• Project management is about making the project environment as stable as possible. What is possible varies.
• Project management needs both awareness and control of the project. Control is impossible without awareness.
• The project manager can control time taken, money spent, and scope fulfilled – but only within set limits.

Today, I want to look at what is controlled, the resources that a project manager uses to carry out the work of the project, and particularly the most important resource. The concept I am looking at today is: The project team is a project’s most important resource. Guard them well, to allow them to get on with their tasks.

We’ve already seen that the project manager can, within limits, control time taken, money spent, and scope fulfilled. But how are they controlled? Essentially, we are looking at the control of the resources that a project has. A project manager will have a certain amount of time and money to achieve a certain amount of scope.

But the key resource, the one which effects all of the project, is, of course, the project team, the people who are actually doing the work. In them, the three areas of control are combined.

Each of the team members has only a limited amount of time they can work on the project. Each of the team members will need to be paid for. And each of the team members will have different skills, and different abilities.

Project management, then, needs to be able to guide the work of the team in the right way. The project manager must allocate the work to the right individuals, giving guidance as to how long to spend on it, what quality is needed, and, if expenditure other than that on the team member’s salary is needed, how much can be spent.

So, project management needs control of the resources allocated to the project, and that includes the project team. But, unlike money and time, team members can easily be distracted and pulled off to work on something else. But a project manager needs to retain control.

This leads us to another project management concept: The project team is a project’s most important resource. Guard them well, to allow them to get on with their tasks.

I’ve been giving some thought recently as to what lies behind the work we do as project managers. Too often we get caught up in the tools and techniques, the how of what we do, without looking at the concepts and ideas behind it, the why of what we do.

So far, I’ve suggested that:

• The primary aim of every project is to benefit the business.
• Project management is about making the project environment as stable as possible. What is possible varies.
• Project management needs both awareness and control of the project. Control is impossible without awareness.

But how can we control a project? What tools do we have available to us to exert control? What can we do to effect the path we are taking?

In general, we have only three areas we can work with in project management. We can vary how long we spend on a task, how much money we spend on it, and what the finished output of that task actually is.

So, for example, we could spend a week on a task, or a year. We could spend pennies, or millions. We could make something which just about works, or a gold-plated solution.

By working with these areas, we can try to influence how the project progresses. But remember, a project manager would not have ultimate control over any of these areas. They can only vary what is done to a limited extent.

A project manager can’t decide to spend a year on a task if the project is supposed to be finished in 6 months. A task which is supposed to cost pennies can not have millions spent on it on the say-so of the project manager. And the minimum quality required is set by someone outside, not by the project manager.

This brings us to the next project management concept: The project manager can control time taken, money spent, and scope fulfilled – but only within set limits.

Recently, I put together a little series on the social media tools that project managers could use to help manage their teams and their projects. I’ve distilled some of this into a presentation, which you can see here:

You can get more information about any of the tools and techniques at The Social Media Project Manager – Roundup page. Hope you find it useful!

Estimating how much work there is in the project, and how long each part of it will take, is a vital skill in project management. You can’t sensibly manage a project without having at least some idea of how long you think each piece of work will take!

But, of course, it’s practically impossible to sit down at the start of a project and pronounce when it is going to finish. Issues crop up, the environment changes, tasks take longer than you thought, and so on.

I’ve already written about the scheduling process for a project. This should help you arrive at a list of tasks. These are your starting point for estimating.

Because you have a list of tasks, you are able to begin estimating the length each one will take. Immediately, this is more useful than trying to estimate the length of the entire project, or major sections of it. Bringing your thinking down to the level of specific tasks makes it much easier to mentally grab hold of the work, and have a sensible idea of how much time is involved.

(This also works as a sanity check on your task list – if you can’t visualise what has to be done to complete a task, maybe you need to break it down a little more.)

Remember, you are not necessarily the expert on how long the tasks will take. You have a project team who will actually be doing the majority of the work – use their expertise and their knowledge of both the work and themselves to come up with estimates of how long each task will take.

And don’t forget: you’ll have these estimates wrong. I’ve been using the word “estimate” in this post, but don’t forget the simpler version – “guess”. Yes, you are using experience and knowledge to try and make it a reasonable guess, but it still is one.

It’s a fact of project management life that at the start of a project the estimates will be off. The reason I suggest only scheduling in detail for a few weeks in advance is that you can learn from how far off your estimates are. The accuracy of your estimates should improve as the project goes on.

What about you? What techniques do you use for estimating? Let me know!