Tag: PRINCE2

Probative and Integrative Swim Lanes: A New Stage Planning Tool

Written by Robert Wysocki on April 13, 2016. Posted in Articles. 8 Comments on 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.

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.

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.

Business Rules for Ending A Stage: Part 1

Written by Robert Wysocki on March 23, 2016. Posted in Articles. 7 Comments on Business Rules for Ending A Stage: Part 1

In the ECPM Framework, once a cycle begins it continues without change until the time-box expires.

By comparison, PRINCE2 focuses on completion of the Work Package as planned for that stage and allows for movable end dates for a stage. Cycle and Stage are synonyms.

The ECPM Framework identifies three situations regarding the end of a cycle:

Normal End of Cycle when the timebox expires
Abnormal End of a Cycle before the time-box expires
Major Change in the Environment

The ECPM Framework ending strategies can apply with equal effectiveness in PRINCE2 in the Controlling a Stage Phase.

WHAT IS A CYCLE?

In the ECPM Framework cycles can be of varying lengths but usually not more than 6 weeks duration. Within that timebox, the project team identifies the tasks that they have estimated can be delivered. Those tasks are of two types: Tasks associated with Probative Swim Lanes and tasks associated with additions to the evolving solution through Integrative Swim Lanes. In most cases priority would be given to completing an Integrative Swim Lane before completing a Probative Swim Lane. The reason is that an Integrative Swim Lanes delivers business value whereas a Probative Swim Lane delivers knowledge (i.e., learning and discovery).

ENDING A CYCLE

There are three situations that can result in the decision to end a cycle. They are described below.

1. Normal End of Cycle when the Timebox Expires

When the timebox expires, the cycle ends – no exceptions. Any Work Packages (WPs) that were planned for that cycle and had not yet been completed are returned to the Scope Bank for prioritization in future swim lanes and cycles. There are no situations where the timebox is extended for even one day. To do so is not at all in keeping with the lean properties characteristic of the ECPM Framework.

This gives us a strategy for planning the balance between Probative and Integrative Swim Lanes in a cycle. There are two strategies to apply for the scheduling of WPs within a cycle:

Prioritize the contents when scheduling WPs within each swim lane

If the tasks are scheduled according to their priority, then any tasks not completed will be of low priority. Because of the learning and discovery that takes place in the cycle, the lowest priority tasks may never receive a high enough priority to be included in the cycle plan.

Integrative Swim Lanes are of a higher priority than Probative Swim Lanes

Integrative Swim Lane tasks deliver an updated solution and incremental business value. Probative Swim Lanes have the potential for identifying business value but not yet.

{module ad 300×100 Large mobile}

2. Abnormal End of a Cycle Before the Timebox Expires

There will be situations that arise where all of the planned WPs were completed in less time than was estimated. WPs should be finished as soon as possible resulting in cycles completed sooner than was estimated. Do not create work just to fill the timebox duration. End the cycle and proceed to the Client Checkpoint Step.

3. Major Change in the Environment

This situation can arise independently of the cycle and outside the control of anyone. The internal and external environments are in a constant state of flux. Just like risks, changes might be expected but when they will arise cannot. If the change is so disruptive as to render the cycle WPs compromised, it might not make business sense to continue the cycle. End the cycle immediately, save the time and resources, and begin planning the next cycle armed with the new information.

MANAGING STAGE BOUNDARIES

In PRINCE2, just as in the ECPM Framework, the Stage is where it all happens. Both frameworks have planned the specific deliverables to be built within a time and cost constraint. Whenever either of these constraints is challenged, some corrective action is required. The two frameworks are very different in these situations. For the ECPM Cycle, we have discussed the actions above. For the PRINCE2 project, the following is specified.

AN AGILE APPROACH FOR ENDING A PRINCE2 STAGE

Taking into account:

learning and discovery from the just ended stage
incomplete WPs from the just ended stage

it is clear that the ECPM Framework design has two basic tenants:

decision making is contained within the roles and responsibilities of the co-managers whenever possible
the number of hand-offs has been minimized to reduce non-value added work time.

