The Artist Still Know as PRINCE
PRINCE – PRojects In Controlled Environments – is a project management framework originally designed for large government projects demanding detailed scrutiny and oversight. It was quickly adopted as a standard in industry and commerce for it’s rigour and is widely used today.
It features an evidential process of documentation, change control and sign-off. It can also be used to develop product-based planning.
It has been stretched, expanded and extended over the years to include many more documents, control points and design considerations.
PRINCE provides an excellent grounding for project planning and control, as do many similar frameworks.
There are two relevant issues, however.
If you strictly follow the full PRINCE II method for even the simplest project you will generate twenty-six documents, in strict order, with all of the associated review and sign-off stages. That imposes a project management overhead of significant size and cost. Strict adherence to PRINCE in the public sector can sometimes cost more than the actual project output.
This is why some clever folks invented PRINCE for Small Projects, a cut-down version with some optional stages and outputs, to try to make the project management overhead more appropriate to the size and scale of the individual project.
Employing PRINCE in any of it’s versions still does not guarantee success. There are many projects run under PRINCE that run late, over budget or deliver well below the stated requirements from the outset. Here's the sticking point: the project management framework is worthless without discipline and control.
Back to the Case Study
In my case study, a major UK utility company was part of an industry-wide process of de-regulation. The government regulator dictated the use of strict PRINCE project management. The utility company created project teams for each of the six major areas of the programme. Each team set about writing it’s individual Project Initiation Document, a key deliverable for sign-off and a baseline for measuring success throughout the project life cycle.
Problem number one: the Project Initiation Document for the Operations Team was rejected every time it was presented to the Stakeholder Board for sign-off. The project manager continued to revise and re-present the Project Initiation Document for the next nine months. It remained without sign-off for the duration of my time on the project.
Meanwhile, the entire programme moved on, as the de-regulation date was a hard, immovable, industry-wide deadline set in a significant government policy.
Problem number two: PRINCE II has a detailed process for change control in order to quantify the impact of changes in terms of time, cost and quality. This compares the proposed change against the Project Initiation Document, the thing that describes the baseline project scope, which is agreed and signed-off at the beginning of the project. You assess and quantify all changes to scope, which are either agreed or rejected.
If you don’t have an agreed scope as your baseline, how do you assess the impact of changes? Changes to what, exactly?
Problem three: the Operations Team continued major software development, as did the other five teams, all working toward an integrated
The other five teams continued to raise change requests that affected the inputs and/or outputs of the Operations Team. Which had no formally agreed scope to assess changes against.
The Stake-holder Board failed to understand how formal change control fails without a finalised Project Initiation Document.
Let’s just say the overall project ran late, over budget and below the quality threshold.
This was not a failure of the PRINCE project management framework, but a failure of the Project Manager and Stakeholder Board to exercise the proper discipline and control to make it work.
The clothes do not make the man. The method does not make the project. RC