Article summary
Software, and computers in general, are excellent at enforcing process. But process is often in direct conflict with people. So what happens when a new software system is thrust upon people? Frustration, revolt, and other negative consequences—a net loss for all involved.
In this post, I’ll explore how we can utilize software to both advance important business processes and ensure that people can derive value from it.
The Context
A recent project added tracking software to a factory’s production process. An existing process converted raw materials into parts and then into finished goods. The process was driven by people (as opposed to robots), and for the most part, they followed it. But occasionally, for a host of good and bad reasons, the process would be broken and lead to unacceptable performance.
This is where software enters the picture. We built a software system to better track parts, their progression through the process, and timing data. Floor workers would be responsible for scanning parts as they moved through the environment. Management’s goal was to use this data to create key performance metrics, and in turn, use these metrics to evaluate compliance and/or adjust the process.
People vs. Process
As you can imagine, forcefully adding the new software to the existing process was a recipe for failure. Here’s how we dealt with it.
1. Identify the risk.
The Research, Design, and Planning phase of our project included three on-site visits with direct user observations. Two clear observations were:
- Management would derive value from the software metrics, but workers would see no direct benefit.
- Any friction in the software—lost scans, confusing visuals, etc.—would only get in the way of workers performing their core duties.
Combining the above leads to an obvious outcome: abandonment of the software by workers. Why bother with this frustrating system when the old manual process works fine?
And, of course, if workers won’t use the software:
- Parts won’t be accurately tracked, therefore
- Data won’t be gathered, therefore
- Metrics won’t be calculated, therefore
- Goals won’t be achieved.
Thankfully, the on-site visits made the above risk blindingly obvious, and we immediately escalated it to management.
2. Assign responsibility to the right party.
To mitigate the risk of abandonment, we decided to pursue two paths:
- Maximize the usability of the software to minimize frustration.
- Ensure that floor workers see the big-picture value in the process change and willingly adopt it.
The software team accepted responsibility for #1–usability is certainly in our wheelhouse. Tools like usability tests are excellent ways to improve the software.
In the case of Part 2, we assigned responsibility to the management team. There might be some things we could do on the software side to help, but ultimately, it was a people problem that needed to be solved by working with people, not by software.
3. Treat this as a change initiative.
Tackling Part 2–getting people to change and adapt to a new process–is far and away harder than improving software usability. It needs to be treated as a serious change initiative.
Thankfully, this is a well-known problem, and many resources exist to help with it. I recommend two books:
- Our Iceberg is Melting by Kotter and Rathgeber
- Influencer: The New Science of Leading Change by Grenny, Patterson, Maxfield, McMillan, and Switzler
Conclusion
Process change is easy, but people change is hard. By identifying the conflict, assigning responsibility to the right parties, and treating people change seriously, we can can find a win-win result.