Change management is hard. We've developed a range of tools to help with the people-side of implementing DevResults.
Getting the most out of DevResults requires keeping information current and complete. We recommend establishing clear internal guidelines for who should be responsible for updating and managing various parts of DevResults.
Download the Responsibilities Matrix to think through:
- Real-world stages in your activity cycle
- The corresponding updates in DevResults to keep the site up-to-date
- Who should execute them.
You can customize these stages and actions as needed and identify the individuals who will be responsible.
To help decide which groups of users should have which permissions, we've assembled an Excel file that shows the default permissions for each standard group. You can use this file to think through how to modify permissions for user groups, develop custom user groups, and assign users to the appropriate group.
- Default Groups tab: shows our default groups and permissions settings. (Locked from editing.)
- Custom Groups tab: use this worksheet to think through modifying groups or developing your own.
- Users tab: allows you to list your users and to assign them to permissions groups.
Roadmap for Data Management
The most challenging element of our work is helping organizations implement plans for using our software. Rolling out data systems across an organization requires aggressive change management processes and a big investment in making them work. We collaborated with MERL/Tech workshop participants to create a start-to-finish roadmap for choosing and implementing a data management platform.
This roadmap covers a range of steps, questions, potential pitfalls, and suggestions for an organization seeking to refine results management, specifically around choosing and implementing tools for doing so. To use this roadmap, we recommend you:
- Customize the list for your organization
- Classify the priority level of different steps
- Seek buy-in at your organization
- Assign responsibilities
- And most importantly, grant authority to make decisions and act.
This guide cover essential components of cultivating stakeholder buy-in, including a worksheet for crafting your messages to different stakeholders and a checklist summary.
Cultivating stakeholder buy-in
In order for your organization to successfully adopt DevResults, the people involved will need to accept and embrace the changes that come with new software.
The first step is to identify your stakeholders. A majority of these will be the people using the software. Make a list of everyone who will use 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 the communications department should know about the available metrics and visualizations.
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.
There are four key points to communicate to your stakeholders. These four points will vary based on a stakeholder’s role with DevResults, so tailor messages to each group by answering these questions:
Context: Why the change is occurring
- Why did your organization choose DevResults?
- What problems will the software solve?
- What problems will remain?
- Why is this change happening now?
Impact: What effect the change will have on them
- 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?
Vision: What outcome they are working toward
- What will workflows look like when the implementation is done?
- What benefits will become routine for these stakeholders?
Resources: Where they can go for help
- 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 or small meetings.
Cultivate enthusiasm by emphasizing cleaner workflows, streamlined data entry, standardized systems, and the possibilities of data-driven management decisions. Users should see the value-add for their own role, not just the organization's strategic objectives.
Finally, 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.
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.
Unaddressed concerns can reduce buy-in, undermining implementation, so stakeholders should feel comfortable voicing their concerns. 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 a supervisor is present. Give 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.
In the absence of organization-wide systems, individuals develop their own way of doing things, which often work very well on a small scale. If a stakeholder feels that they'd be losing something by giving up their own tools, see if there's anything you can offer in exchange for a sacrifice on their part that will further organizational objectives.
It can take several reporting periods to showcase the full benefits of DevResults. In the meantime, how will you show your stakeholders that the software implementation is working?
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. For example:
- # reporting periods with data
- # tasks completed in the system
- # projects reporting data
- # users trained
Once you have come up with your ideas, select the most relevant indicators for each stakeholder group. 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. 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.
As you develop your implementations plans, feel free to reach out to us about any change management question.
Didn't answer your question? Please email us at email@example.com.