A Four Minute Read

On recent projects, one concept that has stymied clients the most – and caught me off guard each time – is that of “debugging” a new process. Process Design teams spend a lot of time and effort creating workflows that are efficient and effective, and the Change Management folks work overtime to make sure people are ready to adopt a new process. The cold reality, though, is that no matter how well designed it is, a new process won’t be perfect. Users will find flaws and potential improvements, workarounds and roadblocks.

In short, there will be bugs.

Who Plans to Fail?

Teams that successfully use the ideas of “Agile” design are familiar, and most likely comfortable, with this (one of the few strengths of the Agile mindset). An Agile plan essentially says, “Whatever we have on that date, we’ll release – what doesn’t work gets prioritized and fixed on future dates.” For markets that tolerate iteration, this works  – the software industry, from whence Agile comes, has trained us as consumers to accept imperfections (“bugs”) and wait for an update.

In other situations, though, stakeholders (process users, their leaders and customers) may not have that attitude. In these cases, crafting – and articulating – a clear debugging plan is key. “Debugging” –  traditionally used in software development – is the ability to systematically trace a process, identify its problems, and fix them.

Mike Tyson famously said, “Everyone has a plan until they get punched in the mouth.” No one plans to design processes that won’t work: Design teams use experienced people and simulations, but it is difficult (if not impossible) to know in advance how the process will behave in the “real world”. Nevertheless, there are some things that can be done to minimize the bugginess of a process before releasing it.

Debugging Steps

First, select an appropriate implementation strategy. Processes can be unveiled in a variety of ways. The organization can run pilots – where only certain users (or teams, or regions) test-drive the process, or it’s only used with certain customers or products. A multi-stage process can be debuted in pieces – as one part is delivering results, the next executes. There’s always the “tear off the Band-Aid” approach. The right strategy is the one that balances the needs of the organization with its ability handle change and stomach revisions during implementation.

Second, work through what can go wrong and what to do about it. This sounds obvious, but is often forgotten. With designers and organizational leaders together in the room, formally discuss, and document:

• What will prohibit people from complying with the new process?
• How do we minimize those opportunities?
• What will the response be if they don’t comply?
• What happens if they do it wrong?

The results of this discussion should be included in the implementation plan. Assuming that people will follow the new process because they are told to – or that the proper response for noncompliance is discipline – is not enough. This needs to be a structured, facilitated discussion.

Next, set up an appropriate provisional governing body for the rollout. Ultimately, “governance” should include a specific process owner and a cross-functional oversight team. The eventual Process Owner may or may not be a part of this implementation team; for right now, the team needs a sample of the process’ designers, users, and downstream customers.

The hard part is to set the rules of engagement. How will the nascent process be monitored? How often will the Debugging team meet to review and adjust the process? (This should be very frequent at the beginning, and can ease as the transition smooths.) When will people be “forced” to use a broken process before the Debugging team can make an adjustment? What constitutes a “process emergency”, and who can authorize a unilateral change? How will the team know what’s working and what isn’t (i.e., how will it be measured)? How will decisions be communicated to the public at large?

These are all important questions to ensure a stable implementation. A key reason to implement a business process is to have a consistent method of doing things; if users are left to figure out their own workarounds when they come across unforeseen challenges, the situation becomes worse than if no process was installed at all. Sometimes this means “letting it burn” – that is, working suboptimally – until an adjustment can be made. It’s obviously not ideal, but better to have consistent awkwardness than anarchy.

Debugging can be tricky for design team members – they are needed because they understand the intent behind process steps, but they need to be careful not to hold anything too precious. If the newly-minted process needs to adjust, it needs to adjust.

Developing and following a communications plan is crucial to this. Acknowledging in advance that everyone is managing a work in progress, and letting people know why, when, how, and who will be debugging, reduces dialectic tension. Users of the new process may be frustrated when things don’t go as planned, but they will become downright apoplectic if they don’t know what the recovery plan is. Overcommunicating helps; presuming that others will trust the design team, or trust the process, is foolhardy. They won’t.

Lastly, agree on an end point. Implementing a new process is part of a project; it doesn’t matter if “Process Debugging” is slated at the end of the Design Phase, or the start of the Implementation Phase. At some point, it needs to stop being a “project” and become its own “process”. The project manager and the debugging team step out, the Process Owner takes control, and ongoing governance maintains the efficacy of the process.

 

Getting it right the first time is absolutely the main thing, but “the best laid plans…” is a cliché for a reason. Picking the right sandbox for a pilot certainly helps minimize disconnects during implementation. Acknowledging the possibility of bugs in the new system, and executing a rigorous method for discovering and eliminating them, will increase the speed of adoption and reduce organizational tension during the change.