I've been in the IT business for more years than I care to count, and I can't recall a time when the economic situation at most companies has been more uncertain than it is now. Sure, the early 1980s were bad; but back then, IT spending was only a blip on the corporate coffer's radar. These days, it's sometimes the biggest item on the balance sheet, and spendable dollars are scarce –­ to say the least.

To make the most of those precious IT dollars, many organizations are getting really good at figuring out ways to tighten project plans and cut any unnecessary steps from the path to project completion. To a certain extent, I can understand that.

However, I've been noticing a disturbing trend recently of cutting back on resources for system testing and development resources at project rollout time ­– especially in business intelligence (BI) projects. I think there are basically two reasons for the trend. One, obviously, is the absolute necessity to pare down IT spending to its bare minimum. I think the other reason, however, is rooted in BI technology itself.

BI vendors have gone to great lengths to make their tool suites very developer friendly. Development environments in the leading tool suites are intuitive and straightforward. Further, although it's (relatively) easy to develop a BI solution in one of these new-breed tools, the solution is still very powerful.

I think this lulls many IT project managers into underestimating the difficulty of developing a robust BI system that meets the needs of the user community and provides the ROI it was expected to. Why? Because, unfortunately, these seemingly simplistic development environments must be used to develop extremely complicated BI systems –­ systems that require the finesse and knowledge that only experienced (and often expensive) systems developers possess.

The result of this oft-made underestimation is that development and testing are resources often cut out of the project plan at the earliest possible instant. Many times these days, that instant is way, way too early. The results of this cost-cutting move, while not often catastrophic, may seriously hobble the project. In the end, it may result in wasting much more money in redos and last-minute fixes than was saved by cutting costs in the first place.

How bad can it be? For one thing, if developers are rolled off immediately after hard-core development is finished, they don't have time to conduct full system testing. Robust system testing does two things. It allows you to see how the system will perform under mostly real- world conditions. It also allows you to ascertain whether problems you do find (and believe me, you will find them) are issues that are inherent in the BI toolset itself, in the system that was developed with the toolset or in the data that is visible through the interface.

In effect, it "stress tests" the system. Such stress testing will uncover issues such as lack of network bandwidth, problems with user-interface or database design, or problems with the data itself. It also enables analysis of where and how problems propagate themselves through the system.

For example, a data field name or mapping may change at only one site that is part of a multilocation rollout. These slight changes might cause major glitches to the system ­– including bringing the entire system to its knees in a really big hurry. If you don't have development resources still working on the system, the problem may not be able to be fixed in a timely manner –­ or at all –­ by any nondevelopment resources you have left.

In that same vein, consider a phased project where one or two target clients might have different requirements than others or one client may uncover a need for specialized system enhancements fairly late into rollout. If you remove the hard-core development resources from the project after the rollout to the initial target site, how can you possibly meet these needs as they crop up?

Surely, this must have been discussed in the upfront planning stages. It probably was, but we all know that the unexpected and Murphy's Law are the only sure things about any IT project! For this reason, it's crucial that there be some development resources on the project ­– whether it's a company resource who has been cross-trained or a vendor resource.

Now, I'm not saying that you should spend one single penny more than you have to on any BI project. That's my point exactly. Ongoing investment in development resources, however expensive those resources might be in the short run, is absolutely critical to the success of any IT project –­ but it is especially crucial to BI projects. It simply comes down to the old adage, "Pay me now, or pay me (a lot!) later."

All information provided is of a general nature and is not intended to address the circumstances of any particular individual or entity. Although we endeavor to provide accurate and timely information, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future. No one should act upon such information without appropriate professional advice after a thorough examination of the particular situation. The views and opinions are those of the author and do not necessarily represent the views and opinions of BearingPoint, Inc.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access