| Change is inevitable. It is unrealistic to expect to execute a project exactly as planned although sometimes it does happen. Allowing change to haphazardly creep into a project at the task level is fatal. When planning is completed, it is devastating to be expected to fudge tasks and add elements to accommodate new objectives without also changing the project Gantt chart. Therefore, it is absolutely necessary at the kickoff meeting to appoint a change committee to implement change procedures covering all possibile changes. The project manager should chair this change committee. He or she should keep the records, receive the change requests, and promptly convene the committee to deal with these requests. The project manager may be able to personally deal with the requests for small changes. Yet, even in the case of small changes, he or she must document the changes in a report that is given to the person requesting the change, the change committee, and the project team. To be efficient, the change committee must be kept small. It also must be able to call on various subject matter experts to help evaluate any proposed changes. Committee membership should include at least one empowered customer representative, an accounting representative (to provide cost analysis), and key project task leaders. Change procedures are simple and straightforward. Written approval from the change committee is mandatory before a change can be implemented. Every change, including the customer's change must be submitted in writing on the following change request form and the change committee will respond with its report: Project Change Request List the benefits from the change, or why the change is necessary. The reason for requesting this change is_____________________. What does the change consist of? What time and resource requirements are associated with the change? How will the change affect the cost of the project? Change Committee Report Disposition: Change approved or Change rejected or Change approved in part How is the project affected? The rationale for the committee decision is_____________________. A person requesting the change must provide the following information: The reason for the change and how it will benefit the project What the change consists of and how it will affect the project's outcomes, process, and timing Estimates, with explanations of any new timing and resource requirements believed to be needed An Estimate on how the change will affect the cost of the project Having to think through and document these items will eliminate many frivolous change requests. It is especially important that the customer understands and agrees to use this process, because it is clearly in his or her best interest. The procedures that the change committee follows must be clear to all members of the project team and to all of the stakeholders. Change requests are to be submitted to the project manager, who will always give them prompt attention. He or she will examine the change request and place it in one of three categories: Trivial, Feasible, or Not Feasible. Trivial changes are changes that the project manager can easily deal with. They clearly do not negatively affect project process, cost, or outcome. They do need to be addressed, and their disposition must be reported. One example of a trivial change might be a customer's request to have the project reports bound in flex bindings with blue instead of red covers. Although this change is very simple, it must be documented and passed on to the task leader who is responsible for publishing the project report, or it will not happen. No cost changes or time changes seem necessary. A very conscientious task leader may discover that with a small additional effort, he or she can produce an outcome that significantly improves the accuracy of a measuring instrument being developed for the project. A question for the project manager to deal with is, "Does this improved accuracy contribute to the objective(s) of the project?" Technical people often are fascinated with achieving exquisite outcomes. They enjoy doing things very well. But, if the project does not profit from the improved accuracy, the extra effort should not be supported. The project manager, through direct inquiries, can determine whether "improved accuracy" contributes to the value of the project's outcome. If the project outcome can become more valuable to the outcome users as a result of this change in the task effort and the cost is negligible, the project manager may consider this change for approval. There are other considerations, however. With reference to this and most proposed changes, the project manager looks at the Gantt chart and the resource table. Is there slack available for this task, and is the task team's time open for the additional effort? If people are available, task timing on the project permits it, the costs are negligible, and the project output gains value for the customer, the project manager approves the change. Checking with people, and checking the charts, tables, and the cost for something like the proposed change often does not take much more of the project manager's time than it takes to read about it. Although documenting the process and the decision may take a little longer, it must be done. Documentation of negative decisions is as important as documentation of positive decisions. Sometimes, the same proposal comes up repeatedly. Having good documentation means that you only have to consider the proposal once. Changes that are not feasible generally cost too much, take too long, or both. The project generally has a time and cost upper limit, which is defined by the sponsor explicitly or implicitly. The sponsor may request a change that is outside this realm without realizing it. The project Gantt chart and the resources table are the measuring tools that the project manager uses. He or she examines the proposed change and compares it to the work packages and tasks on the Gantt chart that are related to it. If it costs $100,000 to do one easily identifiable part of the work, and the change being considered will require a very similar addition of effort, the project manager can reasonably estimate that the change will add another $100,000 to the project's cost. Without the Gantt chart as a reference, the project manager probably would have to do a good deal of analysis to arrive at this conclusion. However, because these changes are always somewhat related to what has already been planned, there is a good chance that their costs can be estimated by referring to work that has already been planned. The project manager can determine an approximate cost that is not obvious to the customer, and can report this cost with an explanation of how it has been determined. The customer makes the final decision about cost feasibility. Knowing the customer's constraints, the project manager will report the cost of the change as something that does not appear feasible. A similar consideration, analyzed with reference to the Gantt chart, may be related to a resource's availability. The change being requested for may call for the use of resources that are not available and never will be. Dealing with trivial changes and changes that are not feasible generally does not require a meeting of the change committee. Dealing with such changes, however, does call for a report to the change committee, the change requestor, and the interested stakeholders. The remaining category of change request feasible changes deals with adding time and effort that appears to be within the cost and time tolerance limits. A detailed examination of what additional tasks or task extensions are necessary must be done to determine what affect the change would have on the project and whether or not it can be considered to be cost effective. To deal with this type of change, the project manager will convene the change committee and invite the appropriate subject experts to draft a rough plan for including the change in the project. Because changes always relate to what has been planned and what has been done, the Gantt chart and the resource table are important sources of data for extending the project. (If the change proposal is not related to what is planned for the project, the proposal calls for a new project.) When the rough plan for the inclusion of the change request has been worked out by the change committee, the approximate cost, and the time and resource requirements for the change are identified. These costs and resource demands can be measured against the benefits achieved by a successful change to provide a basis for the change committee's decision. The final call on this change is generally up to the customer, but the change committee has provided good data for the customer to use in making a decision. If the customer decides that the change effort is worth the cost in terms of the benefits that accompany it, the project manager reconvenes the project team or the affected units of the project team and, replans the project in detail. The new specification the specification that includes the outcomes the change is to achieve is published along with the new Gantt chart and resource table. All older materials then must be taken out of circulation. If the change is approved, the project team will reconvene to replan the project. With a major change, the basic project planning steps creation of a task list, Gantt chart redesign, and risk analysis must be carried out. Work resumes when the new project plan is completed. Project change does not involve tearing up the Gantt chart and starting over. The existing chart provides a major reference for replanning the project. The new Gantt chart will significantly resemble the old chart. Although replanning will not require as much time as did the original project planning, it still is absolutely necessary. The old chart must be permanently set aside, and the new one must be used exclusively. Remember, the new chart reflects the project's changes! If the change is fundamental, the old Gantt chart must be torn up, and planning must be redone, which means starting a new project. In this case, it is important to close out the old project before starting anew. As the project progresses, suggestions for small changes often are made. However, continually dealing with small changes is never functional. The project leader must make judgment calls as to their consideration. Generally, these changes are processed after being batched and considered together. The process of making changes and replanning must not occur often. In a one-year project, generally only one or, at the most, two, major project changes should be processed. If multiple changes are allowed throughout the life of the project, it can cause a specification creep. In many organizations, this is called "scope creep." Monitoring and managing the changes to the specification is the key to delivering of the project on time and within budget. If the change is not approved, the project manager should ensure that the reasons for its denial are documented with the change request. This documentation is imperative for all projects, but more so for major and macro projects due to changing team dynamics. As project sponsors or team members are added or removed from the project, many of the same changes may be requested. By keeping a change log of all of the requested changes, the project manager is able to quickly bring any new team members up to speed. |
