Capture

Elicit business needs from stakeholders

Business analysts interview stakeholders to capture business needs.

Examples Business analysts get pain points, wish lists, and business problems from stakeholders in the discovery process. Then, they ask stakeholders questions about each problem, feature, or idea to capture the true business need.

Capture in Purposeful Architect

Click a title to see excerpts

Discovery with a C.A.U.S.E. excerpt:

You capture all of their data access needs. You move on to their day-to-day processes, capturing every business need they share, even those not required for the initial implementation. You maintain your curiosity, asking them, "what else?" until they have nothing left to share. The tension on the call settles down.

You acknowledge each captured need with the person(s) who shared it, confirming what they said. This provides an opportunity to clarify what they need, and show them that you got it. The participants lean back in their seats as they realize you are listening. The tension on the call dissipates as the team sees you accurately capturing their data sharing needs and access control requirements. You remind the team that you are only confirming their needs, not committing to implement a solution. They chuckle and agree.

Once you have captured and acknowledged the client's needs, you review them after the workshop to understand them. You note any questions or doubts about a need and follow up with the client for answers. You create a document outlining each department's needs, adding one section for common needs and another for conflicting needs. You create diagrams showing the flow of each process the clients outlined, supported with more detailed diagrams of complex processes. You make a list of all your assumptions about their needs.

After you complete the documentation, you schedule a series of shorter sessions to show your understanding of each department's needs. You review the department's needs, along with the common needs. You go through the process flow diagrams to make sure they clearly cover each process. You check each assumption you made in understanding the client's needs. They point out where they have resolved some data access conflicts. You note those and all variances between your understanding and the client's feedback. You capture and acknowledge new needs that emerge from this process.

When you complete the follow-up sessions, you edit your documents with changes. You make sure you understand any needs captured in the follow-up sessions. You show these changes in a final summit meeting that includes the client CEO and the departmental managers. They are impressed with how clearly and completely you captured their needs. The CEO likes how you show the data access conflicts between departments, commenting that you made her job a lot easier. She says she’s excited to work with you in the future. You share how much you respect and appreciate her leadership.

The success of the client's Salesforce implementation hinges on capturing their business needs thoroughly and clearly. You acknowledge the needs as you capture them as the first level of confirmation that you have their needs. You review all that you've captured to develop understanding and insight into what the client needs from Salesforce. You create documents reflecting what you've learned and use them to show your understanding as a second level of confirmation. You edit the documents based on feedback from the client that varies from your initial understanding. You're discovering customer needs with C.A.U.S.E.: capture, acknowledge, understand, show, edit.

Coverage: How Much is Enough? excerpt:

Had to rewrite a bunch of stories because the person who created them didn’t capture all of the requirements and actually left a bunch of open questions before they were assigned out.

Defying Solution Gravity excerpts:

Customer stakeholders may have "pain points' that they want your solution to relieve. For example, their staff spends a lot time copying information from one system to another. Your solution will automatically transfer the data between the systems. Customer stakeholders will lead with their pain points because they are anxious to get relief. Pain points provide a good start to defying Solution Gravity by thrusting you into a customer need. Make sure you capture pain points and acknowledge that back to the stakeholders.

Once stakeholders recognize that you have captured their pain points, Solution Gravity becomes stronger. The stakeholders want relief from their pain as soon as possible. You must continue to defy Solution Gravity to capture all other customer needs in the scope. if the pain points hurt enough, the stakeholders may decide to limit the scope to only relieving the pain points. That risks ending up with an incomplete design, needing additional discovery and design rework. Ideally, the scope will include pain point relief and needs for improvements, making the solution more complete.

Exceptional Discovery excerpt:

Alternatively, you may decide an exception happens so rarely, you’ll work around it operationally. For example, our registration solution assumes that a guest could bring a companion on a double-occupancy package. Yet, what happens if a guest brings two companions, like their spouse and child? We captured the need for multiple companions and implemented a solution for it after meeting higher-priority needs.

Stakeholder Coverage for Discovery excerpt:

You are leading the implementation of Salesforce Sales Cloud for a new client. You want to include all stakeholders in a discovery workshop to capture what they need from Sales Cloud. The project sponsor provided a list of stakeholders: sales managers, sales operations, account representatives and information technology staff. You wonder if they’re missing anyone else who would be affected by the new Sales Cloud?

Discovering the Details, Step by Step excerpt:

The hotel vice president looks askance at the second step. She asks what preferences a guest can have for a room. Their information technology director chimes in with the preferences: smoking/non-smoking, number of beds and proximity to the elevator. The vice president does not want to offer a smoking room to a guest with a non-smoking room preference. You capture that constraint.

Discovering Quality excerpt:

In a discovery session, you capture and refine the client’s sales automation needs, keeping usability in mind. The client’s IT Director wants to make sure your solution will meet their quality standards

Continuous Improvement of Discovery excerpts:

A Rude Surprise

What went wrong? Everyone agreed the solution met the customer’s needs during the discovery workshop. Since then, the customer’s needs had grown and changed, making the solution fall short of what they needed. The solution provider learned discovery should not have stopped with the workshop, even though everyone was sure that they accurately captured all the business needs.

An Olympic Case

Sometimes a new issue or business requirement would come up after a teleconference. If the new issue couldn’t wait for the next teleconference, the ticketing manager and I would discuss it via email. If we had more than ten or so email exchanges about issues between calls, we scheduled a quick teleconference to resolve the urgent issues. While I captured all the issues that arose during the ongoing discovery, we only resolved issues in the current scope. I kept out-of-scope needs for future versions of ticketing apps.

