Skip to main content

Tag: PRINCE2

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.

Probative and Integrative Swim Lanes: A New Stage Planning Tool

The ECPM Framework aligns with the Lean Principles. That alignment is assured through iteration planning that utilizes two artifacts: Probative Swim Lanes and Integrative Swim Lanes.

Integrative Swim Lanes are not new as they are part and parcel of Scrum and every other agile methodology that uses incremental development. The term is not used in PRINCE2 but the concept is included in the Managing Product Delivery Process.

Probative Swim Lanes were first defined by Wysocki (2014) and are a unique artifact of the ECPM Framework. Their purpose is to explore and identify possible solution components consistent with the ECPM Framework principles of “Lean Practices.” Probative Swim Lanes are a planned search for the unknown parts of the current solution. They are planned on a just-in-time basis with the goal of spending minimal resources as long as the direction is tenable. Probative Swim Lanes are the foundation of the ECPM Framework and a “lean tool” too.

Related Article: The Scope Bank: A PRINCE2 Stage Management Tool

Each iteration planning effort aligns quite well with the Stage Planning process that is fundamental to PRINCE2.

TYPES OF DELIVERABLES IN THE ECPM FRAMEWORK STAGE PLAN

Just as with the Version Scoping Phase, the best way to introduce you to the Stage Planning strategy is from the perspective of its deliverables. The Stage Plan includes these deliverables:

  • Update the prioritized list of Probative and Integrative Swim Lanes
  • Establish the contents of the next Stage Build Integrative Swim Lanes
  • Establish the contents of the next Stage Build Probative Swim Lanes
  • Create low-level WBS and Work Package (WP) schedules
  • Establish stage duration
  • Identify and schedule resource requirements
  • Establish technical and resource dependencies
  • Finalize stage schedule

All of the historical and current knowledge to support these deliverables is contained in the Scope Bank. Let’s briefly discuss each deliverable from the Stage Planning Process.

Update the prioritized list of Probative and Integrative Swim Lanes

The input to the updated prioritized functionality list is the prioritized list from the just completed stage: any work planned but not completed from the previous stage, any ideas or changes in the Scope Bank that have not yet been acted upon, and the bundled changes suggested by the client or the development team based on additional learning and discovery from the just completed stage. All of this information is best kept in the Scope Bank.

Establish the Contents of the Next Stage Build Integrative Swim Lanes

This is familiar ground for every project manager. The same vetted tools, templates, and processes used for TPM projects can be used here. Remember that stages will be short (1-6 weeks typically for APM and xPM projects), and so planning is not complex and does not need a lot of software support. For my purposes, whiteboards, sticky notes, and marking pens are sufficient!

The contents of the next stage will take the form of some number of Probative and Integrative Swim Lanes. You also have a preliminary estimate of the stage time box for the coming stage, and so you can determine the stage contents based on what can reasonably be accomplished within that time constraint. If necessary, you might adjust that time-box to accommodate the next item or items on the prioritized list. Apart from any dependencies between the functions, sub-functions, and features, the client team and the development team will jointly decide how much of the prioritized list the development team can deliver in the coming stage. The duration of the stage and the estimated duration of the functions and features to be worked on at this stage is what you will use to determine the contents of what can be worked on at this stage.

If this is the first stage, don’t be too ambitious, especially if your project team members have not had the opportunity to work together on a complex project before. Take the client team into consideration, too. Is this the first opportunity to work with them? What do you know about them? What is your previous experience with them? These are all factors to be considered regarding stage content and length. How they have come together as a team may also influence planning for the coming stage. If they are together for the first time, you should not expect them to be a lean, mean, fighting team. They will stumble at first. So do not burden the team too heavily while they are learning to work together efficiently.

The first step in establishing stage contents is to work down the prioritized list of functions, sub-functions, and features, estimating the time to build them. How far down the list to go is a judgment call. (As a guide, you might use the total number of hours of labor available from the project team in the coming stage. If you feel uncomfortable with this, you might reduce labor hours by some percentage, say 10%, and use that as your guide to cumulative duration hours available in the coming stage.) The cumulative duration of the work you have estimated can be larger than the stage duration if the team size is large enough, so that parallel work can take place. Do not spend time working far down the list past anything that might reasonably be included in the coming stage. That could prove to be a waste of time. Where to stop is a judgment call, so just remember that the complex project manager does not waste time.

Establish the Contents of the Next Stage Build Probative Swim Lanes

The less that is known about the solution, the more important it is to aggressively identify potential solution details. That is the purpose of Probative Swim Lanes. I have often found it helpful to use an iconic prototyping approach in these Probative Swim Lanes to investigate these possible additions to the solution. Several iterations of the prototype can be completed within the stage time-box.

Whereas Integrative Swim Lanes are planned in detail, using TPM tools Probative Swim Lanes are more like xPM projects and do not have such plans, but rather depend on the creative process for their completion. There really is no limit to the approach used in a Probative Swim Lane. Prototyping, brainstorming, and problem solving have already been discussed earlier in this chapter, and are the three approaches I have used in past complex projects. The outputs from these three approaches fall into one of the categories discussed next.

Because of the volatile nature of the Probative Swim Lanes, be prepared to move resources to other stage work as available, when you have:

  • Positive results—more investigation advised. This idea looks like a promising direction to investigate, but more detail is needed. That detail should be left for a later Probative Swim Lane in their next stage or even later, and so its description should be placed in the Scope Bank for prioritization.
  • Negative results—looks like a dead end. This idea doesn’t seem like it will produce any fruitful results. No further action on it is recommended. It should be returned to the Scope Bank for further idea generation. Do not throw any ideas away unless you are clairvoyant!
  • New ideas have surfaced. Probative Swim Lane ideas will often identify other ideas for consideration. Depending on the extent of those ideas, they might be considered within the context of the current swim lane, or relegated to the Scope Bank for later prioritization and consideration.

