Business analysis and system requirements
Before you buy a system, write down what you need. I study your processes as they're actually practised, design the state you want, and hand you a requirements document and a detailed blueprint to put in front of any vendor.
01The problem
Most companies start from the vendor's demo, so their requirements become whatever the vendor sells. After signing, they discover the system doesn't cover much of what they need, and every change is an extra cost.
Who it is for
- You plan to buy a system and haven't written down what you need.
- You have vendor proposals and no clear way to compare them.
- A system in place isn't doing what you expected, and you want to know why before replacing it.
02What the engagement includes
- Workshops with departments to document current processes
- Current-state map and where time is lost
- Future-state design
- Functional and non-functional requirements document
- Detailed solution blueprint
- Written acceptance criteria for every requirement
03Stages
- 01 Current state Workshops with departments, and a map of processes as practised.
- 02 Future state What must happen after the change, in language management and vendors share.
- 03 Requirements Functional and non-functional requirements, and a detailed blueprint.
- 04 Review & sign-off Review with decision-makers, and written acceptance criteria.
04Delivered
05Common questions
Do I need this if the vendor will write the requirements?
The vendor writes what their system can do. A document you own defines what your company needs, and becomes the basis for comparison and acceptance.
What do I receive at the end?
Written documents you own: the process map, the requirements, the blueprint and the acceptance criteria.
A systems project that is stalling, or has not started yet?
One message is enough to know where to start. I'll reply within one business day.