“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where–” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“–so long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”
– Lewis Carroll; Alice’s Adventures in Wonderland
I do a lot of work supporting government departments that need to migrate across information management solutions, usually because the old one doesn’t support the business / users anymore. The extract above from Lewis Carroll is a perfect explanation of why you need to understand your business requirements before piloting any software.
Most organisations correctly identify technology change as a great opportunity to reassess business processes to see if they can be improved or better supported with a newer piece of technology.
This is usually done by creating a set of requirements to provide a benchmark for vendors to demonstrate their product against. This allows them to show if they have the capability to provide what you need. It’s at this requirements stage that organisations often struggle. Often it’s because they aren’t able to articulate what they mean by ‘requirement’. The simplest approach is to break down into two categories:
1 – Business Requirements
2 – Functional Requirements
Business Requirements express what you want to be able to do to meet a business need. So a business requirement might be “Organisation A has to dispose of documentation according to established disposal policy”.
Functional Requirements are how a solution should operate to perform a specific action. So a requirement might be “Solution X must allow the allocation of predefined disposal schedules”.
The reason for this distinction between business and functional is to avoid confusion between yourself and a vendor / developer. If they see one list of requirements, and interpret a business requirement as a functional one, they may end up customising large parts of a product that didn’t need to be changed. Not only is this costly, but it could actually impede users trying to do their work.
To avoid this it’s best to start with what the business requirements of the organisation are. If you can understand that, it’s a lot easier to then identify any specific functionality a solution may have to provide and reduces the chances of an overly customised solution.
Finally a word on how to avoid Alice’s predicament and choosing your road first. There is no formula for pre-set business requirements. Talking with users and business owners as well as those that support the IT and information management infrastructures will define what the business proccesses are and what requirements come from that.
If you work for a government department and still need a little help finding the right road our Information Management Consultants can help – just email us at information.management@nationalarchives.gov.uk.