I started doing “business analysis” before I knew there was such a thing. We called it “Getting the requirements” or “Making sense of the requirements” or (often) “Who came up with the requirements (and the schedule)?”
I read books, went to conferences, thought a lot, and tried things out. A decade later, here’s how things typically go, when the client and I jell as a team, and I do it right, and it works.
By “works,” I mean the new (usually software-enabled) business process has been running for a while, and all stakeholders (including the makers and the person who paid the bill) are saying, “I’m glad we did that. That was worth more than it cost. Let’s do another one!”
So, here’s the candidate pattern.
- A would-be sponsor comes to me with an idea—a What—and a desired (Target) cost and deadline. Their idea is often either:
- Quite tangible—a screen sketch on a napkin–or even too tangible for this stage, i.e. wireframes from marketers and designers, or
- Quite abstract, except for one thing—“We need a mobile app! Yesterday!”
- Using questions and active listening, I help my would-be sponsor back up to Who and Why? Who’s going to use the new or changed product or process? Why would they want to do that? Why would you want them to do that? (Be careful with literal “Why.” It can feel confrontational).
- I then lead an examination of possible Whats that might satisfy the Whos and Whys, from four perspectives, using another pattern, the Merry-Go-Round™ :
- User Interface (UI)
- Data / Information, and
- Rules / Constraints.
- Most often from the Rules and Data, I infer additional Whos affected by the proposed What. Often they are not clearly beneficiaries. What additional changes, either part of the What, or alongside it, are needed to make them whole?
- I then see that an Estimate of cost and timeline is prepared, independent of the Target from #1. Target-Estimate-Commitment is another pattern I’ve observed and use.
- If there’s still too much uncertainty regarding the cost and benefit of the What to proceed, I then recommend where we should “buy a vowel” (a metaphor from the decades-long American game show, “Wheel of Fortune”), typically in one or more of Team, Technology, and Requirements.
- For Team, that means actually doing a bit of the work, end to end, to help them jell and get a sense of velocity.
- For Technology, that means a Proof of Concept, especially if we’re going to bring in something new, e.g. commercial software.
- For Requirements, that means further elicitiation and analysis of those portions of one or more of UI, Function, Data, & Rules where the cost / benefit sensitivity is greatest.
- I then provide decision support for a Commitment regarding the Essentials, Value-adds, and Delighters (Kano model) of the What, helping tie those back to Whos, their goals, and the associated costs and benefits (from the Estimate, with associated ranges and probabilities). I encourage variable-scope thinking. Resources usually are more tightly constrained than scope, and those constraints need protection from the remaining uncertainty (and there’s always more uncertainty than we would like, particularly if it’s potentially a high-impact What).
I have a typical Implementation pattern too, but that’s Out of Scope for now.
That’s how Business Analysis usually goes for me. Like all potentially robust patterns, it’s come from observation, not prescription. I didn’t read or decide, “This Is How It Goes.” Rather, I’ve observed, “This Is How It Usually Goes When It Works Well.”
I hope this candidate pattern works well for you, too. I believe it’s only a real pattern if it’s worked three or more times for three or more people. Please share your stories!
I’ll add two pictures when I get the time. That might make the pattern easier to see.