I’ve talked about the rush to standardization before. This article offers a more detailed look at the problem, and offers an alternative.

It was only a few weeks to the scheduled release date of a new version of the software. Final release testing was running behind, because the production-like environment needed had been in use by others. To make up for lost time, everybody was going to test: release testers, testers embedded on the development teams, programmers, analysts, team managers, EVERYBODY. Everybody set to organizing the work together.

A small group gathered around a whiteboard, planning how to handle the issues that were noticed. They labeled columns for “identified” and “in progress,” then quickly inserted a column for “in triage” between them. They finished with columns for “resolved” and “backlog” for the end states of all issues. It was amazing watching them develop their bug-tracking strategy in under 60 seconds.

The release manager looked up at the board and asked, “Has this been standardized across all the teams?”

I chuckled to myself. Of course it hadn’t, having been just now invented. People rushed off to share the Official Standard Triage Board with the other teams.

Allowing experimentation that drives improvements

During the next few days, I noticed that, while every team had a board that looked the same, they seemed to be using them in slightly different ways. On some boards, issue stickies stayed in the “identified column” for awhile. On others, they stuck in “triage.” Obviously the columns had different interpretations from team to team. Or the standardized columns didn’t match with the way the team understood the work.

While the first team had come up with some pretty good ideas, I couldn’t help but think that, we’d lost any possibility of improvements by others. The very first idea out of the gate had been declared the winner without consideration of alternatives. Was the variation in how the Official Standard Triage Board was used due to lack of understanding of the intent? Or was it a mismatch between a hasty standard and a better idea? Too late! We will never know.

Allowing people to engage creatively in the work

The fact that one team’s idea was declared the standard without considering the ideas of others also meant that the other teams were less engaged in the work. Perhaps lagging transitions in the tracking were attributable to the lower sense of ownership about the process. It’s common to see team’s enthusiasm lagged as a result of having a detailed process imposed rather than chosen.

Even when only one team is involved, people need to maintain creative engagement. Developing a process once and freezing it denies the opportunity of future improvements. When there are obstacles to trying future improvements, people disengage a little from the work. They’re left going through the motions patterned after a thought from the past.

Visibility by senior leadership

But doesn’t the senior leadership need a uniform presentation of status in order to track the overall progress?

It’s true that they have a responsibility to track overall progress, but the standardization may have hindered them in having an accurate picture. Since the standard presentation was being interpreted slightly differently by the different teams, as evidenced by the different tempos in different teams, rolling up the numbers by counting the issues in each column gave an inaccurate, though easily precise, picture of the progress. The boundaries of “in triage” were not identical from team to team.

Hidden issues

Worse, the triage board didn’t have a column for an unanticipated state. There was no column for “stuck” because no one had anticipating running into a hard problem. Yet one had come up. It was an intermittent error from a third-party COTS product that had severe consequences—severe enough to block releasing the system.

When the issue was stuck in “in progress” for a couple days, developers from a couple teams swarmed together to resolve it. Tension was high, and the solution required significant changes. It was risky stuff. Fortunately, they were able to solve the problem without introducing new errors. The triage board didn’t highlight this severe stuck issue, though. The teams worked around the official process to do what was needed, and the actual situation was relatively invisible to senior management. The Official Standard Triage Board just didn’t have a way to express the situation.

Coherence vs. Standardization

Coherence is the ability of various parts of the organization to work together in a understandable fashion. The actions and processes of different groups may vary widely in detail, but are compatible and work together toward compatible goals.

Standardization is the “copy and paste” of process development. It’s as bad in spreading process through an organization as “copy and paste” is in code. Copying a working instance may be a good starting point, but it’s a bad destination. Creative work needs attentive thinking, even when deciding to not change the status quo.

Rather than depend on standardization, it’s enough that processes are coherent through the organization. That is, any variation of the process should be able to provide the needed results. In the case of the triage board, any of the boards should be able to provide visibility into the number of issues identified and their progress toward resolution. As long as each board can do that, it should be sufficient.

The lure of standardization is that it’s not only coherent, but efficient. It’s efficient to create new copies of the same thing. It’s efficient to understand different groups within an organization if we can treat them the same, by having them work and report their results in the same fashion. It’s easy to add up the numbers to an overall sum if they’re all reported in the same fashion.

This efficiency is an illusion. While it may make it easy to generate reports, those reports may be less accurate. While it may make it easy to direct the work of various groups, those groups are undoubtedly working in different manners, according to their understanding of the directive and the work being performed. The sameness from team to team is, to some degree, a convenient fiction allowing us to maintain a facade of standardization. As the divergence between that fiction and the actual work gets greater, it created friction to accomplishing the work.

Benefits of reduced standardization

The price we pay for using coherent processes instead of standardized ones is more work for managers. They must learn how the reports from each process relate to each other. They must ask their teams for the outcomes they want, rather than simply tell them what to do.

The benefits are worth the cost. As we saw in our example, promoting coherence rather than standardization allows us opportunities to improve on what might otherwise be a static standard. It allows greater engagement by those doing the work. And it provides a means to adapt to unanticipated situations in ways that can be both effective and offer visibility to management.

Coherent processes will frequently be converging on standardized practices that prove themselves over time. They will also be constantly diverging as different teams experiment in different directions. These tendencies form a dynamic, rather than static, balance. The result will be stronger and more robust processes for the organization.

This article was previously published on projectmanagement.com.