PRINCE2 processes are not clear on how these decisions are taken but seem to leave open how the project manager and team managers choose to proceed. Within Stage boundaries, the decisions can be taken without outside input or intervention. When Stage boundaries are threatened or exceeded, the decisions are taken outside of the project team. That often requires the sharing of information (written or verbal) to the outside decision makers. That process adds non-value work due to the handoff time required. On the other hand, the ECPM Framework processes minimize non-value work time.

The Pros and Cons of Working Outside Your Comfort Zone

Written by Brad Egeland on March 16, 2016. Posted in Articles. 7 Comments on The Pros and Cons of Working Outside Your Comfort Zone

We often find ourselves working on the familiar things, things we have had repeated success with and things where we are least likely to fail.

We often like to stay in our comfort zone, going with what we know. That’s the easy route. The projects may not always end successfully, but we go into them knowing more and start with a greater chance of success.

It’s easy to start familiar projects with confidence, to win our clients over right out of the gate and start fresh with a new project team knowing we are going down a familiar path. The confidence we start these projects with shows to our customers, and it certainly makes it easier to get these projects off on the right foot because we know what we are doing – there really isn’t any learning curve. But keep in mind there really isn’t much career or professional growth involved, either.

On the other side of the fence, going outside our comfort zone can feel awkward, cause us great concern and stress, and if not handled properly, cause our customers concern and stress as well if we appear to lack confidence. Let’s look at the pros and cons of taking on projects within and outside of our professional comfort zone.

The Pros

Going outside of our comfort zone and immediate areas of knowledge can serve several very positive purposes including:

{module ad 300×100 Large mobile}

Knowledge gain. By going outside our comfort zone, we can acquire new knowledge, try new strategies, test new technology and keep challenging ourselves. At the same time, we bring new project capabilities to our organization’s project offerings.

Expansion of client base. By going outside our comfort zone, we can appeal to a broader client base. As a consultant, I’ve been able to do that by attracting customers that may not be very related to project management and / or professional services. As a project manager, I’ve done that by leading projects for clients outside the area of normal usage for our products and services, thus expanding our niche in the industry and our client base at the same time.

Expansion of services offered. When we go outside our comfort zone, we are open to new and innovative requests from our current project clients. I’ve had several innovative clients ask for services or content that I had not worked on previously, but in the long run, it greatly increased my service offerings to all clients and, therefore, my revenue as well as my service offerings became even broader and more appealing.

The cons

Obviously, there are some very good reasons for going outside of our comfort zones. But with this shift in focus outside of our comfort zone and immediate areas of expertise, comes a realization of a few potential risks. What these are and how we deal with them are specific to our industry, service niche, and the types of customers we are working with, but some general ones that come to mind include:

Vulnerability to cyber crime or data breaches due to working outside expertise and safety zone. Let’s assume that you and / or your organization are as tuned into cyber security as you may claim. Even if you are, once you stroll outside your area of comfort and expertise you may also be taking a walk outside your area of data and data center protection. If you are going where no man in has gone before in your organization, that doesn’t mean you aren’t going right where the hackers find you the most vulnerable. And we now know that everyone and everything can eventually be hacked we are all merely just trying to catch up with the hackers at all times. They are ahead of us, not vice versa, no matter what your IT guys claim.

Increased project failure potential. Project failure happens more frequently than we care to admit and accept anyway, even when we are operating within our comfort zone and areas of expertise. Once we venture outside of that and take on projects in unfamiliar surroundings using unfamiliar technologies with customers in new industries that we haven’t worked in before, we increase the possibility of project failure – at least at first – exponentially. It’s ok, you have to start somewhere, just be mentally prepared and do some extra risk planning just in case.

Winning these projects may be a tougher sell. If you’re used to winning projects easily within your comfort zone, you may need to check your ego at the door and be ready to face some rejections. When asked what credentials you have to take on these new and different projects, don’t lie. But be ready to be heavily questioned by cautious potential clients as to why they should go with you over ‘x’ competitor who has expertise in this particular area where you are lacking. Do research and be ready to respond to such questions. They will come.

