Business Process Design

Have you heard the news?

"60% of all software development projects fail to meet their goals."

Of course you've heard this. EVERYONE has heard this nugget of wisdom. It starts off presentations, it's used in consulting pitches, software integrators put it in their marketing materials, and IT departments promise it won't happen to them (or you). Here's the problem: it's probably wrong. I believe that, in fact, closer to 80% of enterprise software development projects fail to meet goals. The key is — it is a specific type of software project that nearly always fails. The type of development project that nearly always fails is the "old school" waterfall-type project. The kind that starts out with requirements crafted in excruciating detail, progresses to multiple layers of sign-off, is developed in several phases — each with their own system, unit, and user acceptance testing — and eventually finishes with a final result that doesn't fit the needs of a business that has long since moved on. Over the years I've seen software that was released that no longer fits an evolved business model, software that missed huge, key requirements, and software that was released just in time for an acquisition that changed the entire business environment.

Whew. I'm frustrated just thinking about it. Luckily, the software development industry (mostly) figured out that this was a problem quite while ago. Most successful projects today — especially externally facing consumer projects — follow a very different trajectory than the development projects of ten or even five years ago, emphasizing tighter contact with the customer, faster development cycles, and the testing of smaller chunks of code.

So what does this have to do with business process design?

Unfortunately, many business process redesign efforts make those old-school enterprise software projects look like Olympic champions by comparison. Unlike their software development counterparts, most practitioners of "process redesign" have not been so eager to bring their methods into the 21st century. In fact, while software design is largely light-years beyond where it was in the early 1990s, process design — for the most part — has changed very little. The practices learned many years ago a largely still followed:

  1. Document the old process in mind-numbing detail (about two weeks' worth of time)
  2. Identify the issues in the old process (a week here)
  3. Design phases for a new process (another week)
  4. Design the details for the new process (easily four weeks)
  5. Implement the whole thing as one giant project (I don't even want to guess...)
  6. Hope it works (and that the design is still relevant after so much time has passed)

And surprise, like the outmoded techniques for software design, the process design projects conducted in this manner also have an extremely high "failed to achieve results" rate — even worse than for IT projects in my experience. I speak from experience — this is exactly the way we used to perform process redesign work in the past. Redesigning a process using this "technique" was tedious and frustrating, both for us and for our clients. And, it was tough to achieve the desired result.

But it doesn't have to be this way.

Process redesign projects don't have to be lumbering, slow, painful exercises that rarely succeed in achieving their goals. By learning the hard-won lessons of software developers, you can dramatically increase your chances for success in your process redesign project.

When software development moved past traditional waterfall-style development, a new way of thinking emerged called "Agile Development." Agile development stresses speed over perfection, rapid development of small bits of functionality, and testing of all deployed code. How can this be used for business process improvement? Here are three of the main "agile" concepts and how you can use them to improve processes more rapidly and with a much higher success rate: