Introducing the New Project Complexity Model. Part III

Applying Complexity Thinking to Select the Project Cycle

In this third article in the series on project complexity, we examine the relationship between complexity and project cycles. All projects have a cycle, a sequence of stages through which the project passes. Typical cycles comprise a series of periods and phases, each with a defined output that guides research, development, construction, and acquisition of goods and services. As projects have become more complex, project cycles have evolved to address the various levels of complexity. It is important to know the complexity of your project and to apply the approach that is best suited to manage or reduce that complexity. Project cycles can be categorized into broad types:

• Linear: used when the business problem, opportunity, and solution are clear, no major changes are expected, and the effort is considered to be routine.
• Incremental: used when the effort is well-understood and only moderately complex, but the customer wants to deploy value incrementally.
• Iterative: used when the requirements are unclear, incomplete, or subject to change.
• Adaptive: used when the business problem, opportunity, and solution are unclear and the schedule is aggressive.
• Extreme: used when the business objectives are unclear and the solution is undefined.

As we move along the continuum from independent to highly complex projects, the project characteristics move from predictable to uncertain (Figure 1).

Figure 1. Project Complexity Continuum

In addition, as we move along the continuum from independent to highly complex projects, the appropriate project cycles move from linear to iterative to adaptive approaches to manage the uncertainties (Figure 2).

Figure 2: Project Cycle Continuum

Project Cycles for Independent Projects
Independent projects, (Figure 3), are usually predictable and respond well to the use of linear project cycles, e.g., Waterfall model, Rapid Application Development, (RAD) model, Vee model.

Figure 3: Independent Project

Waterfall Model

The waterfall model (Figure 4), the archetypical project cycle model from which all others are derived, is a highly effective project cycle for short-duration, well-understood projects with stable requirements and virtually no external dependencies.

Figure 4: Waterfall Model

The waterfall model is essentially a linear, sequentially based ordering of activities that presumes that requirements are fully developed and approved. It also assumes that events affecting the project are predictable, tools and activities are well-understood, and as a rule, once a phase is complete, it will not be revisited. Development is seen as flowing steadily downward (like a waterfall) through the phases of the model.

Rapid Application Development Model

If requirements are understood and scope is contained, the RAD model (Figure 5) allows for a greatly abbreviated development timeline compared to the waterfall model. This component-based approach allows for incremental testing and defect repair—and therefore, significantly reduced risk—compared to single, comprehensive delivery. RAD can be costly, however, if requirements aren’t well-defined, which creates a high risk of requirements defects, or if the design is not sound, which creates a high risk of integration issues.

Figure 5: RAD Model

The Vee model system (Figure 6) is often used for projects once the basic system requirements are firm and Vee Model design decisions have been made.

Figure 6: Vee Model

The Vee model accounts for the relationships between decomposition, integration, and verification. Integration and verification of subcomponents are planned early. The Vee model assumes the solution will be a closed system, i.e., self-contained and not influenced by its external environment. Accordingly, the system is decomposable, linear, and predictable.³ Unfortunately, this approach does not scale up when addressing large, complex information-age projects, since it assumes that a solution will operate in a steady state with static patterns vs. flexible solutions that evolve and adapt to their changing environment. Solutions today must be “robust enough to withstand or flexible enough to bend and recover from constant change.”

Project Cycles for Moderately Complex Projects

As projects become complex (Figure 7), 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.

Figure 7: Example of Moderately Complex Project

Mark Fowler
The New Methodology

“We need an honest feedback mechanism which can accurately tell us what the situation is at frequent intervals. The key to this feedback is iterative development. Iterative development has been around for a while under many names: incremental, evolutionary, staged, spiral…lots of names. The key to iterative development is to frequently produce working versions of the final system that have a subset of the required features. These working systems are short on functionality, but should otherwise be faithful to the demands of the final system. They should be fully integrated and as carefully tested as a final delivery.”

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. Several iterative models are appropriate as projects become more complex: Incremental Delivery model, Spiral model, and the Agile model.

Incremental Delivery Model

Also referred to as staged delivery and evolutionary delivery, the incremental delivery model (Figure 8) 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 to build, refine, and review, the correct solution gradually emerges.

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 for later releases.

Figure 8: Incremental Delivery Model

Spiral Model

The spiral model (Figure 9) 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 very similar to the prototyping model in that it breaks the project into risk-reduction iterations, each of which addresses a major risk. After major risks have been addressed, the spiral model often terminates as an iterative, adaptive approach and may transition into any other appropriate model.

Figure 9: Spiral Model

Agile Model

“Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Agility is the ability to balance flexibility and stability.”
—Jim Highsmith

The agile movement is flourishing because requirements are so volatile and uncertainties abound. 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 (Figure 10) is appropriate when a great deal of experimentation is required to develop the optimal solution.

Figure 10: Agile Model

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 vs. formal documentation) is acceptable.

Project Cycles for Highly Complex Projects

“Welcome a certain amount of complexity and churn because it creates a chemical reaction that jars creative thinking.”
—Colleen Young, VP and Distinguished Analyst and IT Adviser, Gartner

