Phase and Lifecycle in Project
In case of a small project, we could manage project overall tasks or activities by writing them down and by tracking them. However, when the project becomes larger, it won't be possible for us to do that.
To track the status effectively, what we are going to do would be probably, grouping the tasks or activities required in the projects together in accordance with certain attribute such as relationships with each other, or due date. Project phase is what are explained as "group" here.
Hence project is generally divided into several phases and each phase has group of activities and deliverable.
Obviously, the number of phases, the name of the phases , and the sequence of the phases would be different in industries, domain, and organizations. Even withing the same organization, phases could be differently used for different projects.
This collection and sequence of phase are called as Lifecycle of the project.
Following shows the relationships among project, lifecycles, phases, and tasks or activities.
(Personal experience) Example in SAP implementation project
In my previous experience of ERP(SAP) implementation project in consulting firms, we didn't use the term "Lifecycle" in project. Instead, we used "Releasee", or "Wave", which seems to be more natural in System delivery project to me.
In wave 0, overall planning phase, the scope of application or solutions for following waves are determined and confirmed. In accordance with the defined scope for each wave, the following waves are started. In this case, wave 1, 2, and following waves had the same phases because the major difference of the waves are only scope of application or solutions.
As the wave or phase go to the next one, it was really frequently happened that the Project Manger was changed.
Sample of project lifecycles
There are various kinds of project lifecycles existing as industry standards.
Predictive/Sequential Relationship (Waterfall)
In this approach, phases of project are arranged in such a way that one phase ends, then the next phase can start. Unless the predecessor phase don't end, the next phase could not be started.
Each phase would not be overlapped in this approach.
This approach could be possible for the project whose scope is clear enough and also really stable. If any change during the lifecycle is required, project member need to prepare themselves for tremendous amount of rework and impact on time and costs.
In this approach, the approach explained in previous section as sequential approach are just overlapped to save time.
It is possible for the project which has so many tasks or activities under each phases and relatively high volume of resources. Even though it's essentially the same as the Sequential approach, some portion of the phase, or tasks could be overlapped, except for the tasks which are directly related to each other. This is the background of the concept.
For example, let's take a look at system implementation project. Generally speaking, there are design phase and build phase. Essentially speaking, build phase could not be started before the design phase completes. However, if the logistics part is completed and others are left, which are confirmed that they are not related to logistics part, we can start build phase for the logistics part because the design phase for the logistics part is already completed.
Iterative and Incremental / Spiral
In this approach, deliverables or products of the project are developed through multiple repeatable phases. In the first iteration, first deliverables or products are created. In the second iteration, deliverables or products are updated or enhanced in accordance with the updated/refined scope of the projects.
This is usually adopted to the cases where the requirement for the project is not that clear. Similar sets of tasks or activities are repeated but the deliverables or products are updated, so this is also called as spiral approach.
Actually, this approach is a kind of iterative approach. It is common in both approach that the similar tasks or deliverables are repeated in the projects.
The difference is, whether the delivery to production, or releasing some product to customer or market is conducted or not.
This approach is used for the case that there are certain deadline for project to delivery at least something to customer, or market, however the detail of the requirement for the something which should be delivered is not very clear.
Because of the un-clearness of the project itself, even the overview activity for the 2nd iteration is not clear and it is difficult for project to define the detail of the deliverables or activities required except for the recent schedule. In such a case, this approach is taken.
The duration of each iteration tends to be short, 30-45 days, so each iteration is called as sprint.
Roughly speaking, this approach is saying that "We are going to start project anyway, and provide something as deliverables. If it's required to be modified or further updated or upgraded, we will plan next phase and provide something brushed up more."
I have once experienced proposal of this approach for power pricing. In Japan, it is still true that price of the product is determined by customer or market, not by the company, especially for the consumer products. Price for product would rarely changed in Japan, because customer has strong position.
However, one of our client had an interest in power pricing to their product based on enterprise strategy and changing the prices more flexibly and frequently, rather than fixing the price just based on market price which seemed to be acceptable to customer. There were no business cases in Japan, which we could refer to.
In that situation, our partner decided to take this approach. Though it failed eventuyally.
Hybrid approach is a hybrid of predictive approach and adaptive approach. These 2 seem to be far away from each other, but it's just starting with adaptive approach, and changing to predictive approach.
In the very beginning of the project, it may not be possible to define the scope or required deliverables in project completely, so the adaptive approach was taken. However, as project goes, with a better understanding for the scope, it would be possible for project to take predictive approach. This is the case.
All the projects which I experienced in consulting firms took predictive approach. This must be because of consulting firm has plenty of project experience and knowledge shared among their global network.
This is a kind of goodness and easiness in working in consulting firm, however, for those who wants to try/challenge completely new things, this would be boring.
Those who leave consulting firm and decides to go to work in business firm tends to say "I'm always doing this (e.g. Financial/Legal Due Diligence, ERP Implementation, Financial Modeling, Industry research, etc.)".
I wish I could have opportunity to work in project with adaptive approach, for my future