2020-07-10 Waterfall? incremental? iterative? agile? hybrid? Various project lifecycle options and alternatives are available. But what exactly do we mean with each one of them? What are their key characteristics?
The most effective way to structure the schedule of a project is to divide it in a number of phases (or stages). This way, it is easier to allocate the deliverables that need to be created and thus the needed resources per each stage. A project phase is a time division that is used to group the deliverables planned and the resources needed. The sum of all the phases of a project is called the project lifecycle.
In general, there are two broad types of project phases: the so-called management phases that are used in order to better monitor and control the project, and the so-called specialist, delivery, implementation or development phases that are used in order to group together the work that needs to be done and the corresponding resources. .
The management phases of a project are more-or-less standardized in the project literature (e.g. PMBOK Guide, PRINCE2 Manual etc). The following diagram presents the typical management phases of a project:
Figure 1: The typical management phases of every project
Before any project is started, there is some work that takes place, and this work is of course not part of the project: for example, an organization might be trying to sell the project to a customer; a director might be trying to secure funding for some improvements in their department; a needs analysis is being performed etc… These are examples of activities that would be included in the pre-project part. .
Before a project can be begin, someone in the organization must approve it. Depending on the size, budget, importance etc of the project, this approval might have the form of a more a less formal Business Case. If the business case is approved, then the project has reached the Ready-for-Planning milestone. .
The idea is of course that an organization cannot start a project unless there is some understanding of the scope of the project, how the project will be implemented, what are the needed resources, risks, quality considerations etc… The project manager will prepare the project management plan of the project, and if this plan is approved, then the Ready-for-Implementation milestone is reached. .
The project then starts, the needed resources are acquired, the work is allocated, and the project implementation activities start. The project manager monitors and controls the project in order to ensure that the scope of the project is being delivered as planned. After the customer has accepted the project, the Ready-for-Closing milestone is reached. .
This final part of the project includes the review of the project, the documentation and sharing of the lessons learned, the improvement proposals and the administrative closure of the project. .
The key characteristic of the management phases of a project as described above is that they are sequential: at the appropriate milestones, an approval from the relevant authority must be given in order to proceed. Therefore, two management phases of the project can never run concurrently. Of course, especially within the implementation phase, additional management phases can be defined if needed: for example, if we have a quite big and long project. .
As far as the specialist phases are concerned, various lifecycle options and alternatives are available. But what we mean with each one of them? What are their key characteristics?
The key factors that are considered in order to chose the appropriate project lifecycle include the knowledge and confidence that we have regarding the project scope, the stability of the requirements and the risk of the project and its environment. The general principle is that if we have a clear scope, stable requirements, significant prior experience and know-how, and controlled risk, we can very much define the project delivery steps and their sequence at the beginning of the project. On the contrary, if the scope is unclear, the requirements are expected to change, we do not have enough knowledge or experience, and if the risk is significant, then the delivery steps, their sequence and content will be defined throughout the project lifecycle.
The most traditional project lifecycle is the so-called waterfall or plan-driven lifecycle. This is the best approach when the scope is clear and fixed, and when can feel confident that the project can be very much planned in detail already from its beginning. This is the lifecycle that is used in most construction projects: assuming that the design is approved, the construction can be planned in a very high level of detail.
Figure 2: This is an example of a waterfall lifecycle
In some projects, we cannot or we do not want to define the scope of the project already from the start of the project. In these cases, even if we have a good idea of the project scope already from the beginning, the implementation details are defined throughout the project. This approach helps to maximize the learning from each project phase, so that the next phases are planned in a better way. The project scope is gradually built through a number of iterations, as it is depicted in the following diagram:
Figure 3: This is an example of an iterative lifecycle with three delivery phases (iterations).
Another approach can be used when we want to start delivering small but complete parts of the project as early as possible. In the example of the following diagram, each one of the three delivery phases ends with the delivery of some part (an “increment”) of the scope. This is called an incremental lifecycle:
Figure 4: This is an example of an incremental lifecycle with three delivery phases. Note that at the end of each delivery phase some scope is delivered.
Finally, for the projects where the scope is expected to change throughout the project lifecycle (either by choice or by need!), and it also makes sense to deliver the scope in small pieces, the so-called agile lifecycle can be used. Of course, agile has not only a type of lifecycle, but mostly a mindset. There are other parts in our site that deal with agile in general, and you can even get certified by PMI as an Agile Certified Practitioner (PMI-ACP)
. In this post we focus only on the lifecycle dimension.
In the agile lifecycle, the project duration (often called release duration) is broken down in a number a relatively small phases (their duration usually ranges between one week and one month). Those small phases, also called iterations or sprints, have all the same duration, as defined at the beginning of the project.
The project scope is broken down in a number of small pieces (called features or user stories in the case of sw development projects), and those pieces are documented in a prioritized list called product backlog. So, at the beginning of each agile iteration, we chose what features to implement within this particular iteration. At the end of the iteration, these features should be ready (“done”) in order to be delivered to the customer.
One of the big advantages of this approach is that while we are working on the chosen features within an iteration, new features can be added at will in the backlog, or existing ones modified. Thus, the final content of the scope is defined throughout the project! In short, an agile approach is chosen when the scope is not fully defined at the beginning, it can be decomposed and delivered in a number of small pieces, and we want to be able to test and deliver our work in small batches, starting early.
Figure 5: This is an example of an agile lifecycle with six iterations (sprints). Deliveries are ongoing throughout the project lifecycle.
Of course, very often, a project uses a combination of lifecycle approaches: for example, we might have an overall waterfall approach, but within one of the phases of the waterfall approach, an agile approach can be used in order to develop a sw application. Or, a construction design can be created in an iterative way, and then the actual building can proceed in a waterfall way.
Every project has its own characteristics in terms of requirements stability, scope definition, risk environment, documented team experience, nature of deliverables etc. Only by taking these characteristics into consideration we can decide what is the best way to structure the lifecycle of the project, increasing the chances of its success!