Case Study #2: Poor Communication and Planning

A Fortune 100 company had a project management application for the business to request Information Technology (IT) resources to perform software development. This application was the mechanism through which the company spent hundreds of millions of US dollars every year to develop new technology solutions, and to enhance the technology solutions their customers used every day.

The people who managed the project management software decided to make a significant change to the way the application worked: they decided to add a new role to the project intake process. Projects could not proceed until the people assigned to this new role, for each business unit, personally approved the projects within the application. Once the projects were approved, the requests would notify the relevant IT teams to begin working on the business requests.

The application owner did not assess the impact to all of the stakeholders that would be affected by this change. Even though the software was primarily used by business users to request IT assistance, the application owner for the project management software only notified IT about the change to the process. One email communication was sent to IT, and the change was put into effect.

What was the effect of this change?

  1. The business (the stakeholders with money that they wanted to spend on IT) did not know about the new role or new approval workflow.
    • The first time business users attempted to start new projects, following the process they had always performed, their projects went into a perpetual pending state.
    • Until the business teams reached out to the project management tool owner, they did not know what the new status meant nor what to do to get their projects moving.
    • In some cases this delayed the start of business projects up to 4 months while the roles were assigned.
  2. No continuous improvement mechanism was put in place.
    • Each individual business unit had to discover the change for themselves, and then know who the application owner of the project management tool was to personally reach out and find out what they needed to do to be able to start new projects.

Ultimately, the people behind the project management software were moved off to other positions, and no longer maintain the legacy (nor the new) project management process.

How would wHolistic ChangeSM have handled this differently?

  1. Define the business reason for change – what problem the project management team was trying to solve by adding this role.
    • Potentially, adding the role might not have been the best solution.
  2. Identify change agents to assist with the change effort.
  3. Plan the change, including performing a stakeholder assessment to make sure all impacted parties had a seat at the table to redesign the workflow, and help build the change approach.
  4. Create a community of practice among the people who use the project management application, to get their buy-in to the change.
  5. Develop the communications – including what the stakeholders care about, explaining the change, and ensuring communications go out to all impacted parties through a variety of mechanisms. (Not just one email to IT)
  6. Establish a continuous improvement process, to ensure there is a feedback mechanism from the stakeholders to monitor how the change is going, from their perspective.
  7. Report progress – how the business problem that was the reason for the change has improved, based on the change.

 

About Michelle Smeby

Michelle Smeby is CEO of wHolistic Change, Inc. with more than 10 years of experience implementing enterprise solutions at Fortune 100 companies. Michelle specializes in helping corporations deliver transformational change.
This entry was posted in Avoiding Pitfalls, Executing the Change, Planning the Change Effort, Setting People up for Success and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply