All Posts in Process Management and Improvement

|In: Leadership|Last Updated:

Back in the 1980s, MacGyver was the guy who could build a weapons-grade laser out of duct tape, wire ripped out of a wall, a burnt-out light bulb, and ingenuity.

He was a pop culture anomaly … a hero, one of whose defining characteristic was that he was smart. Not smart in the I’ll-show-those-so-called-experts-a-thing-or-three sense, but in the knows-a-lot-of-science-and-engineering sense.

His other two defining characteristics were more mainstream. He had (of course!) little use for authority. And, there was the duct-tape factor.

MacGyver was to improvisation as Google now is to search: A name turned verb. In some entrepreneurships, those who MacGyver are stars. In others, those in which only the entrepreneur is allowed to … what’s the word? … think, they last maybe a minute and a half.

And in companies that have grown to a size and level of complexity where management matters, MacGyvering just isn’t how we do things around here, even though company leaders often agonize over their organization’s inability to innovate.

But aren’t these really the same thing?

Short answer: No, they’re not.

Long answer: Improvised solutions leave a lot out, they’ll miss a lot, and they’re flimsy. They’re done when they’re good enough to handle what’s going on right now, not when they’re a perfect fit and durable enough to last.

They’re quick, cheap, and disposable.

Compare that with innovation — both the relatively easy innovation that creates new products, and the harder kind that’s needed to improve how an organization does its work.

(If you disagree that internal improvement is the greater challenge: When you innovate how work gets done, you aren’t finished when you’ve built the tangible work product. Your job isn’t done until you’ve overcome the various organizational barriers that so often prevent even the best process and practice improvements from being put into productive use.)

Unlike improvisation, innovation has to be thorough as well as new and different, because when you’re changing how a department does its work, quick, cheap and disposable isn’t acceptable.

In the world of software development, we have lots of experience with improvisation. We call it prototyping. Like any other improvised solution, a software prototype only has to be good enough to be helpful getting actual work done right now. More important, unless you’re dealing with a temporary situation, prototypes should be useful for understanding what the “real” solution should look like, once you’re ready to build it.

We also have a lot of experience with innovation. That’s what we do when we design and build production applications, whether we use old-fashioned waterfall methodologies or one of the increasingly popular Agile alternatives.

Because while Agile development is often confused with prototyping, it’s fundamentally different. It’s just as much about building strong, durable, well-engineered, long-lasting solutions as waterfall, even if Agile builds them incrementally or “spirally” rather than from static, predefined specifications.

So just as IT can adopt Agile without also embracing prototyping, there’s no inconsistency between encouraging innovation and discouraging improvisation elsewhere, either.

At least, there’s no inconsistency from the perspective of how an organization’s leaders want change to happen.

Culturally, inviting innovation while excluding improvisation is a dicier proposition. Because while they aren’t identical — innovation requires more discipline, while improvisation calls for a greater sense of urgency — they share something vital — that “this is how we do things around here” is a good reason to do something different.

So while it’s easy to encourage improvisation without being overly concerned about innovation … entrepreneurships do this all the time … encouraging innovation while keeping improvisation to a minimum probably isn’t in the cards.

And an opinion: Organizations that want to innovate will be more successful applying a combination of improvisation — creating quick-and-dirty prototypes — and Agile-like incremental change that builds on itself, than by taking the waterfallish approach of trying to create a perfect design before implementing anything.

That’s because the whole point of innovation, just as it is for improvisation, is to do something different than anything you’ve done before.

The word for people who think they can do this all at once is “arrogant.” Because while the word is typically used to describe people who think they have nothing to learn from anyone else, it’s also a reasonable description of people who think they have nothing to learn from their future selves — who they’ll be when they’re better-informed than they are right now.

Comments

|In: Industry Commentary|Last Updated:

Evidence is a scary thing. Faced with it, most of us have an uncanny ability to explain it away if it doesn’t fit into our preferred view of How Things Work.

Here in KJR, and in my other weekly blog, InfoWorld’s “Advice Line,” I’ve been writing for years about the difference between processes and practices and the increasing importance of the latter. My arguments relied more on logic than on evidence, though, and so, last year, we conducted a survey to try to remedy this. It’s time to look at the results.

Respondents provided their company’s two most important core business functions and supporting business functions. For each they ranked fixed cost, incremental cost, cycle time, throughput, quality, and excellence in order of importance.

63 participants provided usable responses, although some described fewer than four functions. Aggregating the two core functions and two supporting functions, we ended up with data about 123 core functions and 106 supporting functions.

To classify each function as process or practice: If incremental cost was on the list, it scored one for process; likewise if quality was on the list. Excellence and fixed cost each scored a point for categorizing the function as a practice.

Netting the process score against the practice store, functions that scored +2 counted as pure processes, +1 as processes, 0 as hybrids, -1 as practices, and -2 as pure practices.

Some respondents combined multiple functions into single responses, presumably to provide a more complete look at their companies. For example, a respondent working in the extraction sector listed exploration and production as a single function, when they really are separate functions with separate characteristics.

I decided to include these entries, so the results pertain as much to the aggregate of a company’s business functions as to individual functions.

To the results:

As Figure 1 and Figure 2 show, among core business functions, processes outnumber practices (32% vs 20%), while among supporting functions they’re almost perfectly split (26% vs 25%). In both cases, about half the functions have both process and practice characteristics (they’re hybrids).

 

Company size matters. As Figures 3 and 4 show, the core functions of companies with 250 or fewer employees are far more practice-like than the overall average (33% qualify as practices compared to 20% for the population as a whole, n=43), while their supporting functions are little different from the population as a whole (n=35).

 

Meanwhile, as Figures 5 and 6 show, the core functions of the largest companies are, as you might expect, far more heavily weighted toward the process end of the spectrum (38% are processes while only 17% are practices, n=58). More surprisingly, their supporting functions remain evenly split — size does not appear to affect supporting functions as much as it does core functions (n=49).

How to interpret these results?

  • Practices matter: I don’t owe you a retraction — phew!. Clearly, a lot of the work that takes place in 21st century businesses is properly characterized as practice … just about as much as qualifies as process, in fact.
  • Size matters too: Unsurprisingly, bigger businesses organize more of their work into processes than smaller ones do. It’s unsurprising because the usual competitive advantage size confers is economy of scale — what process has to offer — while smaller companies generally compete on flexibility and agility, which come from employing practices instead.
  • Beware the false dichotomy: Process and practice aren’t categorical alternatives. They’re the endpoints of a range of possibilities, and for a given business function it’s entirely reasonable … and often desirable … to get work done in ways that have both process-like and practice-like characteristics.

Here’s what matters most in all this. As is the case in two other big areas where business and IT intersect, theory has ignored half the universe or more.

The first is data management, where we have well-developed methodologies for dealing with structured data, and no methodology at all for dealing with unstructured data.

The second is applications management, where we have well-developed methodologies for designing business systems but none at all for integrating commercial off-the-shelf software.

The third is how work gets done. Starting with Deming’s statistical process control and continuing through the current “big three” business design methodologies (Lean, Six Sigma, and Theory of Constraints), we have a lot of knowledge about how to organize business processes. But business practices, which according to the evidence we finally  have, constitute roughly half the work? It appears we have some methodologizing to do.

Sounds like a perfect project for some budding business PhD candidate.

                                                                                      

Thanks to all who participated in the survey.

– Bob

Comments