Skip to main content

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.


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.


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.


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.

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

Comments (5)