Author: Robert Wysocki

OUTSIDE THE BOX Forum: When is Agile Required?

We’ve all read articles that talk about choosing between traditional approaches and agile approaches.

Traditional projects can use an agile approach but agile projects cannot use a traditional approach.

There are some projects where that choice is a valid concern. But there are projects where some type of agile approach is not an option. It is a requirement. These are projects where the goal and/or the solution are not clearly defined or understood. In such cases, the discovery of the missing piece(s) must be imbedded in the work of the project and that can only be achieved through some form of iterative process. Each iteration is an attempt to learn or discover missing parts of the goal and/or solution. After some number of iterations, the goal and solution will be clearly known. To avoid an agile approach some traditionalists might try to jury rig their favorite waterfall model but that thinking is seriously flawed.

So complexity and uncertainty are the factors that lead to the conclusion that some type of agile approach is needed. But agile is a journey, not a destination. There are several different agile approaches. So how do we choose the one that is the best fit given the project characteristics? Let’s try to answer that question.

THE COMPLEX PROJECT LANDSCAPE

The most intuitive illustration of the situation is the four-quadrant landscape defined by the two project characteristics: goal and solution. Every project has a goal and a solution to achieve that goal. Complex projects lack some clarity of goal, solution, or both and are found in Quadrants 2, 3 or 4. All of them will require some type of agile model.

Wysocki 09182018 aFigure 1: The Complex Project Landscape

Agile Models Ranked from Mostly Defined to Mostly Undefined

After 25 years of client engagements where all types of agile projects were planned and executed I have adopted a ranking from mostly defined to mostly undefined. You might also use least complex/most certain to most complex/least certain. This is not an objective ranking. There are at least a dozen models that could be included. I’ve only chosen five for this article to illustrate the point. Each is briefly discussed. For a more complete treatment see [Wysocki, 2013]. The ranking is quite subjective but based on my personal experiences in using the models. There are also variants of each of these that affect their application.

Prototyping

This is a tried and true approach couched in the language of the client. There are a variety of variations from iconic models to production models. Prototyping is a very robust tool with a long history of uses including even the most complex and uncertain of project situations. Those would be situations where the project manager is using prototypes to suggest a starting point for the client to get on board with the search for a solution. Prototyping is a tool that keeps the client in their comfort zone during that search. It is quick and simple. There are several software applications that can generate and modify prototypes in real time.

Evolutionary Development Waterfall

The only reason for using this is that it keeps the development team in their comfort zone. Project teams that have a long history of using the Waterfall Model will often choose this as their first step towards an agile environment. Unfortunately that is probably the only reason for using it when the situation calls for an agile model. It is very inefficient and wasteful of resources and time.


Advertisement

Scrum

The agile project world is dominated by Scrum [Schwaber and Beedle, 2001]. It is a sound model that keeps the client in charge through the Product Owner. That is, if you have a properly skilled Product Owner. Of all the common development models Scrum is a customer-driven model. Scrum does not have a project manager but the role is subsumed primarily by the team of senior developers, which operates as a self-managed and self-directed team. Co-location of the team is a critical component. Scrum teams tend to be small (less than 10 members). The temptation is to equate Agile to Scrum. There are many agile models of which Scrum is the most popular but the complex project landscape is broad and deep and can validly support a much richer portfolio than just Scrum.

Dynamic Systems Development Method (DSDM)

This model is popular in the EU [Stapleton, 2003]. At any point during implementation it allows the team to return to any previous stage in the design, development and deployment of the solution. DSDM is what the Waterfall Model would look like in a zero gravity world.

Effective Complex Project Management (ECPM) Framework

This is the new kid on the block [Wysocki, 2014] and [Wysocki, 2016]. It isn’t a model in the sense of the above. Rather it is a framework (Figure 2) that embraces a portfolio of models and a decision process for choosing and adapting the best fit model from the portfolio.

Wysocki 09182018 bFigure 2: The ECPM Framework

It can be used for any agile project but is most useful when so little is known about the goal and/or solution that choosing and adapting the best fit model is not much more than a coin toss. it offers a decision model to help in that choice. The major advantage of using the ECPM Framework is that is designed to include the meaningful involvement of the client. ECPM is also a significant step towards establishing a collaborative project environment. Scrum includes that involvement through the Product Owner. The other models do not have meaningful client involvement as a design feature.

PUTTING IT ALL TOGETHER

