Project Management: How to Get the Project Back on Track? Source

Translated

Image source: Unsplash

Product development, as an investment, is the core of IPD. As investors, the decision-making level (the top of the company) needs to be responsible for the results and involved in the project development process.

But the question is: When to intervene? How to intervene? Should they go deep into every detail like Jobs or empower the R&D and marketing team like Cook?

The top of many enterprises either intervenes too much or too little in the product development process because it is not clear when to intervene, how to intervene, and what to do, which should be specified in advance in the process design.

That is The Out-of-Bounds Check we will talk about in this article. The Out-of-Bounds Check (OOB) is a lean, fast, and efficient process. It allows the team to focus and get back on track when major project changes occur. Setting "boundary conditions" at project approval effectively establish a "contract" between management and the project team as long as boundary conditions such as cost, schedule, function, and quality are not crossed.

This contract defines the timing of management involvement, allowing the team to move the project forward with minimal involvement from the top of the company. When these boundaries are crossed, the Out-of-Bounds Check is a mechanism to correct and readjust the program.

1. What is the Out-Of-Bounds Check?

The Out-Of-Bounds Check is generally abbreviated as OOB. Even if best efforts are made to anticipate and mitigate project risks, projects will be detailed sometimes. It's hard to get the team to refocus and get back on track when that happens. Who decides to reset the team process is often ambiguous, resulting in wasted time, inefficiency, confusion, and even frustration.

An Out-Of-Bounds Check is a simple tool that allows the team to quickly perform a root cause analysis, evaluate alternate solutions, and recommend remedies to the project decision-maker. When the project team detects or predicts an out-of-bounds condition to be triggered 80% of the time, the project manager will gather information to determine whether the team can solve the problem internally and maintain the boundary conditions. If it cannot be solved internally, the information should be sent to the key decision-maker with an overview:

• Which project boundary will be or has been broken;
• The root cause of the boundary being broken;
• Alternate solution (with supported schedule or cost impact data);
• Recommendation by the project team

This communication can be conducted by e-mail or at a scheduled meeting. Key decision-makers respond to approval or modification. The intention of the project team and key decision-makers should be to complete the process quickly in hours or a day instead of several weeks.

2. The Advantages of The Out-Of-Bounds Check

• Quick response: the projects are readjusted in hours or a day instead of days or weeks;
• Once boundary conditions are established, the team is entitled to move forward with minimal guidance;
• There is a single, agreed communication tool and information source, and this consistency minimizes the team's confusion and loss.

The key premise for using this process is that it is agreed upon throughout the organization. The value of this process is to manage within the project's boundaries and speed up decisions as the project breaks boundary conditions.

3. What Business Problems can be Solved?

This lightweight process is an effective recovery tool when the project details. It creates a common language and mechanism for quickly adjusting projects and managing teams when major changes are made to the project. Every time a deviation occurs, each team will not waste time trying to create an exception-handling process. The result is faster analysis, decision-making, and adjustment of new initiatives.

4. Cases

A cross-functional product team is at the development stage of Project X, and the boundary conditions of the team are determined at the time of project approval. The team is at the development stage and has started to deliver the early versions to the test team. The test team found a serious error involving the third-party component during testing. For debugging and resolution, the team needed the help of third-party developers. This issue is a low priority for third-party developers, who will not commit to a specific timeline for resolution. However, the product cannot be launched without this function.

The project manager and development lead decided that if there were no solutions within two weeks, the project would break the functional or schedule boundaries.