Skip to main content

Author: Joan Demuth

Change Management to Move Projects Forward

Written by Joan Demuth on . Posted in Articles. 6 Comments on 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.

Running to Meet the Date: How to Effectively Rush a Project

Written by Joan Demuth on . Posted in Articles. 5 Comments on Running to Meet the Date: How to Effectively Rush a Project

BATimes_Feature_May31_CroppedI have been on several large initiatives where the dictated timeline didn’t allow the team to follow a preferred waterfall approach. It was frustrating for the team because they had to finish in a very short time frame. No requirements had been documented and it felt as though we failed before we even began.

How did we get around this? Utilizing the concepts of Value Stream Mapping; I engaged the business unit and the IT team in working sessions to define future state maps that lead to solid project planning where we could meet the tight deadlines.

In this article we will talk about introducing the business problem, the people who should be involved and the process that my team used; which led to shortened project delivery to meet the business deadlines.

The Problem

The business unit should be able to present the problem(s) they need resolved along with a successful business solution. This should be at a high level and should not get into the ‘nuts and bolts’ on how to implement the solution.

A common practice is to use a Problem/ Opportunity statement such as the one below.

The problem of… Customer places an order and waits two weeks before delivery of the product.
affects… Customer Satisfaction
The impact of which is… Customer cancels the order or refuses at the door because it took too long and they purchased the item using another vendor.
A successful solution would be… Improve order deliver by allowing the customer options for faster delivery.

The People

In order to ‘jump start’ the project you need the right people in the room and make sure they each understand their role. Be sure to identify:

  • Business unit subject matter expert(s) to be sure the processes mapped out will suit the future business need.
  • Project Manager to lead and facilitate the process which will result in a project SOW, Charter and plans.
  • Business Analyst to understand the current and future state so they can work on detailed requirements and help ask the ‘right’ questions.
  • Enterprise Architect to identify synergies in the environment that could be used to resolve problems and identify improvement areas.
  • Design Lead to be familiar with the business process and hear first-hand the requirements coming out of the sessions so they can produce a high level design.
  • Test Lead to understand what is changing, and begin to formulate test plans and approaches.

You may choose to add others, such as key developers assigned to the project or test engineers, depending on the project. Keep in mind, large groups are hard to control and keep on task. Ideally this team would consist of 5-8 people.

I have had very large groups involved. In this case, I have asked developers and test engineers to be the ‘audience’ rather than be active participants. This way, they had the background and could begin work much sooner than if they were excluded.

The Process

Kick Off:

Begin the sessions with a kick off. This is important to bring the team together so they understand the problem, their role and the approach that will be used.

Example of an agenda for the Kick Off:

  1. Introduce team members.
  2. Project overview: Discuss the problems(s) the team is trying to solve
  3. Approach: Give a quick overview of the approach and what can be expected.
    a. Session format (time expectation)

There are two different formats that we have used.

  1. Half day working sessions: ½ of the day working on value stream mapping, the second half of the day following up on items for the working session or catching up on other work.
  2. Full day working session. The entire day is devoted to the value stream mapping until the current state map, future state map and planning sessions are complete.
    b. Provide a brief overview of current and future state mapping.
  3. Roles and Responsibilities for the session.

Draw Current State Map

Begin with a white board and dry erase markers. There are also products that assimilate a white board. You can draw and erase on these white sheets that cling to the wall and then carry the work away with you when you leave the room. Very handy!

The facilitator begins the Current State drawing and invites subject matter experts to the board to contribute. The team should be very interactive in drawing and asking questions. Give everyone a marker; encourage them to get out of their seats. Everyone in the room should be encouraged to contribute, since it is important they all understand the current state once we are complete.

On the map you should identify key inputs, outputs, depict who receives and processes the information, where processes are slowed down, multiple hand offs, where re-work is occurring and why. You can incorporate any notes to help better understand the process. This is very similar to flow charting or data flow diagramming, but less formal.

There isn’t any right or wrong way to draw the map. Don’t be hindered by formal process drawings or standards, just get the process down and understood by the team. You can find symbols commonly used in Value Stream Mapping by exploring the internet. I have used some of the basics, but try to keep it simple for the team to speed up the process.

