PRINCE2 7 small project
The PRINCE2 Manual contains detailed advice and guidance on how to perform tailoring PRINCE2, but rather than go through that here, I want to approach tailoring from a minimalist approach that would suit a small project.
The strategy here would be to relate to each process and theme against the project requirements and the environment within which it must run. I can only give very general advice here since every project is unique buffer at least it will be a starting point to make decisions for tailoring PRINCE2 to a typical average small project.
Tailoring PRINCE2 – The Starting up and Initiating a project processes.
There is always the scope here for merging the starting up a project and initiating a project processes when tailoring PRINCE2, however care should be taken when thinking about the management deliverables and key decision points.
Let us remind ourselves of the SU products:
The project mandate acts as the trigger here.
The project brief which contains the outline business case, the user’s quality expectations, the acceptance criteria, the project approach and the project product description.
You can easily see how all these products could merge seamlessly into the creation of the project initiation documentation when tailoring PRINCE2 at the end of the initiation stage. But remember that the project management team needs to be designed and appointed within the SU process.
I strongly recommend that once the project management team are in place that’s a draft project product description document is created to help everyone understand what must be done.
The second and final management product is a plan for the initiation stage.
Tailoring PRINCE2 – the management products of IP:
- The project initiation documentation
- The benefits management approach
- The second stage plan
If both of the above processes were to be merged then a plan for the initiation stage may not be necessary since in essence we are moving from the project mandate through to the creation of the project initiation documentation.
However, you would still need some for the plan for these two combined processes, so we’ll have set this would replace the initiation stage plan by combining it with those three project activities within SU.
While staying on the topic of plans, it may be that a small projects needs only one delivery stage; in which case the project plan within the PID will double for the second stage plan (since there is only one stage remaining for the whole of the project).
It would be very tempting to run SU and IP as a mini Agile project because merging and simplifying SU and IP would make its intuitive and suitable for a small dedicated team – I feel a ‘sprint’ coming on here!
Tailoring PRINCE2 – combined management products for merging and simplifying SU and IP:
So let’s use these diagrams as a basis for simplifying the deliverables down to the irreducible core:
The project mandate could be and verbal instruction leading to the appointment of one or two individuals filling all of the project board roles – while for the executive and senior user, and the second for the senior supplier roles.
Because it’s a solid simple project the project board decide to carry out their own project assurance, and wherever possible key decision points will either be an informal meeting of foreign exchange of emails.
The project manager is also appointed and will carry out their own administration and the team manager roles. I will assume here that the specialist team may only be one individual and it may be sensible because of the informal nature of the project to appoint them here at the same time.
Tailoring PRINCE2 7 – Plans
The project manager needs to prepare the SU and IP plan which may only be and hand-drawn Gantt chart within a word document clarifying the simple schedule, and budget and resources applied to the point of the project initiation documentation assembly.
This should be sent to the project board for review and agreement – and possibly via email.
As a small project, the project manager decides to merge and the daily log, risk and issue registers into one simple ring binder/diary, where entries will be made by hand.
The word document is started called the project initiation documentation. However, the only information that is initially entered is the project brief (containing a rudimentary project definition, business case and project approach). The project product description is drafted and also included within this document.
Draft versions of the project brief are sent to the project board for review and agreement – and possibly via email.
Even small projects after tailoring PRINCE2 will use ‘management by exception’ and therefore tolerance must be set and agreed.
There is a tendency for people to over complicate documentation and my advice is that they could be just adequate for their purpose and no more.
To give a few examples;
the project brief and a only be two sheets of paper
the project approach merely stating the obvious approach to be used and why
the customers quality expectations may also be simple as that is a product name delivered by a certain date
the acceptance criteria may be a visual check to ensure, for example, that the physical dimensions are met all that for the device can be turned on and a simple function performed.
Tailoring PRINCE2 7 – The Business Case
The business case may only be a simple statement of why the project and hence the end-product must proceed and a rudimentary agreement about who is to provide the funding.
One could argue that for a minimalist project, the benefits review plan is not needed and simply replaced by a request for all the customer or operational manager who is to own the end product in its operational life.
The project product description may be a all that is needed for a small simple project and the that there is no need for any product descriptions. The quality log would now need only one entry which is formal acceptance of the end-product (this too would be included within the ring binder mentioned above).
The remainder of the project initiation documentation are the four approach documents which of course explained how risk, configuration management, issues, and communication are to be handled.
As these sections are added, they too, may only consist of one or two paragraphs for a small simple project.
The project plan will therefore detail the remaining products (one?), activities and resources required, along with a simple schedule. Indeed, at its simplest, the schedule may only be a list of the activities to be carried out leading up to the milestone of the end-product draft ready, acceptance criteria checked, approved and authorized.
As you can see from above the project learn is the same as the second and final stage plan in the project example I have given you.
Tailoring PRINCE2 – planning.
A really small project will only need to be informally planned.
Since there is only one product in the example above, then there is no need for a product breakdown structure nor a product flow diagram (and as I have already said there is no need for further product descriptions).
The project/stage plan will therefore only need the tasks and the resources added.
Even though it is a simple small project do not forget to carry out risk management to ensure appropriate responses are included and agree what how monitoring and control will be carried out.