Since complex projects (Figure 11) are by their very nature unpredictable, it is imperative that the project team keep its options open as long as possible, building those options into the project approach. This adaptive approach requires that considerable time be dedicated to researching and studying the business problem or opportunity; conducting competitive, technological, and benchmark studies; defining dependencies and interrelationships; and identifying potential options to meet the business need or solve the business problem. In addition, the team experiments with alternative solutions and analyzes the economic, technical, operational, cultural, and legal feasibility of each until it becomes clear which solution option has the highest probability of success.

Figure 11: Example of Highly Complex Project

In highly complex projects, it is important to separate design from construction. The goal is to use expert resources and allow them to spend enough time experimenting before they make design decisions.

Models for adaptive project management are still emerging. We suggest two that are designed to provide iterative learning experiences, adapt and evolve as more is learned, examine and experiment to determine solution design viability, and delay decision-making as long as possible (i.e., until the last responsible moment, the point at which further delays will put the project at risk): the Evolutionary Prototyping model and the eXtreme Project Management model. These models employ several contemporary management practices, such as late design freeze, built-in redundancy, lots of experimentation, and designing and building prototypes for multiple parallel solutions.

Evolutionary Prototyping Model

“The best representation of a complex system is the system itself.”
Göktuğ Morçöl, Associate Professor Public Affairs Penn State University

The “keep-our-options-open” approach (Figure 12) often involves rapid prototyping—a fast build of a solution component to prove that an idea is feasible—which is typically used for high-risk components, requirements understanding, or proof of a concept. Evolutionary prototyping is quite effective for multiple iterations of requirements elicitation, analysis, and solution design. Iteration is the best defense against uncertainty because, with each iteration, the technical and business experts examine the prototype and provide learnings that are built into the next iteration. The strength of prototyping is that customers work closely with the project team, providing feedback on each iteration. If requirements are unclear and highly volatile, prototyping helps bring the business need into view.

Figure 12: Evolutionary Prototype Model

eXtreme Project Management Model

“An extreme project is a complex, high-speed, self-correcting venture during which people interact in search of a desirable result under conditions of high uncertainty, high change, and high stress.”
—Doug DeCarlo, author and lecturer

The eXtreme project management model (Figure 12) was developed by Doug DeCarlo and is fully defined in his book, eXtreme Project Management, Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility² The model is designed to be used when a great deal of change is expected during the project, speed is of the essence, and uncertainty and ambiguity exist. Pharmaceutical research for a groundbreaking drug, new product development for a pioneering invention, and major business transformation efforts are examples of extreme projects.

The eXtreme project management model consists of a set of principles, values, questions, and success factors that can be applied effectively to highly complex projects. These elements are outlined below.

This approach consists of a number of short, experimental iterations designed to determine project goals and identify the most viable solution. As in the agile model, eXtreme project management requires that the customer be involved every step of the way until the solution emerges—a practice that involves many iterations. Like the spiral model, the eXtreme model terminates after the solution is found (or when the sponsor is unwilling to fund any more research); the project team then transitions to one of the other appropriate models.

Doug DeCarlo
Consultant, Facilitator, Trainer, Coach, and Keynote Speaker

“eXtreme project management is the art and science of facilitating and managing the flow of thoughts, emotions, and interactions in a way that produces valued outcomes under turbulent and complex conditions: those that feature high speed, high change, high uncertainty, and high stress.”

DeCarlo depicts eXtreme project management as a squiggly line that shows the project from start to finish, demonstrating the open, elastic approach that is required (Figure 13). The focus is on the art of project management versus the more scientific and technical scheduling and planning. eXtreme project management is sometimes also called radical project management or adaptive project management. Some equate it to agile project management.

Figure 13: Open Approach of eXtreme Project Management Model

References

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).

Doug DeCarlo, eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility (San Francisco: Jossey-Bass, 2004).

Hal Mooz, Kevin Forsberg, and Howard Cotterman. Communicating Project Management, (Hoboken, NJ: John Wiley & Sons, 2003).

Larry P. Leach, 2000. Critical Chain Project Management Improves Project Performance. Advanced Projects Institute. Online at: https://www.projecttimes.com/wp-content/uploads/attachments/PMJOURN_R8.PDF (accessed March 2008).

Linda J. Vandergriff, Complex Venture Acquisition, 2006. Complexity Conference White Paper, p.6.

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

Robert K. Wysocki, Effective Project Management, Traditional, Adaptive, Extreme, Fourth Edition (Indianapolis, IN: Wiley Publishing, Inc., 2007), 48.

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

---

Kathleen Hass is the Senior Practice Consultant for Management Concepts and author of Managing Project Complexity, A New Model. Ms. Hass is a prominent presenter at industry conferences, author and lecturer in the project management and business analysis disciplines. Certifications include: SEI CMMI appraiser, Malcolm Baldrige Total Quality Award examiner, Zenger-Miller facilitator, and Project Management Institute Project Management Professional. Ms. Hass serves as Director at Large, IIBA (International Institute of Business Analysis), Chapter Governance Committee chairperson, and member of the Business Analysis Body of Knowledge committee, contributing to several chapters and lead author of the Enterprise Analysis Chapter.