My Typical Business Analysis Pattern

Posted by Robert Merrill on January 16, 2014 under Business Analysis and Requirements, Requirements Merry-Go-Round | Be the First to Comment

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.

  1. A would-be sponsor comes to me with an idea—a What—and a desired (Target) cost and deadline. Their idea is often either:
    1. Quite tangible—a screen sketch on a napkin–or even too tangible for this stage, i.e. wireframes from marketers and designers, or
    2. Quite abstract, except for one thing—“We need a mobile app! Yesterday!”
  2. 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).
  3. 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™ :
    1. User Interface (UI)
    2. Function
    3. Data / Information, and
    4. Rules / Constraints.
  4. 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?
  5. 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.
  6. 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.
    1. For Team, that means actually doing a bit of the work, end to end, to help them jell and get a sense of velocity.
    2. For Technology, that means a Proof of Concept, especially if we’re going to bring in something new, e.g. commercial software.
    3. 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.
  7. 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.

Should Business Analysts be responsible for cost / benefit along with requirements?

Posted by Robert Merrill on January 12, 2014 under Business Analysis and Requirements, Estimation, The Quantitative BA | Be the First to Comment

If you’re too busy to read this, please complete the 10-question survey by Friday 1/17/2013 instead!


Practitioners of Business Analysis, as represented by the International Institute for Business Analysis® (IIBA®), are following in the footsteps of Project Managers and the Project Management Institute (PMI®). BAs want to expand and professionalize their discipline. They believe, and I agree, that there’s more to Business Analysis than developing software requirements.

What I see the IIBA® not yet emphasizing, and Business Analysis practitioners not embracing, is perhaps the highest-impact expansion of the Business Analysis role: Cost / Benefit analysis of concepts, before they even become projects.

Expectations of implementation cost and schedule form early. By the time a project is approved and a Project Manager assigned, these expectations are hardening. The result is often an “aggressive” schedule, with all of the associated downstream problems I present on SlideShare in Room to Breathe: The BA Role in Project Commitments (my 2010 presentation at WI BADD®).

As the first person “on the ground” from the delivery team, the BA is uniquely positioned to help shape expectations of cost, schedule, and benefit, as well as requirements, into something achievable. Estimation, business cases, and cost / benefit analysis are hinted at in the BABOK®, but they are not emphasized. Further, many BAs limit themselves to the subjective—requirements elicitation and analysis—and leave the numbers in a vacuum. Nature abhors a vacuum, so numbers—often optimistic cost and benefits to get the project approved—appear from somewhere, and become a check that the delivery team has to cash.

I’d like to revisit this topic for my 2014 presentation at WI BADD®, and I’m seeking feedback everywhere I can. Please complete my survey by Friday 1/17/2014, and comment below.

Should BAs be involved in creating these early numbers? Do they have the skills and knowledge to do so effectively? Would it help their careers?

If you want to go into more detail, please complete my  Project Estimates and Cost / Benefit analysis.

I’d like to propose and give the most useful talk I can at WI BADD®, and my proposal has to be in by the 20th. Thanks!