Processes Don't Work; People Do

We've all heard the horror stories about out-of-control projects, and many of us have lived through death-march final days in which such projects are finally forced out the door after enormous labor and suffering. But at Kofax, an Irvine, Calif., company that develops products to capture and manage documents, this overly familiar story has an unusual ending.

It all started with Ascent Capture 3, a new version of a popular Kofax product. It was 18 months late, for all the usual reasons: ambiguous requirements that led to creeping expansion of scope and all the last-minute surprises that creates. In one case, a third-party plug-in was discovered itself to be still in beta testing. The worst part was that it had been two years since the previous release. As projects go it was, unfortunately, not that unusual.

What was unusual, though, was the president's reaction. Instead of punishing the innocent and rewarding the uninvolved, as the classic project life cycle dictates, he made a simple but profound decision: Let's fix the process.

The Task Force

Not a radical idea, really, except for one thing. The president didn't just proclaim his wishes as a lofty goal, print a few posters, and hold a meeting to pass on the responsibility. Neither did he go out and buy a methodology and hire a strike force of highly paid consultants to hand it down. He made the people that had to follow the process responsible for defining and implementing it.

First he created a software development task force that comprised a cross-functional team of engineering, quality assurance, and product managers. He charged them with defining, then implementing, a process that would bring sanity and predictability to the development process, allowing Kofax a realistic chance of delivering high quality products on time.

The task force met twice a week. Each area defined what it did and what resources it needed. This flushed out the dependencies among the areas, which led to a series of "gates" through which the product had to pass. The team created for each gate entry and exit criteria, consisting of written documentation that had to be produced, reviewed, and approved.

The first pilot project was conducted in 2000 before being rolled out to all projects. Employees initially resisted investing the time and effort to write and review all the documents, and management had to stick to its guns. Granted, some process elements were jettisoned because they didn't serve a useful purpose. For example, sales projections for a product that did not yet exist tended to be so speculative as to be unhelpful. Kofax kept its eye on the point: not the process itself but results.

Ultimately the skeptics were converted to believers when they saw the benefits of all that reading and writing: they knew what was expected of them in time to deliver it, and others knew what was expected of them in time to provide it.

The Gate Keepers

The process was fairly straightforward, with two important exceptions at the beginning and end. First, each product started with a three-year "roadmap" of future additions and features, with two functional and maintenance releases scheduled each year. The significance of this was huge.

"Once everyone could see that there would be a consistent, steady stream of releases, the desperation to cram every last feature into the next release subsided," said Don Calkins, director of Ascent Software quality assurance. "It made it easier to control the scope on each release."

At the end, there was a post mortem to review what was learned, what could be improved, and what could be removed. "This last step is often forgotten in the heat of the next looming deadline, but it is critical to ongoing improvement," noted Calkins. "Otherwise, you don't really learn from experience."

In between, there were gates for marketing requirements, engineering requirements, product definition, coding, testing, and release. The documents for each stage had to be produced, reviewed, and approved before the product could advance to the next gate. Because of the increasing specificity at each gate, certain activities could go in parallel, saving time.

For example, the test procedures were developed during the coding phase, since both groups were working from the same product definition documents. The technical publications department was able to outline the documentation using the same information, and technical support was able to start developing training plans for its staff and its Web site. Marketing staff had a better feel for what was going to be delivered and when, so they could move forward with pricing and distribution plans.

The Finish Line

Eight projects have been through Kofax's new process, and guess what? It works.

Schedules are not only met, but the products are better. Testing, for example, dropped from 6 months to 2 months on one product alone, because they were able to get started early and did not have to deal with surprises. Even more amazing, the number of serious defects reported from the field dropped by a factor of five, from 27 percent to 5 percent. Reseller conventions turned into celebrations, and death marches became a bad memory.

Sound too good to be true? It isn't. It just goes to show what we've known all along. Processes don't work, people do. It takes a combination of senior management commitment, middle management participation, and cooperation at all levels to take an idea and make it a reality.

Linda Hayes is CEO of WorkSoft Inc. She was one of the founders of AutoTester. She can be reached at linda@worksoft.com.