Several of our recent articles have outlined IT project success factors and the significant rate of failures that have become commonplace. There are many causes for failure. First among them is choosing a solution that does not meet the needs of your organization.
The Request For Proposal (RFP) process is ubiquitous. Everyone uses them because it seems logical; state your needs and ask vendors to supply a price to meet those needs. If you are buying a commodity with little differentiation amongst possible solutions, your RFP requirements list is important. But when buying an intangible like an IT solution that has unlimited variables and options, it becomes absolutely critical.
Unfortunately, it is very common for us to see software RFPs for CAFR 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 3 most common causes:
- The team disagrees that implementing a new IT system is like buying a suit; it is more like the purchase of socks - one size fits all.
- The team involved did not have the time to formally document THEIR needs and felt that a good compromise is to take someone else's.
- The selection team did not have a clear idea of how to go about documenting their needs and so chose to exclusively leverage needs published by vendors or peers.
How to document your needs
In case you fall into the third category (above), improve your IT solution success with these seven steps:
- Document your current business processes. Start by writing down each step. Visit the people that 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 people taking shortcuts you never imagined. The benefits of this documentation process can be more than just selecting the right new system. For example, it can be the critical first step to updating your internal controls risk assessments or developing updated training materials.
- Prepare diagrams of the process. There are many ways to create this material, but we firmly recommend you formally model your business process graphically. Business process diagrams (or models) are excellent at showing gaps in the process or errors in your understanding in a way that the descriptions you gathered in step 1 don't. We particularly recommend Swim Lane diagrams like this:
There are many applications for creating these diagrams. The most commonly used is Microsoft Visio but we also really like Lucid Chart and Creately.
- 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 they apply in the process.
- Consider what could/should be improved:
- What is difficult today?
- What takes a long time with the current process? What would the value to the organization be if you could eliminate this time?
- Are all these 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.
- Create new diagrams of the optimal future process if you implemented the items identified in step 4 above. This improved process is really what you want your new system to support.
- 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."
- 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 have overlooked.
With these 7 steps, the requirements list in your next RFP will be perfectly tailored to your organization, so you can find the solution that will provide the greatest value.