Empathy for the Customer excerpts:

A Promising Meeting Takes an Unexpected Turn

When the product manager finally takes a breath, the purposeful architect asks him if he has any interest in what she needs from his company’s diagramming tool. He claims the tool will meet her needs with all its features, but takes some interest in what she has to say. The purposeful architect says she needs to diagram process flows and data relationships as easily as possible. She would use the tool occasionally and does not want to relearn it every time she uses it. The product manager frowns, admitting to feedback he has received from customers about how long it takes to learn the tool. He opens a requirements template on his laptop to capture what the purposeful architect needs.

A Promising Meeting Takes an Unexpected Turn

The product manager asks the purposeful architect if she would write her use cases and send them to him. She replied that she had already told him her use cases and he missed the opportunity to capture them. She gives the product manager his third and final red flag.

Lessons Learned

The product manager disrespected the customer’s time and attention by leading with features and having an initial reluctance to learn what she needed from a diagramming tool. He didn’t ask the purposeful architect what she needed until she prompted him. Then he squandered more of her time trying to fit her needs into his template. He missed opportunities to follow up with her about what she needed, while making the template and company policy seem more important than her. She tried to help him by suggesting he record the conversation. He should have offered some means to capture her needs without wasting her time.

The purposeful architect had enough when the product manager asked her to capture her own use cases. She had already taken the initiative for him to ask what she needed. She had to take the lead again, asking him to record their conversation instead of struggling with a template. If she provided him with her needs in writing, what initiative would he take to understand them?

The purposeful architect vows not to offer a solution prematurely in discovery, even in the rare case it turns out to be a perfect fit. She will capture customer needs efficiently without interrupting the flow of discovery. She will take any information the customer offers about their needs, taking responsibility for capturing the rest of their needs. Her regret for the meeting faded as she realized the experience gave her insight into how discovery looks from the perspective of a customer stakeholder.

Understanding Customer Requirements excerpts:

A Critical Junction in the Discovery Journey

Understanding what a customer needs forms the core of Discovery with a C.A.U.S.E.: Capture, Acknowledge, understand, Show and Edit. Discovery reaches a critical junction when it comes to understanding customer needs. For example, the business analyst in the above story filled in an incomplete requirement with an incorrect assumption. Had the development team built the solution based on the incorrect assumption, the solution would disappoint the customer and could take substantial time, effort and money to correct. This often happens when software development projects fail. Understanding customer requirements is critical to discovery. A business analyst who captures all of the customer requirements and does not understand them sets the solution project on a trajectory to failure. When a business analyst understands the requirements, s/he sets the project on a course to success. S/he can even recover incomplete requirements.

A person in a business analyst role first prepares for discovery. Then, s/he captures and acknowledges enough requirements to cover the solution scope. At that point, s/he should understand:

Developing the models helps the business analyst understand the customer needs better, possibly introducing new questions about the customer requirements. The business analyst ultimately uses the models to show the other stakeholders his or her understanding of their requirements. This could lead to discovery of new requirements, or improving the captured** requirements. The business analyst edits the models based on stakeholder feedback.

Coming to Terms excerpts:

Discovering a Customer’s Terms

Most customer terms emerge during discovery. Ideally, the business analyst can uncover these terms before the first discovery meeting from the customer’s documents and reports. The most important terms to capture are nouns: people, places and things the business manages within the solution scope. For example, a non-profit organization could deal with donors, donations and event venues.

Clearing the Path to Success

A customer terminology glossary helps the development team understand what the customer means through discovery. If customer stakeholders have different interpretations of a term, they should reconcile those differences before using the term in discovery. The glossary owner will capture and acknowledge the reconciled definition in the glossary, providing a common understanding of the term. The glossary lays the groundwork for clear communication and understanding of customer needs.

The Path to Understanding

Discovery with a C.A.U.S.E. introduces five aspects of the discovery journey - capture and acknowledge customer needs, understand their needs, show this understanding to customer stakeholders and edit understanding based on customer feedback. A business analyst should capture** customer terminology along with their needs during discovery. The graphic below shows how C.A.U.S.E. applies to discovering the customer’s terminology.

Motivating Specific Requirements excerpt:

Motivational Questions

Brenda customizes each questionnaire around a solution request to capture meaningful specifics of what’s needed from a solution. Accurate and complete answers to these questions result in timely delivery of a solution fulfilling the expectations of those who requested it.

What?

Brenda starts with these essential “what” questions:

What is important to capture?

“What is important to capture” defines the information needed for the solution, coming from those “who provide information needed by the solution”, the answer to an earlier question.

Requirements on the Record excerpt:

Tying it All Together

Business analysts and architects have many solutions available to capture requirements and related details. In the sections below, I highlight a few of the most widely used tools.

Getting Your Requirements in Order excerpt:

Value vs. Urgency

When discovery has captured enough requirements to cover a solution’s scope, the business stakeholders should rank them in order of business value to guide development scheduling. Some requirements may have a deadline which gives them a higher ranking.

Discovering Your Client excerpt:

Good Questions

Two people recently asked questions about their new clients in the Salesforce Business Analyst Community. They wanted to know what client information they should gather to prepare for onboarding their clients. One asked about an org chart, workflows, and a glossary, among other things. The other person had already met with stakeholders and created a diagram for their current process. She also captured pain points and some new process requirements.