Summary / call for input

I’ll be the first to admit; I ‘m not usually one who likes to go outside my comfort zone. At least, I wasn’t most of my life – I’ve gotten better at it in recent years. I even liked to take the same vacations over and over again. Trying new foods? Never. Now – fortunately, or, unfortunately, depending on how you look at it – there isn’t much I won’t eat. Thankfully, my wife is a great cook and takes pride in serving our large family healthy food, so my new lack of pickiness has made her very happy. I’ve managed to take that same open mind into the things I do professionally – including the projects I work on and the customers and technology I work with. It’s opened me up to new project and consulting opportunities, helped increase my revenue and the revenue of the organizations that I work with, and it’s made me a better and more well-rounded professional.

How about our readers? Are you comfortable outside your general area of expertise? Are you comfortable learning new things? Have you taken on projects for your organization that were outside either your comfort zone or the organization’s normal area of focus? How did it go? What did you learn?

The Scope Bank: A PRINCE2 Stage Management Tool

Written by Robert Wysocki on March 9, 2016. Posted in Articles. 7 Comments on The Scope Bank: A PRINCE2 Stage Management Tool

The Scope Bank is unique to the ECPM Framework but offers significant management benefits when applied to the PRINCE2 Framework.

The Scope Bank is the clearinghouse for all project activities – a traffic cop if you will. It brings together in one place solution status, stage performance history, potential solution components and a foundation for stage 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.

In PRINCE2, the use of a Scope Bank is the logical consequence of executing a Stage Plan. Scope change requests will arise at any time during a Stage, but their resolution is held until the Stage is complete and its deliverables reviewed. This may well be counter to common PRINCE2 practices. 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 the PRINCE2 Framework.

SCOPE BANK

The Scope Bank is the single depository for the current requirements definition (aka, the Requirements Breakdown Structure (RBS). See Article 3.), open change requests, the current solution, and all learning and discovery that has been accumulated from all cycles that has 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.

I caution teams that nothing should 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. In PRINCE2, it can be the input to the Stage Planning Process. The contents of the Scope Bank are updated at the completion of each cycle just as is done in PRINCE2 at the completion of each Stage. 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.

{module ad 300×100 Large mobile}

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.

The following fields are used to describe an item in the Scope Bank:

ID #:

A reference number or short name that uniquely identifies the entry.

Date posted

The date this entry was first posted to the Scope Bank

Posted by

The person responsible for posting this entry.

Requirements Linkage

Describe the requirement(s) that this change is related too.

Description

A brief statement of what functionality is associated with this entry.

Business value

If known, what business value will be added to the solution if this entry becomes part of the final solution.

Duration

If known, how long will it take to build the functionality associated with this entry?

Resources needed

List the resources that will be needed to build and implement this entry.

Team comments

Any other comments relevant to this entry and its development and deployment into the solution.

Prioritization

Place this entry in the appropriate swimlane (Integrative or Probative) and assign a priority to it.

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 life span. 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

If the enterprise has established a release schedule for incorporating change, that release schedule should be honored when updated solutions are implemented. Releases may occur as often as once per quarter but may be not more frequent than annual. Whatever the infrastructure supports, that should be the pace adopted for solution delivery. In the absence of an accepted release schedule, the solution might be deployed at the discretion of the co-managers.

The Business Value From the Current Solution

The premise underlying cycle planning is to maximize the incremental business value of every cycle. That offers a loose prioritization of a deliverables implementation strategy. The deployment strategy might be based on the incremental business value that would result from the deployment. If it meets certain minimums, deployment will occur.

The Challenge of Deploying the Current Solution

The frequency of solution deployment can be problematic if it is too slow or too fast. The impact of a too slow deployment schedule is a loss of business value. That is obvious. But a too frequent deployment schedule has several not so obvious negative impacts.

Support costs for multiple solutions

The problem arises because not every affected business process and practice will be executed using the updated solution. When a new solution is deployed does every affected business unit automatically switch to the updated solution. Probably not. So this adds support costs associated with multiple solutions in place at the same time. The resulting confusion is obvious.

