Skip to main content

Author: Robert Wysocki

Out of the Box Forum: Designing Project Management Methodologies is a Waste of Time

The project landscape is becoming more complex and uncertain.

The frequency of unknown unknowns is increasing. Risks are high in such a landscape.

These are undeniable facts. The likelihood that a predefined methodology will be robust enough to successfully manage these projects is rare. Flexibility and creativity must characterize every methodology to have any chance of it being useful. The same must be true of those who would manage such projects. If all you can do is use a recipe created by someone else to manage your projects, you will certainly fail.

This is a problem, and fortunately, it has a solution. My approach is founded upon the fact that complex and uncertain projects are unique, and the best way to manage them will also be unique.

Let me pose a management approach. My approach is based on first assessing and describing these three factors:

  • the characteristics of the project
  • the organizational environment in which the project will be executed
  • the stability of the market into which the project deliverables will be deployed

With this assessment in hand, the second step is to define the management approach that will accommodate this project situation. That assumes a vetted portfolio of tools, templates, and processes from which a “recipe” can be created to manage such a project situation. If all you have is Scrum in your vetted portfolio, you are in harm’s way and will almost surely fail. Scrum is excellent, but it cannot work for every project that might arise. If you add DSDM and FTP to your portfolio, you will have a better chance of success, and if you allow the project team to modify either Scrum or DSDM of FTP for this project, you will have an even better chance of success. You see where this is going?

The richer the vetted portfolio from which the recipe can be created, the better will be your chance of succeeding. The vetted portfolio that I use to help my clients design their own portfolios includes:

  • bodies of knowledge (PMBOK, IIBA, IPMA, etc.)
  • a specific set of methodologies (Scrum, FTP, etc.)
  • customized reports
  • business process models
  • Earned Value Analysis
  • process improvement programs
  • professional development program
  • problem-solving models
  • decision-making models
  • conflict resolution models
  • prioritization models
  • RASCI Matrix
  • Risk Management Matrix
  • other proprietary tools, templates, and processes

The project team uses the project assessment and this vetted portfolio and designs the best fit approach for managing their project. Every project will have its own approach, and every organization will have its own vetted portfolio.

This is only the start. We are talking about a very different type of project manager here. So a position family is needed and the support processes for it. An organizational infrastructure is required that includes a new type of PMO. The business model must also be aligned. But these are topics for future postings.

OUTSIDE THE BOX Forum

In 2010 the CEO Office at IBM published the results of a survey (IBM, 2010, Capitalizing on Complexity: Insights from the Global Chief Executive Officer Study, GBE03297-USEN-00, Somers, NY) they had conducted of 1541 CEOs from 60 countries.

Their major finding was that over 50% of the CEOs admitted that they were aware of the complex and uncertain environment in which they were forced to do business, but they were not prepared to deal with it, and they didn’t know what to do about it. They also expected complexity and uncertainty to continue to increase.

If that isn’t a clarion call to action from the project management community, I don’t know what is. To a large extent that call has been ignored until today. Join me and we can change that.

outsidethebox

OUTSIDE THE BOX Forum is my disruptive attempt to suggest how the project management community might address the global problem reported by IBM. I’m going to get your creative juices flowing by offering artifacts that have been used successfully in my ECPM Framework. Some of these artifacts are all situation and client-based, and many evolved over time. They are adaptive. They can be disruptive of common practices. But I have found situations where they have been successful too! We just need a strategy for using the right approach tailored to the right situation. I recognize the challenges we face and that the solutions are not always obvious. Many will continue to be elusive never be found unless we take that first step outside the box. This forum will be successful if you participate with me. I want to hear from you and your experiences stepping outside the box! Learning opportunities will arise, they are it is just another step on our journey to discovering those elusive solutions and responding to IBM’s call to action.

If you factor in the high failure rate of IT projects as reported by the Standish Group you should see the gravity of this global situation. But the response from our PM community has not happened. If you consider yourself to be a professional, you should have taken up the challenge to make a difference. This column is another chance to redeem yourself. It is my clarion call to you. The time has come for you to step up to the bar and do something!

My plan is to stoke the fires with a new posting once a month. Many of them will be derivatives from the IBM CEO Report. I have long been a proponent of outside the box thinking to solve project management process and practice problems. I will be sharing those with you with the expectations that you will respond in kind. Let’s take a brainstorming approach and find the much-needed process and practice solutions.

I won’t minimize the risks especially as we start our journey into the unknown unknowns. It is critical that you participate. I want to hear your thoughts about how we might direct this journey. And I promise an immediate response.

