How we change what others think, feel, believe and do
The Definition phase takes preparing for delivering the project from knowing what is wanted and having an outline of what will be delivered to a clear specification of what will be delivered such that a confident estimate can be made as the time, cost and quality of delivery.
For small and clear projects, Gate 1 and Gate 2 may be passed at the same time, as the deliverables can be specified early and in sufficient detail to make a clear commitment on quality, time and cost. For projects where a more detailed investigation is required before commitments can be made, the Definition phase provides extra time to enable this to happen.
Separate what and how
In Prince 2 terms, the documents delivered at Gate 2 collectively form the PID (Project Initiation Document). It is recommended here that this stage separate the ‘what’ of the specification from the ‘how’ of the plan. This is because the ‘what’, once agreed, changes slowly, whereas the ‘how’ of the plan may vary more often.
Note that the documentation for Gate 2 may vary significantly, depending on the project, how large and complex it is, and consequently the communication and assurance needed. In smaller projects, the only documents that may be needed at this stage are an extended Project Brief and Timeline. Risk Registers and Issue Logs are commonly required. The most likely additional document is a Specification. A more detailed Project Plan and specification change control are more likely to be required in larger projects. Quality and Commitment plans detail plans in these areas.
Activities in this stage include further investigation that allows a detailed specification of what will be delivered.
Investigation in Definition typically continues initial investigations from Discovery into further detail. The goal in all cases is to identify what exactly needs to be done in future work and hence the effort required and the risk involved.
Particularly when software is being written or used, this phase may include further technical exploration to determine the detail of what technical solution should be implemented. This may include:
Where a process is to be changed, further investigations may be appropriate to understand the size of the task and the changes to be made. Activities might thus include:
The project may have significant effects on a range of stakeholders, who in turn may have a significant effect on the project. This clearly needs managing and the social investigation may thus:
Specification details the ‘what’ of the deliverables to be created and deployed in the project and is typically in a separate document. If contractors are being used, this will form a core part of the contract with them. The deliverable may include a wide range of items, including software systems, process changes, training courses, service changes and so on.
Note that if incremental development is being used, the specification may initially be incomplete and expanded with each evolution.
The Outline Design describes the overall architecture of the solution, for example showing how databases and networks will be used, the overall content of training sessions, etc. It provides the ‘big picture’ which is useful for discussion, communication and agreement. For this purpose it typically makes good use of diagrams and charts. It also has the major purpose of being the basis on which more detailed design is completed. The outline design may thus include:
The Functional Specification details exactly how the deliverable operates. It describes the product or solution in full detail, explaining how it functions, both from the user’s viewpoint and with regard to its inner workings. It may thus include:
The functionality of the solution is the major ‘what’ that is delivered and leads to the desired outcomes and benefits.
The success or failure of development of the specified solution is described by a set of quality criteria which can be used later to assess the delivered solution and hence determine whether or not it is acceptable. These criteria thus form a significant check at Gate 3, before the solution is deployed. The primary criteria are related to the delivery of outputs that lead to desired outcomes and benefits. Other criteria stem from these. An acronym for a common set of criteria that can be used is FLURPS, which stands for:
It is important when defining quality criteria that they can feasibly be assessed. For example a criteria of ‘satisfying all users’ does not say what ‘satisfying’ means and assessment of ‘all’ might be a very expensive task.
Solution development is a series of transformations from requirements to specification to design to final solution, including other interpretations along the way. At each transformation there is opportunity for error as some necessary things get left out, unwanted things get added and other things are misunderstood and distorted. Thus gaps form between what is intended and what gets specified, designed and created. Testing is the process of assessing these gaps and determining where transformation errors occur.
Testing thus is a process that happens throughout design and development. Test requirements describe what is to be tested and may include:
Testing is described in further detail in the section on Development.
Depending on the size of the project, Definition documentation may vary greatly. At minimum, this includes an update of the Project Brief and Project Timeline.
Project Brief update
The Project Brief, as originated in the Discovery phase is updated at this stage, to include any further detail or changes, for example to outputs required, timescales, approach and so on.
For smaller projects, many of the items that would be in separate documents for a larger project may be included in this Brief. For a larger project, the separate documents may be referenced from the belief.
The Specification describes in detail that which will be delivered.
The Specification may form the basis of a contract with an external supplier or consultancy who will be engaged to develop and/or deliver it. It also is used in quality assurance to verify that which is built is that which was required and agreed. Where outsourcing and contracts are being used, then sufficient time needs to be included in the project plan for negotiations, tendering and so on.
In a software development project, for example, the specification could include screen layouts, database schema and algorithms. In training design, it will include the overall methods of training and module contents.
The Specification may also include aspects of delivery, such as maintenance. ‘Wire-frame’ mock-ups may also be used within specifications, for example where the HTML for web pages is developed but without any back-end systems (thus you can click on links but nothing as yet happens).
For smaller projects, the Specification may be included in the revised Project Brief.
The Project Plan details the approach being used in the Development and Delivery phases of the project. This may include details of key project decisions, resources, assumptions made, agreements and collaborations and so on. It also should include consideration of project governance, particularly when it varies from the standard Vanguard governance, including meetings, reporting and metrics. Where the projects uses other documents, such as project meeting minutes, then the templates and process for these may be included. Required conformance to any set of other standards may be noted, such as organisational reporting and documentation standards.
For smaller projects, this detail may be included in the revised Project Brief.
The Quality Plan describes the methods and timescales for assuring quality across the project, including testing of deliverables and incorporation of feedback and learning into what is being done.
Quality has been defined as ‘fitness for purpose’ and ‘conforming to requirements’. The ultimate test of quality is customer satisfaction and delight. Assurance of that beforehand typically means testing of products and processes against specifications (and specifications before that against requirements). Depending on the project, user acceptance testing (UAT) may be used as a part of the handover process into ‘business as usual’.
Quality assurance is a form of risk management, acting to identify and prevent risks of non-conformance occurring. It typically includes assessment of potential and actual gaps between what is wanted and what is delivered, and acting to address these. Testing checks one thing (often a ‘product’) against a specification of some kind, identifying non-conformance. Quality assurance includes planning, recording and management of testing. Quality assurance work also starts early in the project, for example testing the Specification against Requirements.
For medium-sized projects, the Quality Plan may be included in the Project Plan.
In many change projects the most difficult part of the process is in the Delivery phase, where the outputs are deployed to a wider group of people, some of whom may be unwilling to participate in this activity, either because they do not want to participate or because operational activities are taking priority.
It is common in change projects to include communications, and these may well form an important part of the Commitment Plan. It is easy to communicate when this simply means telling people about what is happening. The problem is that what is often required is a commitment to specific action. The Commitment Plan thus needs to include activities that will persuade people to participate in and support the deployed change.
An important part of commitment management is in the availability of an escalation process, should people not be participating as required. Typically this requires the support of a senior manager who will change priorities and mandate collaboration for those who would otherwise not participate.
For medium-sized projects, the Commitment Plan may be included in the Project Plan. For smaller projects, this may be included in the updated Project Brief.
The detail of who does what and when should be produced as a separate item that can be constantly updated to reflect reality and the latest forecasts. This plan is then used to track project progress and manage issues such as slippages. Whilst a separate overall plan document may change little, the timeline will usually change frequently.
For smaller projects, where interdependencies are not complex and where there are a limited number of tasks in the plan, this can be adequately done using a spreadsheet. For larger projects, where there are such complexities as multiple people, inter-dependent tasks and the need to calculate the critical path, then MSProject may be more useful.
Depending on the formality of the project, there may be more or less documents that record and communicate other governance activities. As appropriate, these should be managed and stored.
And the big