47% of unsuccessful projects fail to meet goals due to poor requirements management. (Source: PMI)
Only half of organizations (49 percent) report that they have the necessary resources in place to properly perform requirements management, leaving the other half of organizations lacking resources (Source: PMI)
One in six IT projects have an average cost overrun of 200% and a schedule overrun of 70%. (Source: Harvard Business Review)
Mind boggling statistics. Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start. Yet, companies are not paying enough attention to one of the most important areas of project – requirements management!
How do you effectively write business requirements?
First, Identify/review few key projects artifacts
Writing effective business requirements is a CSF on a project. There are several considerations for BA at the onset of requirements gathering –
1.IDENTIFY STAKEHOLDERS – Clearly identify audience and stakeholders for requirements gathering – a proper representation across LOBs like Business, IT, Marketing, Operations, QA should be included from the onset. Use RACI Chart
2.REVIEW PROJECT CHARTER – Review business case, project vision, high-level scope, timelines, budget, risks and assumptions (Project Charter should provide this information)
3.DEFINE PROCESS – Define requirements managements process i.e. how requirements will be gathered, documented, reviewed and signed-off. Discuss tools that will be leveraged. Define and implement change control process.
Next, Start developing requirements
4.USE STAKEHOLDER TERMINOLOGY – Develop glossary of terms
5.START WITH BIG PICTURE – Start with big picture view, in other words, a birds-eye view of business processes, functional areas and technical scope.
6.ORGANIZE REQUIREMENTS – by categories and sub-categories
7.PRIORITIZE REQUIREMENTS – Not all requirements are created equal. Develop a methodology to prioritize requirements, something along the lines of –
- Business Priority – Critical / must-have / good-to-have
- Technical Feasibility – Very complex to implement/ Moderate / Easy to implement
That’s it. I hope this provides a good guidance for BA’s to write effective requirements which will later be consumed by technology team for design and development..
Have I missed anything? Please chime in with your comments.