Business Analysis For Dummies
Book image
Explore Book Buy On Amazon

Regardless of how great your business analysis solution is, the individuals impacted by it determine the success or failure of your project, so a big part of your change management plan is managing stakeholders’ experience with change. Failing to address the human side of change can easily result in a failed project.

Many books and experts focus on change management. As a business analysis professional, you can help get stakeholders on board for the change in two key areas: motivation and competence. Individuals who possess the motivation and competence for the change not only are accepting of the change but also help drive its implementation in the organization.


In order to achieve project success, the intended users of your solution must feel driven to implement the change. They’re truly the only ones who can ultimately put it into action, so you need them to be invested in the solution. Motivated individuals become project supporters and help others become more motivated for the change.

Here are some things you can do to foster stakeholder motivation:

  • Make your project personal to the stakeholders. Communicate to them how the change will improve their efficiency, make their job easier, or potentially free up some of their time.

  • Make sure they know upfront why it’s happening. Individuals who know why the change is being made will be more motivated to implement it. Make sure all stakeholders are clear from the get-go on the reasons behind the project. Everyone should be aware of the project’s goals and of the business value the project delivers.

    This process starts on day one. You should be driving the team toward this information in scoping.

  • Don’t be afraid to continually remind people of the why. If necessary, wear a sandwich board with the goals and business value of your project around the office!

  • Empower stakeholders to be part of the change. Give them a voice on the project by including them in elicitation sessions. If they have a say in how the change will be implemented, they’re more motivated to implement it.


Individuals who possess the knowledge and skills for the change are more open to accepting it. You can start to gauge competence (or lack thereof) toward the end of the project as the solution is being completed.

To avoid having stakeholders understand the why but not the what, get them involved early. Let them touch and feel the new solution as soon as possible. The more time people have to prepare, the better.

Depending on the magnitude of the change, formal and/or informal training on the new software, hardware, processes, and policies may be necessary to give the right level of competence to the impacted stakeholders.

Other ways to build competency include the following:

  • Ensure that full and active executive support is in place. An executive somewhere is paying for the efforts behind your project, but that’s only one piece of the support puzzle. Active executive support also includes visible actions at the executive level. Does the executive promote the project, communicate its importance for the business, and help convince the resisters that it’s best for the business?

  • Overcommunicate. You can’t overdo communication about the project, its rationale, and its impact. Communicate early and often during the project. By doing your stakeholder analysis, you can identify who needs to be involved and how to best communicate with them.

  • Have a training plan in place. Make sure you have a training plan set up to help ensure that everyone knows how to use the new solution before it’s implemented. Training shouldn’t stop when the project is over, either.

    On larger initiatives, consider having formal training reference material available, as well as knowledgeable individuals in place for support after the solution is live. Those folks may be people on the team or users with a deep understanding of the system (often referred to as power users.)

  • Develop procedures for feedback: To help guarantee people will be on board with a change, you need to make sure their voices are heard. Early in the project, set up some mechanism for people to share their concerns, thoughts, and ideas.

    As part of this system, you also need a way to respond. Depending on the size of the project and number of impacted people, responding can take time, so make sure resources are assigned to this task. The worst thing you can do is ask for feedback and then not respond to it.

Regardless of the size of the project and the number of impacted stakeholders, you should put some form of each of these aforementioned items in place — even on small initiatives.

As a business analysis professional, you may or may not have all the skills necessary to ensure a smooth transition. Transition is a critical step in the project, so if you don’t have the skills, work with your team to ensure someone focuses on the change management.

About This Article

This article is from the book:

About the book authors:

Paul Mulvey, CBAP, Director, Client Solutions, B2T Training, has been involved in business analysis since 1995. Kate McGoey, Director, Client Solutions, B2T Training, has more than 20 years' experience in application development and life cycle processes business. Kupe Kupersmith, CBAP, President of B2T Training, possesses more than 14 years of experience in software systems development. He serves as a mentor for business analysis professionals.

This article can be found in the category: