Colin's blog

ARE THERE 3 OR 4 LEVERS?

Colin — Fri, 07 Jan 2011 22:24:45 +0000

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!

IS PRINCE2 TOO BUREAUCRATIC PART 8

Colin — Mon, 27 Dec 2010 13:42:29 +0000

Is there too much documentation at the end of a project? Should we not plan to check if the company got the expected benefits? Is it wrong to discuss with the Project Board how well/poorly the Project Manager did what was defined in the Project Initiation Documentation? Should we not pass on any lessons learned to other projects? Should we not document any unfinished business? Project Managers may be anxious to move on to the next ‘challenge’ (or piece of income), but it’s hardly being bureaucratic to say that you must tie up the loose ends and bring the project to a controlled close. There are too many unfinished projects where the Project Manager has moved on to avoid the ‘dirty’ parts of actually finishing a project.

Maybe the idea of bureaucracy stems from the PRINCE2 organisation structure – or, rather, the incorrect idea that every project has to have at least one person for every role. However many times the manual makes the point about the option to combine roles where sensible, there are still those who immediately envisage a large overhead of Team Managers, Project Support and Project Assurance staff, etc. If the size and criticality of the project needs it, then we may need (and use) all these people. But in many other cases we can combine roles. It’s just a matter of common sense.

IS PRINCE2 TOO BUREAUCRATIC? PART 7

Colin — Tue, 21 Dec 2010 15:04:55 +0000

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?

IS PRINCE2 TOO BUREAUCRATIC PART 6

Colin — Wed, 15 Dec 2010 18:46:23 +0000

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.

IS PRINCE2 TOO BUREAUCRATIC PART 5

Colin — Tue, 07 Dec 2010 13:15:18 +0000

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.

IS PRINCE2 TOO BUREAUCRATIC? PART 4

Colin — Fri, 12 Nov 2010 09:38:30 +0000

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.

IS PRINCE2 TOO BEAUROCRATIC PART 3

Colin — Thu, 28 Oct 2010 14:48:57 +0000

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.

IS PRINCE2 TOO BUREAUCRATIC? Part 2

Colin — Sat, 23 Oct 2010 11:00:43 +0000

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.

IS PRINCE2 TOO BUREAUCRATIC? Part 1

Colin — Tue, 05 Oct 2010 09:46:56 +0000

How often do we hear the moan, “PRINCE2 is OK, but it’s too bureaucratic”. Recently I even heard a comment that PRINCE2 turned the Project Manager into little more than a scribe for the Project Board. In my opinion, people who say these things don’t really understand the method or are subscribers to the ‘just do it’ school of project management.

Why do we get these complaints? Usually, it is because people look at the number of reports in PRINCE2 and imagine themselves sitting down, writing all these reports while the project is dissolving into chaos behind them. They haven’t appreciated the flexibility and scalability of the method. Throughout the PRINCE2 manual there are reminders that, according to the circumstances of the project, a ‘report’ may be informal, verbal, not necessarily a handful of written pages. For example, PRINCE2 takes an anti-bureaucratic stance and says “don’t have regular progress meetings with the Project Board; agree a Stage Plan and then send Highlight Reports unless things are forecast to go badly wrong”. The content of the Highlight Report and the medium used to convey it (telephone call?) are chosen by the Project Board, so surely this follows the ‘let’s get on with the job with minimum interruptions’ principle? If you were a Project Board member having approved a two or three month stage, would you not want some feedback on progress during the stage – without the pain of arranging to spend – what, half a day? – at a progress meeting? As far as I am concerned, PRINCE2 offers the most efficient way of combining maximised work time with good communications.

The whole concept of tolerance is designed to let the various levels of management ‘get on with the job’ – “Here are the limits. Get on with the job unless you forecast that you will go outside these”.

In my next blog let’s start looking at other aspects of this ‘bureaucracy’, the logs.