CHAPTER 7
Appropriate Project Cycles for Moderately Complex Projects

As depicted in the Project Complexity Model, moderately complex projects are longer in duration (three to six months) than independent projects and they are staffed with adequate project leadership and both internal and external team members (five to ten team members) who use semiformal PM methods and who have a track record of developing fairly reliable estimates. Scope is defined and agreed to, and the schedule and budget have some flexibility.

In moderately complex projects, the business objective is defined, basic requirements are understood but are expected to change, and either the solution is difficult to achieve or the technology is unproven. While executive support is adequate, two or three stakeholder groups are involved and the project has external political implications. The organizational change impacts two or three business units, business processes, and IT systems undergoing maintenance or enhancement. The IT environment is also moderately complex. Some new or unfamiliar regulatory requirements must be met, but the exposure level is acceptable. Table 7-1 presents the profile of a moderately complex project.

TABLE 7-1. Profile of a Moderately Complex Project

In the example presented in Figure 7-1, one dimension of the project falls in the “Highly Complex” area (Urgency/Flexibility) and the rest fall within the “Moderately Complex” area. Our Project Complexity Formula (reproduced here as Table 7-2) tells us that this project should be managed as a moderately complex project.

FIGURE 7-1. Example of Moderately Complex Project

TABLE 7-2. Project Complexity Formula

As projects become complex, they also become unpredictable. Recognizing that conventional, linear approaches are not likely to be effective, we need to look for iterative models that allow us to control the unpredictability and uncertainties. Mark Fowler is a strong proponent of iterative development.

Fowler notes that in linear, plan-based models, performance is measured against conformance to the plan. The uncertainties involved make it difficult to determine when the plan no longer represents reality. In contrast, in an iterative environment, the plan is reviewed and reworked at the end of each iteration, incorporating lessons learned from the prior iteration. This approach allows problems with the project schedule to surface early.

As indicated in Figure 7-2, Moderately Complex Projects Mapped to Project Cycle Approaches, iterative approaches become more important as uncertainties increase. Iterative models may also make use of management practices such as:

• Lean: a philosophy adopted from the world of manufacturing that uses multiskilled teams, emphasizes minimization in time and resources to achieve project objectives, and simplifies processes and methods, with the goal of eliminating non-value-added activities

• Skunk works: semi-autonomous project teams separated from the workings of the larger organization that work on critical, time-sensitive, complex, and sometimes secret projects.

FIGURE 7-2. Moderately Complex Projects Mapped to Project Cycle Approaches

Several iterative models are appropriate as projects become more complex:

• Incremental delivery model

• Spiral model

• Agile model.

INCREMENTAL DELIVERY MODEL

Also referred to as staged delivery and evolutionary delivery, the incremental delivery model delivers valuable increments of functionality—parts of the solution—to the customer earlier than the approach of delivering the full solution at the end of the project (often referred to as “big bang” implementation). This model allows for implementation of the solution incrementally, capitalizing on experience and learnings from the results of prior versions. As the iterations of a cycle build, refine, and review, the correct solution gradually emerges.

Using an incremental delivery model, the project is divided into phases, or iterations, with clear objectives culminating in a project decision gate, where progress and risk are reviewed and plans are set for the next phase. The first phase is typically an effort to define basic requirements and experiment with solution design options aimed at resolving uncertainties about the feasibility of technical options. This first phase may be followed by a series of prototyping iterations designed to bring the solution into view.

Once the solution design is relatively firm, functions are prioritized based on risk, business value, and dependencies between each incremental delivery; once high-risk areas are resolved, the goal is to deliver the highest value components first. Additional parts of the solution are deployed until the complete solution is formulated. This approach can be quite effective, but careful planning is required to develop a viable release schedule. Unforeseen dependencies between the increments can cause rework.

