Objective 4: Understand the Costs, Schedule, and Risks Associated with the Project

Understanding what to build is key, but determining how to build it and at what cost is also crucial. To determine whether you should continue with a project, you need to understand roughly how much the project will cost. Most of the costs are related to what resources you will need and how long it will take to complete the project. Combine all of this knowledge with an understanding of the required functionality and its value to the users, and you can build a Business Case for the project. The Business Case documents the economic value of the product, expressing it in quantitative terms such as, for example, return on investment (ROI). The Business Case is the instrument you use to obtain adequate project funding. It also outlines the major unmitigated risks and therefore the level of uncertainty that remains within the project.

In many organizations, especially internal IT departments, the budget has already been set before the project gets to the IT department. In this case, you determine what can be delivered within the budget and the schedule.

For organizations developing software using a low-ceremony approach, the business case may take the form of a short memo or e-mail message, while high-ceremony projects require quite extensive business cases.

For each of our three example projects, you do the following:

Project Ganymede, a small green-field project: The project manager/architect writes up a two-page memo, which functions as a business case, to the project sponsor. This provides the sponsor with sufficient information to understand the value of the expected investments.
Project Mars, a large green-field project: The project manager produces an 8-page Business Case and a 12-page Software Development Plan (SDP), referencing project plans, risks lists, and other key management artifacts. The project manager arranges a half-day review meeting with key stakeholders to walk through the Business Case, risk list, Vision, and Software Development Plan (see the section Project Review: Lifecycle Objective Milestone that follows ).
Project Jupiter, a second generation of a large project: Compared to the first iteration, there is typically less business risk involved in developing the second generation of an application. Roughly the same process is followed as for the first project but with less rigor. The project manager writes a four-page Business Case and produces a Software Development Plan, referencing project plans, risk lists, and other key management artifacts. The project manager arranges a two- hour review meeting with key stakeholders to walk through the Business Case, risk list, Vision, and Software Development Plan (see the section Project Review: Lifecycle Objective Milestone that follows).