A good way to define the problem/opportunity is to interview each stakeholder individually for an hour, with the first 30 minutes covering “what’s the problem?” and the second 30 mins covering “what would good look like?”
Usually, these two halves of the interview should be roughly complementary.
During the interview, the stakeholder may suggest that you interview other people you had not realised were stakeholders.
For each interview, convert the interview notes into an Assessment diagram where you seek to identify causality between any information provided by the interviewee.
For example, Finance might provide you with three observations (Assessments)
- Difficult to create budget estimates for OPEX
- Manual effort required to obtain project spend to feed into Fixed Asset Register management
- Difficult to obtain accurate OPEX and CAPEX estimates for IT projects.
If you decided with Finance that perhaps item 3 heavily influences items 1 and 2, then you might create an Assessment diagram as follows.
You’ll also notice we’ve added Drivers. Drivers are the high-level topics to summarise the problem space definition for a stakeholder.
Refine the meeting notes and Assessment diagram until the stakeholder is satisfied, and agree causality between Assessments with the stakeholder.
After we’ve interviewed Finance, we might interview IT. This second IT interview diagram might look like the following.
Continue with all the interviews until you have notes and a diagram for all stakeholders.
Then, attempt to consolidate key feedback from all interviewees into a single top-down summary of what seem to be the most critical points.
In consultation with Stakeholders, define Goals that you believe will fix the problem, and take a step towards the “What does good look like?” vision (that was part of your stakeholder interviews).
Note at this stage, you haven’t defined how you’re doing to achieve the Goals, just what the goals are.