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.
App dev acceleration technique No. 3: Humanity-based case handling
Michael Hugos described this technique in his excellent "Business Agility" (2009), although that wasn't what he called it. The concept is simple: When implementing any system, 20 percent of the cases handle 80 percent of the transactions, more or less, but every case takes about the same effort to implement.
The application team should deliver a system that handles the right 20 percent of the cases, (this is essential) knows how to kick out the rest for human beings to deal with, and allows those human beings to input the results back into the system when they're done -- that is, humanity-based case handling. If the system is programmed this way, IT ought to be able to deliver the system five times faster than if it had tried to deliver a complete system in the first release.
Two releases later, each taking care of the remaining 20 percent of the cases that handle the remaining 80 percent of the transactions, and the system will handle more than 99 percent of the situations that come up. The business should be able to handle the rest through humanity-based case handling without breaking a sweat.
App dev acceleration technique No. 4: Integration-free implementation
A fact IT professionals know but very few people bother to mention is that integration is where most IT complexity lives.
Most SaaS implementations aren't integrated into the rest of a company's applications portfolio -- and when it comes to shadow SaaS implementations, none of them are. This is the single biggest reason SaaS implementations have a reputation for being quick and easy.
As it turns out, given a choice between speed and integration, many business managers are quite content to live with manual rekeying -- so offer them the same alternative when IT is involved. They won't take you up on it, but that's OK. At least you'll have offered an in-house implementation that's just as quick and easy, and they'll know where all of the extra time and effort goes.
App dev acceleration technique No. 5: Only launch fully staffed projects
Here's something you can use from Goldratt's critical chain methodology, even if you don't use anything else from it. Goldratt defined "fully staffed" to mean that a project never waits for a team member to become available.
If the business only runs as many concurrent projects as it can fully staff, it will deliver more results in the same period of time than if it asks staff to juggle multiple project responsibilities. Because projects never wait for staff, each one will finish more quickly.
App dev acceleration technique No. 6: Solve it without information technology
More than 10 years ago, in my old "Survival Guide" column, I described a restaurant that sells soup in cups, bowls, and bottomless bowls (that is, all you can eat).
The challenge: Design the information technology needed to keep track of which customers should get free refills.
The solution: Don't use information technology at all. Use different-shaped bowls.
Just because project team members work in IT, that doesn't mean their imaginations should be limited to information technology. Sometimes, the only reason simple solutions remain undiscovered is that nobody is looking for them.
This story, "6 tips to break app dev bottlenecks," was originally published at InfoWorld.com. Read more of Bob Lewis' Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.