Frequent process or practice changes

Change brings confusion among those who are affected by the changes. It is a matter of forgetting the old and taking up the new. Not so easy to do with frequent changes. Every organization has its own change velocity. How quickly can the organization accept and deploy change is the question.

Maintaining multiple versions of documentation

Version control has always been a problem especially when it involves software version control. The same problems exist for non-software version control. As long as there is one business unit using a release, the support services specific to that release must be in place and that includes training planning and scheduling too.

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.

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 is 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 anecessary and sufficient set for the attainment of all project success criteria and the delivery of the expected business value.

At the highest level of definition, I would expect the set to contain 6-12 such requirements. These are very high level and speak more towards what an acceptable solution should contain or be able to do. At this level, there is no expectation that those who drafted the high-level requirements would have any idea about how these requirements might be met or even if they can be met. That is part of the adventure of the complex project.

Agreement on the high-level requirements by both the developers and the client is critical to complex project management success. It sets a foundation for change management, decision making, and solution evaluation.

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

Known Requirements Breakdown Structure

As a result of the learning and discovery from completed cycles, additional requirements specifications will become available. Additionally, the project team will be able to formulate how the requirements can be built. That intelligence will be represented in a hierarchical decomposition called the Requirements Breakdown Structure (RBS). The RBS defines what will be in the solution. Further decomposition of the RBS is called the Work Breakdown Structure (WBS). The WBS defines the hierarchical decomposition of the work needed to accomplish every feature present in the RBS.

Figure 7.1 is a graphical representation of the RBS. Figure 7.2 is a graphical representation of the WBS which follows from the RBS.

Figure 7.1 The Requirements Breakdown Structure

The project begins with the high-level requirements identified. Any decomposition that is known at that time can be added. As each cycle is completed additional decomposition will often be added. The RBS will not be complete until the project is complete.

Figure 7.2 The Work Breakdown Structure

The Work Breakdown Structure (WBS) is a product of cycle planning. At some point in the RBS decomposition, an acceptable solution component will have been identified for inclusion into the current solution. The work needed to implement this solution component is defined during cycle planning.

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 – This list will be prioritized and continually updated whenever new change requests are added. That prioritization is usually based on expected business value.
Change requests scheduled for integration – While the actual scheduled cycle may be related to business value more than likely it will be because that cycle will be building deliverables related to the change request.
Change requests in 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.

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 first to be added to the prioritized Integrative Swim Lane list.

PRINCE2 AND THE SCOPE BANK

The Scope Bank is an artifact of a lean framework and for that reason there will be a number of applications to PRINCE2 which is not a lean framework – at least not yet! The two primary applications of the Scope Bank to the PRINCE2 Framework are discussed below.

Stage Planning

The Scope Bank becomes more critical to effective complex project management as the uncertainty and complexity increases.

Uncertainty

The less we know about the goal and the solution, the higher the risk of failure and the more we will depend on the creativity of the project team. When the goal is clearly specified at the beginning of the project and the solution is not known there is no certitude that we will arrive at a solution that meets the expected business value. When the goal is not clearly defined and understood the more like it will be just a dream end state and not achievable as presently stated. For those projects, the goal and solution will converge to deliverables that may or may not achieve the expected business value.

Complexity

The less we know about the solution, the more complex will be the project. The end state is unpredictable.

How to proceed

Planning the next Stage draws on the documented history of the project as stated in the Scope Bank. The next Stage will include some mix of Integrative and Probative Swim Lanes.

PUTTING IT 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.

Bundled Change Management Process

Written by Robert Wysocki on February 24, 2016. Posted in Articles. 6 Comments on Bundled Change Management Process

A Fundamental Characteristic of a Lean Process

In the complex project management landscape, change is an essential component of whatever learning and discovery process has been employed to find an acceptable solution. In the complex project space, change is encouraged as an integral part of the learning and discovery process.

This stands in stark contrast to the traditional project landscape where change is viewed as disruptive and a major contributor to non-value added work. Because of these differences the change request process for the traditional project landscape is not one that will work in the complex project landscape. Rather than discouraging change, the complex project management process must not only encourage it, but have a lean process for managing it.