All of these models and others should be included in the organization’s portfolio and the best fit one chosen based on the project’s characteristics, the organizational environment and culture in which the project will be executed and the market conditions the prevail. The specific types of projects the organization encounters might suggest that other models be included as well as customized models the organization has developed for repeatable projects. Choosing the best fit model is a multi-criteria decision. Preferences and availabilities have a lot to do with the choice. For example, Scrum requires more senior level developers because the projects are self-managed and self-directed. In the absence of senior level developers Scrum would not be a good choice.

[Schwaber and Beedle, 2001] Schwaber, Ken and Mike Beedle, 2001. Agile Software Development with Scrum, Pearson.
[Stapleton, 2003] Stapleton, Jennifer, ed., 2003. DSDM: Business Focused Development, 2nd Edition, Pearson Education
[Wysocki, 2013] Wysocki, Robert K., 2013. Effective Project Management: Traditional, Agile, Extreme. 7th Edition, John Wiley & Sons.
[Wysocki, 2014] Wysocki, Robert K., 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing
[Wysocki, 2016] Wysocki, Robert K. and Colin Bentley, 2016. Global Complex Project Management: An Integrated Adaptive Agile and PRINCE2 LEAN Framework for Achieving Success, J. Ross Publishing

OUTSIDE THE BOX Forum: Becoming Customer-based and Technology-driven is a Survival Strategy for the Digital Economy

the digital world stand-out organizations are continuously evolving towards customer-based and technology-driven approaches.

These evolutions can be disruptive and to be successful demands an organized approach. Transformations needed to achieve this end state can have a disruptive impact on how projects, programs and portfolios are proposed, prioritized and managed. Perhaps with the exception of IT the project management communities have been slow to react. Many organizations are neither customer-based nor technology-driven. This might be their goal but they have no sense of how to do it. Their strategies are usually incremental strategies. That has to change to survive but how should or could that happen. There are lots of moving parts to consider. This article is a step outside that box to launch that conversation. It will identify the first of those challenges and how to address it.

What is a Digital Enterprise?

The transition to a customer-based and technology-driven organization requires a number of fundamental changes to how the organization operates. These transitions are not new and can be traced back to the 1970s under the label of End User Computing. Those who were there can attest to the confusions that resulted. Understand at the outset that this evolving world by its very nature is a high-risk world. It is a world populated by new products and processes and new partnerships both internal to the organization as well as external to the organization. To be successful requires project management approaches that are flexible, adaptive and creative. This is clearly some type of agile world but with new challenges. The first of those challenges is to become customer-based. The customer is no longer an after-thought but rather is seen as an active participant in all business processes.

Who is a Customer?

As for a working definition, the customer is the owner of the deliverables provided by the project. They could be internal or external customers.

Internal Customers

These customers are known. They have faces and names and you can communicate directly with them from the first day of their request to the last day of their use of the project deliverables. They could be individuals (C-level executives, directors, functional managers, LOB managers, resource managers, business unit managers, etc.) or groups of employees (sales representatives, trainers, etc.).

External Customers

These customers are generally not known unless they identify themselves through feedback (good or bad). Think of them as the end user of the product or service delivered by the project.

What is a Customer-based Enterprise?

At the highest level to be customer-based is to be an enterprise that practices meaningful customer involvement across the life span of projects, programs and portfolios. The life span is comprehensive. At the project level a 3-phase robust process can be defined as the architecture for a customer-based environment as follows:

  •  Ideation Phase
  •  Set-up Phase
  •  Execution Phase

However, you might define this process for a specific project in order to embrace meaningful customer involvement it must be:

  •  Adaptive
  •  Flexible
  •  Creative

Advertisement

What is Meaningful Customer Involvement?

Having your customer sign-off on a specification document or acceptance test is involvement but it is not meaningful involvement. To be meaningful the customer involvement must include full-time participation in the project that will deliver a process or product for their direct use. That participation should include decision-making authority and responsibility. The Product Owner in a Scrum Project is the closest example of that meaningful involvement. However, their involvement does not extend beyond the planning activities of the project deliverables. If their involvement extended into the Execution Phase as a decision-maker, that comes closer to a customer-based environment. An example of that customer-based team environment is shown in Figure 1.

Wysocki 09052018 1
Figure 1: Co-Manager Model