A cumulative history of project performance metrics should be maintained. These metrics should inform the project team about the rate at which convergence to an acceptable solution is occurring. The frequency of changes, the severity of change, and similar metrics can help.

Tracking Scope Bank Size

One metric that I have found useful is to track the size of the Scope Bank over each stage. The figure below shows three trends in Scope Bank size that I have used in client engagements.

fig 8.1
Tracking Scope Bank Size

Tracking the Size of Probative Swim Lanes and Integrative Swim Lanes

The overall size of the Scope Bank is a good indicator of project performance, but it does not tell the whole story. For that, we need to look at the relative sizes of the two swim lanes over time. At the next level of detail, I like to track the relationship between the Probative versus Integrative Swim Lanes over the history of the project. The figure below shows an example of this type of report. It shows all four possible relationships between the two swim lanes: one is increasing, and one is decreasing (a) and (d) are both increasing (c), or both are decreasing (b). Each pattern carries at least one interpretation.

fig 8.2
Size of Probative versus Integrative Swim Lanes

There are two strategies that I have used successfully to manage project stages. The first strategy is to have the first stage focus on building a prototype followed by several stages dominated by Probative Swim Lanes. If you have established good client relationships from previous complex projects, this can work quite effectively. If you do not have that client relationship, this strategy is not a good choice for the reason that it does not contribute to the early establishment of meaningful client involvement. For the second strategy, the less I know about the solution, the more I would lean towards prototyping for the first few stages. Before you can effectively define probative initiatives, you and the client need a sense of direction as to where that elusive solution might be found. Early prototyping stages will do the job and will also contribute to building that much needed client relationship.

In this example, little is known about the solution, and so the early stages will be focused on discovering functions and features of the solution. Early brainstorming sessions should be conducted in the Version Scoping Phase and first few Stage Planning Phases. You need to “stoke the fires” and get as many ideas as possible into the Probative Swim Lanes. Prototyping can be effective in the early stages.

As Probative Swim Lanes successfully identify parts of the solution, they should be followed by Integrative Swim Lanes as soon as possible. It is important to get even a partial solution in front of the client. The most useful information about the missing parts of the solution will come from the learning and discovery by the client team as they work with the then solution.

Remember that the successful identification of solution components through the use of Probative Swim Lanes feeds the Integrative Swim Lane contents, and hence the convergence of the solution to the complete solution. It is the responsibility of the co-project managers to maintain a healthy balance between Probative and Integrative Swim Lanes so that convergence to that final solution is assured. That balance will change as the project progresses through the stages.

Written reports that circulate among the team members do not exist in complex projects. They are a waste of time in a complex project. But your management and the sponsor may not share that same opinion and will require periodic status reports. You will have to accommodate their wishes; they pay the bills. All inter-team reporting is verbal, and everyone on the team who needs to know will know. There are reports that circulate outside of the team, but these are the responsibility of the co-project managers. In many cases, they will be exception reports or escalations of open issues and problems that are outside the span of the authority of the co-project managers, and are then escalated to the appropriate senior manager or project sponsor. The co-project managers often will use the team meetings to quickly give the team the status of open issues that affect the project.

The monitoring and controlling functions pertain to the stage build tasks. As part of that control function, the team collects whatever learning and discovery took place and records it in the Scope Bank. All change requests go into the Scope Bank as well. No changes are acted upon within a stage. All changes and other learning and discovery are reviewed at the checkpoint. The review results in placing newly discovered functions and features into a priority list for consideration at the next or some future stage.

NEXT STAGE PLAN

Stage duration and stage contents are the primary focus.

Next Stage Duration

The decision as to stage length for the next stage is based on two prioritized lists: the functionality to be integrated into the current solution and the ideas to be investigated in the next stage. Team resources are also considered because they place constraints on what can actually be accomplished within the stage timeframe. The actual contents of the two prioritized lists have to be evaluated subjectively to decide on stage length. Remember to be true to the overall time box decision made during the Version Scope Phase if possible.

Next Stage Contents

This is the most complex decision that has to be made because the swim lanes tasks are staffed by the same limited resource pool. The priorities within a swim lane have been reset, but the priorities between swim lanes are still to be determined. The simplest way to state this last decision about stage contents is: Given the available resources should we add the next Probative Swim Lane tasks or the next Integrative Swim Lane tasks? Resource availability may answer the question without any further considerations, but the decision is usually more complex. It is an issue of balance between the status and needs of each swim lane. Each swim lane will have a backlog that needs to be taken into account. If there is a large backlog in the Integrative Swim Lane, that diminishes the need to invest resources in the Probative Swim Lanes. The reverse strategy also applies.

The next stage length is known, and a new prioritized list of functionality is available. How far down the two swim lane lists can the team expect to get with this next stage? There may be some give and take between next stage deliverables and the stage time box, but this should be minimal and easily resolved.

I had cautioned you that in the early stages of a project, do not be too aggressive. As the team gets to the perform stage and the client team is more comfortable working with the development team, the list of deliverables for the next stage can get a bit more aggressive. The ECPM has the luxury of returning undone functionality to the Scope Bank and reprioritizing it for consideration in a later stage. There is still the temptation on the part of technical professionals to have a “steak appetite on a baloney budget.” Do not set the client up for results that cannot be achieved. That would put a serious dent in a relationship that was hard earned.

IMPLICATIONS FOR PRINCE2

Just as the Probative and Integrative Swim Lanes can be included in the stage so also can these tracking tools be used in Stage Planning.

The process you use for ending a stage may compromise the content and presentation of the swim lane performance, however.

END NOTES
Wysocki, Robert K., 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value. Plantation, FL: J. Ross Publishing.