This article recommends a Bundled Change Management Process designed specifically for the complex project landscape. It is also a lean process that easily integrates into the PRINCE2 Stage Planning Process.

Both the ECPM Framework and PRINCE2 share a lot in common with respect to the Change Process. Once an ECPM Framework Cycle Plan is approved, it is executed without incorporating any change requests that may arise during the execution of that cycle. This is unique to the ECPM Framework, but it has application in any methodology such as PRINCE2.

Change requests will arise; that is the nature of complex project execution. Processing them up to the decision point can waste resources. Accepting the change requests as they arise and holding them in the Scope Bank for processing during the Client Checkpoint preserves the “lean” characteristics of the ECPM Framework and significantly improves the effectiveness and business value of the decisions taken.

WHAT IS THE BUNDLED CHANGE MANAGEMENT PROCESS?

In an ECPM Framework project, the scope change management process does not exist in the forms that the traditionalist will be familiar. Scope change in an ECPM Framework project occurs, but not like it does in a TPM project. Any thought or idea that the client team or the development team has as to something different to do in the solution is captured and stored in the Scope Bank. The major difference between TPM and ECPM Framework scope change is that in TPM, the scope change requests are considered one at a time on a first-come-first-served basis and a decision made. In ECPM Framework, scope changes become part of the Client Checkpoint.

It is easy to see that in a TPM project there is a lot of wasted time revising a plan to accommodate scope changes. That does not happen in the ECPM Framework because the plan going forward has not yet been prepared, so there is no wasted time processing scope changes.

Because change is constant, a good complex project management methodology must have a clear and effective change management process. The change management process has you plan the project again, so it now incorporates the approved changes.

Perhaps the use of a PMLC Model based on just-in-time planning is a better approach, at least from a “lean” perspective. Even if you have to use a plan-driven PMLC Model, incorporating the Bundled Change Management Process will be a good insurance policy.

An integral part of the Bundled Management Process is documentation. I strongly suggest that every change is treated as a major change until proven otherwise. To not do so is to court disaster. That means every change request follows the same procedure. The figure that follows is an example of the steps in a typical Bundled Change Management Process.

If the project is subject to frequent change requests and these are processed on an as-received basis, significant resources can be wasted. Frequent change requests are a common occurrence in the search for an acceptable solution. Some of these change requests will be well thought-out; others may be nothing more than educated guesses or even wild speculation. All requests must be viewed as significant requests until proven otherwise, and processed, but unless there is a more efficient way of handling them, there will be wasted resources and time.

{module ad 300×100 Large mobile}

Bundling change requests and processing them in bulk (at the end of a cycle or at milestone events) can avoid wasting resources and protect the project plan. EII has designed a bundled change request process specifically to handle the unique needs of complex projects in search of an acceptable solution.

So What’s Different?

Scope change in an ECPM project occurs, but not like it does in a traditional project. Learning and discovery are the hallmarks of an ECPM Cycle so that any thought or idea for a change in the solution is captured and stored in the Scope Bank.

Change requests are considered one at a time on a first-come-first-served basis in a TPM project. That is not the case with the ECPM Framework. In an ECPM Project, scope changes become part of the project plan going forward. In traditional and PRINCE2 projects they are an add-on to a project plan that already exists.

It’s easy to see that in these approaches there is a lot of wasted time revising a plan to accommodate scope changes. That doesn’t happen in the ECPM Framework because the plan going forward has not yet been prepared – there is no wasted time processing these changes. In the ECPM Framework planning is a just-in-time event. In the ECPM Framework, resources are used to best business advantage on value-added work, whereas in traditional projects, there is no assurance that that is the case.

Project Impact Statement

A common application of the prioritized scope triangle variables occurs whenever a scope change request is made. The analysis of the change request is documented in a Project Impact Statement (PIS). If the change is to be approved, there will be several alternatives as to how that change can be accommodated. These alternatives can be prioritized using the prioritized scope triangle and forwarded to the Client Checkpoint Step for consideration.

