by: Nader K. Rad, PMBOK® Guide-Seventh Edition Development Team member
What does product life cycle have to do with project management? Well, let me tell you about that with an example: Let’s say we have a project to build a plant. We will spend some time designing and building it, and then it will be handed over to another team for operations.
Our project is the main investment, and the agent for change – which in this case is the creation of the plant – and then the operations is where value is generated by using the product we have created. Operations continue until many years later when the owner decides to stop using that plant because it’s not justifiable, or for some other reason.
What do you do with the plant when you decide to stop using it? There’s always the option of just abandoning the plant, which may create good opportunities for photographers many years later, like this plant not far away from me in Charleroi, Belgium. In many cases, though, for safety, environmental, or economic reasons, you may want to disassemble useful parts of the plant, demolish the rest, build walls or fences, etc. In this case, these activities form a packaged change, which should be managed properly with a clear purpose. In other words, it can be seen as another project.
Is that everything, then? Hardly so. When the plant is in operation, many things change in the environment; the plant doesn’t stay exactly the same until it’s retired. In many cases, we make changes to the product (the plant) during its operation to adapt to the environment and increase our profits. Some changes are simple, and we just implement them. Some changes are bigger and more challenging, though, and need serious management. Those changes will be managed by a project.
Do we have to stop operations during the project? It depends: Sometimes we have to, and sometimes we don’t. In some cases, the project can be focused on changing one part of the product, while the other parts continue their operations normally. In IT development projects, it’s possible to deliver incrementally during the project: releasing a working version of the product into production while the team is working on the next release.
In some projects, the day-to-day operations and changes are so tightly coupled that they may look like the following and may even be done with mixed teams responsible for both aspects.
When we, as people involved in projects, think about the product life cycle, there are lots of things to consider; for example,
How can we match our project life cycle with the wider product life cycle?
Are we going to put the [new] product into operation at the end of the project, or are we going to have incremental delivery? In either case, how are we going to match our project management with that delivery approach?
How are we going to develop the product in order to match the delivery approach? Do we need a sequential development approach or a cyclical, iterative one? In each case, how are we going to adapt our project management method to better support the delivery approach
Put simply, there isn’t just one way of managing projects, and we should not force the one approach that we are most used to, or is the most popular at the time, onto all types of projects, regardless of their natures and needs. In other words, we should consider life cycle management as one of our performance domains in project management. The main focus of this performance domain is the project life cycle (the series of phases that a project passes through from its start to its completion), but it should also consider everything that impacts the project life cycle, including the product life cycle, development approach, and delivery cadence.