Do Requirements Really Matter?
Of course they do, but you wouldn’t know it by looking at many of the companies we meet with while they are in the process of selecting a performance management solution. A company we worked with a few months ago illustrates this point perfectly.
When we walked in the door they were far down the path with a particular vendor and they just wanted us to ‘validate’ their decision. In other words, did we believe their assessment was right that this vendor could meet their requirements. Well, we’d have to see those requirements first. The good news is that on the technology side they had a decent set of requirements outlining required interfaces, supported databases, desired performance/responsiveness, remote access needs, security, etc. It was a 12 page document and also included a project timeline.
On the business side, it was a paragraph someone had sent as an email. It went something like ‘need to implement a system to replace Excel-based planning and reporting’. Now of course the finance team and business unit leaders involved had a lot more thoughts on what they wanted, but it was all in their heads. It was not clear that they had even discussed it with each other. There was no way this was going to end well. So, we recommended they step back for a moment and let us help them develop detailed requirements.
They put together a team of 40 key stakeholders and we interviewed all of them (some in departmental groups, others individually). The end product was a nearly 60-page document reviewing the current status of their systems, related challenges, and required functionality of the new system. While the raw interview data was maintained, the requirements were summarized by product functionality area and prioritized by frequency of request. One of the first things that became apparent was that they were looking at capabilities that went far beyond just planning and reporting.
The end result of all of this was that the vendor they were about to purchase was now obviously not a fit. Using these new detailed requirements we helped them identify several vendors that could potentially meet their needs. They went on to evaluate four of them against their specific requirements. They then scored them according to their ability to meet each requirement and went into contract discussions with the top two scoring vendors.
Without detailed business requirements you could easily select the wrong solution, as almost happened here. In addition how can you compare vendors without knowing what specific criteria you are using for the evaluation and scoring? There is also a hidden benefit to this requirements process. Those 40 people that were interviewed now feel that their voices were heard and their input was taken into account. While it is unlikely that 100% of their requests will be met by the new solution, because they were part of the process they will help support a successful rollout and accelerate user buy-in and adoption.
Leave a Comment
You must be logged in to post a comment.
