The Project Lifecycle

Is the Project Life Cycle what separates projects from a regular business?

Professor Peter Morris, one of the world’s foremost experts on project management, once said, “The life cycle is the one thing that uniquely differentiates projects from non-projects.” The concept of a life cycle has become something of a dream in some parts of the project management world. It is sometimes confused with the so-called “waterfall” method to project management, which indicates a misunderstanding of what project management is all about.

Let’s begin with the fundamental concepts of the most basic project (and program) lifecycles.

The majority of organizations have more project ideas than resources to carry them out. That’s a positive thing since it indicates that the company is forward-thinking and inventive rather than complacent and stagnant. The trick is to find the finest ideas that can be implemented efficiently with the existing resources. Although initial filtering out of ideas may be done at the portfolio level, the core of a strong start to the project life cycle is to assess the value of a project in one or two early stages.

We need to talk about ‘agility’ before we can describe these two phases (or if they should be merged). All projects must be managed with flexibility; the issue is, “How much flexibility is appropriate?” ’. The solution to this question is centered on two project characteristics: ‘predictability’ and ‘cost of change.’

Predictability refers to how effectively we can plan the project’s goals from the start. This is extremely predictable if we are building a bridge with a known span and weight-carrying capability. Before we begin to develop this output, we have the information to thoroughly design it. It’s also worth mentioning that once work has begun, the cost of changing is quite high. You can’t suddenly decide that you want it to transport huge freight trains instead of only walkers after the foundations and pillars have been built.

When designing an App, on the other hand, we know the top-level customer’s problem we want it to solve, but predicting exactly how our potential customers would want their problems treated is far more difficult. We won’t be able to specify the final product upfront, so we’ll have to work iteratively while checking in with customers to see whether what we’ve supplied is what they want. This situation has the extra benefit of a far cheaper change cost than the bridge. The interdependence of component characteristics is substantially lower than that of bridge components. They may be added, deleted, or altered on their own, as long as the underlying architecture was built with flexibility in mind.

So, what does this have to do with the life cycle?

We don’t need as much agility when predictability is high, but we do need a lot of agility where predictability is low. Design effort is concentrated on the first two phases of the cycle in the ‘reduced agility’ environment. Design is disseminated throughout the delivery process in the ‘greater agility’ context.

Because designing a bridge is an expensive undertaking in and of itself, it makes sense to do it in two phases. A ‘fast look’ may result in basic designs, as well as a plan for the ‘detailed look,’ so that whoever is giving the funds understands what they must commit to for the detailed design to be completed in the following step.

Because much of an App’s design work is completed during the delivery phase, the first two phases may be combined. Although some outline scope management is still required to determine whether the entire project is likely to be economical, suit the organization’s goal, and be within its risk appetite, all of this may be done in a single first step.

Decision gates between phases are an important part of a lifecycle. These are just there to combat the “I began it, so I’ll finish it” mentality that has resulted in so many disastrous projects not being canceled as soon as their non-viability is shown. Another thing that many who regard it as a barrier to high levels of agility despise is a gated lifetime. There is no such thing as a barrier. It’s merely a way out of a badly thought-through enterprise, and no amount of agility can save such a project.

The false idea is that gates can only exist if the up-front design is prioritized. That isn’t the case at all. At each gate, the criteria used to evaluate the project should be consistent with the level of agility being employed.

Finally, a project’s distinguishing characteristic is that it employs a temporary crew that will be disbanded after the project’s objectives have been fulfilled and the customer has been turned over. During the ‘close’ phase, this is done.

Some people who operate in environments where great agility is required advocate for #noprojects2 and claim that everything should be a ‘product.’ That’s good if you just want ‘products’ where the team that begins the work is permanent and will continue to develop it until it is decommissioned or ‘sunsetted.’ In some ways, you win and in others, you lose. If you don’t want to handle a piece of work as a project, it doesn’t imply it shouldn’t exist. In truth, the development portion of product management uses many of the same techniques as project management; it just chooses to apply them in a business-as-usual setting without the project life cycle control.