8.3 Summary of tailoring guidance for the PRINCE2 themes
PRINCE2 uses themes to describe aspects of project management that must be addressed continually. It is essential to use all of the seven themes. Table 8.1 provides a summary of guidance where particular areas of understanding may be required for each theme.
|Theme||Overview of the tailoring required and further considerations|
Although no changes are required to this theme, it may contain more information (and possibly emphasis) on the tolerances around benefits with respect to priorities, timescales and the amount of product being delivered. This business case could show the amount of product being delivered in the form of a best-case, a worst-case and an expected-case scenario in relation to the amount of the final product that may be delivered or flexed.
It may be appropriate to explicitly define what would constitute a minimum viable product (MVP), as well as some indication of priorities within the overall scope and related quality criteria.
When creating a business case, it is essential to have an understanding of how the incremental delivery of a product and the value associated with it could impact project viability (positively or negatively) and also the ability to achieve the early delivery of some benefits.
Where there is a high level of uncertainty the business case should be developed very quickly and the assumptions tested rapidly. This approach could be described as ‘taking a leap of faith’.
Although no changes are required to this theme as defined in PRINCE2, additional delivery-level roles may need to be added, and the most common agile roles should be mapped appropriately to the roles of the project management team structure.
Understanding is required of:
The full and uncompromised use of management by exception is essential to enable PRINCE2 and agile to be combined, in order to empower the project management team and enable it to self-organize within clearly defined boundaries.
It is important to understand the difference between scope and quality when defining customer quality expectations, acceptance criteria, product descriptions, quality criteria and quality tolerances. They need to be defined in such a way that flexing what is being delivered does not compromise the fitness for purpose of any product, or ultimately the final product. Further to this, carefully differentiating functional from non-functional requirements is important, as this can help with respect to prioritization.
The use of agile concepts and techniques such as the definition of ‘done’ and the definition of ‘ready’ can be used to define quality criteria and acceptance criteria.
The frequency of quality checking (in the form of reviews or tests) will have a significant impact on how a project is planned, as this will affect the iterative and incremental delivery of the project’s products and how they are released.
Although no changes are required with this theme, many agile techniques and approaches exist in this area. They focus on the effort related to features (e.g. sprint planning) and often appear in an informal, low-tech, visible format such as a simple list or backlog.
Planning is often done empirically.
Agile typically looks at how much can be produced in a fixed timeframe such as a sprint or a release (or how much value can be delivered). This is often shown at the start in the form of a burn chart that can then be tracked.
This is in contrast to creating milestones representing how long something will take and showing this on a Gantt chart, as this is of limited value. Gantt charts may be of value at the higher levels of plan but they should be synchronized to the agile way of working and should avoid the duplication of information that is being held in the form of backlogs.
The agile way of working addresses many risk areas such as avoiding too much detail at the start of a project (as it will not be fully understood at this point). However, agile comes with its own set of potential risks and these need to be proactively managed (e.g. ensuring that customer engagement is continual and that customer representatives are correctly empowered).
Many agile techniques address risks, for example daily stand-up meetings, frequent delivery of products, frequent use reviews, customer interaction and empowered teams organizing themselves to deliver the right thing at the right time.
Although no changes are needed to this theme, the agile way of working embraces change and responds to it. The PRINCE2 approach to change control needs to allow for this and helps to create a more accurate final product.
The appropriate definition of product descriptions, quality criteria, quality tolerances and work packages is important. They can be defined in such a way as to allow for change, while at the same time creating a clearly defined baseline that can prevent a change to the very purpose of a product going undetected.
A change authority may still be appropriate but is unlikely to function at the delivery level unless it carries out its duties informally, and the change authority needs to understand how detailed change is perceived and addressed in agile.
A change budget is unlikely to exist, as the agile way of working uses the prioritization of what is being delivered as contingency.
Configuration management will need to be set up in a way that also helps to embrace change, as it may happen frequently.
Similarly to the Plans theme, many agile techniques apply in this area where the emphasis is on tracking what is being delivered in the form of such things as velocity, lead times or value. This is as opposed to tracking time and cost, which are not suitable as a measure of a project’s progress. Tolerances would be set in accordance with this.
Tracking progress will depend on the situation and what people need information on. If it is within a sprint, then burn-up or burn-down charts may suffice (see section 15.4.1). If it is across releases, then showing the value accrued and how this relates to the business case may be more appropriate.
The frequent delivery of products that meet the appropriate acceptance criteria/quality criteria is the primary source of information with respect to progress and provides the basis for forecasting future progress.
Table 8.1 Things to consider when tailoring the PRINCE2 themes to PRINCE2 Agile
Planning poker is a technique used to estimate effort or the relative size of development goals. Each member of the development group selects one card from a set of numbered cards and places it face down on a table. The cards are revealed, and the estimates are then discussed.
A description of the rate of progress a team is making. For example, if a team is completing 20 user stories per week, then this is their velocity and it can be used to empirically forecast their future rate of progress (assuming that the conditions remain the same).