Project planning has got to be one of the most difficult areas in computing. And yet often it is what is most overlooked. Popular insistence on hourly rates makes for easy comparisons of two resources, and allows management to avoid scope and specification, the exact opposite of what you want to do if you’re trying to watch costs. Also, without a fixed fee you cannot make an accurate ROI decision because you don’t know how long it will take to complete. Person A costs X, person B costs Y, the cheaper of the two is probably a better bet, even if they’re a little slower. Not only does this miss the impact of experience, which drives up rates naturally, but also an experienced technologist can make strategic and time-saving decisions up front if he knows what the project is comprised of. But if he is being directed this way and that he is more likely to waste time and therefore money on the wrong things.

Time and time again I’ve seen projects get started, with the most clear intentions in mind end up being a huge can of worms once they get underway. Take for example an upgrade we did for a large security firm in midtown Manhattan.

The project started out fairly straightforward. Migrate an existing Oracle 8i database running on a terribly slow single processor and single disk Sun server to a 4-processor Sun server with a 10 disk raid array. Since there was version compatability we had a good sense that (a) the application would continue to work the same way, (b) the optimizer would still work the same way, so performance of queries would be consistent, and related Operating System and backup scripts would continue to work as before with little change. Predictability is the key to scoping a project, which is of course key to coming up with a fixed cost at the outset.

As things unfolded, the management team decided that 9i was a key requirement, and that despite potential trouble along the way, the expected downtime was a sensible time to upgrade, that application functionality did not rely heavily on 8i features that might have changed, and cost-wise it would be better to do the two together. Nice on paper.

Of course a change like this completely eliminates the predictability for a project, quickly pushing us onto an hourly basis for work beyond a certain point. It is open ended because application changes are difficult to predict and changes in Oracle’s Cost Based Optimizer could impact performance as well.

After a period of almost 20 hours of downtime, and a lot of tired IT folks, we managed to get things running again. The biggest hurdle turned out to be getting the standby database working again as we encountered some Oracle bugs with the configuration, which were causing core dumps, and general panic as well.

All of this underlines the need for careful planning, testing, and then deployment. It’s like checking out track conditions and the route on the day of the race, it just makes good sense. Even if you have ten years experience running marathons as we do in Oracle IT, you still want to do your due diligence or the technology might bite back. Also try to lean towards well-scoped projects that are conducive to fixed fees, and avoid hasty comparisons of hourly rates between different resources.