Requirements for ERP / COTS projects are documented in all shapes and sizes. There is no standard method. It is left on consultants, Business Analysts, Business Users (Subject Matter Expert) discretion. The result is – requirements are all over the place.
- are collection of vague wish list
- are replica of existing system and processes
- include solution (big mistake)
- include detailed workflow (business process)
- are organised mess of all the above….
Before, we discuss further, it is important to note that requirements are documented at various project stages. The objective of documenting requirements at each stage is different. I will cover this topic in the separate post.
Focus of this post is Stage-1 – RFP/RFQ. This is the project initiation stage. Client undertake internal analysis and document business problems, objectives and requirements. Client prepare RFP/RFQ , so that, software vendors can respond.
During project initiation, it is important to have a complete coverage of the requirements. This helps in evaluation of packaged software (ERP/COTS)
Following are the objectives of requirements elicitation, during this stage:
- To have good coverage and representation of entire business
- To state the problem in business terms (non-technical), so the intent of requirement is clear to all stakeholders
- To document detailed requirements, where appropriate
- To document requirements independent of the solution. Hence, any vendor can demonstrate how their software can satisfy the requirement.
- To focus on capabilities that business wants to maintain, improve or establish.
So, what is the best way to document business requirements?
I suggest, telling stories about your requirements. We call this ‘User Stories’ .
If you are not familiar with User Stories, I suggest to read about user stories, before proceeding the post.
Now let us see, how we can document requirements by telling stories.
I like using following example table:
In the above example, each requirement is described as a User story. Acceptance criteria defines key capabilities/functions that must be satisfied by the requirement. During software evaluation, evaluate each requirement with shortlisted vendors and compare which product satisfy your needs the most.
Additional columns can be added to the above template:
- Effort estimate – What is the high-level estimate to deliver the requirement?
- Assumptions – Under which assumption(s) the requirement is documented?
- What’s involved – What is involved in delivering the requirement. Is it standard product feature, customisation, configuration or third party product integration etc.?
- Owner – Who is the internal business owner of the requirement?
- Raised by – Who have suggested the requirement?
- Cost of Delay – What is the cost to business, if the requirement delivery is delayed?
- ROI – What is expected returns on investment for the requirement?
Assumptions: The above recommendation is valid under following assumptions:
- Your business is selecting modern ERP/COTS software. Therefore, it supports – customisation of workflows, User-Interface design, adding customer fields etc.
- All the different types of requirements are documented consistently under proposed template
- Requirements that covers your niche (core capabilities/market differentiators) have detailed documentation, that is covered separately. For example, refer to above example (Requirement P-2, columns ‘Notes’)
Possible criticism of the above approach:
- User stories is an Agile/Scrum requirements documentation tool. So, it is fit for Agile projects only.
- User stories are not detailed. So, it can mislead the business/client during software selection process
- Business Requirement Documents including process flows (As-Is / To-be) are much better approach.
Possibly more….. However, it is subject to discussion!
Bottom line is that User stories is one of the best way to document requirements during project initiation for ERP / COTS projects. If done correctly, it takes your project to the next level.