IT projects have a reputation for spiraling out of control. This is all the more regrettable, given two core principles of next-gen IT: (1) there is no such thing as an IT project because IT is all about business change and improvement; and (2) IT should avoid being a business-change bottleneck.
Worse, the bad rap is often well-deserved.
[ Find out the 10 business skills every IT pro must master, beware the 9 warning signs of bad IT architecture, and steer clear of the 12 "best practices" IT should avoid at all costs. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]
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.
App dev acceleration technique No. 2a: Gurus
You've read that there are no irreplaceable employees? Ignore it. You want irreplaceable employees or, if not that exactly, employees who are very hard to replace. In this case, they're called gurus. They're the developers who know a core system well enough to make it sing, dance, and play the tuba if that's what the business needs. More, they know how the system is put together well enough to quickly figure out the most efficient way of getting it to do so.
App dev acceleration technique No. 2b: The Conference Room Pilot methodology
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.