PRINCE2 Agile 2016
Previous Section   Next Section

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.

Definition: Disruptive

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
  • Appoint the executive and the project manager:
    • Create daily log, A.7
  • Event(s):
    • Project kick-off
  • Capture previous lessons:
    • Create lessons log, A.14
  • Event(s):
    • (Previous) project/release retrospectives
  • Design and appoint the project management team:
    • Update the daily log, A.7
    • Create project management team role descriptions
    • Create project management team structure
  • Event(s):
    • Project kick-off
  • Prepare the outline business case:
    • Create the outline business case, A.2
    • Create the project product description, A.21
    • Update the daily log, A.7
  • Artefacts:
    • Vision
  • Event(s):
    • Project kick-off
  • Select the project approach and assemble the project brief:
    • Create/select the project approach
    • Create additional role descriptions
    • Assemble project brief, A.19
    • Update the daily log, A.7
  • Artefacts:
    • Vision
    • Product backlog
  • Event(s):
    • Project kick-off
  • Plan the initiation stage:
    • Create the stage plan, A.16
    • Update the daily log, A.7

No common equivalent

  • Prepare the risk management strategy:
    • Create the risk management strategy, A.24
    • Create and populate the risk register, A.25
  • Event(s):
    • Project kick-off
  • Prepare the configuration management strategy:
    • Create the configuration management strategy, A.6
    • Create the initial configuration item records, A.5
    • Create and populate the issue register, A.12
  • Event(s):
    • Project kick-off
  • Prepare the quality management strategy:
    • Create the quality management strategy, A.22
    • Create the quality register, A.23
  • Artefacts:
    • Vision
    • Definition of ‘done’
  • Event(s):
    • Project kick-off
  • Prepare the communication management strategy:
    • Create the communication management strategy, A.4
  • Event(s):
    • Project kick-off
  • Set up project controls:
    • Create project controls
    • Update role descriptions
    • Update project management team structure
  • Artefact(s):
    • Information radiators
  • Event(s):
    • Project kick-off
    • Release planning
  • Create the project plan:
    • Create the project plan, A.16
    • Create product descriptions, A.17
    • Create and update the configuration item records, A.5
    • Update the project management team structure
    • Update role descriptions
  • Artefacts:
    • Vision
    • Product backlog
  • Event(s):
    • Project kick-off
    • Release planning
  • Refine the business case:
    • Create the benefits review plan, A.1
    • Create the detailed business case, A.2
  • Artefacts:
    • Vision
    • Product backlog
    • Release backlog
  • Event(s):
    • Project kick-off
    • Release planning
  • Assemble the project initiation documentation (PID):
    • Assemble the PID, A.20
  • Event(s):
    • Project kick-off

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

Define outcomes

Section 9.4

Use concepts from Lean Startup

Section 20.4.2

Identifying risks to the agile way of working with the Agilometer

Chapter 24

Use the project product description

Section 23.1, A.21

Define a business case in an agile context

Chapter 9

Know what is covered by sprint zero (iteration zero or (the) discovery (phase))

Section 9.2

Run workshops to kick off a project

Section 26.4.1

Assess different levels of uncertainty with Cynefin

Section 17.4.1

Use more informal communication channels

Chapter 26

Plan the frequency of releases

Chapter 27

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

Section 10.4

Communicate on a project using agile

Chapter 26

Plan and control a PRINCE2 project using agile

Chapters 12, 15

Tailor any of the PRINCE2 management products

Chapter 23

Table 17.2 Relevant agile guidance for Starting up a Project and Initiating a Project

Previous Section   Next Section

Collapse