The Process Co-Manager is much like the typical project manager we have had in place for some time with one exception. The Process Co-Manager share authority and decision-making responsibility with the Product Co-Manager. The Product Co-Manager represents the Customer and has the authority to act on behalf of the Customer whether internal or external.

On Becoming Customer-based and Technology-Driven

This is not an easy transformation. It won’t happen by next Tuesday. It is a process that requires a village to happen. The end state must be defined at the outset and supported throughout the enterprise. Its implementation can be top down or bottom up.

Top Down Implementation

It begins with a strategic plan. The Objective/Strategy/Tactics (OST) Model shown in Figure 2 is a good example of a top down approach.

Wysocki 09052018 2Figure 2: The OST Model

The OST Model can be used to completely reconfigure the enterprise to be a digital enterprise. It requires active support from the very top of the enterprise. It is a series of process steps that will usually occupy several planning cycles as the number of transformations will span the business processes and all lines of business.

Bottom Up Implementation

It begins with a demonstration project in a single line of business. It could be a new or existing line of business. A bottom up progression is a less aggressive form of transformation as it will involve probably a single line of business or a single functional area of the enterprise. It is a good learning experience for the organization too.

If the enterprise is entertaining a new line of business that is customer-driven and technology-based a bottom up implementation process might be the best choice. It can be done independent of the remaining business processes and practices. It can also be considered as a learning experience for the enterprise.

Putting It All Together

Let’s be very clear, despite the fact that the digital transformation can be dated to the 1970s its impact on both project management and business analysis processes and practices is just getting started. From a process perspective not much has been done. From a practice perspective most of what has been done is not published but remains as proprietary. This article is one of many designed to promote that process effort. The newsletter HPW Newsletter (see www.eiipubs.com) traces that history.

What is Meaningful Customer Involvement?
Having your customer sign-off on a specification document or acceptance test is involvement but it is not meaningful involvement. To be meaningful the customer involvement must include full-time participation in the project that will deliver a process or product for their direct use. That participation should include decision-making authority and responsibility. The Product Owner in a Scrum Project is the closest example of that meaningful involvement. However, their involvement does not extend beyond the planning activities of the project deliverables. If their involvement extended into the Execution Phase as a decision-maker, that comes closer to a customer-based environment. An example of that customer-based team environment is shown in Figure 1.

Figure 1: Co-Manager Model
The Process Co-Manager is much like the typical project manager we have had in place for some time with one exception. The Process Co-Manager share authority and decision-making responsibility with the Product Co-Manager. The Product Co-Manager represents the Customer and has the authority to act on behalf of the Customer whether internal or external.

On Becoming Customer-based and Technology-Driven
This is not an easy transformation. It won’t happen by next Tuesday. It is a process that requires a village to happen. The end state must be defined at the outset and supported throughout the enterprise. Its implementation can be top down or bottom up.

Top Down Implementation
It begins with a strategic plan. The Objective/Strategy/Tactics (OST) Model shown in Figure 2 is a good example of a top down approach.

Figure 2: The OST Model

The OST Model can be used to completely reconfigure the enterprise to be a digital enterprise. It requires active support from the very top of the enterprise. It is a series of process steps that will usually occupy several planning cycles as the number of transformations will span the business processes and all lines of business.

Bottom Up Implementation
It begins with a demonstration project in a single line of business. It could be a new or existing line of business. A bottom up progression is a less aggressive form of transformation as it will involve probably a single line of business or a single functional area of the enterprise. It is a good learning experience for the organization too.

If the enterprise is entertaining a new line of business that is customer-driven and technology-based a bottom up implementation process might be the best choice. It can be done independent of the remaining business processes and practices. It can also be considered as a learning experience for the enterprise.

Putting It All Together
Let’s be very clear, despite the fact that the digital transformation can be dated to the 1970s its impact on both project management and business analysis processes and practices is just getting started. From a process perspective not much has been done. From a practice perspective most of what has been done is not published but remains as proprietary. This article is one of many designed to promote that process effort. The newsletter HPW Newsletter (see www.eiipubs.com) traces that history.

OUTSIDE THE BOX Forum: Waterfall + Agile ≠ Hybrid

The label “Hybrid Project Management” has been applied to projects that use Waterfall followed by Agile.

That is too restrictive and does not allow for the flexibility, adaptability and creativity required of most complex projects that arise in the digital world. Rather the term, Hybrid Project Management should be reserved to those projects which do not fit any known methodology like Waterfall, Scrum, DSDM, Prince2 or any one of the dozens of other models. These projects being unique require that a unique management approach be designed to fit their unique situation. That unique situation can be defined by the project characteristics, the organizational environment within which the project will be executed and the market situation where the deliverables will be deployed.

