I’ve had my attention on an aspect of project management that is absolutely fascinating and that I haven’t spent much time on in the last five or six years. Shutdown/Turnaround project scheduling is, in many ways, the epitome of the project scheduling paradigm and, like everything else in the project management industry, it too has evolved in recent history.

For most of us, when we think of project schedules, we think of building something. The end result is something that didn’t exist before the project started. Perhaps it’s a building or a spacecraft or a software system or a new drug. Shutdown/Turnaround projects are quite different. In every major manufacturing plant, there is some maintenance which can be accomplished while the plant is running and some maintenance which can only be accomplished when the plant is not. For example, it’s common for a major pulp and paper or chemical plant or steel mill to shut down completely once or twice per year in order to refurbish those significant elements of the plant which can’t be updated otherwise. The goal becomes to go from shutdown to start up as quickly as possible; to turn the plant around from stopped to started. Hence the term shutdown and/or turnaround for this kind of project.

A major shutdown for such a plant might last anywhere from four to six days. Sometimes a plant requires a less significant pause in operations which might last only one day. The value of the project is measured by opportunity cost. This means we measure the value of the material that the plant cannot produce due to its being closed. In some plants that’s often $100k to $200k per hour. Yes, $100,000 to $200,000 per hour. That’s scheduling pressure and therein lies a very different kind of project management.

A shutdown planning team is typically a small close-knit group of highly trained schedulers who will prepare all the schedules, update them as need be and prepare the foremen and contractors with whatever they need to get their work accomplished as quickly as possible.

This kind of project management carries a number of idiosyncrasies that we aren’t likely to find in high tech project management or bio research project management. Here are some:

Notice
When we think of white-collar project management, we think of an orderly progression towards the start of the project. We get funding. We get an executive sponsor. We make a project charter. We organize our project team. We prioritize our work, and so on. A shutdown schedule is often planned for months in advance, but the actual start of the project can come up on you without notice. That can happen if there’s an emergency shutdown due to equipment failure. I remember meeting with a number of shutdown scheduling managers a few years ago. One scheduling manager from the nuclear industry was bemoaning how he might get only six weeks notice for a shutdown project on his nuclear power plant. A scheduling manager from a chemical plant responding with a note of disbelief “Six weeks!” he said. “Do you know what notice I get? I see a bunch of guys running by the door to my office and I say ‘Hey guys, where are you going?’ and they respond ‘We just shut down’. That’s the notice I get.”

Sub-contracting
When the value of your project is being measured in the hundreds of thousands of dollars per hour, you don’t quibble over finding the right people to do the work. Also, the project will only last a few days out of the year, so every shutdown project I’ve ever been a part of had a huge sub-contracting aspect to it. Literally hundreds of people might be brought in from dozens of sub-contractors over a tiny amount of time. These personnel must all be managed. The contractors must be rigidly controlled to ensure they go to the right place and are ready at the right time and, last but not at all least, these hundreds of people who are not used to being in this plant full time must be safe.

Safety
We often have safety concerns in project management but in a shutdown environment it’s more prevalent a problem. The vast majority of personnel will be on the site for only a few days, some of them for the first time. A major industrial plant is a dangerous place even when it’s not operating and all these people need to be kept safe.

Resource Leveling
These days in enterprise project management we tend to talk about Resource Capacity Planning to see what additional work we could take on. That’s not the case here. When there is a shut down, there is no other work that will contend for these resources. The CEO himself can be called upon if that’s required in order to get the job done. So there is no multi-project resource contention. There is also no limit to the number of resources I can contract. What there is, are the physical limitations of resources on the plant site and for each piece of equipment. You might have a task to rewire an electrical room and, in theory, you could do it with 20 electrical engineers. However, the room can’t fit more than three people so your resource leveling has to contend with that. We tend to think of resource scheduling in a shutdown not just of personnel but also equipment, such as heavy lifting cranes and physical space restrictions. It’s a significant resource management challenge.

Per-minute Planning
In a high-tech type of project, we think of scheduling in person-days or person-weeks. In a shutdown, we tend to think in quarter-hour increments or even down to the minute. Knowing that a task can be complete at 6:30 instead of 7:00 can have an enormous impact to the overall schedule. After all, that half hour is worth $50,000 to $100,000!

