Overview

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 deployment?
• 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 canceled.

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.