Change Management Tips

There are two knowledge areas that will determine how well the product you build will satisfy the needs it was built to meet. The first is requirements management, or scope management. The way in which you capture requirements initially, and trace them throughout the design and build process will have a profound impact on how well your product meets your customer’s needs. The second is change management. The needs your product will meet are not static so engaging in a project which can’t support changes to the original requirements is doomed to failure.

Changing needs are not the only source of change. It’s very common for stakeholders and business analysts to learn more about satisfying business needs as they define other needs. Let me give you an example. Let’s say you’re building an e-store (a commercial web site) and you need a means of alerting your customer to a sale you’re conducting on a subset of your products. You find out that the platform you’re using to build the web site supports a new form of popup window so you determine that the popup is the best way to meet this need. The popup approach has a much wider potential application so you determine that the popup window would actually be the best way to handle the choice of shipping methods, but you’ve already designed that feature without the use of a popup. This is a legitimate source of change.

There will be other sources of change that have nothing to do with requirements. Take budget as an example. You may have initiated your project during a "boom” time in the economy when your organization’s finances were robust and your sponsors envisioned a "Cadillac” solution to their business needs. Now the economy is in a recession and the budget is no longer available for the "Cadillac” solution so you have to scale back the project scope.

Schedule can also be a source of change. You may have initiated your project at a time when an 18 month schedule would have put your product on the market before your competition, but now you learn that the competition have initiated a project to introduce their version of the product to the market place and they have advertised an introduction date 15 months in the future. You now need to change your plans to get to the market place in under 15 months to preserve your marketing lead.

Requirements management and change management work hand in hand to produce the product that your customer or client needs to succeed, when they need it, and for the right budget. Your project is bound to fail no matter how well requirements are gathered if you don’t have a good process for managing change. A good process will be effective in implementing the right changes and rejecting the wrong ones. To do that, the process needs to identify the activities that will gather accurate information to base a decision on and the right people to make the decision.

This article doesn’t intend to teach you all you need to know about change management. It’s intent is to provide project management practitioners who have studied change management with some tips that will help them implement the theory they’ve learned elsewhere. The bible for project management best practices is the PMBOK® and the certification that signifies you’ve learned all that source has to teach you is the Project Management Professional (PMP®) certification. I urge you to investigate taking the PMP® certification exam. There are several excellent PMP exam preparation training products and PMP courses available that will help you achieve that goal. Some are in class, some are available on-line, and some are plug and play such as our product, AceIt©. AceIt is available from our web site at http://www.threeo.ca for those of you who are interested.

1. Tailor the process to your organization. If your organization has never implemented any form of change management you will be forced to define the tasks and responsibilities to support the process from scratch. Just remember that you have 2 key goals: gather all the accurate information that the decision makers need to approve or reject the requested change and that the right stakeholders make the decisions. You want to achieve these goals with the least amount of fuss possible. Don’t skip any steps that support these goals but don’t take unnecessary steps to satisfy someone else’s vision of a good process and don’t make the steps overly burdensome. Customize existing processes where your organization has them. For example, you may not have a project change management process but have a process for introducing change through operational activities. Examine that process to see which activities will fit with your project’s needs. You should be able to re-use the change request form from the existing process at the very least. Consideration should also be given to the software development methodology chosen for the project, where the product is a software system. Agile type development methods should not be over-burdened with change management activities.
2. Change management activities will not be a "one size fits all” proposition. There will be requested changes where you’ll need all the activities your process calls. These will tend to be the larger changes, for example the introduction of a new set of features, or a significant change to budget or schedule. Changes that don’t involve a major shift in scope, schedule, or budget should not require a sponsor to make a decision. Design your change management process to accommodate both major changes where a decision should be made by a sponsor, and minor changes where the decision can be made by you, or another member of the team.
3. Build time into your plan for the analysis and investigating activities that will be required to determine the cost of implementing a change request. It is impossible to predict how much time will be required because you can’t predict how many change requests you’ll receive and how complex they will be. If you knew what changes your stakeholders would request, you’d make them part of the requirements. One way of addressing this lack of information is to choose a buffer as a percentage of the estimated build time and track hours against this buffer. One disadvantage of this approach is that it is very difficult to pre-determine who will need the buffer. Developers or programmers and QA testers will typically be called on for effort estimation in software projects, but business analysts and others may also be required to investigate. You need to identify a course of action when the buffer is fully depleted. You can request a change asking for more analysis time. You can also close off the process and delay further analysis until the next iteration, if you’re doing iterative software development.
4. Educate your team and your stakeholders on the process you define for your project. Subject Matter Experts (SMEs) who will be called on to perform analysis and investigation to determine the cost of the requested changes need to understand their roles in your process, how the process will engage them, and how their deadlines will be determined. Stakeholders should also be educated on how the process will manage the changes they request. They should be educated on the information and detail level they will be required to supply, expectations and demands on their time to answer any questions that the SMEs may have in the course of their analysis, the turn-around they can expect when they request a change, the decision making process, and how the process will communicate with them. All team members and stakeholders should be educated on the process, including the sponsors.
5. Track each change in a change log. This log will become a central source of information about the changes submitted. Information that should be tracked will include: identifier, date received, originator, current status, current owner, decision, cost (effort or money), and implementation date (if applicable). The log will become a key communications tool for both you and your team. It should be posted in a central location, provide read access to everyone on the team, and write access to you or the person responsible for managing change on your project. Don’t neglect to record the amount of effort or budget that approved change requests have collectively cost. This information will be useful in helping to explain where budget or time has been spent.
6. Don’t forget to re-baseline your project after a change to the scope, schedule, budget, or quality standards has been made. Most project managers will always remember to update their MS Project plans after a change, but not everyone will remember to change other artifacts such as the reports, charts, and graphs that report performance to the project goals and objectives. When you adjust your MS Project plan to reflect a new end date, don’t forget to change your Budgeted Cost of Work Performed (BCWP) when calculating your Schedule Performance Index (SPI).

These tips won’t make a bad change management process work, or replace a change management process, but they will help you define a good process and make it easier to implement. For tips on managing your change request buffers, click this link. For tips on alternative methods of paying for changes, click this link.