How to prepare a better solution requirement list for IT project success

Many of our articles address factors related to IT project success and the significant rate at which these projects fail. There are many causes for failure; first among them is choosing a solution that does not meet the needs of your organization.

Typically, selecting an IT solution begins with the Request For Proposal (RFP) process. The process seems logical—state your needs and ask vendors to supply a price to meet those needs. If you're buying a commodity with little differentiation among options, developing a list of requirements is important. But if you're buying an intangible like an IT solution, with unlimited variables and options, that list becomes absolutely critical.

Unfortunately, it is very common to see software requirement lists for Comprehensive Annual Financial Report Automation or Continuous Controls Monitoring (CCM) systems with requirements:

• That are very broad
• Derived exclusively from a vendor's list of features
• Copied from another, theoretically similar organization's RFP

To see the error in this approach, imagine buying an expensive suit. After seeing it hanging in the store and being impressed with what you see, the next step is always to try it on. Why? It is the only way to guarantee it fits you. Even though the tag says it's your size, that is no guarantee of fit, is it?

Take that suit home without trying it on and it might fit exactly (unlikely); it might need some alterations, or it might be completely wrong for your body.

Why do so many organizations have such ill-defined requirements? The most common reasons include:

1. The team disagrees that implementing a new IT system is like buying a suit; they see it as more like the purchase of socks—one size fits all.
2. The team did not have time to formally document their needs, but felt that a good compromise was to use someone else's.
3. The team did not have a clear idea of how to document their needs, so they chose to leverage those published by vendors or peers.

How to document your needs

If you fall into the third category above, you can improve the probability of your IT solution's success by applying these seven steps:

1. Document your current business processes. Start by writing down each step. Visit the people who perform each step and ask them what they do, in what order, and why. Be prepared for some surprises. There will be steps you did not know about and shortcuts you never imagined. The benefits of this documentation process can go beyond selecting the right new system. For example, it can be the critical first step to updating your internal controls risk assessments or training materials.
2. Prepare process diagrams. There are many ways to create this material, but we firmly recommend modeling your business process graphically. Business process diagrams (or models) are excellent at displaying process gaps or errors in understanding in a way that descriptions like those gathered in Step 1 will not. We recommend swimlane diagrams like this:
   Many applications can be used to create these diagrams. The most commonly used is Microsoft Visio but we also like Lucid Chart and Creately.
3. Gather copies of any inputs (forms, authorizations, etc.) or outputs (reports) of your business processes as attachments to your documentation. Be sure to label the diagram to show where in the process they apply.
4. Consider what could/should be improved:
   1. What is difficult today?
   2. What takes a long time with the current process? What would the value to the organization be if you could eliminate or shorten this time?
   3. Are all steps necessary? Could we remove some of them and still achieve our desired results?
   Often these opportunities will jump out at you in the diagram. They may appear as many steps that loop back on top of themselves, for example.
5. Create new diagrams of the optimal future process, incorporating the items identified in Step 4. This improved process is a better representation of what you want your new system to support.
6. Transform the steps in the business process into a requirements list. For example, if a step in your diagram is, "Batch email statement," the need might be, "Ability to email statements to all accounts that have an outstanding balance without any manual intervention."
7. Finally, now is the time to consider vendor feature lists or the needs documented in other, similar organizations to see if there are any items you may have overlooked.

By applying these seven steps, you can tailor your software requirements list to your organization, and more likely find the solution that provides the greatest value.