Change Management in Projects

Transcription

1 Change Management in Projects Overview About Change Management The Challenge: Manage change will remaining responsive to customer needs. You cannot hope to manage change if you have not done a good job of planning the project. Less-effective project leaders feel there is little time in today s fast-paced organization to develop a good project plan. Then, when the inevitable changes do occur, there is no way to evaluate the impact of the change upon the project. Thus poor planning leaves you unable to manage change. Change Management vs. Change Control Some people spend a lot of effort on project control. This is like trying to manage a stampede; it is a reactive form of management. Proper planning doesn t necessarily prevent stampedes; instead, it provides a baseline that allows us to respond to stampedes appropriately and redirect them to the path that best supports project objectives. The best approach is to partner with the customer to effectively deal with change. The Role of Requirements Another problem many projects have in managing change is the absence of good requirements. Without clear requirements you have no way to gauge the impact of a requested change. Even after Requirements definition, the project is still subject to unmanaged change. Emphasis here is on the word unmanaged. This unmanaged change includes needed changes that are ignored or deferred, due to a heavy does of change control procedures. A well-managed change request initiates a small project that lives within the project you are working on until you implement it or the customer withdraws it. The Process Change management can be viewed as a special project inside the larger project. This special project has a series of activities that study, recommend and implement requested changes. The special project is available as soon as you establish project requirements, and exists through the end of the project. Change Management and the Vital Signs Change requests often affect project scope. Some changes do not affect the project at all, for example, a change in the number of manual procedures needing documentation. Evaluate each of the vital signs to determine the best tradeoff that meets customer needs. Changes can affect the following vital signs: Schedule Cost Quality Risk A decision to implement a scope increase without increasing Schedule and Cost usually results in reduced Quality and increased Risk. When this happens, chances are that the change evaluation was weak, or the information was not communicated effectively.

2 Results of Successful Change The results of successful Change Management include an evaluation of the impact of a change and an approve/withdraw/defer decision. Successful Change Management also includes tracking of pending changes and a plan to implement approved changes. Finally, Change Management results in a satisfied customer and project team members who understand and are ready to accommodate the change. The outputs of successful change management include: Accepted Changes Current Change Log Revised Project Plan, including objectives, estimates, schedules and resources. Implement Change Procedures This activity is the initiation of Change Management procedures. It takes place upon completion and approval of the Project Charter (SOW). The activity communicates a consistent change procedure and presents needed forms and change request support. Procedure 1. Evaluate Change Factors Review the Change Factors below. These are the principle reasons for project change. Anticipate them and you will be better able to manage change, rather than merely controlling it. Changes are lurking in the woods, even as you read this. If you skip this step, you are guaranteed that your project will come in over budget and late! Change Factors Environmental Change o Business requirements change or increase o Volumes/amounts o Hardware o Standards o Social structure o External mandates Process Problems o Organization: team or customer staff changes o Misinterpretations or mistakes occur o Ambiguous specifications o Incomplete design o Incomplete documentation Technical Change o Detail added during development o Application of new techniques o Design changes to overcome newly discovered problems project-change.doc.doc Page 2 of 7

3 Hold a Change Management Meeting Hold a meeting to explain the purpose and procedures of Change Management. Customer management, your management, various customer representatives, and key team members should attend. Review the activities of the Change Management process, documented in this section. These activities are operative at the end of the Project Charter, through project completion. Importance of Clarifying Responsibilities Lack of change management leads to disaster. Unclear roles and responsibilities are the greatest reasons why change management fails to occur. Consider the following: It is the customer s responsibility to request change (unless there is a technical issue). It is the project leader s responsibility to assign the change for impact evaluation. It is the project team s responsibility to estimate the impact of the change. It is the project leader s responsibility to track pending change requests. It is the customer s responsibility to decide whether to implement the request, based on the impact analysis provided. Hope for Change Change is not a bad thing. In fact, if you are not getting change requests, something is wrong with your communications with your customers. Perhaps they have stopped reviewing and thinking about the project. Note: Not all projects changes come to you on formal forms. Often the team develops changes along the way: just one more report. The change management process works in that situation too. You need to be able to track all changes in scope. The change management process should be consistent, despite the nature of the change. Guidelines The client or customer should make the final decision about any change, based on your analysis of impact on the project s vital signs. A project should not change more than 25%. Log and track the status of all pending changes. At the end of the project, follow-through on all deferred or withdrawn changes. Log and Assign It is important to be responsive to change requests. We suggest helping customers to complete the change request. This activity logs the change for tracking purposes and assigns it for evaluation. This series of steps completes the activity: project-change.doc.doc Page 3 of 7

