A reader writes:
What should an analyst do when a Subject Matter Expert does not have extended knowledge and/or does not make decisions? Should the analyst become a SME herself, insist on getting a help for the existing SME or both? What if no one else knows the subject very well?
Anyone with a minimum of experience as a business analyst is likely to have gone through this situation one time or another. Just from my own past experience and stories from my coachees, I can think of many scenarios, such as:
- A new dashboard being created to support management decisions, when the only SME available is a financial analyst whose expertise is limited to the financial metrics the dashboard will cover, leaving a significant knowledge gap relative to other aspects of the solution, such as metrics around customer satisfaction and defect resolution that will be part of the solution.
- A document imaging system being migrated to the cloud from an on-premise installation, with no one available to clarify which capabilities and functions need to be preserved or can be eliminated without business impact.
The risks for project success will be obvious to the project team, but not necessarily for the stakeholders anxious to see a solution delivered as fast as possible. In the case of the two examples above, the risks would include:
- Significant time and effort spent building the dashboard only to see it achieve low user adoption. Because the charts about customer satisfaction and defect resolution can be filtered by geography and time period, but doesn’t support drill-down at team level, the information pretty useless for managers looking for actionable insights to improve team-level performance.
- Unnecessarily delays and cost incurred in the migration of the document imaging system to the cloud and in future maintenance work. The team rushes to build custom features to ensure all functionality from the on-premise installation is preserved simply because there’s no one available to point out to the team of the 35% of capabilities the legacy system has are completely irrelevant for users.
What to do to prevent this kind of undesired outcomes?
As with most things, the answer is highly dependent on context. Let’s go through the options one by one:
1. Become a subject matter expert yourself.
The reason this alternative rarely works has to do more with project timeline than with the efficacy of the approach itself. If done right, it could be a successful approach, but you’ll rarely find the prerequisites fulfilled:
- Enough time to do analysis with an entire focus on the problem space. That means leaving out any assumptions about infrastructure or means of delivery–you’re simply exploring the business problem to be solved and concentrating on understanding what the new business capability should look like, free from design constraints.
- Willingness of key stakeholders (business managers and subject matter experts) to participate directly and actively in knowledge transfer and “problem discovery” activities.
For example, in the document imaging project, the BA would be granted time to speak to and observe the work of the people who interact with the current imaging system directly or indirectly in order understand the real business and user needs. She’d then start to envision the desired future state in order to clarify the problem to be solved. Even if no one in the organization is a subject matter expert in the full business capability, the BA would be able to work with the people responsible for internal document retention policies and with operational business managers, subject matter experts, and IT staff who participate directly or indirectly in the various aspects of collecting, retrieving, and disposing of documents, in order to clarify the business needs.
In practice, what often happens is that a project champion will expect all this work to fit into the originally planned requirements specification phase. This will prevent the BA from staying in the problem space long enough to understand the core business needs to be addressed before jumping into “solution mode”. For lack of business context, the BA might end up specifying requirements for an audited document approval workflow that results in a workflow history log that saves irrelevant system-related information such as “Workflow Template ID”, while ignoring critical information such as “Reason for Change” and “Review History”.
2. Insist on having a subject matter expert assigned to the project.
This would be an obvious choice, if available for the project team. Bringing up the risks of proceeding without subject matter expertise to the project sponsor may be a good way to influence this outcome.
“Have you given up on making this project a success?”, or a similar “no”-script question that plays on your counterpart’s natural human aversion to loss [1] may be an effective technique to apply here. The project sponsor will start seeing their opportunity slipping away, and want to do everything to avoid that loss–including enlisting experts to provide input.
Even if the project sponsor is only being motivated by finishing the project on time and to spec without concern for value delivery, the same script can be used with someone who would be impacted by the project For instance, asking the head of a department that uses a document approval and review process, “Are you comfortable with us moving forward with this project without input from your team about the capabilities they need?” could easily trigger the desired reaction.
3. Refuse to move forward unless option 1 or 2 can be accommodated.
This alternative is available when you’re willing and able to potentially walk away from the project if the situation doesn’t change. This is much easier to do when you’re an independent consultant, but it may also be feasible for managers or teams with sufficient control over the projects they decide to pursue.
When you can’t get any traction with the project sponsor to make the necessary changes and designate the right SMEs to the project, as an independent consultant you could say, “You know, successful customers are worth far more to me than just working on a project where we see a high risk of not being successful. So if we can’t change the rules and get a knowledgeable stakeholder to participate and make the right decisions, thank you for the opportunity, but I’m going to have to decline.”
Likewise, a BA manager might be able to take a similar stance, explaining that an analyst will not remain assigned to a project where there’s a high risk of failure due to the lack of appropriate input from experts to support the creation of reasonable requirements and promote an in-depth understanding the impacts the proposed changes will have in the user base.
# # #
It might be tempting for a business analyst to accept the situation and start working on system requirements without the opportunity to engage in discussions about what needs to be created, managed, operated, changed and discontinued in the business in business terms. This will cause the project team to keep thinking and talking in terms of building software systems, not business solutions, and will dramatically increase the risks of delivering an elegant solution to the wrong problem. A high-performing business analyst will do everything he or she can do to ensure the right stakeholders are properly engaged at the onset in sketching out the elements of a winning business solution before kicking off the requirements work.
[1] To learn more about this powerful negotiation technique, see the excellent book Never Split the Difference.