OUTSIDE THE BOX FORUM is a bold venture into the unknown. I expect to share a variety of disruptive ideas for your consideration. These ideas will address a number of open questions, issues, and challenges to complex project management. This effort will not succeed unless you participate with us. Help us out with your response to a most important question:

Improving PRINCE2 Project Manager Flexibility

One of the basic principles of the ECPM Framework is to protect the flexibility and decision-making authority of the Project Co-Managers. The vetted portfolio is the artifact that accomplishes this.

Every instantiation of the ECPM Framework in an organization includes a portfolio of vetted tools, templates, and processes from which a project manager chooses what will be used to manage their specific project. The ECPM Framework provides the template of contents for that portfolio. It is called the ECPM/kit and includes the following categories:

  • bodies of knowledge
  • a specific portfolio of PMLC Model Templates
  • vetted tools, templates, and processes
  • customized reports
  • business process models
  • process improvement program
  • professional development program
  • problem-solving process
  • decision-making process
  • RASCI Matrix

Related Article: Output Decisions From the Client Checkpoint

Every organization has its own culture, best practices, and business processes. Some will be commercial off-the-shelf products; others will be home grown and meet specific situations that may be unique to the organization. To plan and execute projects the organization will offer a portfolio of tools, templates, and processes that have been vetted for use by anyone in the organization. That vetting is often the responsibility of a Project Support Office (PSO). Because the portfolio includes only vetted items, their use will have been pre-approved. It is up to the co-managers to decide which to use given the situation they face. Additions to the vetted portfolio are always welcome as new employees are hired and new tools, templates, and processes are introduced by the thought leaders in their respective disciplines.

The vetted portfolio offers any project manager complete freedom to choose which to use among a set of pre-approved alternatives. Some organizations may require the manager to offer the rationale for their choices whenever those choices depart from common practice. Supporting that freedom is critical to the successful execution of complex projects. This is consistent with the cook/chef metaphor and is an essential characteristic of the complex project landscape.

THE ECPM FRAMEWORK KIT

The major strength of the ECPM Framework is that it places full control over the management of the project in the hands of the co-managers. But that control would be a ticket to chaos if it weren’t contained within a portfolio of vetted tools, templates, and processes. We call that portfolio the ECPM/kit. Having that portfolio in place and used presents several benefits and challenges to the organization:

  • The ECPM/kit contains all of the tools, templates, and processes that will be needed to satisfy the management requirements of any project that the organization might encounter.
  • The ECPM/kit includes a continuous improvement process that monitors project performance and provides an open environment for project performance enhancements.
  • The co-managers have a detailed working knowledge of the portfolio and how to adjust it to satisfy any project management requirements that might arise.
  • The co-managers have the authority and responsibility to do what makes sense for effective project management.

The creation of the ECPM/kit is an exercise that is included the workshop that was conducted to design and deploy the organization’s version of the ECPM Framework. The ECPM/kit is a dynamic entity. It is constantly updated with new ideas from the project teams, new employees and evolving industry processes and practices. If the PMO is the steward, their responsibility is to make sure the ECPM/kit is complete and doesn’t needlessly constrain the co-managers to less than optimal choices of alternatives.

MAINTAINING AND SUPPORTING THE ECPM/kit

The ECPM/kit must support all of the project management needs of every project. Built into the ECPM Framework is a continuous process improvement program shown in Figure 10.1

fig 10.1
Figure 10.1 ECPM Framework Continuous Process Improvement Program

Source: Wysocki, Robert K. and Steve Tendon, Patterns of Effective Complex Project Management: A Journey Towards a Hyper-productive End State (J. Ross Publishing, forthcoming)

The DOI (Declaration of Interdependence) Performance Assessment is the decision framework that drives the continuous process improvement program. It is instigated at the completion of each of the three stages of the ECPM Framework.

The six DOI Statements are:

We increase return on investment by making the continuous flow of value our focus.

The proper use of the Effective Complex Project Management (ECPM) Framework maximizes the Return on Investment (ROI) from several perspectives:

  • Each iteration not only moves closer to defining an acceptable solution but also delivers a production version of the current solution.
  • Each iteration includes a significant Client Checkpoint where the best fit alignment to the project and its environment is reconfirmed or adjusted.
  • Each iteration maintains its “lean” principles to avoid wasted time and cost.

We deliver reliable results by engaging customers in frequent interactions and shared ownership.

The ECPM Framework is designed around a collaborative and meaningful client involvement. Meaningful client involvement is the key to delivering reliable results. There are several examples of meaningful client involvement in the ECPM Framework:

  • Equal responsibility and authority between the parties comes directly from the ECPM Co-Manager Project Team Model. One manager pays attention to the process (the project manager). The other manager pays attention to the product (the client product manager).
  • An open and honest environment is the bedrock of a successful project result .