Lead Time Items
One of the most disastrous things that can happen on a shutdown is to get to a critical task only to find that something that takes days or weeks to order isn’t there. I remember one of our staff working on a shutdown. He was there a week or two in advance and, the day before the scheduled shutdown, a contractor slipped and the result was catastrophic. A tool touched the wrong thing on a power transformer which promptly spectacularly disintegrated. This transformer was not supposed to be replaced and there was no replacement on site. The transformer company half-way across the country had to be immediately contracted to create a new transformer to conform exactly to the one that had been destroyed. Price was no object. A special train was contracted to transport the device to the site in the middle of the night. In the meantime, temporary generators were rushed into the site so contractors could continue working. Total delay: approximately 24 hours; meaning over $2 million dollars (remember, we measure the cost as the value of what can’t be produced in the time the plant is closed).

If you’re involved in such projects and in creating a project management environment, there are a number of places to look for where you can generate value for your organization. Here are three:

Reiterative Planning
Unlike some projects, a shutdown project is very repetitive. But this gives us a unique opportunity to realize some significant efficiencies. Several years ago, I worked with a planning group which worked over a two year period to analyze project schedules for their main shutdown. They compared the plans to the “as-built” schedule to compare what was planned to what actually happened. They looked for any level of inefficiency in the schedule to see where the plan for the next shutdown could be made shorter. In the end, they reduced the planned shutdown schedule from 6.6 days (which had been believed to be the shorted theoretical time) to 4.4 days, a savings of over $2,000,000 per shutdown!

Document Management
Many organizations have digitized plant maintenance and equipment documentation systems so they can be instantly available from any terminal in the plant. The time that used to be taken to run from one end of the plant to the other, in order to go through a series of file cabinets to find a maintenance guide should be a thing of the past. If you can link these documents to the tasks in the online schedule, then finding information faster and easier can realize big efficiency gains

Contractor Updating
With web-based systems, contractors can now participate in systems to update the schedule as
it’s happening on the shop floor, or immediately following the shift in which the work is done. It’s essential to collect the actual progress information, as quickly as possible, while the schedule is underway so that the schedule can be updated for the next shift. Also, one major aspect of a shutdown that is an enormous undertaking is figuring out, once it’s done, what contractor did what work and reconciling the invoices from the contractors with the work that was accomplished. Both of these goals can be helped with a contractor timesheet system that is linked directly into the schedule.

The lessons we learn from shutdown/turnaround planning can be of benefit to everyone but, what I think is most valuable, is realizing that project management isn’t one big homogeneous set of practices. Trying to blindly apply the same practices we’d use for one kind of project management into a shutdown might have disastrous consequences. For each project management environment you are confronted with, you must look at it for the particular business challenges it represents, and bring forward the tools that are appropriate to those challenges.

---

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected].

Applying Complexity Thinking to Manage Project Complexity Dimensions

“For every complex problem there is a simple solution. And it is wrong:”
H. L. Mencken, journalist and satirist

Traditional project management, system engineering, and business analysis practices are often insufficient when applied to complex projects that behave dynamically. In the case of complex projects, leadership is the critical component that can make the difference. This fourth article in the series on managing project complexity presents practical techniques for project leaders faced with challenging complex initiatives. We estimate that putting these techniques into practice can reduce project rework by 30 to 50 percent, thus eliminating excessive time and cost overruns. For detailed information about the complexity management techniques presented here, refer to the book: Managing Complex Projects: A New Model.

Managing the Complexities of Long Duration Projects

The biggest problem with long-term projects is that so many unforeseeable things can happen. These projects run the risk of working to achieve a business objective that has changed during the course of the project. Consequently, the new business solution may no longer meet current business needs. Dependencies that have been identified and managed may disappear, but new ones often emerge. In addition, project teams fatigue over time, losing interest in the project. Long-duration projects typically cause a lack of confidence in time and cost estimates. Complexity management techniques include both adaptive and conventional approaches:

