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.com 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 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, 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.com 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 salesforce.com”. 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 SFDC flow!
  • Subscribe to this blog and receive a free ebook “The 8 Steps to Managing Successful Salesforce.com Projects”, with real life examples of business requirements as they were translated into functional requirements!