Writing solid requirements is an artform.
Whether it’s a biblical tome of a Business Requirements Document (a la Waterfall), or a slew of chirpy User Stories from an Agile framework, they all fulfil the same purpose.
To articulate what the new system will be doing in order to fulfil the requirements for the client.
It’s communication in it’s most basic form.
It tells them what they are getting.
The question is:
Does it match what they _think_ they are getting?
That might be a big gap.
I think I can distil almost all disputes, arguments, legal wrangles, divorces, break-ups, and rifts of any kind between any type of relationship to:
The mismatch between expectations.
The key to making sure a project goes well, is to ensure that the gap is minimised as much as possible.
Good communication is key.
I need to make sure the client can really see what they are going to get.
So I illustrate with words, pictures, mock-ups, scenarios, process diagrams, and examples.
They may all be lumped in a big requirements document.
Or they may be located in JIRA instance as User Stories with Acceptance criteria, along with process maps, and relevant narrative in a wiki or documentation product like Confluence or Microsoft DevOps.
It can be artefacts – documents, backed up by a verbal presentation to walk through the proposed solution.
I might need more than one calls.
I might need to present the information differently for different stakeholders.
I might need to reset, or adjust expectations so that the gap is narrowed down.
And that, is the 42 of writing great requirements documents.
#userstories #requirementsgathering #communicationiskey #documentation
#awesomeadmin #awesomeadmins #crm #excellence #salesforce
#salesforceadmin #Salesforcecertified #salesforceconsultant #salesforceadministrator #salesforceadmins #salesforceconsulting
#salesforceconsultingprojects #salesforcecrm #salesforceohana
#salesforcepartner #salesforcepartners #salesforceprojectdelivery #salesforceprojects #trailblazer #trailblazercommunity #trailblazers