Change Management to Move Projects Forward

Change Management is Misunderstood

“The only man I know who behaves sensibly is my tailor; he takes my measurements anew each time he sees me.  The rest go on with their old measurements and expect me to fit them.”  ~George Bernard Shaw

There is a misconception, in many organizations, that if we simply keep moving along with the changes, without officially acknowledging or evaluating their impact, that everything will work out in the end. People with this naïve approach believe:

• The project will be within the budget.
• The end product will ultimately be better and support our project Return On Investment (ROI) and strategic value.
• The cost and timeline will still be met.
• No one is worse for wear.

This misconception is especially strong when small to medium-size projects are deployed. After all, we have done this successfully in the past without the ‘formality’ of change management.

The reality is, change absolutely causes dysfunction within a project team. When change is introduced and not communicated properly it leads to:

• Confusion and frustration of what is required, infiltrating components of the team.
• Some members of the team not knowing a change was introduced and they do not perform tasks to support that change.
• If tasks are not performed to support the change, additional time to correct this is required during development, testing and training.
• Delays are often experienced or unnecessary overtime.
• The change that was introduced, informally, may be retracted; causing some work to be ‘backed out’.  This assumes there is a formal declaration the change was rejected; which of course there probably isn’t. The team just knows.
• Stakeholders may think the requirements are different than they are.
• There is no history of the changes to help ‘tell the story’ of the project.
• Change in direction could affect the overall business alignment, vision and training; without those areas realizing the change took place until it’s too late to correct.

Agree on Changes that Add Value

“All change is not growth, as all movement is not forward.”  ~Ellen Glasgow

I was recently on a project where many changes were introduced, after requirements were agreed upon and ‘finalized’. Many of these changes made good business sense and we understood the need to the end user. However, the customer was tasked with remaining on-time and staying within budget.  How can significant change keep us on-track and deliver on-time and on-budget?

Here is some background: Our customer needed to produce a sales scorecard for our field representatives. Key metrics were essential to help managers coach and mentor the sales staff. The reporting scorecard, with drill down reporting capability, would be the tool to help them understand the weekly sales and be the driver to help the business meet plan. If we didn’t deliver in a timely manner, the field might not have time to react and meet projections.

Therefore, the Project Manger (PM), Business Analyst (BA), customer and project team agreed that before the team worked on any changes in direction or ‘new’ requirements; the change would be evaluated and presented to our customer. We put into place a controlled change management process as follows:

Impact of the Change

In order to understand the impact of the change and provide an accurate evaluation, the Information Technology (IT) team may need five minutes or up to a couple of days. Many times the IT team needs to determine if the request can be supported with data, configuration or code changes that we already have, or if a new process needs to be developed. The business too may need to spend time determining impact to the field, training and/or ROI.

In my project, the PM and customer would discuss the amount of time and impact it would take to evaluate the change, prior to putting rigor around gathering information on the impact of the change itself. In some cases, the fact the change would take 15 hours of work to determine impacts to cost, timeline and resources while also delaying the release by a day; was enough to cancel the change on the spot with no additional effort. The PM would document this in a Change Log, being sure to document the decision, but would not create a formal Change Request Form. This was a quick and easy way to weed out ‘nice to haves’ or changes that didn’t really move the business forward.

If the time to evaluate the change and associated impact was accepted, the core team would be assembled for evaluation. The following questions would influence the team’s  go-forward plans:

1. Do we understand the new request? If not, we would get more clarity from the customer.
2. What tasks would need to be added to our work to accomplish the request, including requirement gathering, changes to design, additional testing, new process development, configuration changes, training and so on?
3. Do we have the resources to fulfill the request and if not, who do we need?
4. Impact to timeline, if any?
5. Impact to cost, if any?
6. Are there any risks introduced? What are they?
7. What are the benefits to fulfilling the request, from the business and IT perspective?
8. Do we have any options for the business in order to accomplish the goal but at a lower cost or timeline for delivery?

Since time was of the essence; we would do this quickly after the change was recognized.

During this evaluation, work continued as originally planned. No one on the team would begin work on the change. The work did not begin on the change request until the customer accepted the cost, timeline and solution impacts.

Communicate the Change

The PM would communicate the results of the evaluation to the customer within a couple of days, max.

Our customer was then armed with all the information they needed to determine if the impact of the change was acceptable or determine if the impact was too large and if the change needed to be rejected.  

