“Discovery” is the essential first step of any Salesforce project in which Business Analysts and Solutions Architects work together to define the business’s requirements, against which a solution will be designed. You can think of Discovery as an articulation of the business needs using a set of analytical processes and artifacts.
Discovery phases of work present several challenges for technical teams – deciding where to start is hard, ambiguous business processes, end-users request solutions instead of sharing needs, stakeholders’ time is limited, and so on. In this article, I will share a 5-step process to help transform chaos into order during your Salesforce Discovery projects
Structuring Discovery
If Discovery is incomplete, your solution design will have gaps or inaccurately represent the business needs. The goal of Discovery is to ensure that functional and technical requirements are comprehensively elicited and documented.
Discovery should follow a top-down process, starting high-level and drilling down into lower levels of detail. By starting at the top, you are able to capture context – the “why” that drives requirements and ultimately speaks to the success of the project.
Working methodologically from the top-down will “shift left” the effort associated with the development lifecycle and help to buffer against budget loss via rework and miscommunication come time for User Acceptance Testing (when design changes are far more expensive to make).
Each level of Discovery lays the groundwork for the subsequent one. Once Discovery is complete, your team should be able to describe with confidence:
- What constitutes success for the solution
- How the business is ordered
- What the key entities are and how they relate
- How the business operates
- What the needs of end-users are
1. Setting the Vision
Starting Discovery by co-creating a vision statement for the project is a great way to build trust with your client. Developing a shared vision statement helps to build alignment on the headline objectives of the solution and foster a common language for success.
The vision statement should act as a compass for the project. You should plan on referencing back to the vision statement at three key points in the development lifecycle:
- Requirements validation: Cross-check requirements to ensure that they speak to the intended vision for the system.
- Solution playback: When proposing a solution design to the client, explain how it speaks to their vision for the to-be system.
- UAT and user training: When introducing users to the system before go-live, be sure to highlight how features meet their needs as articulated in the vision statement.
- Go-live: Use the vision statement to support the change management process, helping end-users to navigate change by reminding them of the value of the new system.
A vision statement should be both optimistic and realistic. The vision statement should be solution agnostic but outline an intention for change, priorities, and a raison d’être (reason to be – aka the “why”). A good vision statement could read something like:
2. Outlining the Operational Structure
Outlining the operational structure is all about understanding systems and stakeholders. Understanding the operational structure of the business is key to understanding how the business works at the highest level.
The important outcomes of this level of Discovery include that your team can articulate:
- The business units or departments
- The organizational structure, including hierarchical reporting lines
- The key roles (personas) that you are designing for, including their purpose and pain points
- The as-is and to-be technological landscape of the business (including non-Salesforce products and platforms)
- The high-level functional areas that your design should support
Framing the operational context of the business lays the foundation for lower-level discovery, ensuring you have an adequate broad-based understanding of the systems and stakeholders.
3. Defining the Business Rules
The business rules refer to the functional conventions that the business abides by. I map business rules across two related dimensions: key entities (which become Salesforce objects) and their relationships, and the high-level patterns of data ownership and visibility.
Entities refer to “things” that the business deals with – people, organizations, purchases, programs, etc. When defining business rules, we want to discover important information about these conceptual entities, including:
- What defines the entity?
- What are the key relationships with other entities?
- What key attributes describe the entity?
- Who typically owns data for this entity?
- How is data for this entity captured?
During Discovery, it’s important to think functionally, not technically. We’re aiming to understand how the business works, not to propose solutions (yet!). In addition to drafting conceptual data models, one might track important information relating to entities as follows:
Once entities and relationships are established, define the high-level visibility patterns by persona, noting any instances in which certain users should have no record access, read access, or read/write access. Note any exceptions to these rules:
4. Mapping Business Processes
Mapping business processes helps the team understand how different stakeholders execute tasks using various systems across time. Your process maps, or process flows, should:
- Follow a consistent notation style
- Include no more than 8-10 action elements per diagram
- Indicate an actor and the system where the action takes place (where applicable)
- Link to supporting documentation
- Use “drill-downs” to decompose processes into greater levels of granularity
While there are many business process mapping notation styles, your Salesforce process maps should have a similar anatomy to the style proposed in Universal Process Notation (UPN):
Understanding how and where to “drill down” to produce a complete set of process maps to adequately represent the business is a challenge for many newer consultants and Business Analysts. If you are tight on time, consider structuring your process maps across five levels, prioritizing high and low-level tasks like this:
- Organizational operations: Outline the high-level functions of the business as a whole.
- Departmental efforts: Outline the functions of each department or business unit that constitute the business.
- High-level tasks: Describe the tasks undertaken by teams within a department or business unit to complete high-level business goals.
- Low-level tasks: Define the granular tasks performed by individuals (personas) to actualize high-level tasks.
- Exceptions and complications: Outline relevant exceptions to the standard process(es).
It’s important to map both as-is (how the business currently works) and to-be (how the business should work once the project is successfully delivered) states. Business Process Re-engineering is the practice that refers to refining business processes for operational efficiency.
5. Eliciting Requirements
The final stage of the Discovery process is defining discrete requirements. Requirements are granular business needs that you can define implementable solutions for.
Requirements can be non-functional (referring to technical system requirements) or functional (referring to user requirements). Most commonly, requirements are expressed in the form of User Stories.
Once you’ve mapped business processes, requirements should begin to emerge organically. You should likely be able to generate a User Story for each action element in your process flows. Let’s take the following process flow as an example:
This process flow could surface the following functional requirements in the form of user stories:
User Story 1: As an MEL Officer, I want to issue the Feedback Survey when a program finishes so that I can support the Programs team in continuous improvement efforts.
User Story 2: As a Program Manager, I want to re-issue the Feedback Survey if a participant hasn’t responded within one week, so that I can help the Monitoring Evaluation & Learning Team improve survey completion rates.
User Story 3: As a Program Manager, I want the ‘Final Reminder’ email to be sent to participants who haven’t completed the re-issued Feedback Survey after one week so that I can help the MEL Team improve survey completion rates.
User Story 4: As a Program Manager, I want participants who don’t respond to the Feedback Survey to be marked as ‘non-responsive’ in the system so the MEL team knows they should not reach out for further information from the participant.
User Story 5: As a Program Manager, I want participants who do respond to the Feedback Survey to be marked as ‘responsive’ in the system, so the MEL team knows they can reach out for further information from the participant.
Remember that high-quality user stories should:
- Follow the “As a [persona], I want to [action], so that I can [objective]” syntax
- Be mutually exclusive but collectively exhaustive
- Follow the INVEST framework
- Have a set of 1-5 user acceptance Cciteria
- Have a set of assumptions
To determine non-functional requirements, consider asking questions relating to security, scalability, performance, accessibility, and maintainability. For instance, a non-functional requirement regarding email deliverability may be pertinent in the above example to ensure that participants receive system emails.
Discovery Outputs
Now that you’ve got a structure to help you define the workshops you’ll need during discovery, let’s talk about outputs! The output of this journey of definition should be a set of coherent artifacts that clearly articulate the business from top to bottom.
Here are five artifacts that you should be able to produce for each level of analysis:
- Vision
- Operational Structure
- System landscape diagram
- Organogram
- Functional decomposition
- Personas
- Epics
- Business Rules
- Business Processes
- UPN diagrams/process flows
- Requirements
- User stories
- User acceptance criteria
- Assumptions
- Non-fuctional requirements
Finishing Discovery
Wrapping up Discovery phases can be as difficult as starting them. Knowing when to stop “discovering” can be tricky, especially when stakeholders disagree or processes are changeable.
Discovery phases should be complete when you can validate the completeness and correctness of your set of in-scope requirements.
Let’s unpack this statement. Completeness refers to the corpus of requirements being representative of all needs of the business within the defined scope of work. Correctness refers to the validity of the requirements, ensuring that they accurately represent the needs of the business.
Once you have validated both the completeness and correctness of your requirements, you can close Discovery and move on to developing a solution design.
Final Thoughts
Conducting a successful Salesforce Discovery is equal parts art and science. Strong people and communication skills are essential – but true experts equip themselves with a sound methodology to execute thorough Discoveries!
If Discoveries give you stress, trust the process and remember that practice makes perfect.
Comments: