This is a process that is lean, fast, and effective in getting teams focused and back on track when material changes are made in a project.
Setting “boundary conditions” at the time of a project’s approval is an effective way to create a “contract” between the management and project teams. This contract allows teams to move forward with minimal guidance as long as the boundary conditions (typical cost, schedule, features & quality) 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.
Project Boundary Conditions
What is the Tool? Out of Bounds Review
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, its difficult to get the team refocused and back on track. There is often ambiguity around who makes the decisions that resets the course of the team, and result is lost time, inefficiency, confusion and frustration. The Out of Bounds Review is a simple tool that provides a team the mechanism to quickly conduct a root cause analysis, evaluate alternatives, and then recommend a remedy to the project decision makers..
When a project team detects (or anticipates at 80% 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 within the team and still maintain the boundary condition. If not, s/he 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 (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. It is best if teams are empowered to communicate the recommendation and “we’re moving forward unless we received contrary direction.”
It should be the intent of both the project team and the key decision makers to complete this process quickly – hours/days, not days/weeks.
What are the Benefits?
- Projects are re-aligned 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 on the team.
What Business Problems Do We 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 has changed significantly. There is not 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 on 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 the each project constituency executes there role on a timely basis. The value of this process lies in managing within relevant boundaries of the project and then accelerating decision making when the project breaks the boundary conditions. If there is a break down in roles and responsibilities, the process will be marginalized and possible exacerbate the impact of the broken boundary.
A cross-functional product team is in the development phase of delivering Widget X. Boundary conditions for the team were established at the time of project approval and funding. The team is 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 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 & development lead determine that if there is not a resolution within two weeks, the project either break 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 alternatives to re-align the boundary conditions