4.1 Pre-project and the initiation stage
In the beginning, someone has an idea or a need. This may result from new business objectives, responding to competitive pressures, changes in legislation, or a recommendation in a report or an audit. The trigger for the project could be almost anything. In PRINCE2, this trigger is called a project mandate. The project mandate is provided by the commissioning organization (corporate or programme management) and can vary in form from a verbal instruction to a well-defined and justified project definition.
Prior to the activity to scope the project appropriately, it is important to verify that the project is worthwhile and viable. Such activities are covered by the process Starting up a Project, which culminates in the production of a project brief and a stage plan for project initiation.
The project board reviews the project brief and decides whether to initiate the project, and states the levels of authority to be delegated to the project manager for the initiation stage.
4.1.2 Initiation stage
Once there is a decision to go ahead with the project, it needs to be planned in sufficient detail. Funding needs to be obtained and controls should be defined to ensure that the project proceeds in accordance with the wishes of those people paying for the project and those who will make use of what the project delivers. The planning, establishment of the project management strategies and controls, development of a robust business case, and a means of reviewing benefits are covered by the Initiating a Project process. Also, during the initiation stage, the Managing a Stage Boundary process is used to plan the next stage.
The initiation stage culminates in the production of the project initiation documentation, which is reviewed by the project board to decide whether to authorize the project. As the contents of the project initiation documentation are likely to change throughout the project, this version of the project initiation documentation is preserved as input for later performance reviews.
4.1.3 How pre-project and the initiation stage would typically look when using agile
188.8.131.52 Plan, monitor and control
- Project-level planning focuses on sets of features and intended releases.
- There is strong engagement from all levels of the project management team in the planning and estimation activities.
- Stage-level planning is carried out collaboratively with the customer in order to most accurately meet their needs and achieve the most benefit.
- Plans are timeboxed in some form – this could be in the form of a specific time interval (e.g. 2-weekly) or it could be flow-based over a longer period – and these plans would be created at a time (i.e. ‘just in time’) and a level of detail that is appropriate to allow for uncertainties.
A generic term that is widely used to describe something a product does, or the way in which a product does something. A feature can be at any level of detail (e.g. it is waterproof, it makes a tone when switched off) and can be related to a specific requirement, user story or epic. Another similar term is ‘function’.
- The use of self-organizing teams and people-centric values such as empowerment may be explicitly defined as part of the project approach.
- Mandating or recommending the use of specific agile approaches such as Scrum and/or Kanban may be explicitly defined as part of the project approach.
- The project initiation documentation (PID) may have been created collaboratively in a workshop in order to disseminate information to the project team quickly and more accurately and with a high level of engagement and ownership.
- Information on what constitutes a minimum viable product (MVP) is defined (see section 184.108.40.206).
- The trigger for the project may have come from a product roadmap.
- There may be an indication of the appropriate use of agile for the project.
- The project product description is likely to have been defined to show which requirements are mandatory and which are not.
- The project product description purpose is likely to be outcome-based (focusing on the delivery of value) as opposed to the delivery of a specific solution.
- Product descriptions have initially been captured using user stories (or as epics), although it will be expected that more will be discovered throughout this phase and beyond.
- The business case is defined in a flexible way to allow for the amount of what is being delivered (and its value) to change to a degree during the project.
- The benefits review plan focuses on how to deliver value regularly and as early as possible. This will involve describing what products will be delivered when, and what value will be enabled.
- The PID is likely to be a less formal document, as some of the baseline information is visible in the form of an information radiator (see section 15.4.2).
- The PID will be less detailed in certain sections (e.g. product descriptions), since the solution is not necessarily defined at the start. It is a living document that evolves, although it will still need to be baselined.
- The communication management strategy will have been created using the concept of ‘minimum viability’ where communication approaches, and particularly documentation, are assessed on the basis of the minimum acceptable level that does not compromise the quality level of the final product.
- See also explanations of tailoring the project brief and PID in section 23.1.
Definition: User story
A tool used to write a requirement in the form of who, what and why.
A high-level definition of a requirement that has not yet been sufficiently refined or understood. Eventually, an epic will be refined and broken down into several user stories/requirements.
Definition: Information radiator
A general term used to describe the use of walls or boards containing information that can be readily accessed by people working on the project. It can contain any information, although it would typically show such things as work to do and how work is progressing.