Two types of people stand in the way of oncoming trains: the totally insane and software implementers. The primary difference between them is that the first group has an excuse.
The very fact that software implementers have been making the same error leading to the same deadly outcomes over and over again for decades now speaks to something, and I believe I’ve finally figured out what. Software implementers have an overwhelming aversion to defining workflow/information flow and individual work process in sufficient specificity to determine what the software actually should do—so they flat out refuse to go there. And as a result, they don’t know what the software should do before they implement—and they thereby default to attempting to run the application either “as-is,” with limited configuration or with misaligned configuration. Both cases are described by a three-letter acronym: DOA. The software arrives out of alignment with business process, and all hell breaks loose, typically in user acceptance training.
Before trying to identify the source of the aversion, let’s first define “sufficient specificity.” Process definition occurs at two levels. The higher level is workflow that connects employee with employee; function with function; company with customer; and company with supplier. Workflow includes information flow, because the two are joined at the hip everywhere except in manufacturing. The second and lower level is individual work process that describes how individuals do their own work. Individual work process is a dependent variable driven by workflow and should never be reengineered before workflow redesign.
Within the context of a software implementation, workflow redesign has to encompass every movement of work and information involving the new software, including source and destination flows. Further, workflow definitions should n-e-v-e-r represent the “as-is state.” If that happens, you’ll either minimize the value of the new system—or, worse yet, damage your company by doing the wrong stuff faster.
Individual work process design should follow the “to-be” workflow and drill all the way down to the user keystroke level to capture not only the data needs but navigation needs as well. Just don’t make the mistake of dissecting your as-is individual work process, because changing workflow requires reengineering work process – and why spend gads of time dissecting something that’s about to go away.
Okay, so why won’t most companies and individuals responsible for software implementations take these steps before deploying new software that immediately disrupts the business and takes a year or two to straighten out—if it ever can be straightened out? At first blush I can offer a host of reasons: lack of internal process skills; trying to apply Lean or six sigma to develop technology requirements; IT trying to define business process instead of business-side people doing the work; silo management interfering with process redesign; no budget; no one with time to execute process design; and “no time.” Of course, fixing things later takes exponentially more time and expense than doing things right, but I suppose that having new software arrive DOA is one way to get time and budget for process work, although the process design phase has almost surely been fatally compromised by putting technology ahead of process.
These are all contributors, but I suspect not the main driver. Over time, I’ve come to believe that most train wrecks that pass for software implementations stem from one, simple fact—we’ve made redesigning business process too damn hard. And indeed, if you don’t know how to streamline and automate the process of designing process, it becomes ugly quickly.
For example, we’ve just witnessed a company courageously attempt to redesign their enormously complex process for global service delivery before implementing SAP. Why “courageously?” Because without understanding how to streamline and automate the process design process, they did all their work slowly and manually—stretching an initiative they could have accomplished expeditiously in two months into a year’s work, and countless extra resource hours. And they still couldn’t get past identifying individual work processes by name and on to actually engineering them step-by-step, task-by-task—the level that provides the majority of application software requirements.
I had an epiphany over this. Seeing what it took to accomplish process design across this company by brute force hit me like a blinding flash of the obvious. Very few people or companies have the will power and resources to subject themselves to an exercise like this. But since skipping business process design shouldn’t even be on the table as an option, the only rational alternative is to learn how to streamline and automate process design.
Interested in learning how? If so, download a free Visual Workflow white paper from our site. Using the VW framework will save you untold hours and effort—and most importantly, could save your new software implementation.
Dick: Although I agree self-inflicted complexity is at the root of many implementation failures, I have found that failure to focus on the desired outcome plagues most of the projects I’ve worked with.
Cases in point: many students in my strategy classes have made statements similar to these, in spite of (or maybe because of) many years of IT experience:
“The objective is to provide a desktop device with appropriate software for every user.”
“The company needs to implement cutting-edge technology to be competitive.”
“The goal is to have all users trained and current on the latest release.”
These vague statements have resulted in the “qwerty” comment from me, which is what happens when I bang my head on the keyboard in frustration.
Such myopia causes projects to go off the rails because the tactic itself mutates into an objective. So, at some point in the project life cycle, nobody really understands what the project was intended to achieve to begin with.
That confusion is the root cause of most project failures.
Andrew – actually, we agree in broad strokes. You can’t effectively start process redesign until you’re clear about intended outcomes. However, just identifying desired outcomes outcomes doesn’t tell you how to select and configure software. Selection and config must be predicated on detailed understanding of workflow and individual work process if the app is going to accomplish what’s needed.
Thanks for the comment.
Dick,
Yes, you’re absolutely right about unnecessarily complex software. I can think of a certain word processing application that could go a diet. But even relatively simple is hard. One well-documented example of this is the Chandler project. A few years ago Mitch Kapor set out to build a new kind of PIM (a PIM!). I don’t think Kapor and his team of alpha programmers have achieved a 1.0 release as they move into year 6 or 7–I’ve lost track. You can read about the trials of the Chandler project in Scott Rosenberg’s great “Dreaming in Code.”