^ [[3.3 The PM2-Agile Model]] # 3.3.1 Lifecycle Every project has a beginning and an end. The lifecycle of a project has an identifiable start and end, which can be associated with a time scale. Each **project phase** represents a period of time during the life of the project where **similar types of activities are executed** (e.g. planning type activities ‘peak’ in terms of effort during the planning phase, etc.). Projects pass through four distinct phases, as described by PM2. ![[3.3.1 PM2 project phases.png]] The project **lifecycle** **includes all events and activities** from the point of inception of the idea/need through to the final completion of the project. Note that the interfaces between phases are seldomly separated clearly – **activities related to a specific phase** (e.g. planning activities) **continue to be executed during the subsequent phase(s)** (e.g. during the executing phase). ![[3.3.1 The PM2 project lifecycle – overlapping of phase-related activities.png]] The characteristics of **some of these phases (e.g. planning) may not be as tangible at the level of the Agile team** as they are at the overall project level. However, project phases still exist and a **common understanding** between both the project team members and other project stakeholders should be fostered. The overall sequential character follows the concept that the project has a defined beginning and ending date. Therefore, project activities must start with initiating and planning, then lead to implementation, and finally end with acceptance, transitioning and closing. ==However, team-level tasks do not have a sequential character within iterations: planning, analysing, coding, testing and reviewing are done in every iteration.== Some Agile practices may also include a special time slot for planning and reviewing. The **PM2-Agile has iterative cycles at three levels** – **daily cycles, iterations, and releases**. ==Regardless of their duration==, these cycles follow what is known as the PM2-**Agile ‘CIR’ rhythm (Coordinate, Implement, Review)**. ![[3.3.1 The PM2-Agile CIR rhythm.png]] The **combination of the high-level phases and lower level iteration cycles** results in an effort/time curve with **greater overlap between activities** over time, spanning multiple phases of the project. ![[3.3.1 The PM2 project lifecycle with activity iterations – extensive overlapping of phase-related activities.png]] At the **beginning** of the project, a key concern is to understand what to build by determining an overall vision and identifying the stakeholders and their success criteria. Because there is a lot of uncertainty at this stage, **PM2-Agile acknowledges the need to identify and declare all the assumptions that will guide the identification of the possible system capabilities**. Declaring assumptions and not treating them as facts, gives the stakeholders and the team the opportunity to ask questions and discuss about the problems and the best way to solve them. **The goal is to ascertain at least one solution and then assess whether it is technically feasible based on those assumptions.** This is done by identifying the ==several hypothesis that must be tested== in order to ==validate the declared assumptions and mitigate the uncertainty risks as soon as possible==. It is also critical to understand the high-level estimates of costs, schedules, and risks associated with the development aspect of the project. Including these estimates in the project-level estimates and planning artefacts ensures that they are considered. **As the project progresses**, the focus of the domain-specific activities shifts towards **incrementally building the solution**. As the team progresses towards **testing the hypotheses that validate the declared assumptions, a better understanding is achieved of what has to be done and how**. PM2-Agile supports these actions by incorporating a ==benefit hypothesis for each feature that targets the validation of an assumption==. As the **development progresses throughout the different iterations**, **requirements are continuously revisited and clarified**. Both technical and non-technical risks are also regularly addressed. This iterative and incremental nature of PM2-Agile creates a **sustainable and paced delivery of value to the organisation**. This value is measured rigorously using a measuring and **learning framework**. This framework captures proper and relevant data from an **MVP** (or subsequent versions) and uses it as a (validated) learning mechanism **to enable decision-making**. As the project nears **completion**, the focus shifts to ensuring that the **solution is well-integrated into the overall project deliverables**. Furthermore, it must contribute to the accrual of the benefits desired by the organisation. There is also an emphasis to ensure that the organisation can assume ownership and is accountable for the evolution and maintenance of the information system when the project closes. A summary representation of the key Agile activities and artefacts for each project phase is shown below. A detailed presentation of the Agile artefacts is provided in section 7, ‘Artefacts’. Note that **artefacts are delivered incrementally and iteratively** following the Agile principles. ![[3.3.1 An overview of the PM2-Agile activities and artefacts in each phase.png]] From an Agile perspective, **projects may have several releases** as a result of the incremental progress achieved in one or more iterations. Additionally, the **output of each iteration is the result of the incremental progress achieved every day**. This multilevel approach ==spans the several phases== of the project as foreseen in PM2 and at all three levels, value is delivered and feedback is collected. ![[3.3.1 From project phases to daily cycles.png]] Next: - [[3.3.2 Iterations]] | [[3.3.3 Releases]] - [[3.4 The PM2-Agile Mindsets]]