We expect uncertainty and manage for it through iterations, anticipation, and adaptation.

The complex project landscape is defined through not only its complex nature but also the uncertainty of change. That change arises from three dependent sources:

  • The changing priorities of the project in the program or portfolio wherein it resides.
  • The changing internal environment.
  • The changing external environment.

We know that all of these changes will occur, but we don’t know when and we don’t know what impact will result. That means our project management approach must be nimble and flexible.

We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.

An open and honest team environment is the key to releasing creativity and innovation. The ECPM Framework has a number of processes and practices that embolden creativity and innovation:

  • the ECPM Brainstorming Process
  • the use of Probative Swim Lanes for discovery
  • the use of ECPM Brainstorming for solution alternatives
  • establishing the open and honest team environment

We boost performance through group accountability for results and shared responsibility for team effectiveness.

Whatever the team produces is due to the efforts of all the team members pulling in the same direction. There are no “knights in shining armor.” ECPM includes a number of processes and practices that allow such behavior:

  • The ECPM Brainstorming Process is open and encourages every member to express their ideas and suggestions.
  • The ECPM Framework is based on individual accountability for results.

We improve effectiveness and reliability through situationally specific strategies, processes and practices.

The Patterns that describe the real value and benefits of the ECPM Framework through its adaptive and agile structure:

  • As internal and external situations change so do the strategies, processes, and practices that support those situations change

Improved Stage Planning: Output Decisions from the Client Checkpoint

In keeping with the Co-Manager model introduced in an earlier article, the Client Checkpoint is a major decision step in the ECPM Framework.

You can think of it as a StageGate that directs and channels project execution with the goal of maximizing delivered business value. Needless to say, meaningful client involvement in the Client Checkpoint is a Critical Success Factor (CSF) to the delivery of expected business value. The Client Checkpoint is structured around the well-known Input/Process/Output Process (shown below).

fig 9.6
Figure 9.6 ECPM Framework IPO Process

It is described within the context of the ECPM Project Execution Phase and adapted to the PRINCE2 Framework.

OUTPUT DATA

The final piece of the Client Checkpoint Step is a decision-making step. It basically answers the question: What are we going to do in the next cycle? The Process Analysis gives the co-managers all of the information they need to answer that question. From the above Input Data and Process analyses, the following decisions to bring the Client Checkpoint Step to a close: re-prioritized list of Integrative Swim Lane contents; re-prioritized list of Probative Swim Lane contents; next cycle duration; and next cycle contents.

Related Article: Probative and Integrative Swim Lanes: A New Stage Planning Tool

Re-Prioritized List of Integrative Swim Lane Contents

Any functions or features planned for integration in the previous cycle, but not integrated, will have to be added back into the Scope Bank List and reprioritized with all other functions and features not yet integrated. This is not unusual. Just remember that the functions and features not integrated in the previous cycle should have been the lowest priority in that cycle. From what has been learned in the previous cycle about the priority of functions and features to be added, those functions and feature not integrated into the previous cycle may have a priority lower than the new candidates for integration. The failure to complete the previous cycle may not be a failure after all.

This decision will be an updated and prioritized list of the functions and features that have been identified as part of the solution, but not yet integrated into the solution. The more of the solution you can present to the client team the better. So, some priority should be given to an Integrative Swim Lane over a Probative Swim Lane.

Re-Prioritized List of Probative Swim Lane contents

The discovery and learning from the previous cycle will suggest further Probative Swim Lane ideas. These will be integrated with the current list of Probative Swim Lane ideas and the new list re-prioritized. The criteria used to prioritize will have to account for the likelihood that a discovery or learning will actually result in addition to the current solution.

This will be an updated and prioritized list of all of the ideas that have been identified, but not yet investigated. If the solution is mostly unknown and the Integrative Swim Lane list is sparse, some priority should be given to a Probative Swim Lane over an Integrative Swim Lane. The tiebreaker will always be the capability of the project team to accommodate the mix.

Using these updated and re-prioritized swim lanes is the major input to the next cycle plan. See Article 7, Part 2 for details.

IMPLICATIONS FOR PRINCE2 STAGE PLANNING

The whole swim lane approach is well suited for direct integration into the PRINCE2 Stage Planning process. The only caveat is to limit the need for outside intervention and decision making. The co-managers and entire project team should have the knowledge to make all decisions for solution discovery and integration within the time, cost and quality constraints of the project.

Using the ECPM Client Checkpoint: Improved Stage Planning