A major difference between the linear approaches (the waterfall and Vee models) relates to scope changes. In the linear models, scope changes are not expected or encouraged. In the incremental model, customers operate the initial releases in a production environment and have the opportunity to recommend improvements to requirements. Figure 7-3 depicts the incremental delivery model.

FIGURE 7-3. Incremental Delivery Model

SPIRAL MODEL

The development model that also applies to moderately complex projects is the spiral model developed by Dr. Barry Boehm in 1980. This model focuses on requirements, feasibility, and risk; once these are resolved, teams often transition to the traditional waterfall or Vee model.

The spiral model is often described as an iterative waterfall approach used to encourage customer and stakeholder involvement in risk resolution early in the project. This approach is similar to the prototyping model in that it breaks the project into risk-reduction iterations, each of which addresses a major risk. After all major risks have been addressed, the spiral model terminates as an iterative, adaptive approach and may transition into any other appropriate model. Figure 7-4 depicts the spiral model.

Since early iterations of the project are the cheapest, the spiral model approach enables the project team to address the highest risks at the lowest total cost. This approach ensures that as costs increase, risks decrease. The spiral model approach is quite effective, but skilled management is required to pull it off. Typical steps include:²

1. Determine objectives, alternatives, and constraints
2. Identify and resolve risks
3. Evaluate alternatives
4. Develop the deliverables for that iteration and verify that they are correct
5. Plan the next iteration
6. Commit to an approach for the next iteration.

FIGURE 7-4. Spiral Model

AGILE MODEL

The agile movement is flourishing because requirements are so volatile and difficult to define. The relatively new agile methods attempt to arrive at a compromise between too much and not enough process. The agile model is often used when the business objectives and solution are unknown or not clearly defined. It uses a highly iterative and incremental process whereby developers and project stakeholders actively work together to understand the domain, identify what needs to be built, and prioritize functionality.³ The agile model is appropriate when a great deal of experimentation is required to develop the optimal solution.

Over the past few years, interest in agile (a.k.a. “lightweight”) methodologies has been growing. Described as an approach to rid IT development of burdensome bureaucracy⁴ (or alternatively, a “license to hack”), agile methodologies have generated interest throughout the IT world. The emphasis in agile methods differs substantially from the emphasis in traditional, more “heavyweight” engineering methods. The most notable difference is that they are less document-oriented, requiring less documentation for a given task. When agile methods are used for software development, they often use source code as a key part of documentation. Two additional, fundamental distinctions are that:⁵

• Agile methods are adaptive rather than predictive. Engineering methods plan out a large part of the solution in great detail and then manage changes throughout the project. Agile methods seek to adapt and thrive on change.

• Agile methods are people-oriented rather than process-oriented. The goal of engineering methods is to define a process that is repeatable and independent of the development team. Agile methods focus on the skill of the development team, trying to make the process support the team more effectively in its work.

Much like the early stages of a research and development project, agile methods are used when project value is clear (even if the business objectives are unclear); the customer participates throughout the project; experts (designers, developers, business visionaries, project manager, and business analyst) are co-located; incremental feature-driven development is possible; and visual documentation (cards on the wall versus formal documentation) is acceptable. The agile model involves significant risk, however, because the project often has no fixed budget or timeline—these are impossible to determine because there is no clear goal and solution. Figure 7-5 depicts the agile model.

FIGURE 7-5. Agile Model

NOTES

1. Mark Fowler, “The New Methodology” (2003). Online at http://www.martinfowler.com/articles/newMethodology.html (accessed March 2008).

2. Business eSolutions, “Project Lifecycle Models: How They Differ and When to Use Them.” Online at http://www.business-esolutions.com/islm.htm#modifiedwaterfall (accessed January 2008).

3. Scott W. Ambler, “Agile Analysis.” Online at http://www.agilemodeling.com/essays/agileAnalysis.htm (accessed January 2008).

4. Mark Fowler, “The New Methodology” (2003). Online at http://www.martinfowler.com/articles/newMethodology.html (accessed March 2008).

5. Ibid.