A project manager must begin working on a project with the expectation that the customer will request change at least once, perhaps several times, regarding the project outcome(s). The project manager must be prepared for the possibility that a task leader or an external subject matter expert will discover and present a new or better way to perform tasks after the completion of the task list. If the proposed change occurs during the project planning period, it can be accommodated by backing up the planning process and replanning with the change(s) in mind. Before this is done, however, the project manager must create a new, revised specification statement and clear it with the customer, appropriate subject matter experts, and key team members. The project must always be working toward one clear goal, and all prior specifications must be destroyed.
Change requests that arise during the project's planning process are not hard to deal with if they are few and infrequent. Changes do interrupt the planning process and cost time and money, but aside from that and the frustrations the team experiences, they can be handled effectively. When a customer is uncertain about exactly what he or she wants and frequently changes his or her mind this must be dealt with as a special case.
Customers often want a project to begin before they have decided on a precise outcome. They may not expect to be able to precisely define what they want for some time. However, IPM is based on the premise that a precise outcome statement specification must be decided upon before planning can begin. Both experience and logic support this proposition. Nevertheless, when thinking is at the scope level, it is often reasonable for the customer to be uncertain of the precise outcomes. Can an integrated project be started under these conditions? The answer is yes. A preliminary specification can be created. A project manager begins the project by leading the creation of this specification.
As the project manager helps migrate the project from scope to specification, he or she aims for a precise specification that will capture the current best estimates of what the outcome should be. This specification will be used in the initial planning and execution of the project. At the same time, the project manager puts in place a project specification change procedure to deal efficiently with the outcome changes the customer may desire later on.
Experience has proven that this approach is more efficient than simply starting in a general direction, then adjusting, redirecting, and reorganizing as an outcome concept emerges. It must be understood that in IPM, replanning will be a major event and will not take place piecemeal. It will not occur often during the life of the project. Small and frequent modifications of the specification must be prevented because such practices kill projects.
The rationale for insisting on the creation of a specification before starting project planning derives from the processes that must take place when the change in a project is executed. Before a project can be changed, there must be something to change. The effort to get the customer to agree on what the "current" best estimate of what the outcome should be is defined within the statement of work. Sometimes, customers do not decide on exactly what they want until they see what is involved in providing them with what they think they want. Sometimes, the general dimensions of an outcome are identified, but the exact characteristics of the outcome must wait on "research in progress." The customer and the project manager agree that a precise outcome definition within the general framework of the expected outcome will enable the project manager to begin the project planning. It also will provide for the startup of project execution. The initial plan is expected to be relevant when the revised outcome statement is decided upon.
Creation of the initial project plan gives the project team something useful to do now, and it creates a good plan for the team to examine and change when a specification revision is presented. This fits in with the fundamental process of project change. When a change is proposed, the original project plan the Gantt chart and the resource table is the necessary reference for the considerations of what can be done and what this will cost.