Red Hat sponsored this post.
Red Hat prides itself on its community-focused, open culture. This culture applies not only to working in upstream communities, but also internally when we make decisions and define organizational processes. For the most wide-reaching, significant changes, we use something called the Open Decision Framework to ensure transparency and that feedback from affected parties is taken into account. But even the smallest processes tend to attract feedback and suggestions from interested parties. This sort of shared ownership and openness to contribution, no matter your role or position, is one of our strengths in constantly evaluating and improving. However, the freedom to suggest improvements needs to be moderated in a way that can lead to a productive discussion of desired changes.
Maybe you are new to an organization and have run headlong into a tedious manual signoff process. Or perhaps you’ve been with the organization from the beginning and seen processes introduced and calcified in ways that make them no longer useful for their original purpose, or has caused them to consume increasing time from participants as external circumstances have changed. Whatever the reason change is needed, negotiating a change in an organization’s process can be difficult, with resistance coming in many forms.
Below is an outline of some key items that I have found to be useful to cover in a process-improvement or process-change proposal. By covering each of the items in this framework when you suggest a change, you will be able to create understanding and buy-in from the critical parties, who can agree to adopt the changes, or at least ensure those parties are able to directly address why the changes are not appropriate while taking your concerns into account.
0. Assume Positive Intent
This step is not a part of any proposal you bring forth, rather it is a mental state you should adopt before crafting a proposal for change. In this case, assuming positive intent means acknowledging that processes aren’t created for fun, and they aren’t created because someone wanted to punish someone else or waste their time. They are generally created to solve a problem that the organization has and to meet a business obligation. If you do not believe that to be the case within your own organization, you will need to address that situation before you can hope to improve anything else. Sometimes processes do evolve piecemeal in a way that loses sight of the original goals, in which case realignment is important but keep an open mind about how things got to their current state as you advocate for change.
Once you’ve accepted that the process you seek to change was, at least at some point in time, necessary and well-intended, you can move on to how to improve it.
1. Demonstrate Understanding of the Problem
Before you can propose a solution, you need to demonstrate that you understand the problem. The process you are chafing against was put in place to solve a problem, and any suggestion you make for changing that process needs to discuss (though not necessarily solve, as we’ll see) those problems as well. In this section of your proposal, you need to outline the problems, requirements and goals the original process targeted. Outline the problem space as best you understand it.
This serves a few purposes. First, it will demonstrate to the people you would like to adopt your changes that you understand the problems that need to be addressed. It avoids the common initial rejection of proposed changes, which is “yes, doing X is painful, but we need to do X because of Y.” This section also aims to get everyone on the same page about what the current process is trying to achieve before you move on to revisiting how that thing should be achieved or possibly if it should be achieved at all.
2. Demonstrate Understanding of the Process
Having outlined what the current process was intended to solve, the next step is to show that you understand the current process by revisiting how the current process solves the requirements described in the previous section. For now, hold off on discussing why the process falls short of solving those goals. This section is intended to build rapport between you and the people who own or created the current process. It acknowledges the work they did building and maintaining the current process and that you understand the thing you are trying to change. It circumvents your suggestions being dismissed on the basis of you not having enough context or understanding to be proposing changes.
This section should revisit the goals, problems and requirements from the previous section and explain how the current process functions to achieve them. If some goals are not met by the current process, you can mention this, but don’t go into detail here, since we’ll cover it in the next section. As with the previous section, writing down this information circumvents change rejection of the form: “We can’t stop doing X, because X ensures Y.” By documenting in this section that you understand that we are doing X in order to ensure Y, you are positioning yourself to make the case for how else you can ensure Y, or that Y is not important enough to justify doing X.
3. Describe the Pain Points
Now we’re at the part where people often start when they run into a process they want to change: Explain where the current process is falling short. Is it too much manual effort, and there is room for automation? Are too many people being required to do something that isn’t worthwhile? Are there too few people able to approve something, so people end up waiting for signoffs? Are there goals that are not being met by the current process that should be? Are there goals of the original process that are no longer relevant to the organization, or that given the human cost of the process in place, are simply not worth the effort?
A key point here is that this is an opportunity not only to discuss the inconveniences and costs of the current process, which may have grown since it was originally put in place to the point where it’s no longer worth it, but also the original goals of the process, which may not be relevant or as important as they were when the process was created. Processes grow stale when the effort they require grows beyond the original expectation or when the goals they were meant to achieve become less important. Therefore processes can be fixed by changing the implementation (the cost it puts on the participants), or by redefining the problem to be solved (re-evaluating the importance of the original goals). Revisit both of these things as you do this exercise.
4. Describe the Proposed Changes
Now we come to the heart of the proposal for improvement. Should some of the goals and requirements of the original process be dropped as no longer relevant? Should new ones be introduced? Should the mechanics of the existing process and/or enforcement be changed to reduce human toil? Propose your changes to the goals and process here, and make your case for why those changes are necessary and appropriate. It is important to remember that process change can be about not only changing the mechanical process but changing the goals the process is intended to achieve. Describe changes to both of these things, as appropriate, building on the existing challenges you outlined in the previous section.
5. Map the Solution
Finally, summarize how the changes you are proposing will address the (possibly updated) requirements. List the updated goals and requirements, making explicit note of any original ones that are being dropped or modified, or any new ones that are being introduced, and explain how the new or updated process will continue to address all of these revised goals.
6. Solicit Feedback and Propose a Rollout
This section will vary quite a bit depending on your role in your organization, the organization itself and the process you want to update. But you should include here a discussion of how you intend to get buy-in from the organization. Does the proposal need to circulate among some senior members first for initial feedback before being filtered down to a wider audience? Does it need to align on a release boundary or some other date? Who do you think needs to sign off on or agree to the change? Who needs to implement it? Have a plan for how you see the change being communicated to the organization, feedback solicited, and ultimately the how and when the changes will be applied to the process.
I want to be clear that getting feedback or buy-in and determining how the change will be rolled out are extremely important and sometimes difficult steps, however, they are not the main focus of this article. What they involve will vary depending on your organization and the process you are looking to change, but do spend time thinking through how you will address these very critical steps in the context of your own organization and your role within it.
Processes are often easy targets for criticism. They are rarely perfect and often require people to do things that don’t feel immediately productive to them. Sometimes processes grow stale and need updating, or have room for small quality-of-life tweaks. Providing feedback and helping fix those processes is valuable, but voicing complaints in a vacuum about the aspects you do not like is unlikely to result in change. To advocate for a change to a process, you must demonstrate that you understand why the process is in place. Perhaps after going through that exercise, you realize there actually is no room for improvement (sometimes problems are hard!) If you do still see an opportunity for improvement, you will be in a better position to make your case for those changes.
This provides a minimal framework for thinking about process change, but designing processes, changing them, measuring the effects of those changes and many other aspects are full-time jobs for some people. If it’s a topic you find interesting, there are much deeper guides, resources, and formal procedures to consider.
The links below describe some of the formal approaches to process change that exist and cover additional steps that are applicable to highly critical and disciplined process changes. Many of these resources are provided by businesses offering tools and services for process change. I am not endorsing their products or services.
The New Stack is a wholly owned subsidiary of Insight Partners. TNS owner Insight Partners is an investor in the following companies: Bit.
Lead image via Pixabay.