Do Not Defer the Difficult in IT ProjectsBy Bruce F. Webster | Posted 2008-09-23 Email Print
Baseline columnist Bruce F. Webster argues why it is paramount that you tackle hard problems in IT projects like application development and systems integration from the outset and not procrastinate the looming trouble and complexity that lies ahead.
When an IT project starts, those involved – both managers and developers – want to feel that they’re making progress. They also want to demonstrate the same 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.