Acknowledge.png

Acknowledge

Reflect the capture of information
Business analysts acknowledge stakeholders’ needs and ideas to confirm they captured what the stakeholders meant.

Examples
When capturing pain points, business problems, and ideas from a stakeholder, a business analyst acknowledges the captured information back to the stakeholder. Acknowledgment confirms to the stakeholder that the business analyst captured what the stakeholder intended. It also allows the stakeholder to clarify what they said.

Acknowledge in Purposeful Architect

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

  • 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.
  • 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.

Defying Solution Gravity excerpt:

  • 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.

Understanding Customer Requirements excerpt:

  • 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.

Coming to Terms excerpts:

  • 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.