- Set up a system for capturing requirements
- Map processes
- Develop user stories
If you want to use Elements Catalyst for capturing requirements you will need to run a free 14 day trial.
The top reasons for project failure are incomplete requirements and poor scope control
Standish Group – 25 years of research into project failures
Why capture requirements
- You need to start catching and fielding all the requirements that hit you and track them centrally. Better still get the users to submit their requests online and eliminate the email hell you currently live in.
- With a tracking mechanism for your requests you can start to get a view on the priority, importance and the risks of the requests. That way you can plan releases rather than respond to the latest panic, the most vocal user or the most senior stakeholder.
- It is good to look back and see what you have achieved in the last week, month, year. Happy people are those who feel like they have made measurable progress every day. FACT.
- Accountability and traceability is important when 6 months down the line you are asked to justify a configuration. The requirements with their history and comments will provide the evidence you need.
- Requests are your backlog of potential change. You can use it to plan resourcing for the next quarter or year.
- It is the way you control the scope of each sprint.
The anatomy of a request
A requirement needs more than a simple statement “I need a …”. You need more supporting information to be able to assess, prioritize and implement it. You need the minimum information before a requirements can be submitted:
- Business impact
- Risk level
- Required by date and reason
You need a consistent way of capturing, managing and analyzing the requirements. The tools used by your IT team – such as JIRA – are too heavyweight and complex. You could build an app in Salesforce. But where would you find the time? So instead most people reach for a spreadsheet or create a huge requirements document. It seems quick and easy, but in the long run it will kill you.
9 reasons why spreadsheets are a bad idea.
- Requirements have a lifecycle that needs to be formally managed. Everyone should be able to raise and submit a requirement. But after that, it needs to be formally assessed, prioritized and managed.
- Requirements are more than a wish list. They need supporting information which could be notes but may also be in external systems; documents, webpages or screenshots, photographs of sketches on whiteboards.
- Requirements need analysis and investigation. Every requirement needs to be considered in the context of the business and technology to understand how to implement it. They do not sit in isolation.
- Requirements need collaboration. To assess and understand what is required takes a combined effort; the user who submitted, architects, Salesforce Admin, IT.
- Requirements need traceability and line of sight. This is linkage from requirement to business processes impacted to release that it is implemented in.
- Requirements need to be grouped and prioritized. Business changes and technical implementations are phased in releases. Requirements need to tagged to one or more releases so they can be filtered.
- Requirements are created during process mapping. As the business processes are captured, existing requirements are incorporated and new requirements are identified. Requirements add detail and context.
- Requirements need enterprise scale and security. They live beyond the life of a single project and should be managed and controlled in an enterprise app.
- Requirements have a lifecycle that need to managed through with routing.
Here is the typical lifecycle of a requirement
Elements Catalyst can be the central repository of all requirements – not just Salesforce. Any Elements Viewer can submit a requirement. New requirements can also be added whilst mapping processes as they are discovered. Start Elements Catalyst free 14 day trial.
Only Elements Requirements Managers can manage a requirement through the lifecycle. You can customise the lifecycle statuses and routing.
Requirements have some standard fields and you can add custom fields:
- ID (automatically assigned)
- What is required
- Status (in workflow)
- Business impact
- Risk level
- Required by date
- Required by reason
- Release (to tie it to)
- How it might be implemented (for your amusement!!)
- Tags (for filtering)
In the right panel Viewers and Editors can add and view supporting information:
- URL links
- additional metadata (you build a form to capture what you want)
- links to a step in a process diagram
- user stories (more of these later)
They can also be linked to metadata items in Salesforce so they form part of your Org documentation.
Below is a screenshot of a list of requirements, and the selected one “Need a new record type : Product recall” has the right panel open.
NEXT – Mapping business processes