A USEFUL DEFINITION OF A HYBRID PROJECT

For some obscure reason hybrid project management was defined as an integration of Waterfall followed by Agile before any definition of what constitutes a hybrid project. Organizations have spent years and lots of money designing project management models. Their inventories will include versions of the Waterfall Model along with one or more versions of Scrum, FDD, DSDM and perhaps other agile models. So, CMMI Maturity Level 2 is well established but, according to Mulally, is seldom used. Assuming we have competent project managers, it is safe to assume they have found other alternatives than those provided by their organization and defined in the project management body of knowledge. Those alternatives are probably variations of what their organization has provided. These alternatives are not published but travel below the radar but it is safe to assume that these alternatives align with these three factors:

  • the behavioral and physical characteristics of the project
  • the organizational environment in which the project will be executed
  • the external supply/demand markets for the deliverables

All three of these are dynamic. They can change at any time and in unexpected ways. When any one of the factors change, the specific project management approach designed by the HPMgr might also need to change. The objective is to maintain the alignment of the project management approach to the project in order to achieve maximum business value and minimization of the risk of project failure. In other words, projects are unique and so should the best fit model for managing them also be unique. That is the basic principle underlying a hybrid approach and sets the stage for defining HPMgt.


Advertisement

HYBRID PROJECT MANAGEMENT FRAMEWORK

According to David Robins [Robins, 2016] HPMgt is built upon traditional project management (TPMgt) to get the project started and agile Project Management (aPMgt) to execute the project. Agile is a class of project management methodologies and therefore is not capitalized. According to Robins each hybrid project beings with the Work Breakdown Structure (WBS) from TPMgt and then uses agile practices such as Scrum from aPMgt to build the deliverables. That is too restrictive. A hybrid project is unique as defined by the three factors above and the Hybrid Project Manager (HPMgr) will find it necessary to take exceptions due to those three factors. Robin’s model is too restrictive as it forces the project to align to a specific model. The model should be defined to align to the project. The correct HPMgt is a richer framework which is defined by a vetted portfolio of tools, templates and processes from which the project team constructs a unique project management approach. This framework supports every project from a very informal approach to managing a simple project to a very formal approach to managing a very complex project. Robin’s model is far too restrictive to allow such flexibility and adaptability.

In order to achieve and maintain the alignment to any project a robust HPMgt Framework must be defined. At the highest level of abstraction, a robust framework must have these 3 phases:

  • Ideation Phase
  • Set-up Phase
  • Execution Phase

These were defined in an earlier work [Wysocki, 2014]. For the HPMGT Framework this is the starting point for further development. The development is unique in that it will always be robust. The days of fixed methodologies are gone. The ones we do have are relegated to template status. Organizations that are transforming to the digital world will find HPMgt Framework as the only way to manage projects.

BENEFITS OF THE HPMgt FRAMEWORK

Project Management Methodologies have traditionally been defined for classes of projects. They work as long as the project meets the pre-requisites specified by the methodology. That may happen in some cases but what about those projects which do not meet the pre-requisites. [Mulally, 2017] found that those projects may in fact be the vast majority of projects. He estimates that less than 2% of organizations are at CMMI Maturity Level 3 or greater. Does that mean that 98% of projects fail to meet the stated pre-requisities. Probably not, but what are these organizations doing? According to my definition they are probably doing HPMgt!

Assuming you buy my definition of the HPMgt Framework, we have a lot work to do to define this new approach to project management. It is an approach where the unique project is used to define the unique approach to managing it. If you are using HPMgt, you will not need any pre-defined methodologies. The methodologies that you do have (such as Waterfall, Scrum, DSDM, FDD and dozens of others) should be seen as templates from which a unique approach can be crafted. For example, lacking a Product Owner you might use Scrum but use a BA as the Product Owner. WalMart has a very similar situation that frequently uses this adaptation.