If the project is subject to frequent change requests and these are processed on an as received basis, significant resources can be wasted. Bundling change requests and processing them in bulk can avoid wasting resources and protect the project plan. That is the process followed in the ECPM Framework.

Regardless of the PMLC Model you choose, you will have to deal with scope change requests coming from the client and from the project team. In some cases, you’ll be expecting these change requests, but not when they arrive – but you’ll be ready to process them. In other cases, you will not be expecting them (or at least won’t want them), but you still need a method to process them.

During project planning, I introduce the client to the Bundled Change Management Process and its benefits and get their agreement to its use. The Bundled Change Management Process can be in place from the start the project.

PRINCE2 and the Change Process

There are four obvious benefits that the ECPM Framework Scope Triangle, and specifically the change process, can bring to the PRINCE2 Framework:

It is lean – groups the requests into a single decision package
It is lean – allows for prioritization of requests
It is lean – schedules change implementation for maximum business value
It is lean – minimizes non-value added time

The major benefit is that the process will reduce the time wasted to process change requests. All meaningful analysis of the change requests is done at the completion of the current cycle. The analysis includes a prioritization and scheduling of the approved change requests. Only one plan revision is done at these deadline dates rather than one plan revision for every change request in the bundle – an obvious saving of time, cost, and resource utilization.

Prince2 devotes a chapter to change control and issues management ( Managing Successful Projects with PRINCE2, 2009 edition, AXELOS) with the emphasis on issue management. Issue management is not unlike problem-solving, and I have discussed how the ECPM Framework Scope Triangle is an excellent structure for managing problem-solving and analysis of the alternatives.

In the complex project world change is to be expected, unlike the traditional project world where change is less frequent and disruptive of established plans and schedules. PRINCE2 change control is not lean! The ECPM Framework approach to problem-solving and bundled change management is an excellent lean process that can be adapted and integrated into the PRINCE2 Framework with minimal disruption of the management process.

Benefits of Using the Bundled Change Management Process

The major benefit is that the process will reduce the time wasted to process change requests. All meaningful analysis of the change requests is done at the completion of the current cycle. In a TPM environment that means deadline dates for change requests are established. There can be more than one such deadline date embedded in the plan-drive model. At these planned dates, all of the open change requests are analyzed as a package. The analysis includes a prioritization and scheduling of the approved change requests, so only one plan revision is done at these dates rather than one plan revision for every change request in the bundle.

This practice is in contrast to typical change requests, which are handled as they arise in most current methodologies. This can be inefficient and can lead to churning, contradictions and waste of resources.

Bundling change requests and analyzing them as a group is far more efficient and consistent with “lean” practices. This is entirely consistent with the Agile experience as it considers all learning and discovery since the last completed cycle and asks: What is the best way to proceed given what we now know? That knowledge is cumulative and treated as a group may generate other ideas that would not be discovered if treated one at a time. At the same time some ideas may be related to one another and if pursued as a package, may preserve the lean characteristics of the ECPM Framework and the PRINCE2 Framework as well. In this way, planning decisions are made as late as possible and always using the most current and cumulative learning and discovery.

Submit Change Requests

The first principle to learn is that every change is a significant change. Adopt that maxim and you will seldom go wrong. What that means is that every change requested by the client must be documented in a Project Change Request. That document might be as simple as a memo but might also follow a format provided by the project team. In any case, it is the start of another round of establishing Conditions of Satisfaction (COS).

Only when the request is clearly understood can the project team evaluate the impact of the change and determine whether the change can be accommodated.

Change requests can arise at any time and can come from any one of several sources. Furthermore, the request can be well thought out or just a statement like: What would it be like if we could …? Both extremes must be accommodated by the request form that formally enters the idea into the project.

The request process begins with a statement from the individual making the request. The figure below is an example. It is designed to allow the requestor to provide as much detail as is available. The last thing would be to have a requirement that creates an obstacle to suggesting a change. Rather, you would rather have a request form that encourages ideas.

Review Change Requests

