Colin's blog

I have written a description and pieces of advice on how to pass the PRINCE2 Foundation exam. This is free to anyone who would like it. Just reply to this blog or email me at colin@colinbentley.co.uk and I will email a copy to you.

I recently did a webinar for IT Governance about using PRINCE2 for small projects. It seemed to go down well and I gave out several templates and examples of case studies that should be useful.

One of the main reasons for the Starting up a Project process is that the project mandate often lacks essential information, hence the need to turn it into a Project Brief. Hey! Don't throw that cigarette packet away. It may be my new project mandate!

In Sept 2010 in a good Tech Republic blog, Patrick Gray wrote "Most of us have seen the famous “three levers” diagram of project management. The story goes that one can move any two of the levers (scope, timeline, or cost) and the other will move independently of the others. For example you could increase the scope of a project and decrease the timeline, but your costs will rapidly spiral up. Or if you cut costs and keep your scope constant, the timeline will increase. The three levers are a nice conceptual tool, but they imply CIOs have more control over their projects than usually happens in practice. For most CIOs, scope is the only factor within their control once a project starts, and the one that should be most jealously guarded.

While cost management, rigorous tracking of deliverables and documentation, and tight resource management are all admirable, many projects take a dangerously cavalier attitude towards scope. I have seen businesses that require signed authorization and an escort to the locked supply closet for a fresh pen, yet allow a junior person from an implementation firm to commit the project to several weeks of additional work (and tens of thousands of dollars) without batting an eye. ...."
I thought the newer thinking was that there was a rectangle with four elements, time, cost, scope and quality. Moving any one of them will affect at least one other and may affect all three others. I would make two points for PRINCE2. If you are using PRINCE2 correctly, there is no way in which 'a junior person' can commit the project to any extra work. All changes must go through the change procedure, and the impact analysis will show to the Change Authority what the effect would be on cost, time, scope quality, benefits and tolerances - all this before a decision is made. If the junior tries to carry out the extra work without telling anyone, this would soon be clear by the Team Manager reviewing the time and cost used.

Another corner of the rectangle is quality. I'm sure most of us know that the first thing that workers turn to when time gets short is cutting the amount of time spent on quality checking. PRINCE2 builds quality and its checking into a project from day one, and the Quality Register will soon identify any effort to slip an untested product under the wire. Go with PRINCE2. You know it makes sense!

Do we need an Exception Report? – remember, no-one says it has to be written. Should we advise the Project Board that one or more of their tolerance limits is under threat? Should we do this as soon as we know about it? Of course we should. Have a look at the information that PRINCE2 suggests should be made available to the Project Board when an exception situation arises. It all looks sensible and necessary.

So where do we look for this bureaucracy – at End Stage Reports? Surely we have to submit to the Project Board an assessment of how we performed in the current stage, what the Project Plan, the Business Case and the risk situation now look like before it will think of approving the next Stage Plan?

So, the next question is do we need a Project Brief AND Project Initiation Documentation? Is this not duplication? If you consider a five year project and the extra information that is created in the Project Initiation Documentation, I don’t believe it is duplication. The Project Brief information forms part of the Project Initiation Documentation, but we add lots of good things – controls, strategies, a refined Business Case and Risk Register etc. If you have a small project or work in an environment with lots of small projects, you may think of combining the processes, Starting up a Project and Initiating a Project. This would appear on the face of it to cut out the Project Brief, but the information is still needed for the Project Initiation Documentation.

To start a project PRINCE2 suggests that a Project Brief is put together from a Project Mandate. Presumably the ‘too bureaucratic’ lobby is happy that whoever wants a project should provide a Project Mandate – or whatever name they wish to give to the information about what they want the project to do, etc. Notice that I didn’t say ‘write’. Many Project Mandates have been word of mouth. So isn’t it necessary to ensure that all the information that you need is there before you dive in? I’m not saying that every bit of specification should be known before a project starts. The Product Description of the Project Brief says what information should be available and my experience says that this is sensible. Remember, if the Project Mandate has all the information you need, then, as the manual says, it becomes the Project Brief without any further work. But you do need to check that it is all there. Often it isn’t.

You may not like the idea of a Quality Log. Presumably you are not against checking the quality of products? You can keep details of the planned quality check in your Gantt chart, but that doesn’t tell you who the chairperson is to be or who will take what role, what the results were, how many errors were found, when the product was finally signed off. You should be able to find such information by sifting through several documents (assuming that you have been ‘bureaucratic’ enough to file them away in some order) but isn’t this inefficient – dare I say too bureaucratic? You may not like the format of the Quality Log as suggested by PRINCE2, but the philosophy seems right. So design your own – not for the purpose of creating lots of documentation, but in order to retrieve, use and disseminate the information. If something is suggested as an entry in the log that you don’t need, get rid of it. But just be sure that it isn’t a useful piece of information that you should be using.

With regard to the Issue Log, I have been in too may projects where there was no standard form (i.e. definition of the set of information required when submitting an issue) and no central collection point not to appreciate the need for the Issue Log. How else will you ensure that everyone can see what everyone else has raised? What easier way is there to check that impact analysis has been done, that action is being taken, that you know who is working on it, what the result was? I don't think it needs to be over-complicated, but you do need a list of issues, date, who raised it, who is dealing with it and what the status is. You could take the two 'who' questions and put that info on the actual issue form. Knowing and tracking issues is part of a project's health check for the pm.

Let’s have a look at other aspects of this ‘bureaucracy’, the registers. PRINCE2 suggests three; a Risk Register, an Issue Register and a Quality Register. Risks are surely so important that we need to collect them together? If nothing else, it gives us a quick-to-read summary of how many serious risks we have, what we need to be communicating to the Project Board for their assessments. And a condensed view of all risks may reveal that two or more risks or risk actions that are proposed might together represent a new risk or create an unacceptable situation. With regard to the Issue Register, I have been in too may projects where there was no standard form (i.e. definition of the set of information required when submitting an issue) and no central collection point not to appreciate the need for the Issue Register. How else will you ensure that everyone can see what everyone else has raised?

What easier way is there to check that impact analysis has been done, that action is being taken, that you know who is working on it, what the result was? You may not like the idea of a Quality Register. Presumably you are not against checking the quality of products? You can keep details of the planned quality check in your Gantt chart, but that doesn’t tell you who the chairperson is to be or who will take what role, what the results were, how many errors were found, when the product was finally signed off. You should be able to find such information by sifting through several documents (assuming that you have been ‘bureaucratic’ enough to file them away in some order) but isn’t this inefficient – dare I say too bureaucratic? You may not like the format of the Quality Register as suggested by PRINCE2, but the philosophy seems right. So design your own – not for the purpose of creating lots of documentation, but in order to retrieve, use and disseminate the information. If something is suggested as an entry in the log that you don’t need, get rid of it. But just be sure that it isn’t a useful piece of information that you should be using.

In the 2009 revision of the PRINCE2 manual OGC decided to change Log to Register. The reason given for this was that a log suggests an unstructured record, whereas a register describes a structured one.

In my next blog we will look at how PRINCE2 suggests that a Project Brief is put together.