Project Management Strategies Series Article 3 - Managing Change By Stephen Yuhas
This information is brought to you by mkt1on1 at http://db2bdh-ednxp4m49ogs247bq7q.hop.clickbank.net Change Management is not easy. It is a painful process that requires the Project Manager to be both a warrior and a diplomat. You will need an arsenal of quality tools, and well honed soft skills to make it through managing a change with little or no collateral damage. I am sure you think I am exaggerating. Here's why I am not: 1. You will have 3 factions to deal with: • • •
A key group of stakeholders will think the change is vital to the success of the project (they may or may not be right) and will be unwilling to budge until the change is agreed upon and implemented. Another group will have no capacity to absorb the change without additional funding and/or time. Leadership. You are not likely to get more time. You may or may not get additional funding, but more funding is not likely to help without crashing the schedule anyway until new resources are brought up to speed.
It's even more fun when the stakeholders who want the change are also leadership. I'm sure you've heard, "Just get it done" before. 2. Most people are naturally resistant to change: Once headed in a particular direction, it's at least irritating and often demoralizing to people who have to change direction or start over. Maintaining positive energy in the ranks is a challenge, especially if things keep changing. 3. Someone ultimately is going to be unhappy about the final decision. In the end though, change is natural and will happen. You will be successful if: • •
You clearly set expectations about how change will be managed early in the project. Decisions to make or not make a change are well informed decisions.
Key Strategies for Managing Change 1. Plan your butt off and define scope extremely well. Strong planning around solid scope definition is a key to minimizing unexpected change down the road. 2. Force quality requirements development. Don't even think about design or engineering before you have a high level of confidence that requirements are solid and well understood. If you inherit requirements, make everyone review them and agree to them again before going too far into design. You will be pressured to run ahead because things will appear stagnant during requirements engineering. Trust me, stand your ground. It will pay off down the road. 3. Plan for change. It will happen regardless of how well you do 1-2 above. Developing a simple to follow process as part of your plan will help set the expectation for everyone and make it easy for you to act swiftly when the time comes. 4. Get the following key stakeholders to agree/sign-off on your project plan and requirements. This won't always help when the rubber hits the road, but it does put everyone on a level playing field when that first change request comes in: • •
The Project Sponsor. This person will be like Dr. Jekyll and Mr. Hyde when it comes to change depending on which faction has his/her ear. If you can at least get agreement for your change management process, you will minimize snap decisions that can de-rail your project. Engineering/Development Managers. This group will be moderately resistant to change without additional time or funding. They will be protective of their teams and will push back on requiring their people to work additional hours. Assuring them that no decisions will be made without their input will keep them from assuming a defensive posture and help drive collaboration when the time comes.
•
Quality Assurance or Test Managers. This group always gets screwed when it comes to change. No wiggle room in the schedule often means shortening of the QA cycle. They know it, and are already on the defensive. Incorporating quality considerations into your change management process will enable this group to describe risks to quality when certain decisions are made. While this may not ultimately change the final decision, at least this group will have been at the table with a voice.
The Change Management Plan This section of your project plan needs to include the following: 1. Clear criteria for when the change management process is required 2. Roles and responsibilities 3. A simple step by step procedure that includes how to perform these key steps: • • • • •
Requesting the change Impact assessment Exploring alternatives Making the final decision Drafting the tactical plan to incorporate the change and get back on track
In addition, you will need to have standard templates/tools in place ahead of time to help manage the change when the time comes. • • •
A Change Management form or template. A SWORD Analysis (a future article) A Change Management Log
Change Management Criteria The change management process is required when a requested change will likely have any impact on project scope, increase in schedule, increase in cost, or degradation of quality. Other texts may say that ANY impact to schedule or cost require the change management procedure to be executed. I personally disagree, but you can decide for yourself. Roles and Responsibilities Every project should have a predefined Change Control Board (CCB) that includes at least the Project Manager, Project Sponsor, Development/Engineering Managers, and QA/Test Managers. Your projects may require additional roles. Here are some quick guidelines: • • •
Roles should be included if they have resources assigned to the project, human resources, HW/SW resources, financial resources, etc. Roles should be included if they are managing projects that have dependencies on your project, or vice versa. Roles should be included if they have oversight across multiple related projects, i.e. Program Managers or Release Managers.
Each member of the CCB will have different responsibilities. Here are some examples: Project Manager(s) • • • •
Document the change request Manage the change request through the process Facilitate the CCB meetings Incorporate approved change requests into the project
Project Sponsor(s) •
Attend CCB Meetings
•
Make final decision to approve or reject each change request
HR managers for resources assigned to projects and System managers managing systems impacted by your project • • •
Perform Impact Assessments as requested Attend CCB Meetings Participate in implementation planning for approved change requests
Release/Program Managers • • •
Drive Impact Assessment for dependent projects Attend CCB meetings Participate in implementation planning for approved change requests
Impact Assessment This is the most important piece of managing a change request. A quality impact assessment will drive an informed decision and, when the change request is approved, will ensure smooth introduction of the change into the in-flight project. Do this well. Each group/team represented in your project and dependent projects will need to complete an Impact Assessment. Simply put, this is an estimate of additional cost and/or duration that team will incur if the change is approved. This information is compiled from all teams and then brought to the Change Control Board meeting for discussion and decision. Exploring Alternatives Very often, a person requesting a change will be very focused on exactly what he/she wants for a solution, and will not clearly articulate what the problem is that needs to be solved. Because of this, you should always go through the exercise of exploring alternatives. A good branistorming exercise with key stakeholders almost always results in a creative solution that will result in less drama that the originally proposed solution. This is because everyone has had a chance to voice opinion, and will be more willing to compromise. Look for another article by me titled, "SWORD Analysis, SWOT with an Edge" where I discuss a great method for exploring alternatives. Making the Final Decision Now that you have all of the information compiled, the final decision is made. If you have done everything up to this point as described above, the decision is simply a formality. More often than not, the decision was already made during Exploring Alternatives. But in very rare cases, it's not so simple. In cases like that, you will need to call upon your sponsor to make the final call. Drafting the Tactical Plan OK - so now you have an approved change request. The final step - implement the change. Simple? Not quite. Think of a change as a small project within the project. As such, you will need to have a plan for how the change will be implemented. This plan should contain many of the sections of the project plan, but very simplified. Your plan to implement the change should be a single page document or less. Here are the sections you will need: • • •
Roles and Responsibilities Tasks, including who is assigned, and when it is due Status reporting plan - how people can expect to be notified of the progress
The Log Finally, you will need to track the progress of all of your change requests so that you can manage several at once, as well as keeping everyone in the know about them. Your log should contain the following sections:
• • • • •
ID - Simple numbering suffices Title - A short title describing the change Description - a paragraph that describes the change in more detail Requestor - The name of the person requesting the change status - Requested, Assessed, Alternatives Explored, Accepted/Rejected, Implemented (if accepted)
Add more if you like, but these are the primary sections. Phew! I know it seems like a lot, but trust me, you will need to get good at this. Strong change management skills are what will separate good project managers from great project managers. Keep reading and I'll keep writing!