17.3 PRINCE2 Agile guidance on Starting up a Project and Initiating a Project
In PRINCE2 it is important that a project gets off to a good start with the appropriate amount of upfront work. Not only that but this upfront work is typically broken down into two parts. Most upfront work done in some agile environments only concerns getting ready for delivery. PRINCE2 provides more rigour to this work by putting more structure around what ‘being ready’ means (during Initiating a Project), and also making sure it is worth getting ready in the first place (during Starting up a Project).
Upfront work can be regarded as unnecessary to a degree by some in the agile community as it is seen as being ‘predictive’ and not ‘emergent’. PRINCE2 is predictive to a degree but can be very emergent if required (e.g. by reducing the length and formality of the initiation stage). However, any PRINCE2 project needs to be justified and has to be viable from the start. Fundamentally, part of this upfront work must answer the ‘why?’ question in the form of a business case (i.e. Why are we doing this project?). One important reason for knowing this is so that the project manager (and perhaps anyone involved on the project) can tell when it needs to be stopped before the planned end date.
A widely used term that has more than one definition but in general terms refers to situations where there are high degrees of uncertainty (e.g. with product innovation) and the product being developed will significantly disrupt (intentionally or accidentally) the existing environment or marketplace (e.g. 3D printing).
Lean Startup is often cited as demonstrating how agile can work when faced with high levels of uncertainty, and there are parallels between growing a small company (often using ‘disruptive’ technologies) and running a challenging project. Even dynamic ground-breaking start-ups need to justify coming into existence to investors and need to be held to account at funding reviews from time to time.
Collecting enough information means that a lot of areas need to be looked at because they can all impact the business case in one form or another (e.g. risks, organizational structure, quality planning, communication planning and how the project is tailored).
How this information is presented depends on the needs of the project and the project board. Typically this may be in a document but it could be delivered along with a face-to-face presentation. Alternatively, most, if not all, of this information could be visible on the walls of a team room using lots of visualization.
As part of these two processes (Starting up a Project and Initiating a Project), the suitability of using agile needs to be assessed. The use of agile will bring many advantages but it will also bring with it a set of risks if agile is used inappropriately. This is assessed using the Agilometer (see Chapter 24).
17.3.1 Further guidance that may also be appropriate
The project product description (and the business case) should be defined with more focus on how the output can be described so that the outcomes and benefits can be adjusted during the project. If the project product description just focuses on the intended solution then the supplier is more likely to focus on this than the value it intends to deliver. This in turn may impact contractual arrangements made before delivery commences (e.g. how much the style will reflect the agile way of working).
The high-level and intermediate-level requirements are likely to be held as a list which may take the form of a spreadsheet or a low-tech list on a wall and may be referred to as a backlog.
An early definition of ‘done’ is likely to be part of the quality management strategy or an existing one that has been used from a previous project.
The mapping of existing agile roles to the PRINCE2 roles will be defined and understood (e.g. how the team manager role will be fulfilled).
Understanding is required of agile terminology such as project chartering, discovery phase, visioning, sprint zero and product roadmaps.
Agile suitability needs to be assessed by looking at what agile ways of working exist or need to exist, and what their respective advantages and disadvantages are (e.g. is co-locating the team a good idea or will it be too expensive and undermine the business case?)
Workshops are likely to be used to collaboratively create and understand deliverables.
Levels of uncertainty need to be explicitly stated as these may affect the choice of agile techniques such as the use of prototyping, spikes or experiments and the choice of how long to make timeboxes. Sometimes a project may be taking place in a very volatile context or with vague requirements. At other times the context could be more stable and there is less need for prototypes, spikes and experiments.
The level of formality will be decided with respect to such things as control, communication and planning (e.g. how will progress be tracked – on a wall or using a tool?).
If there are high levels of uncertainty then this phase is likely to be very short.
An assessment should be made of the impact of frequent releases on areas such as how quality will be managed and how the frequent delivery of products (or products in differing states) will take place (e.g. whether they will always go directly into operational use).
Table 17.1 shows PRINCE2 activities for start up and initiation and how they relate to agile artefacts and events (all product description references for PRINCE2 products are located in Appendix A).
|PRINCE2 activities and products||Applicable agile artefacts and events|
No common equivalent
Table 17.1 PRINCE2 Agile activities for start up and initiation
17.3.2 How to ...
There are many behaviours, concepts, frameworks and techniques that are used in agile and referenced throughout this manual. Table 17.2 provides cross-references to some of the most relevant for use during Starting up a Project and Initiating a Project.
|Chapter and section references|
Use concepts from Lean Startup
Identifying risks to the agile way of working with the Agilometer
Use the project product description
Section 23.1, A.21
Define a business case in an agile context
Know what is covered by sprint zero (iteration zero or (the) discovery (phase))
Run workshops to kick off a project
Assess different levels of uncertainty with Cynefin
Use more informal communication channels
Plan the frequency of releases
Create and manage a product backlog
Sections 2.2, 25.6, Appendix H
Write a definition of ‘done’
Section 11.4, Appendix H
Map agile roles to PRINCE2 roles and describe the considerations to take into account
Communicate on a project using agile
Plan and control a PRINCE2 project using agile
Chapters 12, 15
Tailor any of the PRINCE2 management products
Table 17.2 Relevant agile guidance for Starting up a Project and Initiating a Project