All Posts in Process Management and Improvement

|In: Organizational Effectiveness|Last Updated:

Process is a blurry word.

It should be limited to situations where employees follow a sequence of well-defined steps that deliver repeatable, predictable results. Mass production, that is.

Instead, it’s often defined as “how work gets done,” however it gets done. Which leads to sloppy thinking, along the lines of, “Hmmm. Application development is a process. We’re having trouble with it. The problem must be that we haven’t defined the steps well enough.”

That way lies madness. When the time comes for developers to figure out how to put a module, object, component or service together, there’s a certain amount of figuring things out that can’t be reduced to a recipe.

In other words, application development is a practice, not a process. You don’t want repeatable, predictable results, because your developers only create each module once.

If IT was Nissan, app dev would correspond to the design department. It only created one production-ready blueprint of the 2013 Altima. It’s manufacturing that produces thousands of identical Altimas based on design’s blueprint.

None of which means process doesn’t matter in IT. IT does lots of things over and over again, from provisioning virtual servers, to deploying new desktops and laptops, to administering (and please, I beg you — not “administrating”!) access rights, privileges and restrictions for newly hired employees.

And even many practices, like troubleshooting, are embedded into broader processes like incident management, which is to say you can’t diagnose and fix all problems just by following a recipe (although “reboot” does solve a distressingly large fraction of them.

But before IT gets to the actual troubleshooting, it ought to follow a very well-defined set of steps for:

  • Capturing and documenting the problem.
  • Attempting to troubleshoot it during the call, assuming the problem was called in (embedded practice).
  • Calculating the incident’s priority relative to everything else that’s going on.
  • Assigning the ticket to a qualified technician.
  • Resolving the issue (another embedded practice).
  • Communicating status back to the caller at well-defined points in the process.
  • Confirming the solution with the caller.
  • Logging the resolution.

For all those situations where, like incident management, consistency ranks high on your list of Things That Matter, making sure staff follow a well-designed and well-documented process is how you get it to happen.

One problem: You can’t. Or, rather, you shouldn’t. Getting everyone to follow a process is a lot like the legendary guy who had a dog with no legs: Every morning he had to take Spot out for a drag.

When you have to drag employees along, it’s a … well, it’s a drag.

One more problem: You can’t. If you’re the CIO or IT Ops manager, it’s up to the Service Desk manager to make sure the incident management process happens the way it’s supposed to.

Now imagine, just for the sake of argument, that what the Service Desk manager knows how to do is supervise the work. That’s a very different matter from managing a process, and it leads to very different, generally worse results.

Which leads to this week’s pair of IT critical success factors: For those situations where process matters (roughly half of what IT deals with on a regular basis), what matters most is having (1) a “process culture,” and (2) managers who understand how to manage processes, and who embrace the idea of managing this way.

Process culture

Since founding IT Catalysts, my now-quiesced consulting company, I’ve used the definition of culture taught to me by my now-retired, anthropology-trained business partner: Learned behavior people exhibit in response to their environment.

A simpler version: In business, culture is “how we do things around here.” If you want staff to follow well-defined, well-documented processes, following well-defined, well-documented processes has to be how we do things around here. If it is … if you have a process culture … process will happen more or less automatically. If it isn’t, all you’ll get is malicious obedience.

Process management

Remember the Service Desk manager who likes supervising the work? That’s a problem if what you want is the consistency that comes from following well-defined processes. So it matters that process managers think in terms of establishing metrics and targets, setting up checklists and check-offs, and having regularly scheduled process review and improvement meetings. And, it matters that whenever possible such topics as priority-setting should be handled by algorithms instead of personal preference and judgment.

It matters enough that managerial competence in process management qualifies as another IT CSF.

Because if you think the IT staff can wreck your plans through malicious obedience, just imagine how much damage one of your managers can do.

Comments

|In: Career Management|Last Updated:

Humans are the collaborating animal.

Sure, bees dance, termites build mounds, and wolves and orcas hunt in packs. But no other animal gets together to build anything on the level of skyscrapers or Mars rovers, to fight in anything resembling a human armed force, or compose and then sing barbershop quartets, let alone symphonies.

But for every successful collaboration there are probably ten that fail, whether they’re ERP implementations, failed designs for a 9/11 memorial, most legislation, or every Pirates of the Caribbean sequel and every other Disney-theme-park-ride-turned-into-a-movie.

What goes wrong? With Disney, it’s probably the need to manufacture another movie even if nobody has had even a tiny spark of inspiration to justify one. For the rest …

Often, the problem comes down to different people from different organizations coming to the party with different hidden assumptions. When these go undetected and unresolved, the usual outcome is something less than success.

Two weeks ago we looked at one aspect of the situation: How each party values the three bottom-line goods of business — revenue, cost, and risk.

Last week we looked at a second aspect of it: How organizational styles compare, and in particular their levels of empowerment, formality, and communication.

This week we look at one more aspect: Each organization’s operating mode.

At the risk of oversimplifying, organizations have three ways to do their work.

The first is to work through processes and procedures, which is to say recipes. Everything is specified, and if everyone just follows the steps as they’re described, the result will be what it’s supposed to be.

The second is to work in accordance with “practices.” Like processes, practices are organized into an accepted series of steps to follow. Unlike processes, in a practice the specifics are left to the practitioners, who are expected to apply their knowledge, experience, and judgment to each situation they face.

The third is to innovate and improvise — to figure things out based on the logic and context of each situation.

The way it ought to be is that for each type of work that has to get done, the organization responsible for it makes a conscious choice from among these three ways of working, recognizing that really, they aren’t categories so much as they’re three poles in a continuum of possibilities.

The way it usually does work is that for each type of work, whoever does it chooses whichever approach they like the best — the decisions come from hidden assumptions, not explicit analysis.

Likewise IT. So when the two organizations try to collaborate, their two sets of preferences don’t line up, because why would they?

Imagine, just for the sake of argument, that IT’s overall operating mode strikes an even balance between process and practice, with very little improvisation going on.

Now imagine the other organization IT has to collaborate with is Marketing. As the figure illustrates, our mythical Marketing organization is heavy on practice and improvisation. Following recipes just isn’t in its DNA.

Now what?

The starting point is to be conscious: of your own organization’s preferences, and those of the organization you’ll be collaborating with. How can you find out?

Ask. Not using this vocabulary, which might seem strange to anyone who doesn’t read Keep the Joint Running. But just asking, as in, “Tell me about the kinds of work you do here.”

As you listen, keep an ear out for key phrases like, “We just do what makes sense,” a tip-off that improvisation is important there. Or, “This is how we do things around here,” which sounds a lot like process.

“We know our business and get the job done”? That’s a practice orientation.

It will take some conversation, some reading between the lines, and eventually, perhaps, after you’ve built some rapport, some time spent familiarizing your colleagues in Marketing (or wherever) with these concepts. At some point in the conversation you’ll familiarize your colleagues with your IT self-assessment, and you can ask for their self-assessment.

Better yet, you’ll be able to discuss why IT is what it is and why Marketing is what it is.

That’s when both organizations will stop choosing their operating mode based on personal preference and start deciding based on the logic of their (and your) circumstances.

Once you’ve achieved that, you’ll be in a very good position to help your colleagues solve the problems they have in ways that will fit their operating mode, rather than trying to force-fit them into yours.

That’s preferable for a very simple reason: If your solutions fit their operating mode, they might actually adopt them.

Comments