Do not defer the difficult in IT projects

When an IT project starts, those involved — both managers and developers — want to feel that they’re making progress. They also want to demonstrate that progress to those above them in the organization. So there is a very natural, very human tendency to concentrate on the easiest tasks, the “low-hanging fruit” that can be readily implemented and checked off.

Such tasks often include the user interface, if there is one. The tools and libraries for creating user interfaces (UIs) have become increasingly sophisticated and powerful over the years. It’s quite possible with some applications to have the user interfaces mocked up and visible — and nearly complete — before there is any functionality in the application itself.

In turn, this makes it possible for you to demonstrate the UI to upper management and show what great progress is being made. Of course, this can get you into trouble, since upper management may think you’re a lot farther along than you actually are. Even worse, you may think you’re a lot farther along than you actually are.

A separate but equally common tendency in many large IT projects is to get a specific module or subsystem about 80 percent done — just to the point where it starts getting more difficult to push ahead — and then set it down to focus on another module or subsystem where you can zip along. Again, this gives the sensation of progress and allows you to report up the management chain how well things are going.

Make no mistake: In all this, you really are getting work done. Your user interface is visible and able to be evaluated by the eventual end-users; your modules and subsystems are all getting to the 80 percent-or-so completion point. You may be right on schedule or even a bit ahead, so everything’s looking great.And this is when the real problems start.

Because at this point, you find yourself dealing with all the hard-to-solve or hard-to-implement issues for the system under development. You may have calculations or data analyses that the system needs to make but you simply don’t know how to do it yet. You may have projected performance and throughput levels that your system can’t really handle yet. You may interactions with internal, back-end, and external systems that you’ve just implemented as stubs up until now. In short, you’re moving from the stuff that you know how to do to the stuff that you’re not sure how to do.

The real complication, though, is that you are facing these issues simultaneously for some, many, or even most of your different modules or subsystems. You can no longer put the hard work on hold and jump to an easy task, because all the easy work is done. Everything left to do is difficult and may require invention and creative breakthroughs. Progress suddenly slows down dramatically; the project schedule starts to slip, and slip significantly.

But wait! It gets even worse. Because you have deferred the hard work in different modules and subsystems across the board, you may now find yourself in a form of “solution deadlock.”

It works like this: Let’s say you have a hard problem X to solve in subsystem A; you also have a hard problem Y to solve in subsystem B. After brilliant work and brainstorming, you have come up with solutions to X and Y. The problem: the two solutions are mutually incompatible. In other words, the solution to X precludes the solution to Y, and vice versa. This may seem unlikely, but I have seen it any number of times, particularly where problem X is a functionality problem requiring intense data retrieval and processing, while problem Y is a performance problem requiring a much quicker response time or heavier load processing than the system can currently handle.

Now imagine that you have a dozen or so different “hard problems” to solve — with any number of interdependencies and exclusions — and you can begin to understand why so many IT projects get to the 80 percent to 90 percent “completed” stage and then get stuck there for months.

The answer to this challenge requires courage, talent, and coordination: you need to actively identify all the hard problems up front and then solve them first. It requires courage because it means that your project schedule is going to progress slowly very early on, resulting in pressure and questions from upper management. It requires talent because you need to have people smart enough and experienced enough to identify and then solve these problems. It requires coordination because you need to treat these hard problems as a collection, instead of individually, to avoid solution deadlock.

I have a mental image that I associate with this particular challenge. Imagine mixing flour, sugar, and spices together in a bowl — as if you’re making cookies — and then throwing in half a dozen walnuts, still in their shells. Now put the mixture into a sieve and sift it all together.

Everything goes through just fine — except for those walnuts. It doesn’t matter how long or hard you work the sieve, the walnuts will just roll around and not go through. You have to take them out, crack them open, remove the nutmeat and grind it to a fine powder before you can get it through the sieve. Nothing else will do.

Just something to keep in mind.

[Adapted from an article originally written for the online version of Baseline.]

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.