MANAGING LARGE, LONG-DURATION PROJECTS
Complexities				Management Approaches
Constantly changing: Business goals Competitors Global economy Partnerships and alliances Stakeholders Project boundaries Business objectives Scope Dependencies Interrelationships Too large: invisible, unmanageable, unable to identify dependencies and relationships Team fatigue, leading to unpredictable human behaviors				Adaptive Adopt the appropriate project cycle and PM practices for the situation. Minimize scope. Delay design decisions until the last responsible moment. Use incremental development. Use progressive elaboration and rolling wave planning. Establish a systematic estimating process using multiple estimating methods. Pay close attention to team composition and health. Use lean techniques. Use RAD development to increase velocity for well-understood components. Conventional Perform rigorous time and cost management. Use stage-gate management. Conduct continuous risk management. Use a systematic approach to develop reliable estimates.

Managing the Complexities of Large, Dispersed, Culturally Diverse Project Teams

Complex projects almost always involve multiple layers and types of teams. Geographical diversity and dependency on technology dramatically magnify the levels of organizational complexity. Outsourcing all or part of the solution also adds a significant level of complexity. Applying the appropriate practices, tools, and techniques to multiple parties at the right time is a complex endeavor. The project manager role is more about team leadership than project management. Techniques to consider:

MANAGING LARGE, DISPERSED, CULTURALLY DIVERSE PROJECT TEAMS
Complexities	Management Approaches
Many complex adaptive teams Human behaviors impossible to predict Multi-layered, interdependent teams Geographically dispersed Culturally diverse Virtual Multi-skilled Dissimilar procedures, practices, and tools leading to integration issues Risk management inadequacies and inconsistencies, leading to unknown events Integration of interdependent components produced by different teams	Adaptive Establish an experienced core leadership team. Leverage the power of teams. Build great teams. Use edge-of-chaos management when appropriate. Empower agile teams instilled with a culture of discipline. Use virtual teams as a strategic asset. Insist on face-to-face meetings for key planning and decision-making. Use virtual collaboration and information sharing technology. Conventional Lead, don’t manage contractor teams. Insist on standard procedures and tools when appropriate. Establish a culture of collaboration and open communication.

Managing the Complexities of Innovative, Urgent Projects

An urgent project that demands an innovative solution and has an aggressive scope and schedule is another type of complex project. Urgent projects, by their very nature, are different from what we consider to be traditional projects. Traditional projects are usually started with a defined scope, budget, and timeline, and an attempt is made to follow a prescribed methodology. Urgent projects are seldom started this way. For urgent projects, time is critical for project success; delays mean a high probability of project failure. Crisis situations such as war and natural disasters are examples of urgent projects. Urgent projects are both planned (innovative new product) and unplanned (hurricane Katrina). Consider the following managerial approaches:

MANAGING INNOVATIVE, URGENT PROJECTS
Complexities	Management Approaches
Urgent projects: Planned – innovative products Unplanned – unknown critical situations or events High stakes; highly visible Time rules, supersedes best practices Cost typically not an issue (but can becomes an issue if urgency wanes) Team struggles to remain independent of external constraints Process is thrown out Interdependencies are missed due to speed and isolation Sense of urgency fades Environment of confusion, mistakes and misinformation	Adaptive Establish permanent, flexible innovation teams or task forces. Hand pick the best team members. Use “twinned leadership”. Use “edge of chaos” leadership. Time-box the effort; promote urgency. Deliver minimal workable solution. Partnerships vs. contractor relationship. Insist on face-to-face decision-making. Deploy all available resources. Employ a proactive communication strategy to maintain the sense of urgency. Support teambuilding. Monitor changing perceptions of urgency. Conventional Establish a time-boxed schedule. Creates sense of urgency Forces decision-making Conduct decision gate reviews.

Managing the Complexities of Project Ambiguity

A significant percentage of project failures occur because of unclear business problems or opportunities, and ambiguous, difficult-to-define solutions. In addition, business objectives are dynamic, changing as the business changes. Techniques include:

