My Framework for Process Improvement

How do you fix a system when it starts to break, or you realize the results it’s producing aren’t what was intended - without shutting it down or starting from scratch?

This is the approach that I’ve built over my years working on processes and bringing strategic goals into better alignment with the on the ground reality the processes live in.

It’s based on my experience with 211, when this was just a vague set of ideas - extended with lessons from Scrum, Python programming, and books like Keeping the Score.
I wanted to formalize my thoughts, creating a foundation that can be revised and extended. Currently it focuses on process-improvement, but with small tweaks it would fit general change management or creating wholely new processes and systems.

The Principles

• Skeptical Curiosity
• Simplify
• Involve Everyone

Skeptical Curiosity

Treat everything with skepticism - every metric, perspective, process narrative, etc. comes with assumptions and may be incomplete or inaccurate in some way. Validate that you have a good understanding though multiple sources and/or direct observations whenever possible. If that isn’t possible, highlight what can’t be confirmed.

See my post on metrics for more about their strengths and weaknesses. In a nutshell, all metrics are abstractions and trade context for being portable & transparent to non-experts; sometimes that tradeoff works but sometimes the specifics are more important making a more targeted benchmark better.

It’s worth highlighting that this goes both ways - the strategy and its assumptions should be considered alongside processes; but that’s outside the scope of this post.

Simplify

Break systems, processes, etc., into manageable and coherent chunks for investigation and experimentation.

Involve Everyone

Take perspectives and ideas from everyone, leverage them for better understanding and new approaches. Demonstrate that insights and efforts towards improvement lead to implementation and advocacy.

The Framework

1. Understand the Current System
2. Identify Strengths and Weaknesses
3. Break the Process into Observable Components
4. Run Controlled Experiments
5. Reflect on, Iterate on, and Integrate Lessons

Understand the Current System

Map out the current process to identify constraints, dependencies, and stakeholders. This means getting “in the trenches” where the tasks are done to see how the process(es) really happen and where there is friction.
On the flip side, make sure the strategy driving things is clear and maps onto the process(es) that exist - strategic goals may no longer align with on the ground reality.

Mapping the system will be foundational to future steps, but it’s the multi-level communication and digging into the reality of how things are put into practice that makes the difference here.

Identify Strengths and Weaknesses

Work with staff at every level to find pain points, bottlenecks, gaps in communication, or other issues which are holding things back.
Likewise, find the areas that are working well, or even overperforming, so they can be preserved and reinforced.

Using what was discovered in Step 1 and in ongoing communication with all levels, dig in to determine what each group views as working well (or poorly) and why. Disconnects or conflicts in views may point to communication gaps or other big-picture issues. Look into the process and non-process factors.

Review the metrics, KPIs, etc. that are in use, and if they accurately reflect the outcomes that are desired or need to be adjusted.

Whenever possible highlight what’s working well, especially unexpected areas where they’re on-target or overperforming. This not only helps morale, it gives a concrete foundation to build on and lets everyone focus on the areas of actual need.

How many times is a step being sped through or even skipped because it is high-friction, and/or the reasoning for the step is unclear? Does the front line think the purpose of a step is X while the Program Manager thinks it is Y, how is that impacting outcomes? And so on.

Break the Process into Observable Components

Break the mapped process into discrete steps - documenting the inputs, outputs, and dependencies.
Prioritize the steps which are the biggest pain points/bottlenecks/etc.
Determine which could be impacted through changes in process, input/output, dependencies, or communication.

Every process will have different ways it could be broken down depending on the larger system it’s within. By considering the inputs, outputs and dependencies the effects on other areas can be understood. Then decisions can be made on where flexibility exists to allow experimentation.

Run Controlled Experiments

Take high priority steps and develop a set of alternative approaches to test, have clear goals, expected outcomes, and timelines so the result can be objectively evaluated.
Keep in mind that quantitative validation will not always be possible or reliable, so consider if qualitative reviews would give better results.

For example: across the national 211 ecosystem there had been a steady decline in response rates for partners to update and/or validate their listings as accurate. While this was prior to the creation of this framework, it illustrates how to approach experimenting on a single step. I identified the outreach step as the one most readily adjusted, and trackable - so I had our staff try a variety of options: different outreach timings and cadences, different methods (email vs phone vs mail), different follow-up schedules, etc. With a backstop of public validation via websites and similar sources if we couldn’t get a full formal review by a person at the organization.

Reflect, Iterate, and Integrate

Continuously gather feedback from everyone involved, evaluate the qualitative and quantitative outcomes, document what lessons were learned and integrate the successes into core operations.

As experiments run their course, it’s important to stay in contact and understand what impacts they have - both on what you were targeting, and any unexpected side effects. It’s easy to focus on metrics and qualitative information, but it’s as important to be aware of qualitative changes both in output and with the organization overall.

When an experiment goes well, and meets the benchmarks needed, incorporate it into documentation and the way things are done to lock in the gains. With a little luck, the frontline staff will have gotten excited to see their efforts having an impact and will continue to experiment in small ways to continuously improve. By keeping lines of communication open, this energy will help staff grow and could create unforeseen opportunities.

Conclusion

This framework isn’t set in stone, and will evolve over time - this is just a snapshot of the current state. One of the primary goals is to actively involve everyone, making use of knowledge and understanding held by the ground-level staff to improve not just their processes but hone the overall strategy and goals. The other motivation is to encourage sustainability, both in processes and in culture - the end result should be a system that maintains the enthusiasm and grows the capabilities of everyone involved.

Takeaways

While I think that the full framework is very accessible, here is a slightly abbreviated version for immediate testing to see if it works for you:

1. Map out the process, note what works well and where there seem to be problems
2. Pick the most significant problem area, and create a set of alternative approaches (with a timeframe for differences to emerge)
3. Try one alternative at a time, adjusting as you go - when meets your goals are met, make that approach part of the core process Repeat as necessary until outcomes match the goals, and everyone involved feels engaged and involved in improvements.

Next time

I will be reading Optimal Illusions: The False Promise of Optimization which I think should raise some interesting questions about how to best organize our efforts. Next time I’ll cover what I’ve learned and what I feel are the practical implications.

Photo credit: Photo by Tatiana Nifatova on Unsplash