Although the entire purpose of a project is to produce a product, the specific goals of the team will vary
substantially throughout the project. In the beginning, there usually is considerable latitude in the requirements for
the product. It may not be clear whether the project is feasible or even if it is likely to be profitable. At that
time, it is critical to bring an answer to these questions and of little to no value to start developing the product in
earnest. Toward the end of the project, the product itself is usually complete, and issues of quality, delivery,
and completeness then take center stage. At different points in time, tasks are undertaken in new ways and work
products will have new content.
To coordinate the team's efforts in a manner that takes these fundamental observations into account, the project
lifecycle should be divided into a sequence of phases. Each phase has a defined set of goals, a particular iteration
style, and customized tasks and work products to address the unique needs of the project at that point. The project
lifecycle provides stakeholders with oversight, transparency, and steering mechanisms to control project
funding, scope, risk exposure, value provided, and other aspects of the process.
It helps to organize iterations into phases. Each phase ends with a milestone aimed at providing oversight by raising
and answering a set of questions that are typically critical to stakeholders:
Inception. Do we agree on project scope and objectives and whether or not the
project should proceed?
Elaboration. Do we agree on the executable architecture to be used for
developing the application, and do we find that the value delivered so far and the remaining risk is acceptable?
Construction. Do we find that we have an application that is sufficiently close
to being released that we should switch the primary focus of the team to tuning, polishing, and ensuring successful
Transition. Is the application ready to release?
If the answer is Yes to those questions at the phase review, the project continues. If the answer is No, the phase is
delayed (usually by adding an extra iteration) until a satisfactory answer is received, or the stakeholders may
determine that the project should be cancelled.
Within each phase, you might have one or several iterations, where the iterations aim at producing the results required
to answer these questions. As an example, to answer the question for Elaboration, we typically need to implement and
test key aspects of the system so that we understand what architecture we need, what commercial, off-the-shelf (COTS)
components we may need, what key risks we face and how to address them, the effectiveness of the team, and so on. These
needs will steer how we prioritize what is to be done in an Elaboration iteration.
One of the objectives of the project lifecycle is to focus on two key stakeholder drivers: risk reduction and
value creation. As figure 1 shows, the four phases here described focus the team on risk reduction related
to the questions to be answered at the end of the phase, while tracking value creation.
Figure 1 - Risk reduction (red curve) and value creation (green curve) during the project lifecycle
Risk is a manifestation of the likelihood of unexpected things happening to the project, and risk stands in the
way of value creation. Risk is directly proportional to uncertainty in estimates, and stakeholders typically want to
know sooner rather than later what value the project can deliver in the stipulated time. In many cases, you reduce risk
when you create value by implementing and testing the most critical capabilities. However, there are situations where
risk reduction and immediate value creation are at odds with each other, requiring careful balancing of these competing
priorities to maximize stakeholder value.
See Balance competing priorities to maximize stakeholder value.