Over Target Baseline / Over Target Schedule

There is a condition in the DoD contracting business called OTB (Over Target Baseline) and its partner OTS (Over Target Schedule). This is the condition program managers want to avoid like the plague. It is a condition almost every commercial enterprise project lives in.
    I'll go way out on a limb here and say this condition in the commercial world has NOTHING to do with the fact that the project is a software project. 50% to 75% of the content of most aerospace and defense "flying machines" are software. It's not software that is the problem it's management process.
    So let's look at the conditions and processes of OTB/OTS in the context of a commercial enterprise software project.

• Step 1 - agree that the project is in trouble. Once we acknowledge this, some kind of replanning needs to be done. Using the lessons learned up to this point, how would we do it differently? Remember a Gen Colin Powell quote - "bad news is not wine, it doesn't get better with age." Face up to the problems and fix them. Don't pretend it'll get better - it NEVER does. Can't tell you how many times I've heard "we'll make it up in System Test."
• Step 2 - establish some consensus on the remaining scope. What have we produced so far? Is it what we planned to produce? If not, why not? If so, what remains along the road to "done?"
• Step 3- Develop a revised plan - using the information from Step 2, what does the new plan look like? This plan must consider what went wrong in the last plan. The new plan must have a plan not to repeat the mistakes of the past. The primary failure mode I see in commercial IT is "Late starts." There is a fundamental run in projects - "late starts = late finishes." Having work start on time is the foundation of success. But you've got to have a credible plan for starting work. This is another core benefit of Scrum style development. The starts are defined on 4 week boundaries.
• Step 4 - review this plan and gain concurrence of the customer, the stakeholders, the development team, any one and every one involved in the project. Concurrence is not the same as consensus. It must be concurrence. 100% agreement.
• Step 5 - issue guidance to replan the budgets for the remaining work. Eliminate the variances. This"resets" the project baseline. But you have to make sure you reset only the schedule first and not lose the cost variance. It is rare, but possible to reset the cost baseline. But care needs to be taken not to lose visibility into the schedule issues
• Step 6 - revise the detailed schedules (you do have those, right?) and prepare a new Estimate to Complete
• Step 7 - input the new ETC into the Earned Value Management System (you do have one of those, right?)
• Step 8 - review all these changes and plans for the future with the owners of the Work Packages. In defense these folks are called Control Account Managers. In the commercial work - if there is someone accountable for both schedule and budget for each Work Package - they have not formal name. This BTW is one of the core failure modes of project management of enterprise IT - there is rarely the "accountability" in the form seen in government projects.
• Step 9 - Finalize all these variables
• Step 10 - have senior management sign off on the new plan and schedule.

How Can This Approach Be Put To Work In The Commerical Work?
    The first action is to agree that the owners of the Work Packages are ACCOUNTABLE for the performance is the Work Package. In many of the commercial enterprise projects we work on this is a novel concept. The Project Manager is accountable and sometimes that accountability flows down to the responsibility of those doing the work.
    But there is a subtle and critically important concept here. Those doing the work are ACCOUNTABLE. Accountability is not the same as Responsibility. One of the core concept of agile software development is the mutual accountability of the team. This is in fact the definition of a team

A group of individuals who hold each other mutually accountable for a shared outcome

Once you move from responsible to accountable you established the foundation for success. Responsbile means "hey I tried." Accountable means "hey I failed to do what I promised to do." This BTW is the basis of Hal Macomber's promise based management method.
    Now most of the 10 steps cannot be directly applied to commercial projects for several reasons:

1. There is not a culture of accountability
2. There is not a culture of planning in enough depth to determine the plan, the risks, and the measures of progress
3. The unified process of managing the project - from senior management down to the developers - is difficult to impose, except in large organizations.

What Are The Simple Steps?

1. Define work packages as the unit of work
2. Define the duration for these work packages to be short to medium. Answer the question "how long am I willing to wait before I find out we're late?"
3. Connect cost, schedule, and technical performance (project deliverables meeting specification) and speak only in these three variables. This is the basis of Earned Value.