A Six-Minute Read

I recently needed to purchase an advance ticket on Indian Railways. Reservations can only be made on registered, verified accounts. Accounts can only be verified via text message to an Indian mobile phone.

Before anyone can purchase an Indian SIM card – in order to receive that text message – one must have a local Indian address and someone who can vouch for them (a hotel address is enough, as is an introduction to the SIM card vendor by, say, a bellman). Also, one must provide two recent visa photos as well as photocopies of their passport’s picture page, and the page with the Indian visa stamped in it (along with presentation of originals); these copies must be signed in the presence of the SIM vendor. One visa photo is affixed to the Application for Activation, and then must be signed over the photo, verifying the applicant was present as the pasting was completed; the second photo is similarly glued into the vendor’s log book, which is also signed by the applicant.

The paperwork is physically submitted the following morning to the local authorities and reviewed. Presuming all goes well, after a 24-48 hour waiting period, the phone number will be active.

Stories such as this explain why people cringe when they hear about business “Process” – they imagine their lives have been forfeited to a byzantine, bureaucratic mousetrap of paperwork, signatures, reviews, and perhaps even a few walking tours through the alleys of Mumbai to find a tout willing to negotiate the price of a visa photo.

This is not “Process”, it is “procedure”, and the two should not be confused.

A successful business process is three things – Effective, Efficient, and Adaptable. In other words, it needs to do what it needs to do; it should consume as few resources (time, people, money) as possible; and it needs to react to “real world” situations.

It’s that last piece – Adaptability – that’s always tough.

Rigid Process is a Waste (of Time, Money, and Human Spirit)

Processes need to be adaptable, not because employees can’t be trusted to implement consistently, but precisely because the circumstances they face will differ from time to time, from customer to customer, from region to region. Shoehorning every situation into a common set of procedures is a fool’s errand for two reasons.

The first is, when conditions don’t perfectly fit, they are summarily rejected until they do fit (how many forms are returned and resubmitted as particular boxes are ticked?). The second is, in order to create a set of procedures that can encompass every conceivable permutation creates a flowchart that more closely resembles a transit map designed by the manic five-year-old stepchild of lunatic bureaucrats than a useful tool for busy professionals. And, when the customer shows up with a situation that doesn’t align neatly with the maze’s entry points – or the user’s understanding of the process – we’re back to the first scenario of rejected paperwork and wasted time.

Design Intelligently

We can’t rely on smart, good employees to adapt as necessary; bad Process will beat good People, every time. Process Adaptability is not improvisation; to assure effectiveness and efficiency, the flexibility must be designed in.

Process Objectives.

Before going directly to boxes and arrows, the design team needs a holistic understanding of what the process should achieve. What are the objectives of this process? What are you really trying to accomplish? Try not to define objectives as pre-existing artifacts (“We want Customer Activation forms filled out more completely”) as actual business results (“Centralized database of new users”).

• What are the immediate benefits this process should accomplish?
• What are the long-term results it should achieve?
• What is mandatory, and what are the “nice-to-gets”?
• How “low” can we push decision-making?

Think in terms of measurable output – not any specific “form” or paperwork, but rather, “How will we know we have accomplished each objective?”

This leads to the design requirements of the process itself.

Process Outputs.

A good starting place  – for just about anything really – is the finish line. (As Dr. Covey said, “Begin with the End in Mind”.) Who are the customers of this process? What outputs do they receive? Meet with them, and develop an understanding of what their requirements are, with regards to time, quality, and cost. Also understand what is mandatory and what is negotiable.

Don’t settle for rote answers as “We need the Q5 filled out” – look at what information they need, what is the content required for them to succeed? Brainstorm alternatives that can focus on their needs and eliminate the faff.

Process Inputs.

Take a look at what feeds into the process, and who it comes from. Again, raise the level of discussion to look at the information and not necessarily the medium; that said, understand all of the different channels and media through which this information arrives (e.g., online forms, free-form email, telephone calls).

Build the Steps

With an understanding of both the process’ objectives, and the needs of the output, the team can design freedom into the process. How important is it – and where is it important – to provide “cookie-cutter” exactitude? Specify that in the process. What’s most important – equality or equivalence? What is the level of consistency and quality needed to accomplish the objectives (i.e., how do we prevent “perfect” from being the enemy of “good”?).

Often, the “steps” are created to replicate one version of status quo– “If everyone just did it like me, things would be perfect”. Challenge yourselves to move past that, and discover as many options as possible that meet both the process’ requirements and the customers’.

The team can use all that information to brainstorm different alternatives; judging those back against the individual process objectives allows for the best design – or combination of designs – to move forward.

Implement Wisely

It isn’t difficult to find examples of processes that are rolled out with difficulty (or outright incoherence).

Communicate the process objectives widely.

This further reinforces the potential for adaptability; if everyone understands what’s trying to be accomplished, rather than what checklist to complete, they can exhibit greater latitude and simultaneously stay true to business requirements.

Practice using the new process.

Role-play, run test cases, create simulations. “You’re smart people, you’ll figure it out” is demoralizing and insulting both to process users and their customers (i.e., victims).

Presume you’re going to fail.

Not only should you build debugging into your implementation, but be prepared to look at all the different decision points that real users face in the real world (that’s a lot of reality). Look for opportunities to praise those who adapted, and highlight their accomplishments; look for areas where people become paralyzed, and determine how to reduce the frustration.

This Isn’t a New Idea

Some of the above should look familiar to anyone who knows “SIPOC” analysis – think of this as SIPOC, enhanced with “Process Objectives”. By adding this layer of desired results, and extending the format into design rather than analysis, you give yourself a unique ability to create a business process that meets the needs of its users and customers, and one that is built for constant improvement.

Creating a process that is adaptable does not mean leaving it up to employees to ad lib or to consistently rely on their “good judgment”. Properly defining the process objectives as part of process design gives everyone the framework and the latitude necessary.