Stakeholder Coverage for Discovery — Purposeful Architect
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?
You ask the project sponsor if anyone else should participate in discovery. She thinks they have it covered, and suggests that you ask the other stakeholders. You take that one step further, asking each stakeholder if the list represents everyone who will:
- Get information from Sales Cloud, including external systems
- Enter data into Sales Cloud, manually or from external systems
- Support Sales Cloud, operationally or technically
- Govern Sales Cloud, such as a manager who approves a quote
All sales stakeholders agree that you have a complete list. Next, you show the list to the IT stakeholders. When they get to governance, they ask about generating contracts from Sales Cloud. You confirm that sales has that in their plan. They ask who represents the legal department, since they approve all contracts.
You return to sales operations to ask which stakeholder represents legal. They hesitate and say no one. They explain the company attorney with decision-making authority, Bill, is difficult to work with, especially when it comes to technology.
You meet with a sales manager and ask him about Bill representing legal on the team. He says, “If you include Bill, this project will fail.” You acknowledge his opinion of Bill, based on Bill’s reputation in sales as a roadblock.
You return to the project sponsor and ask her about Bill. She laughs and says, “Bill? Good luck getting him on board.” You ask if Bill should participate in discovery. She takes on a serious demeanor. She thinks for a moment and finally says, “Go ahead and invite him to the stakeholder team. I’ll be impressed if you can convince him.”
You meet with Bill, full of curiosity about this allegedly gruff attorney. He greets you with a litany of complaints about technology. You acknowledge each of his complaints, then share mitigating technical risk is an important part of your job. He pauses for a moment, like he’s sizing you up.
You inquire about the legal department’s mission. Immediately, he expresses frustration with the sales teams. “You give them an inch, and they’ll take at least a mile,” he bellows. “We need to protect the company’s interests. The sales team puts their commissions ahead of responsible business practices!” he says. You ask about legal’s biggest challenges. He immediately answers, “Risky deals!”
You point out that both of you put a lot of effort into minimizing risk. He could help you with that as a stakeholder on the Sales Cloud project. “I don’t know about technology and frankly I don’t care,” he grunts.
You inform Bill that his participation in discovery gives him influence over the system that he will ultimately use. Plus, the team needs his legal expertise. You’ll help him with any technical details. He likes the sound of that and agrees to join the stakeholder team.
The Sales Cloud discovery workshop goes well. Contract generation intrigues Bill. You help him understand how it facilitates collaboration on contracts and streamlines their approval. He appreciates having contract collaboration on the record. It mitigates risk as well as misunderstandings.
Bill approaches you at the end of the workshop and thanks you for including him in the process. You acknowledge the value he added. The project sponsor picks up on that, reminding you how impressed she is that you included Bill in discovery. She appreciates that Bill’s buy-in mitigated a lot of risk in the project.
Stakeholders should represent everyone, and everything affected by your solution.
Originally published at https://www.purposefularchitect.com on May 11, 2020.