Organizational change and systems and technology implementation projects typically are high-risk and return endeavors. They require the commitment of significant resources and have potentially high returns, but a large number of them produce disappointing results. This paper defines a methodology for controlling projects to maximize the likeli­hood of completing them on time and within budget. The methodology has been successfully applied to dozens of large and small projects. It is presented as a means of controlling a single project, but is equally appro­priate for overall control of a group of related subprojects.

Controlling a project seems so simple, yet few organizations do it effec­tively. Why? It is typically because they

• don't understand what is required
• don't have a methodol­ogy or the tools
• are focused on controlling the wrong things
• don't believe that it is worth the effort.

The methodology pre­sented addresses all of these reasons, and each of
these steps will be explored in more detail. It is important to apply a variation of Pareto's Law in each of the steps. Focus on the very im­portant few, but don't let the important many cause unexpected and unpleasant surprises.

Successful control of a project begins with a sound definition of the critical assumptions and the expected outcomes. This definition must be written and agreed to by all parties. The project plan that defines the work that must be done to produce the desired outcomes is developed from the project definition. A project control system must be imple­mented before execution of the project plan begins. The execution of the plan is the step with the largest resource commitment and risk. The implementation of a control system to measure progress and report status during execution is critical to producing the desired outcomes. No project is complete until the lessons learned and suggestions for future project teams are captured and documented.

DEFINE THE PROJECT

The project definition begins with a mission statement that identifies what is to be accomplished, the target for accomplishment, and the expected benefits. Figure 2 presents a template for and an example of a mission statement. The expected benefits are the business reasons for undertaking the project. The organizational change or technology is the means to the benefits, not the benefits themselves. The benefits should be time-phased because they typically are not all realized upon completion of the project. Some of the benefits are realized after the project has been completed and the organization has had time to im­prove its operations using the capabilities delivered by the project.

The mission statement is then broken down into a set of objec­tives that are necessary and sufficient to achieve the project mission. This means that the mission cannot be met unless all the objectives are accomplished and that it will be met when all the objectives are accomplished. Too frequently, the mission statement will not be met by achieving the objectives, or objectives are included that are not necessary to achieve the mission of the project. The first case cannot be tolerated. The second case provides opportunity to recover from schedule slippage. Each objective must have a target date and a list of the expected benefits from accomplishing the objective. A project will typically have 5 to 20 objectives, and each objective will have a list of deliverables associated with it. Each deliverable must be de­fined, bounded, and time-targeted. It is helpful if the deliverables can be categorized as:

• critical with widespread use
• critical with limited use
• necessary
• deferrable.

This categorization facilitates recovery planning when it becomes necessary. A valuable component of the project definition that is fre­quently overlooked is a concise summary description of each deliver­able. Write a paragraph describing each deliverable in business terms and sequence them by expected availability date. Avoid the typical scope of work that can only be understood by the individual who wrote it.

The critical assumptions are the last component of the project defi­nition. They should include:

• any firm deadlines
• resource constraints
• minimum performance levels
• regulatory or contractual requirements.

The project definition provides the first opportunity to manage ex­pectations. The mission statement, objectives, deliverables, and target dates define the expectations for the project. The boundaries of the project scope, performance measures, target dates, and the timing of benefits characterize them. Test key stakeholders to ensure that there are no undocumented expectations.

The available options when you are handed an ill-defined project are to

• ignore the problem and gladly accept the assignment
• turn the offer down and pursue a different job
• create fear, uncertainty, and doubt about successful completion
• build the refinement of the definition into the project plan.

The last alternative is the only one that makes sense. It makes the problem visible and presents a reasoned way to address it without de­lays or unpleasant surprises.

To Be Continued

For balance of this article, click on the below link:

Lean Manufacturing Articles and go to Series 01