Cultivating stakeholder buy-in
In order for your organization to adopt DevResults fully, you will need the people involved to embrace the changes that come with the new software. For this reason, cultivating stakeholder buy-in will be an essential element of your DevResults implementation.
Your first step is to identify the stakeholders in question. A stakeholder can be anyone with a reason to care about DevResults, so the majority of your stakeholders will probably be the people who will be using the software. Make a list of every person who will be using DevResults at your organization and at any partner organizations. (The Permissions Matrix includes a tab for the user list.) Also include other colleagues who may be affected by the software even though they are not directly involved with it. For example, maybe there are supervisors at your organization who will not be accessing DevResults but who will be needing to account for it in their staffing plans.
Once you have identified your stakeholders, you must begin the work of developing their enthusiasm for DevResults; as with any process, you will see a better response if the participants are willing – even excited – to be involved. A certain amount of anxiety and resistance is to be expected in the face of any change, but for most people, you can overcome these natural reactions by providing clear expectations and proof of progress over the course of the implementation.
Anxiety and resistance can stem from uncertainty. If your stakeholders do not know why you are changing their workflows or what they should be doing differently, then they will be more likely to cling to established habits. Setting expectations can dispel uncertainty and smooth the path to adopting DevResults.
When setting expectations, there are four key points that you should communicate to your stakeholders.
- Context: Why the change is occurring
- Impact: What effect the change will have on them
- Vision: What outcome they are working toward
- Resources: Where they can go for help
These four points may vary based on the stakeholder’s involvement with DevResults. A trainer, for example, will experience a different impact than a manager will. For that reason, it makes sense to group your stakeholders by their roles and to tailor your message to each group.
To help craft your message, answer the following questions for each group.
- Why did your organization choose DevResults?
- What problems will the software solve?
- What problems will remain?
- Why is this change happening now?
- What specific pain points do these stakeholders currently have?
- How will DevResults improve these specific pain points?
- Will DevResults create any additional pain points?
- How will DevResults change the day-to-day responsibilities of these stakeholders?
- What will workflows look like when the implementation is done?
- What benefits will become routine for these stakeholders?
- Who should these stakeholders ask for help?
- What materials can these stakeholders reference?
Next, think about how to deliver your messages. What channels of communication are available to you? Keep in mind that real-time communication (in-person or even over the phone) tends to be more effective, especially if it is on a small scale; you can put off reading an email indefinitely, but it is virtually impossible to avoid thinking about the content of a one-on-one conversation. For a DevResults implementation, it is not usually practical to have individual conversations with every stakeholder, so you will need to balance the quality of your interactions with the quantity of stakeholders that you reach.
One final note about communication with stakeholders: it is better to overdo it than to underdo it. Sometimes people need to hear the same thing several times or in several different ways before understanding it. In your communications plan, go with “and” rather than “or” whenever possible.
Download the Stakeholder Expectations Worksheet to craft the message you will use to set expectations for each stakeholder group. Feel free to rename, add, or subtract the groups as you see fit.
Even if you set clear expectations for your stakeholders, they may become discouraged with the implementation if they don’t see any signs of progress. It takes time and effort to change the status quo, and without positive feedback, this investment can feel wasted. We all know that it will take several reporting periods (months, years) to showcase the full benefits of DevResults. So in the meantime, how will you show your stakeholders that the software implementation is working?
It’s time to get meta. Brainstorm a list of indicators for your DevResults implementation. These indicators should measure progress toward your organization’s adoption of the software, and should be influenced by stakeholder contributions. So “# of reporting periods with data,” for example, would not be a good indicator because the result will go up steadily regardless of how hard your stakeholders work. Better indicators might include “# of tasks completed in the system” or “# of projects reporting data.” Make sure that the indicators do not reference any confidential information, because the whole point is visibility.
Once you have come up with your ideas, select the most relevant indicators for each stakeholder group. Aim for between three and five indicators per group (overlap is fine). Set your targets and decide how you will report your progress. Will you make announcements at meetings? Send out email updates? Keep a scoreboard in the office? Anything goes as long as your stakeholders can track their progress – although visuals tend to be the most powerful motivators.
As you hit milestones on your indicators, make sure to advertise and celebrate your success. Think about ways to incentivize progress on your indicators. Here are some examples.
- Create a “user of the month” award for stakeholders who are making significant individual contributions.
- Showcase the progress that individual projects are making at staff meetings.
- Include DevResults use on performance reports.
- Host a launch party for new projects joining DevResults.
- Turn your projects into teams and develop competitions around using the software. Create a checklist – the first team to complete it gets a prize.
There is no “right way” to track and incentivize progress. You know best what your stakeholders will respond to. The goal is to create a series of short-term wins that will create the momentum you need to carry you to the end of the implementation.
In the face of any change, it is normal to have questions and worries. Left unaddressed, however, such concerns can prevent stakeholders from buying in, undermining your implementation. For this reason, stakeholders should feel comfortable voicing their concerns about the implementation with you.
Some organizational dynamics can get in the way of such candid communication. For example, a stakeholder might refrain from expressing doubts at a meeting because the supervisor is present. Give your stakeholders a way to express concerns directly to you, and make it clear that you welcome their input. Conversely, some people will be more comfortable speaking with their supervisors than with you, so make sure that the leaders at your organization know that you want their input.
You can always punt the hard questions over to us at DevResults, and we will help you figure out the best way address the issue.
To see a comprehensive list of the tasks in this guide, download the Stakeholder Buy-In Checklist.
Didn't answer your question? Please email us at firstname.lastname@example.org.