REFERENCES
[Mulally, 2017] Mulally, Mark, 2017. All is not the same in the World of Project Management, ProjectManagement.com, 3/27/17
[Robins, 2016] Robins, David, 2016. Introduction to Hybrid project management methodology, (HTTPS://WWW.BINFIRE.COM/AUTHOR/DAVID/)
[Wysocki, 2014] Wysocki, Robert K., 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing. 
[Wysocki, 2019] Wysocki, Robert K., 2019. Effective Project Management: Traditional, Agile, Extreme, Hybrid, 8th Edition (EII Publications, forthcoming)

OUTSIDE THE BOX Forum: The Iron Triangle is Obsolete – Long Live the Scope Triangle, Part 2 of 2

The Scope Bank is unique to the Effective Complex Project Management (ECPM) Framework, and it functions as the traffic cop and depository of the solution discovery and development history.

The Scope Bank is the clearinghouse for all project activities. It brings together in one place solution status, cycle performance history, potential solution components and a foundation for cycle management of the project. It is the basis for problem resolution, decision making, resource management and just-in-time planning.

The Scope Bank is always up to date at decision time. In the ECPM Framework, the Scope Bank is much like a tool whose purpose is to direct the deliverables coming out of all completed cycles and plan for the deliverables to be developed in the following cycles.

Scope change requests will arise at any time during a cycle but their resolution is held until the cycle is complete and its deliverables reviewed. There will be situations where an ECPM cycle is not completed. In these situations, the deliverables that were not complete are returned to the Scope Bank for further prioritization and scheduling. The ECPM Framework cycle duration is sacrosanct. It ends as planned and not an hour later.

The Scope Bank has been a major artifact of the ECPM Framework and has every indication that it can bring added value to the processes and practices of its projects.

SCOPE BANK

The Scope Bank is the single depository for the current requirements. It contains open change requests, the current solution, and all learning and discovery that has been accumulated from all cycles that have not yet been acted upon. This includes all unresolved change requests. The Scope Bank is unique to the ECPM Framework and is an essential part of the portfolio of tools, templates, and processes that support the ECPM Framework.

Nothing should ever be removed from the Scope Bank unless it is built into the solution. So, it still remains in the Scope Bank but from a different perspective. An idea once suggested and thought to be of no use early in the project might later turn out to be just the opposite. In some cases, I have seen a previously rejected idea suggest a new idea that leads to new features and functions added to the solution. So, the message is that every idea is a good idea, we just haven’t figured out how – yet! If it isn’t in the Scope Bank, it will have been forgotten and no longer of any value to the solution.

The Scope Bank is the primary input to the Client Checkpoint in the ECPM Framework. The contents of the Scope Bank are updated at the completion of each cycle. The contents include future Integrative Swim Lanes and ideas for future Probative Swim Lanes. Since there are fixed resources for the next cycle, the contents of these two types of swim lanes must be jointly prioritized. Depending on the degree to which the solution is complete, there will be a healthy mix of the two types of swim lanes.

The process of discovery and learning by the team is continuous throughout the cycle. Any new ideas or thoughts on functionality are simply recorded in the Scope Bank and saved for the Client Checkpoint Phase. The Scope Bank can physically be a list posted in the Team War Room, or some electronic form (spreadsheet or word processing document). Whichever form you decide to use, make sure it is always visible to the team.

For the cycle just completed, the cycle plan called for a specific list of functions and features to be added to the deliverables through one or more Integrative Swim Lanes. No schedule or scope changes were allowed during the cycle, yet it is possible that not all the planned functions and features actually made it into the deliverables. There are several reasons for that, which we will not discuss. They are obvious reasons (e.g., schedule slippages that could not be recovered, a discovery that rendered the functionality unnecessary), which occur in all projects. The ECPM Framework accommodates these anomalies without skipping a beat. Any functions or features not completed in the just-completed cycle are returned to the Scope Bank and prioritized for consideration in a future cycle.

SCOPE BANK CONTENTS

The following presents a brief discussion of each of the items that are in the Scope Bank at any point during the project lifespan. The item descriptors listed above are most useful for scope change requests and processing but otherwise are provided as appropriate.

Current Solution

Complex projects are high-risk projects. That means they could be delayed or even terminated at any point in time. To minimize any potential business losses every cycle ends with an updated production ready solution. That solution is not complete but at least any business value that can be generated from it will be generated if the project is terminated and the solution deployed. While the expected return on investment for a completely acceptable solution may not have been realized at least there is some return on investment.

There are several factors that are at play for a favorable deployment decision. Three are important here:

  • The Enterprise Release Schedule
  • The Business Value from the Current Solution
  • The Challenge of Deploying the Current Solution
    • Support costs for multiple solutions
    • Frequent process or practice changes
    • Maintaining multiple versions of documentation

Requirements

Plan-driven project management models include complete requirements specification as a pre-requisite to the planning effort. That has forced guessing which leads to several requirements revisions during project execution and hence to plan revisions. There is a lot of waste and non-value-added work in such approaches. This is not in keeping with lean practices.


Advertisement

Requirements and their elicitation have been a major obstacle to project management for several reasons:

  • In the complex project landscape, the upfront identification of requirements is unlikely because either or both of the goal or solution are usually not completely known.
  • Complete requirements specifications are learned and discovered during project execution.
  • The world is dynamic and ever-changing and doesn’t stand still just because you are managing a project.

The ECPM Framework has mitigated this obstacle by modifying the accepted definition of a requirement. This definition begins with a high-level description of what an acceptable solution must provide from a performance aspect. In some cases, it defines what an acceptable solution must contain without any performance criteria added. To wit:

DEFINITION: ECPM Framework High-level Requirement
A specific end-state condition whose successful integration into the solution delivers specific, measurable, and incremental business value to the organization. 
The set of ECPM Framework high-level requirements forms a necessary and sufficient set for the attainment of all project success criteria and the delivery of the expected business value.

At any point during the project life span the solution is such that requirements are either:

  • Integrated into the solution
  • Under development for future integration into the solution
  • Not yet approved for integration into the solution but requires further study and analysis
  • Unlikely to be integrated into the solution without compromise

Change Requests

Every cycle will result in new learning and discovery. This will result in requests for changes to requirements, functionality or other project adjustments. The changes might suggest changes to what has already been identified for addition to the solution or changes to potential solution components. They will usually arise from the client members of the project team. The intake process involves documenting them and adding them to the Scope Bank following the cycle in which they first arose. This list is cumulative and includes:

  • Change requests not yet acted upon
  • Change requests scheduled for integration
  • Change requests in the solution

Integrative Swim Lanes

Once a deliverable has been approved for integration into the solution it is prioritized along with others to be included in the solution. That prioritization is usually business value based but other technical considerations will usually determine the cycle in which it will be included.

Built and scheduled for integration

Much like any Scope Change, the schedule is based on technical rather than business criteria. There will be exceptions when the expected business value or marketing benefits exceed the cost of implementation.

Integrated into the solution

It is important that the history of integrated change requests be kept for later reference. Project performance reports may well quantitatively compare that history at the cycle level.

Probative Swim Lanes

Probative Swim Lanes are unique to the ECPM Framework. They include a variety of experiments and other research projects. Most statisticians would see Probative Swim Lanes as just another design of experiments. I am one of those statisticians and would call Probative Swim Lanes primitive designs of experiments. Whatever you choose to call them, the idea here is to preserve the lean characteristics of the ECPM Framework. Probative Swim Lanes are often one of the following:

  • prototyping – trying out a number of ideas using different models
  • brainstorming – discussing alternatives and formulating approaches
  • researching – gathering information on possible approaches

The incremental search for a solution is that Probative Swim Lanes are sequentially linked. The objective is to spend time and money incrementally as ideas develop and earn further expense and time allocations rather than all at once on an untested idea. This is in keeping with the lean characteristics of the ECPM Framework.

Completed but not yet acted upon

Probative Swim Lanes can result in either solution increments to be built (future Integrative Swim Lanes) or result in dead ends (Probative Swim Lane Archives). In both cases that history must be preserved. It is the best intelligence the project team will have as far as suggesting and executing future Probative Swim Lanes.

Active investigation

The history of a single Probative Swim Lane may include several efforts. Not until a decision is reached is that effort reaches a decision point.

Defined but not yet been scheduled

Probative Swim Lanes that result in future additions to the solution have to first be added into the prioritized Integrative Swim Lane list.

PUTTING IT ALL TOGETHER

The Scope Bank is the solution history of the project from its inception. The plans and deliverables from all of the completed cycles are recorded there. All of the change requests and their resolution are also documented. Cumulatively this information is the best available for cycle planning.

OUTSIDE THE BOX Forum: The Iron Triangle is Obsolete – Long Live the Scope Triangle, Part 1 of 2

The Scope Triangle is an interesting artifact of project management planning.

The term is not used in PMI’s PMBOK® Sixth Edition. The closest the PMBOK comes is to list scope, quality, schedule, budget, resources and risk as the constraints that impact the project. PMBOK goes on to say that these constraints form an interdependent set in that if one changes at least one other will be affected. In this 3-part article paper we will develop the Scope Triangle and show how it can be used in project management training.

Representing the Project

There are two ways to graphically envision the project that have been described in the literature. They are briefly described below.

The Iron Triangle

I cannot find the source for this term but it has come to mean the relationship between cost, time and scope (Figure 1). As is the case with the six constraints identified in PMBOK these three constraints also form an interdependent set. Specify any two and the third is determined. Or to put it another way if your manager says something like “I want you to develop a web-based order entry system for the new widget line and I will need it operational in 2 months. You have a budget of $50,000 to cover all one-time development costs,” you probably can’t do it. The chances that these three constraints form a consistent set are unlikely. Better would be “I need you to develop and order entry system for the new widget line and I need it operational in 2 months. How much will it cost to develop?”

wysocki 07092018aFigure 1: The Iron Triangle

While Figure 1 may be an intuitive way to envision the project plan it has little value in project execution.

The Scope Triangle

The Scope Triangle (Figure 2) was first introduced in my training programs in the 1980s and subsequently published it in the first edition of my book “Effective Project Management: How to Plan, Manage, and Deliver Projects on Time and within Budget,” (Wysocki, Robert K, Robert Beck, Jr. and David B. Crane, 1995, New York, NY: John Wiley & Sons, Inc. ISBN 0-471-11521-5). The intention then was to illustrate with a simple graphic that the project plan was a system in balance, at least on day one of the project.

wysocki 07092018cFigure 2: The Scope Triangle

The interpretation is rather intuitive, which is why there has been excellent instructional value in using it. The Scope and Quality are exactly bounded by the length of the three sides of the triangle representing cost, time and resource availability. Don’t try to draw the Scope Triangle. It is conceptual only. Given that the project plan makes sense on day one of the project the project plan is a system in balance. If any one of the five variables changes, at least one other variable must change in order to restore balance to the system. For example, if the client changes the due date of the deliverables to an earlier date, the length of the time side is reduced and the three sides no longer enclose Scope and Quality. To restore balance to the system anyone of several variables could change. For example, Scope could be reduced or the budget increased to hire outside contractors or some combination of the two.

Figure 2 is a useful way to envision the project plan and it has good value in maintaining the project plan, handling problem situations and managing scope change requests as is discussed below.


Advertisement

Using the Scope Triangle as a Management Tool

The Scope Triangle has been used in training programs for over 25 years. It is a good model in which to imbed and teach the following three project management activities.

Managing Scope Change

In the traditional approaches to project management a formal scope change process is needed. Most processes start with a request from the client. The appropriate team member will analyze the request and issue a Project Impact Statement in which alternatives and their impact on the project plan are documented. The client chooses one and the project plan is updated to reflect the chosen alternative.

The Scope Triangle is used to prioritize the alternatives from those that affect only the project team and the resources it controls to those that affect the resource managers to those that affect the client through added cost or schedule adjustments.

Resolving Problems

Problems are sure to arise in even the best planned projects. Schedule delays, supplier shipment errors, loss of a scarce resource and a variety of risks that materialize and must be handled. There is a hierarchy of resolutions (related to the Scope Triangle) that are offered in the order listed:

  • Accommodated within project resources and timelines
  • Accommodated but will require extension of deliverable schedule
  • Accommodated within the current deliverable schedule but additional resources will be needed
  • Accommodated but additional resources and extension of deliverable schedule will be needed
  • Accommodated with multiple releases and prioritization of deliverables across release dates
  • Cannot be accommodated without significant change to the project

Representing the Project Portfolio

Recent application of the Scope Triangle deal with some basic concepts of project portfolio management especially agile portfolio management. In the Scope Triangle shown in Figure 2 replace the inside of the triangle with all of the projects vying for inclusion in the portfolio. The initial proposed projects will most likely require more time, or money or more human resources available at that time.

wysocki 07092018bFigure 3: Project Portfolio Management

Think of removing the proposed projects in some reversed prioritized order until each of the three bounding constraints are all met. The prioritized order will be based on some combination of risk and business value.

Putting It All Together

The Scope Triangle is a valuable tool for teaching scope management, problem resolution and portfolio management concepts. It is an intuitive graphic that every project manager should burn into their brain to help them approach the three applications with a much better strategy.