In keeping with the Co-Manager model introduced in an earlier article, the Client Checkpoint is a major decision step in the ECPM Framework.

You can think of it as a StageGate that directs and channels project execution with the goal of maximizing delivered business value. Needless to say, meaningful client involvement in the Client Checkpoint is a Critical Success Factor (CSF) to the delivery of expected business value. The Client Checkpoint is structured around the well-known Input/Process/Output Process (shown below).

fig 9.1
Figure 9.1: ECPM Framework IPO Process

It is described within the context of the ECPM Project Execution Phase and adapted to the PRINCE2 Framework.

CONDUCT CLIENT CHECKPOINT

The Client Checkpoint Phase is the critical juncture of the ECPM project’s past with its future. The past is defined by the updated solution from the just completed cycle and the current contents of the Scope Bank. The future will be drawn from the learning and discovery resulting from the just completed cycle. Early in the project, expect there to be several possible directions to consider. In this phase, the client team and the development team review everything that has been done and everything that has been discovered to craft the contents of the next cycle. There may be conflicting directions, so be prepared. This exercise must be done with care if the project has any hope of delivering an effective solution.

Related Article: Probative and Integrative Swim Lanes: A New Stage Planning Tool

Without a doubt, this is the most important phase of the ECPM. For it is here that the future of the ECPM project is revisited. The client team and the development team come together and assess what has been accomplished, what has been discovered and learned from the completed cycles, and what should be done in the cycle to come. The client team and the development team jointly perform a quality review of the features and functionality produced in the just completed cycle. It is compared to the requirements, and its part in the solution and the overall goal of maximum business value. Adjustments are made to the high-level plan and next cycle work, as appropriate. The sequence Cycle Plan–Cycle Build–Client Checkpoint is repeated until the time and cost budgets for this version have been expended, the project should be terminated because it is not converging on an acceptable solution, or an acceptable solution has been reached for this version and this version of the deliverables is complete and can be closed.

Together, both teams will analyze what has happened in the project so far and jointly decide what will happen in the project in the next cycle. This is a very creative and challenging part of an ECPM project. Project deliverables from the just completed cycle are discussed with the full participation of all. This is a characteristic of what I mean by “client-facing.” These discussions focus on what has to be done to maximize business value within the time and cost constraints established by the client (client-driven). I have often observed how the client and the team interact in these checkpoints. From those observations, it was obvious whether or not the project was moving along according to the principles and core values of the ECPM.

The Conduct Client Checkpoint Phase is a critical review that takes place after every Build Next Cycle Deliverables Phase is completed. During the phase, both the client team and the development team will benefit from several discovery and learning episodes. Variations to the version functionality will surface; alternative approaches to delivering certain functionality will be suggested; and, each team will learn through their continuous involvement with the other team. There is a definite synergy that will develop between the two teams. All of this must be considered along with the functionality that had originally been assigned to the next cycle. The result is a revised prioritization of functionality for the next cycle.

The most important thing to remember is not to speculate on the future. For the next cycle, prioritize only the functionality that you are certain will be in the final solution. That newly prioritized list will be input to deciding on the Integrative Swim Lanes for the coming cycle. The learning and discovery from the just completed Cycle Build Phase will be input to deciding on the Probative Swim Lanes for the coming cycle. The available resources and the resource requirements of the prioritized Integrative and Probative Swim Lanes will dictate the contents of the coming cycle.

There are a number of activities that take place during the Client Checkpoint. The clearest description is to use the familiar model: Input, Process, Output. Figure 10/1 is that model applied to the ECPM Client Checkpoint.

Input Data

The input data consists of the items listed in Figure 9.1:

  • Planned versus actual deliverables
  • Learning and discovery
  • Probative swim land results
  • Updated scope bank
  • Status reports
  • External environment
  • Internal environment
  • Updated RBS

Planned versus Actual Deliverables

At the end of a cycle, unfinished deliverables are returned to the Scope Bank for re-prioritization. As a result of learning and discovery of the just completed cycle, unfinished deliverables may never get a high enough priority to be completed in a later cycle. This is quite common, especially when you consider the fact that the work of the cycle build plan should be completed according to its priority. The question, then, is what is its priority with respect to other prioritized functions and features waiting in the Integrative Swim Lane list in the Scope Bank?

  • Any functionality and features planned and integrated in the previous cycle

These are the deliverables from all previous Integrative Swim Lanes. In other words, the current solution. What was delivered will be used to update the solution through the RBS. So, the RBS is a hierarchical map of the current solution. It should be posted in the Team War Room. Through experience, I found that the updated RBS is one of the most visual artifacts produced in an ECPM project. I have also seen it used as an idea generator for planning Probative Swim Lane contents.

  • Any functionality and features planned but not integrated in the previous cycle