MANAGING AMBIGUOUS PROJECTS
Complexities	Management Approaches
Unclear business problem or opportunity Solution difficult to define Unclear business objectives Unclear solution feasibility Stakeholders difficult to identify Unclear dependencies/interrelationships Unclear project boundaries Unclear scope Unknown unknowns	Adaptive Focus on clear business objectives. Establish “innovation teams”. Apply edge-of-chaos management. Guide the group to creative decisions. Adopt professional business analysis practices: Feasibility analysis Root-cause analysis Value-chain analysis Business case development. Use techniques that foster creativity. Build a team that is “in the zone”. Conventional Establish clear business objectives. Conduct project risk analysis.

Managing the Complexities of Poorly Understood, Volatile Requirements

Project complexity ensues when requirements are unstable and poorly understood, functionality is complex, or customer/user support is insufficient.

“Individual requirements are rarely complex in themselves; it is the relationships and interdependencies between them that result in complexity—so it is these that need to be spotted and managed.”
—Dan Rossner, PA Consulting Group

Defining and managing requirements is hard—very hard—for many reasons. The complexity of the requirements management effort is rooted in widespread deficiencies in requirements practices, inadequate involvement by key stakeholders, and numerous interdependencies among individual requirements. Consider the following:

MANAGING PROJECTS WITH POORLY UNDERSTOOD, VOLATILE REQUIREMENTS
Complexities	Management Approaches
Requirements alone are not complex; it is the interdependencies and interrelationships that make them complex: Inconsistent expectations Insufficient/sporadic stakeholder involvement, leading to missed, ambiguous, and incomplete information Deficient/inadequate practices, causing defect-laden requirements Unknown unknowns Requirement complexities: Ambiguity Interdependencies Interrelationships Boundaries Overlaps Inconsistencies Changes Traceability.	Adaptive Use professional business analysis practices. Establish requirements integration teams. Minimize scope. Use agile requirements analysis Test-driven requirements development Iteration/incremental development Visualization/visual control. Define at the appropriate level of detail. Establish a requirements knowledge management system. Communicate the right message to the right audience to continually validate requirements. Conventional Involve customers/users throughout the project. Manage changes.

Managing the Complexities of High-Visibility Strategic Projects with Political Implications

Strategic projects are by their very nature politically sensitive. Every organization has undefined political processes and ever-present power struggles. Political maneuvers can be stifling and overwhelming to a project, and can even lead to project failure. Strategies can shift, causing virtually every aspect of the project to change. Project stakeholders often have conflicting expectations. Techniques include:

MANAGING POLITICALLY SENSITIVE STRATEGIC PROJECTS
Complexities	Management Approaches
Constant change caused by: Political maneuvers Power struggles Changing strategies Changing expectations Inconsistent expectations Multiple stakeholder group interrelationships Political sensitivity	Adaptive Establish a political management strategy and plan. Establish an executive steering committee with effective decision-making. Focus on networking, relationship-building. Seek a mentor and coach. Manage customer relationships. Become a public relations expert: Promote project Promote self. Focus on business benefits. Manage virtual alliances. Involve customers and users in every aspect of the project. Leverage the authority of the functional managers. Conventional Establish strong executive sponsorship and executive oversight. Devote considerable attention to managing stakeholders and their expectations.

Managing Large-Scale Organizational Change

Large-scale organizational change typically involves new technologies, mergers and acquisitions, restructurings, new strategies, cultural transformation, globalization, new partnerships, and/or e-business. Handling change well can mean the difference between success and failure of a project, and consequently, of an organization. Techniques offered by the change-management guru include (Kotter, 2002):

MANAGING LARGE-SCALE CHANGE INITIATIVES
Complexities	Management Approaches
Unpredictable human emotions Resistance to change causing anxiety, tension, anger, pride, arrogance, cynicism, exhaustion, insecurity Complacency and loss of support, leading to isolation of project team No executive guiding coalition, causing inconsistent management behaviors Unclear vision; current culture blocks the new vision	Adaptive Establish a cultural change framework. Create a sense of urgency. Build an influential guiding team. Establish a clear, compelling vision. Communicate for buy-in. Empower stakeholders for action. Deliver short-term wins. Use external and internal incentives. Conduct rigorous industry analysis. Prototype new products. Conventional Manage dependencies. Conduct research, due diligence, and analysis.

Managing Complex Dependencies and External Constraints

