Reading Time: 3 minutes
I saw a really well constructed Request for Proposal this week. It was about 10 pages long and listed a set of business requirements and a set of technical requirements for an LMS, without being overly prescriptive about the specifics of how the system should operate. I work on responses to a lot of these and was nice to see one that was so well written.
It got me thinking about how difficult it is to create a good requirements list. Every so often at Epic we see Requests for Proposals that include almightly Excel spreadsheets listing sometimes hundreds of requirements that vendors must meet, usually to be marked as either a) as standard, b) with configuration, c) with development or d) not at all.
These monster spreadsheets are hugely problematic, not just for the agencies that answer them but for the clients who distribute them too. For the agency, it’s a fairly simple calculation as to whether the cost of the effort involved in filling it in is worth the value of the final contract. But for the customer, the problems may be less obvious.
The first problem is to do with requirements analysis. It’s a really tough job writing requirements. Done well, there will be a business analyst behind the scenes, someone with experience of requirements gathering and definition, who has done the research around their organisation and has converted the needs into well defined requirements. Done badly, which it often is, there will someone from the Learning & Development or HR department copy and pasting LMS feature lists they found on the internet into something that looks broadly like what they think they need. This is a recipe for disaster and the customer could well end up with a system that doesn’t meet their specific needs as an organization.
The second problem is to do with requirements definition. It takes real skill to write a good software requirement. It must be succinct, clear and unambiguous. Something like “The LMS must support groups” is a common one. Are these site-wide groups used for the purposes of course enrolment and reporting, or are they course-specific groups used for the purposes of engaging in learning activities together? A better requirement would read, “The LMS must support site-wide groups for the purposes of course enrolment.” It’s very common to be sending back clarifications on requirements like this.
The third problem is overly specific requirements. If you go too far in the other direction you can easily over-specify the requirement to the point that no known-LMS would be able to meet it without some customisation, and then your costs are going to spiral, when in actual fact there are probably many products that are good enough ‘as is’.
So writing good requirements is a really tough job, and it’s hard finding people with the right skills in many organisations. The RFP I saw which did this well had been commissioned from some experts who had clearly done a good job of interviewing user groups and translating those into succinct and unambiguous business requirements. It was a joy to work with, I just wish they always arrived in our in boxes in this way!
Reminds me of this comic strip from a few years back, which sums it all up nicely.
