Clarifying Some Key Points
This section contains a few notes on some of the items in the checklist, to help you revise. Here I focus on a few of the areas which can be the source of misunderstanding or concern. If you scan a section and you’re confident that you already know that point well, move on to the next one.
Getting an overview of Starting Up a Project
You can get lost in the detail a bit when studying the different parts of PRINCE2. In case you’re not absolutely clear on what Start Up is about, then in a nutshell it:
Happens before the project, and happens quickly
Sketches out the proposed project
Checks that the proposed project looks justified
Filters out a bad project idea early, rather than rushing into full planning (Initiation) straight away only to discover later on that it’s a bad idea and the planning work was all a waste of time and resources
Appoints people to project management team roles to make the decision on whether to initiate the project, and decides who will control the project if it does go forward
Going fast with Start Up
Start Up should happen rapidly. You may not even do all of the Start Up process for a particular project. The whole thrust of the process is to check that the project looks worthwhile, on the sketchy information currently available, and that it’s worth investing in the much more detailed work of Initiation (the full planning).
Two specific phrases in the PRINCE2 manual spell out this sketchy nature of Start Up and the main purpose of the process. The first is that the process ‘prevents poorly conceived projects from ever being initiated’. That, perhaps, is wishful thinking, but it certainly helps reinforce the idea of checking out a potential project before diving into the detailed, and more expensive, work of Initiation. The second phrase that’s significant in the manual is that Start Up is about doing the ‘minimum necessary’ to decide whether to go forward to Initiation. In other words, you don’t have to do everything in the process on every project. [Manual 12.1]
Being clear that Start Up isn’t a stage
It’s a common mistake to think Starting Up a Project is a stage. It isn’t. It comes before the project and so before any project stages. For that reason there’s no Stage Plan for it. The PRINCE2 lifecycle is longer than the project lifecycle. PRINCE2 finishes when the project finishes but it starts earlier than the project, and that earlier part is Start Up.
Figure 4-1 shows the position of Start Up relative to the project, and may help you get clear on this point if you still find it a bit confusing.
Figure 4-1: Start Up in relation to the project.
Knowing your brief from your PID
When you’re learning PRINCE2, sometimes the products all seem to swim around in your head, and it’s easy to get confused, particularly where headings are similar. There’s a similarity between the brief and the Project Initiation Documentation (PID), and you need to be clear on what each is.
A helpful analogy is with having a house built for you. As a highly paid PRINCE2 expert (well, soon anyway), if you go to an architect to ask for your new house to be designed, the architect will sketch out an idea first. When you’ve approved the sketch and agreed that that’s pretty much what you want for the house, the architect will go away and produce detailed plans which conform to planning and building regulations. The architect doesn’t start with full drawings then, but with a sketch. That’s the difference in concept between the brief, which is a ‘sketch’ of the project, and the PID, which is the equivalent of the scale drawings. Both the sketch and the scale drawings will show a kitchen. It’s just that the scale drawings show it in much more detail than the sketch did. The detailed drawings will also show more things, such as the electrical circuits. In the same way, some of the content of the PID is the same as in the brief, but it’s in more detail, and there are some new things which were just too detailed for a sketch.
Understanding nesting – the brief as a folder
Another common cause of confusion is how management products fit together and what higher-level products they fit into. For example, where does the Business Case come? Does it belong in the brief or is it in the PID? The answer is that the Business Case is in both, but at different times in its development. When the Business Case is first written, it’s sketchy (the Outline Business Case). After the brief is approved, that Business Case is worked into full detail, at which point it goes into the PID. The PID, including the Business Case inside it, is then maintained throughout the project. In fact, the minimum that the Business Case can be updated is at the end of each stage; in the process Managing a Stage Boundary there’s an activity ‘Update the Business Case’.
Going back to how products fit together, it may help you to think of both the Project Brief and the PID as folders containing other things.
Being clear on roles and job descriptions
PRINCE2 stresses that appointments are to roles rather than to jobs because one person may have more than role, and most roles can be shared by more than one person. Both of these facts bring great flexibility. For example, one person may be both the Project Manager and a team member. This person is running the project but also doing some of the work of the project. The Senior User role on the Project Board may be shared between two people whose staff are both affected by the project. One Senior User comes from Department A and the other from Department B in the organisation. The allocation of roles can then be backed up with job or role descriptions. So, a job description may say that one person on the project is covering two roles or part of a role.
The full detail of roles and responsibilities is in the Organization theme. Don’t worry about this detail too much if you haven’t yet learned about that theme, because it will make more sense when you have.