One of the strengths of bundling change requests is that every request is reviewed, critiqued, and considered in relation to all of the other open change requests. Those change requests are also reviewed along with any learning and discovery that occurred during the just completed cycle. There may be some hidden synergies waiting to be exploited in the coming cycles. That is far more effective and efficient than any one-at-a-time approach. It gives the project team the opportunity to group similar open change requests for better decision-making and use of resources. There will be situations where the grouping of similar change requests may generate other changes that otherwise would not have seen the light of day.

Add Change Requests to Scope Bank

The Scope Bank is the holding pen for all Change Requests. No analysis is done at this early stage. The Change Request might be categorized according to how it relates to requirements and/or the current solution. That gives better visibility into how Change Requests might be leveraged as a group rather than individually.

At Cycle Completion, Prioritize Change Requests

This prioritization is usually related to how the open Change Requests align with the possible content of the next cycle. This prioritization is usually nothing more than a classification (like MoSCoW, ABC, etc.) so that a group of Change Requests can be further analyzed for inclusion in the next cycle.

Conduct Impact Study for High Priority Change Requests

This is the first detailed analysis of those Change Requests that are relevant to the next cycle. The impacts can be to requirements satisfaction, solution development, generation of incremental business value, risk/complexity/cost/duration estimates.

The response to a change request is a document called a Project Impact Statement. It is a response that identifies the alternative courses of action that the project manager is willing to consider. The requestor is then charged with choosing the best alternative. The Project Impact Statement describes the feasible alternatives that the project manager was able to identify, the positive and negative aspects of each, and perhaps a recommendation as to which alternative might be best. The final decision regarding the choice of alternatives rests with the requestor.

The Impact Study involves looking at the project plan, assessing how the change request impacts the plan, and issuing the impact study. It is then forwarded to upper management for final disposition. They may return it to the project manager for further analysis and recommendations, or reject it and notify the client of their action. The project manager reworks the impact study and returns it to upper management for final disposition. If they approve the change, the project manager will implement it into the project plan.

Analyze Impact Studies

This analysis is designed to build content that will be proposed for the next cycle. It is an excellent planning tool for complex project management. Among the factors to consider are:

ScheduleAny changes to the schedule will almost always have negative effects on completion dates.
ResourcesThere availability has already been accommodated in the current cycle and project schedules. Schedule changes will almost always upset those commitments and add time to cycle and project completion.
Risk If the changes only impact future cycles, those can be managed. But if the changes impact previous cycles, they can be very disruptive. The point here is that the disruption may result in rework of components of the current solution. The cost of these disruptions needs to be compared with the incremental business value as part of the decision to accept the change.

Select Approved Changes for Next Cycle

While you might think that the selected changes start at the top of the priority list and work down until available resources and cycle duration limits are reached, that is not necessarily the case. For example, Some Change Requests may hold the promise of generating excellent business value, but the associated risk is high, development time is excessive, and resource requirements are scarce. All of this may give way to Change Requests that deliver business value faster even though it may not be to the level of some other Change Request.

Change Requests can generate Probative or Integrative Swim Lane Work Packages for the next cycle. Change Requests focus on “What” is needed in the solution but not “How” those Change Requests can actually be implemented. The “How” may have several alternatives and it is not obvious which if any are the best choice. That calls for some number of Swim Lanes to investigate the alternative “Hows.” In the more obvious situations the “How” will be obvious, and so an Integrative Swim Lane will be planned.

PUTTING IT TOGETHER

The major benefit of using the Bundled Change Management Process is two-fold:

Preserves the lean properties of the ECPM Framework

Bundling change requests gives the project team the opportunity to consider the relationships between and among requests. Natural groupings will result. Some groups can be accommodated as one request thus reducing the total labor as compared to handling them separately. Others can be built into a future cycle when related to the content of that cycle again reducing to total labor expended. Others will be postponed and maybe lose priority and not be accommodated at all.

Increases the business value delivered

The ultimate measure of project success will always be delivered business value. The team will try to maximize this for the resources expended. Bundling change requests and analyzing them together allows for prioritization that cannot be done if they are processed individually.