Once the customer approved or rejected the change request, the PM would send a message to the entire project team providing the status. If the change was accepted, the team changed direction and followed the plan to work on the items needed to support the change. If it was rejected, the team was aware and simply continued work as originally planned.

Benefits of Change Management Process

The benefits of this process for our team included:

• Allowing the business customer to have all the facts in front of them before deciding to move forward.
• Customer understood why a request, that sounds small from a business perspective, could be significant on the IT side.

1. Using change management and the evaluation process, the customer could be educated on all impacts to the relatively simple change request.
2. For example:

We would like to know the sales by x, y and z. However, IT found out that x, y and z were not captured at the point of sale and not stored on the database. The IT team would need to apply complicated business logic to the data in order to derive it. This meant complicated test scripts and data validation efforts. All of this added considerable time to what sounded like a simple piece of data. The business customer didn’t like the fact the information needed to be derived in such a complicated solution, due to past training issues on ‘where did this data come from’. The customer opted to reject the request. The customer was armed with new information and elected to create a project request to capture the desired information at the time of sale.

• Saves time and ensures on-time delivery because ‘small’ unexpected changes popping up mid-stream are not allowed to divert efforts, unexpectedly adding significant amounts of time, risk or large issues to the project.
• The customer, project team and other stakeholders were always kept abreast of the status of any change requests and were not blindsided by changes they were not aware of.

Ease into the Change Process

“If you want to make enemies, try to change something.”  ~Woodrow Wilson

Some ways to help the project team understand that proper change management will ensure quality, keep us on task, maintain the timeline and help us focus on the high priority change that leads to growth are highlighted below:

• Support the idea of accepting new changes from the customer on a regular basis.

1. Don’t treat change as a roadblock; treat it as an opportunity to improve the product.
2. Pass the positive attitude on.
3. Help your team understand you are committed to saving them time and money, as well as producing a quality product.
4. If the timeline needs to be extended, you support that too!

• Initiate the change management process in its most simple format.

1. Use the change log. Create a quick and dirty excel spreadsheet. Have columns for the Change Reference #, Description, Status, Cost Impact, Time Impact, Decision, Approver (who can also reject the item) and Notes.
2. Track all changes in the change log and use this for communication.
3. As your organization matures, it will be easy to introduce a Change Request form that has more details.

• Bring forth options.

1. When IT understands the reason for the change, IT should be able to produce several solutions that would result in the same benefit.
2. Options bring with them choices, choices lead to better decisions.

• Appoint a change board.

1. Identify the person, or group of people who will come together to discuss the impact of proposed changes and approve or reject them.
2. This group will quickly see the value in evaluating the true business benefit and need when they factor in all the impact the change will create.

• Follow through!

1. Don’t let the process slip.
2. Act quickly when a change is proposed.

• IT must recognize, evaluate and bring forth options in a timely manner. The longer you wait, the more impact there will be.

1. Communicate results to all team members and stakeholders.

• Everyone must understand the decision and impact so they can react.

The Joy of Change

“Nobody can go back and start a new beginning, but anyone can start today and make a new ending.”  Maria Robinson

After initiating it, my customer was completely sold on the change management process.

We did initiate change along the way, utilizing change management, and we knew what we were dealing with and understood all related impact.

As change requests were approved, hours increased, our date moved out and training was adjusted to meet the needs. The entire team was communicated with and knew when a change in focus was initiated and agreement gained.

The delivery was on-time, within the approved budget and met all expectations

Since we used this process, the entire team from analysis, design, development, configuration, testing and training efforts could support and execute against agreed upon scope changes. There was very little post-implementation support, because we captured all the requirements and planned for all scope changes along the way.

So, even though the project evolved from the ‘original’ plan, it was a controlled, well-planned and executed change. All business and IT folks were informed. The end product was quality that drove the business forward. That’s what it is all about!

Don’t forget to leave your comments below.

---

Joan Demuth, PMP, is a Project Manager with Bremer Bank. Before joining Bremer, she led continuous improvement initiatives as well as served as the lead senior project manager on multi-million dollar IT projects. Joan previously served as a Business Analyst for more than 7 years. Joan has an MBA from the University of Sioux Falls.

The views in this article are solely the views of the author and do not reflect the views of Bremer Bank or its affiliates.