Requirements Gathering 101

I had a discussion recently with a really good friend who was looking to vent their frustration, and possibly seek a little direction on how to best handle a major project oversight that could cost their company over $50,000.  This expense was unbudgeted, missed in the project plan, would certainly raise a few management eyebrows, and possibly roll a few heads.

The company is upgrading a key component in their infrastructure, implementing a big enterprise reaching Altiris server with a grunty SQL backend.  The technical requester specified that the most expensive version of Windows Server and SQL Enterprise Edition were needed, due to the number of connections and computers that would need to be supported by this configuration, and the configuration called for a lot of RAM and storage.  This server set is also required to support several other enterprise-wide initiatives already underway at the organization, such as a Windows 7 roll out, continuous vulnerability and patch management, and the deployment plans for several applications.  Altiris is one of my favorite tools, and once entrenched within an organization, becomes pivotal to daily life for IT and Security management.

Half of the hardware was on back order, the RAM was expensive, the hardware and software should have been identified and ordered months ago, the clock was ticking, and the impact that this was going to have would amount to significant delays and budget overruns in several projects.  Steam was seen leaving my buddy’s ears.  Foam was forming at the corner of their lips.

The first question I asked after hearing the situation was “Are you 100% certain that you need the Enterprise versions of the O/S and SQL?”  The response was that the experts called for a specific configuration, and this was what was being sourced.  I suggested that they get in touch with these “experts” and discuss the requirements and justification for the O/S and database components.  The hardware specs sounded slightly inflated, but not uncommon for the proposed purpose.  Better to invest here now than to face a capacity or capability crunch shortly after implementation.  The rest was finger-pointing and unfortunate error, all very common in today’s IT world where we are still doing more with less, run ragged in multiple directions, short-staffed and over worked.  As long as that is considered “normal” expect to see mistakes made and items missed, and be prepared to deal with it.

Don’t trust a single proposal, even when or especially when dealing with a crisis.  Insist on seeing multiple proposals to keep your costs down.  Otherwise you may see someone’s dream machine, top of the line, excessive and expensive solutions.  The solution will definitely work, and performance will be awesome, but why drive a Ferrari down the DVP in rush hour?  Just to look good?  It still won’t make you Brad Pitt, and you will arrive downtown about the same time my old Jeep does.

I heard back from my friend this morning that the issue has been resolved.  When pressed, the consulting experts could not justify Enterprise anything, and in fact admitted that they could make do with the standard O/S and even fall back to minimal install of SQL 2005 if they had to.  Another vendor was found with the missing configuration items in inventory.  I recommended that they use the standard O/S, get a more current and robust version of SQL and avoid Enterprise, and spend a little bit of the savings on extra RAM, processors, or a 10% bonus for their favorite free technical advisor who just saved them $48,000 of unbudgeted IT project spend.

I’m getting a free lunch!