The Importance of Creating IT System Requirement Specification Documents for Strategic Sourcing

Far more often than I’d like, I find myself in a battle with my clients: trying to convince my stakeholders to first develop a comprehensive set of system and user requirements before going to the market to source a business critical IT application. The situation typically goes something like this:

There is a desire to go to the market and gather generic information on an application IT would like to deploy. Usually, Sourcing will be asked to create a RFI (and sometimes, if you can believe it, a RFP). In an effort to identify potential suppliers, Sourcing will ask the business for a User (or System) Requirements Specification Document.

The business will respond that it’s “too early” to get into all of that. They just want to get a “feel for the marketplace” or perhaps some baseline pricing for budgeting purposes. I’ll push back, explaining that without a good set of requirements, I’m in effect throwing darts at a board hoping that I will bring back a qualified set of potential suppliers and that the suppliers themselves may not be able to fully provide an adequate response to the business’ request. Sometimes, to satisfy my kvetching, stakeholders will send back a rudimentary set of core features and functionality they might want in their application.

The problem with this approach is that there is a significant waste of time and energy going back and forth with the stakeholders and the suppliers asking and answering questions that could have been easily addressed from the beginning with a good set of system requirements.

It goes without saying that developing a thorough list of requirements for an IT procurement can be a significant undertaking. There are numerous business units that need to be involved and several categories of requirements that need to be defined. The basic categories that should be included in a Requirements Specification Document are:

• Functional Requirements
• Interface Requirements
• Reporting Requirements
• System Administration Requirements
• Security Requirements
• Disaster Recovery Requirements
• Support Requirements 

Then, depending of the type of system that is being procured, there could be additional requirements for items such as data migration and sub-system integrations.

So, from a Sourcing perspective, without a basic listing of requirements, it can be difficult to provide potential suppliers with the information they need to respond to a request for information. Beyond that, there are numerous other benefits in addressing detailed requirements as early as possible in the procurement process.

Thorough requirements documentation reduces the risk of project failure and lower the chances of rework throughout the sourcing event. It also enhances the communications between all of various organizational inputs that need to be considered throughout the life of the project (the PMO, Security and Privacy groups, etc.)

The good news is that the requirements don’t need to be perfect right out of the gate. It’s reasonable to assume that the business may not know everything it that needs or want from a new IT application. Requirements gathering should be considered a discovery and invention process. Furthermore, there is nothing that stops a project team from changing their requirements as new data is accrued and other insights gained.

At the end of the day, taking the time to create and maintain a strong set of system requirements before going into a sourcing event mitigates risk, builds consensus throughout the various stakeholders, improves communication among the project team, and allows the suppliers to provide a robust response to RFx documents.