A cycle ends when its time box expires, or if all planned deliverables are complete. What was planned in the Integrative Swim Lanes for the just completed cycle may not have happened for a variety of reasons. This is not the result of change. It is the result of running out of time or experiencing some other event that prevented the orderly completion of the cycle plan. Since the cycle time box is fixed, any schedule delays that cannot be recovered will result in some Integrative Swim Lane deliverables not being integrated into the solution in the just completed cycle. These incomplete deliverables will be returned to the Scope Bank for reprioritization and consideration in some later cycle.

Learning and Discovery

The client will need some time to evaluate the most recent contributions to the solution. That evaluation has two aspects to it. The first aspect will be the experimentation with the newly expanded solution, paying particular attention to the functions and features added in the just completed Integrative Swim Lanes. Are other changes suggested from what was just produced? The second aspect is the results from the Probative Swim Lanes. Did you learn about any new functions or features? Are there any clues about other parts of the solution yet to be built? Will additional Probative Swim Lanes be needed to define these discoveries further, or can they be planned for inclusion in the solution through future Integrative Swim Lanes?

Learning and discovery will involve an unedited cumulative list, including ideas generated in the just completed cycle and all other ideas not acted upon. Once acted upon, an idea might end up in a future Probative Swim Lane or Integrative Swim Lane. Until then, the idea remains in the Scope Bank.

  • Any changes that took place in the business environment during the previous cycles

These changes will happen outside the control of the project team. A competitor introduces a new or upgraded product that competes directly with the deliverables you expect to produce in your project. This brings a TPM project to a screeching halt in almost every case, but that is not what happens on an ECPM project. Like a good athlete, the ECPM co-project managers anticipate such changes and can adjust accordingly. Whatever solution existed at the completion of the previous cycle may have sufficient business value to compete now. If not, all is not lost because the ECPM project can adjust deliverables going forward, and come into the market at a later time with expanded functionality and features.

Actual requirements are not static but, in fact, are quite dynamic. They can change several times throughout the life of the project for one or more of the following reasons:

  • Changes in market
  • Actions of a competitor
  • Emergence of new or enhanced technologies
  • Organizational priorities change
  • Changes in sponsors
  • Learning and discovery from a previous cycle

Probative Swim Lane Results

The Integrative Swim Lanes are well-defined, and the development and the cycle build plan established. The Probative Swim Lanes are very different. They can be highly speculative, and can change the depth of investigation and directions at any time. A good Probative Swim Lane investigation needs to be as adaptable as the situation dictates. The best return will be from a hands-off management style. Let the creative process unfold without any constraints except the cycle time box. The Probative Swim Lanes are designed to expand the depth and breadth of the solution. The major question is: Has anything been learned about further enhancements to the solution? A Probative Swim Lane has three results: to integrate; modify and repeat; or abandon.

1. Integrate: An enhancement to the solution has been identified.

Another piece to the solution puzzle has been discovered! It may have taken several Probative Swim Lanes spread over several cycles to reach that conclusion. The discovery may be so significant that a celebration is in order, but don’t order the pizza just yet! The solution piece needs to be documented and placed in the Integrative Swim Lane queue for prioritization and consideration in a future Integrative Swim Lane.

2. Modify and repeat: This direction may produce results and should be continued.

The idea shows promise. Continuing in the same direction or some other discovered direction will be appropriate. It needs to be documented and placed on the priority list for consideration in a future Probative Swim Lane.

3. Abandon: Nothing new has been identified, and this direction should be abandoned for the time being.

No idea is ever removed from the Scope Bank. What does not seem like a fruitful direction now may turn out to be valuable later in the project.

As work proceeds on a Probative Swim Lanes, results may suggest that the basis for the swim lane does not seem like a fruitful direction to pursue. The less that is known about the solution, the more likely will be that result. From experience, my best advice is not to “throw the baby out with the bathwater” too soon. I have experienced situations where a past Probative Swim Lane did not produce any immediate insight, but later provided an idea that did. Just remember to put all Probative Swim Lane results (both good and bad) in the Scope Bank for future reference.

Search for new functions and features

The less you know about the solution, the more challenging the identification of Probative Swim Lanes and the higher the risk that you will not find that solution at all. Because the project team is journeying into the unknown, do not be discouraged by short-term results. Sometimes, it will take several false starts before a promising direction is discovered. Even then, it may take several additional Probative Swim Lanes to explore a discovery fully, and then implement it through one or more Integrative Swim Lanes.