For example: Begin with a drawing of a crown (crown = customer; who is the ‘king’). The customer places an order on the internet or phone. What happens next? Does the order sit in a queue for a long period of time? How long? Who picks up the order and where does it go? Don’t focus on gaps or areas for improvement yet. Just get the process drawn so that everyone can see the full picture.

Critique Current state

Once the current state is mapped, step back and analyze the ‘pieces’ of the process.

  1. Determine if the current state can be separated into smaller processes; such as ‘Place Order’, ‘Process Order’ and ‘Deliver Order’. Identify these on your current state map by drawing a vertical dotted line between each process and across the top of the mapping write the name of the process.
  2. Put a timeline along the bottom of your current state map to identify how long it takes a process to complete, or time frames of delay within a process. For example: Once the order is placed, the order goes to a queue and it may sit in the queue for seconds, minutes, days. Identify this time frame.
  3. ‘Kaizen Bursts’ are used to identify pain points in the current state map where improvements should be made. A Kaizen burst is a multi-pointed star and in the center you write the item that needs improvement. In our example, a Kaizen burst would go next to the order queue with the words, ‘Order is delayed in the queue for a day before processing continues’.
  4. Be sure to identify items that cannot change due to regulatory or compliance.

Critiquing the current state should be very interactive. Challenge the current thinking and looking for areas where waste is present and should be eliminated.

Finally, be sure everyone agrees with the Current State and the problems identified. In some cases you may need to review the diagram with a Decision Team to gain agreement on the Current State and all pain points identified. The Decision Team is comprised of higher level decision makers who need to approve the direction of the initiative. They may provide insight as to which pain points are most important and may add more items. Be sure to update the Current State with their suggestions. If you have the decision maker in the sessions, the Decision Team may not be needed.

Draw Future State Map

Utilizing the Current State Map with all identified pain points, timelines and inefficiencies; map out how the ideal process should work. How can each of the Kaizen Bursts be eliminated to have a more efficient process? A tip is to put the current state map on the top ½ of the whiteboard and the future state on the bottom ½ of the whiteboard.

Guidelines for Future State Mapping:

a. Work on one process at a time, to help maintain focus
b. Encourage alternatives
c. Do not judge or evaluate ideas
d. Keep an open minded
e. Build on others ideas.

The goal is to determine if all the steps in the current state are actually needed and how we can avoid/ eliminate delays and interruptions to improve work flow.

The team should strive to:

a. Combine steps. This is efficient when there are too many handoffs.
b. Shorten time periods between processes. Possibly build in service level agreements. For requests that are less critical, identify those and process differently than items that have a higher priority.
c. Remove inefficiencies, bottlenecks, interruptions and /or delays.

Using our example of the orders sitting in the queue for a day, the team may consider the following:

  • What options do we have to process out of the queue?
  • Is it as simple as changing the timing?
  • Do we have an existing technology that could be used to assist with manual process that we are not currently utilizing?

Be open to drawing a solution, erasing it, modifying it and redrawing again. Encourage people to draw out their thoughts. A crazy idea may lead to the perfect simple solution, so consider it.

Expect the team to get stuck on the future state. This is very common because we are trying to provide an agreed upon solution. If the team ‘gets stuck’ use some tricks.

  1. 5 minutes of silence. Give all participants a marker, tell them they cannot talk for 5 minutes, and instruct them to use their marker to draw out their ideas. Be sure they know they can ‘piggy back’ on other team member ideas. This will generate discussion, after the 5 minutes has ended, and can get the team out of a rut.
  2. ‘5 Whys’ for many problems team members are actually stating the symptom. By asking why, you begin to explore the root of the problem. By uncovering the root cause you can solve the full problem instead of resolving it only half way.

After the team works through the Future State, another review with the Decision team should occur. The Future State should be updated with ideas from the Decision team before the model is considered final.

Implementation Planning

The result of your effort will be requirements to improve the process, how and where those improvements need to be made, and a solid understanding between team members on what needs to be done. Using each process in the Future State, you can document more detailed requirements while high level design is taking place. You can identify all impacted systems; determine where changes will be needed, develop work plans and begin estimating the work.

Conclusion:

Utilizing this approach, our teams were able to jump start the project by working together up front to identify requirements, design and development; including impact analysis and many times we left the room ready to code. In the end, saving valuable time and getting the job done right.

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.