I originally authored this for the PM Tips project management website.  The original article is located  here.

I’ve already written a lot about customer indecision, change orders, and the customer’s inability to truly know what it is they want.  And I’m sure I’ll write considerably more on the topic as it is one of the most critical issues we deal with and our ability to manage these situations is often directly tied to customer satisfaction.  It’s our job as project managers to drag that out of them and to anticipate what some of their unstated needs are along the way. 

Even though I’ve shared many of my own thoughts on this topic, I still find that it’s interesting to present other view points and text giving different angles on the same popular topics.  Most of the text from this article comes from the book “Integrated Project Management” by Earl Hall and Juliane Johnson.  This is subsection of their chapter on project change and deals with the how to handle customer indecision and changing requirements.  It’s a little dry, and I think it underestimates the amount of changes that PMs must deal with in the course of an implementation, but fundamentally it’s pretty sound.

Management of Customer Indecisions

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, integrated project management (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 andthe resource table—is the necessary reference for the considerations of what can be done and what this will cost.

 


Comments




Leave a Reply