Most of the new value IT delivers comes in the form of the new or enhanced applications needed to enable business change. Unfortunately, that's also where IT is most often the bottleneck. Here are six techniques for speeding up the IT side of business change projects.

App dev acceleration technique No. 1: Encourage "shadow projects"

IT's traditional approach to shadow projects is to emulate Sergeant Schultz from "Hogan's Heroes": Officially, we're supposed to prevent them all, but much of the time we avert our eyes and say, "I see nuthink!" -- with all the sincerity we can muster.

For nearly 10 years, I've been advocating an alternative. Originally dubbed the "Access Tangle Replacement Methodology," it calls for IT to stop trying to stamp out "shadow IT" and instead encourage user-developed prototypes. Every so often, IT inventories them, offering to replace those that have become essential to business workflows with production-grade systems that use the user-developed prototypes as specifications.

ATRS (ETRS when IT replaces an Excel tangle) has three big advantages. First, business change is built in and takes place before IT ever becomes involved. Second, there's no argument over whether the specifications were right because a system that does the job already is the specification. Third, IT won't be a bottleneck because until the new system is done, the user-developed system is there to carry the load.

CRP is one of the most important agile variants. It's also the least visible.

It's important because unlike every other agile variant, CRP was designed from the ground up to support the installation, configuration, and integration of commercial off-the-shelf software. Other agile variants may be adapted to it, but they were designed for application development -- a practice that differs in at least a half-dozen ways from package implementations.

In CRP, you lock your savviest business managers and users in a conference room (hence the name) with one or two of your gurus, a plain-vanilla or current-state version of the system to be implemented or enhanced, a big stack of test cases, and pizza.

The business managers and users run the test cases through the system, documenting the business process they use as they do so. Along the way they point out, "If you could get the system to do x, we could handle this case more effectively," at which point the guru either gets the system to do x, or proposes an alternative that would be much easier to implement while still supporting enhanced business effectiveness.

The system is done when the business managers and users figure they've reached the point of diminishing returns -- or when nobody can stand the thought of another bite of pizza.