Large-scale change inevitably involves cross-functional dependencies, external constraints, and changes to the external environment that will need to be identified, owned, and managed by a senior person on the project leadership team. Experience has demonstrated that these dependencies and constraints are dynamic and are sometimes difficult to identify. They are likely to change not only throughout the project, but also after the new solution has been deployed. Considerations include:

MANAGING PROJECTS WITH COMPLEX DEPENDENCIES AND EXTERNAL CONSTRAINTS
Complexities	Management Approaches
Unknown dependencies Unknown constraints Interrelating constraints Unpredictable reactions to interventions Unintended consequences Outsourced team dependency Unpredictable human behaviors Significant level of IT complexity Multiple contractors Large number of teams Multiple project plans High visibility Sensitivity to political, environmental and social issues	Adaptive Manage uncertainties. Assign owners to dependencies. Adapt to new practices. Establish a framework for managing external partner dependencies: Supplier partnerships Integrated design teams Governance Management Technical Management. Conventional Manage risks. Conduct contract negotiations. Manage contacts.

Managing IT Complexity

Complexity of IT projects comes in many flavors, both technical and managerial. In addition, there is a great deal of pressure to build the next generation of IT systems that are expected to be agile and easily changed. Consider these approaches:

MANAGING PROJECTS WITH SIGNIFICANT IT COMPLEXITY
Complexities	Management Approaches
Technical Collection of systems functioning together to achieve a common mission Integration issues Unproven technology Managerial Multiple contractors A large and diverse project team A central master plan with separate plans for subprojects Highly visible and sensitive to political, environmental, and social issues Agility Intelligent Adaptable Innovative Easily changes	Adaptive Management Techniques Build Solutions that Empower Customers. Establish “Skunk Works” Teams. Exploit the Advantages of Edge-Of-Chaos Management. Introduce a Last-Responsible-Moment Decision Making Process. Structure the Effort into Micro Projects. Create Communities Of Practice and Diversity Of Thought. Ensure Your IT Architect is Seasoned. Forge New Partnerships. Set Up Integration Teams. Strike the Right Balance Between Discipline and Agility. Complexity-Reducing Design Techniques Limit Solution Component Dependencies. Make Use of Enabling solution Design Tools. Design for People – Build for Change. Technologies That Enable Change Service Oriented Architecture (SOA). Business Process Management (BPM). Web 2.0 Development. Unified Communications (UC).

Conclusion

Complex project management is sensible chaos—striking the right balance between plans (static) and process (dynamic). We recommend using some conventional project management techniques along with some complexity thinking techniques that are “on the edge of chaos” to manage changes and uncertainties and to foster creativity and innovation.

References
Lissack, Michael R., Roos, Johan. (2002) The Next Common Sense, The e-Manager’s Guide to Mastering Complexity. London, UK: Nicholas Brealey Publishing
Rind, D. (2 April 1999), Complexity and Climate, Science Magazine, Complex Systems Special Issue, 2 April 1999: Vol. 284. no. 5411, pp. 105 – 107
Alawneh, Luay, Debbabi, Jarraya, Yosr, Soeanu, Andrei, Hassayne, Fawzi. A Unified Approach for Verification and Validation of Systems and Software Engineering Models, 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS’06) pp. 409-418
New York Times, 11 July 2002 “Cost overruns (totally hundreds of billions of dollars) for large public works projects have stayed largely constant for most the last century.”
Mooz, Hal, Forsberg, Kevin, Cotterman, Howard, (2003). Communicating Project Management, Hoboken, New Jersey: John Wiley & Sons,
Porter, Michael. (1985) Competitive Advantage: Creating and Sustaining Superior Performance. New York, NY: Simon and Shuster Inc.
Lippert, M., Roock, S., Wolf, H., Züllighoven, H. XP in Complex Project Settings: Some Extensions, In: Informatik/Informatique. Schweizerischer Verband der Informatikorganisationen. Nr. 2, April, 2002.
Ambler, Scott W. Agile Analysis. http://www.agilemodeling.com/essays/agileAnalysis.htm
Kotter, John P. (2002) Getting to the Heart of How to Make Change Happen. Boston, MA: Harvard Business School Press

---

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.

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.