4 1. Record the Request on the Change Log Record the change request on the Change Log. Indicate the status as under Evaluation. Quickly determine the extent of the requested change in order to assign evaluation to a team member. You may find the One Minute Manager described below useful for this. Simply answer the questions yes or no. The more times you answer yes, the greater the extent of the change. The primary reason for doing this is to determine roughly how long it will take to evaluate the change. 2. Determine if it is a Small Change Small changes may not need to follow the regular change management path. However, you should still log these changes on the Change Log and keep track of actual time to implement the change on the form. You can quickly evaluate Informal or verbal requests for change to determine their impact. Small changes with minimal impact should be handled immediately. A small change should not require more than 3 hours total effort including evaluation and actual effort. If you have any doubt, follow the formal change request form procedures. Warning: There is a tendency for many changes to appear small. Modifications that involve more than one function, more than one data flow, the contents of a data store or more than two people to evaluate are large changes. 3. Assign for Evaluation Assign the change request to a team member for evaluation. If the team member understands the change, he or she should be able to estimate effort to evaluate the change. Review your answers to the One Minute Change Manager with the evaluating team member to improve understanding of the change. You then schedule the change evaluation just like any other delegated activity. 4. Update the Change Log Maintain the Change Log at all times during the project to track pending, approved and implemented change requests. Track the current status of changes with these change codes: - Logged - Withdrawn - Evaluated - Deferred - Accepted - Implemented 5. Disposition Use and file the output as follows: Review at the end of each phase to assure responsiveness and follow-through. At the end of the project, make sure an original is saved and a copy is archived in a records storage area. project-change.doc.doc Page 4 of 7

5 The One Minute Change Manager Do we know how the requested change affects... The problems we are trying to solve? Our objectives, their measurement or their scope? The tasks already completed and those necessary to successfully finish the project? Organizations affected by and those who can affect the project? The accuracy of the estimates and the assumptions that drive them? The staff, their availability, skills, styles and strengths... And how we are planning to apply them? The baseline schedule that the project can be completed within? Our status, compared to the schedule, and why? The expectations of this project, and the actions we are taking to maintain communication and public relations? What it will take to end the project successfully? Develop Change Impact Statement During this activity you evaluate the requested change by examining the appropriate requirements, design, procedures, completed documentation training plans, etc. The resulting impact statement will describe the sections of these diagrams, documents, or structures that must be modified in order to implement the change. Procedure 1. Determine Deliverable Changes Use the e (Evaluator) form to evaluate the change. This evaluation of the change relates to the impacts to the project and the deliverables. Review the change narrative and benefit of the change on the r (Requestor) form. Clarify the benefits, if necessary. Evaluate the areas of impact and effect of the change on the evaluator s side. In addition, the Impact Statement should describe the point in the life cycle that contains the activities that will be redone. Any activities to be redone should have reviews as well. 2. Determine Other Changes Some change requests have their impact in areas other than the deliverables. For example, perhaps additional procedures will require documentation. Another example is an increase in the amount of training to be provided to the end-user. Each change, regardless of its nature, should be evaluated according to quantitative criteria, so you can estimate the effort, cost and delay in the next step. Guidelines The Impact Statement does not attempt to evaluate the change. It serves only to determine what must be altered and what the resulting effect will be. The r and e forms must be kept together. project-change.doc.doc Page 5 of 7

6 Estimate Effort, Cost, and Delay The purpose of this activity is to estimate the effect of the change and documenting the result on the e or Evaluator s Form. The impact estimate should reflect all relevant factors of the vital signs: Scope, Schedule, Cost, Quality and Risk. 1. Analyze Schedule and Resource Impact Look at planned activities that may be impacted by the change. Include work that must be redone and current efforts. Identify the rough schedule and cost impact on later phase efforts. Summarize total resource requirements and costs. Add schedule impacts and assess the impact on quality and risk. 2. Evaluate Against Objectives Evaluate the request against the project (original or revised) objectives and determine if: The change is necessary to meet objectives and/or If the request changes the objectives. 3. Make a Recommendation Review the results of the analysis against the stated benefits of the change. Make your recommendation for resolution of the change. Warning: If a change will cause a slippage in delivery, add costs or require additional resources, and make sure you inform your customer. Stay consistent to instill the idea that changes are not free! Decide Whether to Implement Change Customer management must decide whether the change will be withdrawn, deferred, or accepted and implemented. If accepted, the group must agree when the change will be implemented. They must also agree to the resulting impacts on the vital signs of the project. Warning: It is not the role of the project leader, team, or project organization to make this decision. Instead, it should be made at the highest possible level in the customer department. You have done all you can to influence the decision by performing a professional analysis of the business case regarding the change. After the Decision Record the resolution of the in the Change Log. File all requests. They represent expenditure of time. Guidelines Change is expensive. Any changes to the project should be given the same attention and effort as the original planned work. Don t skip reviews of the s and Change Logs to save time. Make sure to update and file all affected documentation. project-change.doc.doc Page 6 of 7

7 For Each : Change Management Process Customer Log & Assign Small Changes Assigned Ongoing Change Management Develop Change Impact Statement Change Log Track Actual Effort, Cost, Delay Impact Statement Estimate Effort, Cost & Delay Completed Change Request Form Project Plan Revision Alternatives Decide Whether to Implement Change Accepted Changes Modify Completed Work Implemented Change Forms Deferred Changes Project Document File Withdrawn Changes Reference: Adapted from The Project Guide, Version 4.0/SE, The Guide Associates, Inc., project-change.doc.doc Page 7 of 7