Getting Projects Back on the Rails

“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” - Darrow

What's New?

Rarely does a project go from start to completion without changes occurring along the way - both anticipated and unanticipated. Even with the best efforts to anticipate and mitigate project risks, sometimes projects go off the rails. And when that happens, more times than not, it’s difficult to get the team refocused and back on track. There is often ambiguity around who makes the decisions that reset the course of the team, and the result is lost time, inefficiency, confusion, and frustration.

What’s new is a lean, fast, and effective process for getting teams and management aligned and back on track when material changes that affect the plan of record are made to a project. An organization’s ability to respond quickly and effectively to any change is a fundamental characteristic that separates the marginal from the successful.

What Is the Tool? Out-of-Bounds Review

The Out-of-Bounds Review is a process that can be utilized by a wide variety of projects to realign teams after a project has gone out of scope. It is a simple tool that provides the team with a mechanism to quickly conduct a root-cause analysis, evaluate alternatives, and recommend a remedy to the project decision makers. Setting “boundary conditions”, which reflect the critical elements of a project (typically cost, schedule, features, and/or quality), at the time of project approval creates a “contract” between the management and project teams. This contract allows teams to move forward with minimal guidance as long as the boundary conditions are not crossed. And when those boundaries are crossed, the Out-of-Bounds (OOB) Review is the mechanism to course correct and realign to a new plan of record.

When a project team detects (or anticipates at a high confidence level) that an Out-of-Bounds (OOB) condition will occur, the program manager gathers relative information to determine if the team can resolve the issue and still maintain the boundary condition. If the team cannot, the program manager would craft an OOB communication to be sent to key decision makers outlining:

1)  Which project boundary will be/has been broken

2)  The root cause for the broken boundary

3)  Alternatives to resolve the issue (with supporting schedule and/or cost-impact data)

4)  Recommendation of the project team

This communication can be delivered either via email or in a scheduled meeting. Key decision makers respond with either approval or a modified approach. To accelerate realignment, it is best if teams are empowered to communicate the recommendation and move forward unless they receive contrary directions.

It should be the intent of both the project team and key decision makers to complete this process quickly (within hours/days, not days/weeks).

What Are the Benefits?

  • Projects are realigned within hours/days, not days/weeks.

  • Once boundary conditions are established, the team is empowered to move forward with minimal guidance.

  • There is a single, agreed-upon communications vehicle and source of information. This consistency minimizes confusion and churn within the team.

Which Business Problems Does It Solve?

This light-weight process is an effective recovery vehicle for when projects go off the rails. It creates a common language and mechanism to quickly align the project and management teams when a project changes significantly. There is no time wasted by each team trying to create an exception handling process each time a deviation occurs. The result is faster analysis, decision making, and alignment to a new plan of record.

What Are some Considerations?

It is critical that there is agreement throughout the organization that the process will be consistently used and that each project constituency will execute their role on a timely basis. The value of this process lies in managing the project within relevant boundaries and then accelerating decision making when the boundary conditions are broken. If there is a breakdown in roles and responsibilities, the process will be marginalized and possibly exacerbate the impact of the broken boundaries.

Case Study

A cross-functional product team is in the development phase of delivering Widget X. The following boundary conditions for the project were established at the time of project approval and funding.

The team, in the development phase, has begun delivering early builds to the quality team. Testing has uncovered a critical bug involving a third-party component. In order to debug and resolve the issue, the team needs the help of the third-party developers. However, this is a lower-priority problem for them, and they will not commit to a timetable for resolution. Product marketing does not want to ship the product without this functionality. The project manager and development lead determine that if there is no resolution within two weeks, the project will break either the Feature Boundary or the Schedule Boundary. The project manager begins working with the development lead and product manager to analyze the root causes of this problem and evaluate alternatives to realign the boundary conditions.

Visualization: The Out-of-Bounds (OOB) Review

Out-of-Bounds Review

  1. Description of broken boundary and impact on project

A critical bug has been discovered in a third-party module. This module delivers a “must-have” feature for the release, which is scheduled to coincide with the annual industry conference. The bug is reproducible in approximately 25% of the test scenarios. However, this issue is not a high enough priority for the third-party developer, and resources have not been assigned to analyze or resolve it. The current impact is a delay in the schedule for 4-6 weeks.

  1. Alternatives

    1. Form a tiger team to replicate the functionality and/or create a workaround for bug scenarios.

    2. Decouple the feature and continue developing while working on the issue in parallel.

    3. Continue with the current version of the module and fix the issue in the next release.

    4. Recommendation

      1. Decouple the feature and continue developing while working on the issue in parallel.

      2. Request executive intervention with the third-party management team to raise priority.

A face-to-face meeting with key decision makers is not practical due to international travel schedules, so the program manager provides the above information in an email to the decision makers and copies the core project team to accelerate the process.