Documenting Requirements is a Requirement

BR and FR

You went through all the work to understand what your stakeholders and subject matter experts (the “troops”) need for your new salesforce project (the ” business requirements”), and you never documented them… so you ended up spending a lot of time undoing some of what you did and re-working other pieces of what you did. Sound familiar?

We all know what this feels like.. and it is horrible!

Here is a three-step process to help ensure you will not feel this way again!!

1. Take the time to document the business requirements. Mind your PB&Js!

2. Get the sign-off from your troops, and let them confirm that you understand the business requirements correctly (or correct you where you missed something).

3. Translate the business requirements into functional requirements. Functional requirements are the salesforce technical features you will need to develop in the final solution you deliver to meet the business requirements.

The translation process will always increase your effectiveness by providing the following benefits:

  • Your mind will no longer be burdened with the task of holding all of the design decisions you  have already  determined. You are waisting seriously valuable energy just because you are not writing down your functional requirements! I promise you will feel free and your energy will increase as soon as you make a habit of documenting everything.
  • You will find the holes in your ideas (or in your understanding of the requirements) before you actually start building, allowing you to pivot or get the additional information necessary before you have lost valuable time developing.
  • As your attention moves back and forth between other projects or duties/tasks, you can always easily pick up where you were without too  much struggle. And if you have a team that can help you out, you now have easy to access tasks that you can use for delegation (your documentation provides the full picture so the person you ask to help you will know exactly what you are trying to do even if you don’t have time to explain everything!).
  • Oh and if someone emails you out of the blue asking for more detail about this project you are working on… you don’t have to spend any time on your email back just forward the documentation!
  • You can use the product of your efforts to create a visual aid of the “current state” and the “future state using”. This is one of the best ways to get stakeholder buy-in for a new project or app from the AppExchange… the current state always looks so messy compared to the future Salesforce flow!