First Things First: Get the Business Analysis Basics in Place
In a classic StickyMinds interview, Jerry Weinberg noted that there are fundamental practices that, while commonly known to drive positive project results, are still not widely adopted. The practices he listed are: requirements, reviews, and configuration management.
Weinberg goes on to say that “We have people doing better things in all these areas, but it hasn’t swept the industry.” Typically, the first two of these items fall to the business analysts, on whom I’ll focus my attention in this article.
My professional experience includes establishing new business analysis practices in four companies and what Weinberg had to say definitely rang true. While we can debate about best and better practices for eliciting, analyzing, and documenting requirements, many organizations have yet to adopt a requirements practice at all. When they do so, they will have the opportunity to realize significant benefits.
This should not come as a big surprise. We are just really seeing the formal emergence of the business analysis profession. In fact, our professional organization IIBA, just celebrated its eight-year anniversary and 25,000 members.
As I contemplated this state of affairs, I recalled a book I read recently, Training Camp by Jon Gordon. The book shares a narrative of a young football rookie, trying to make a major league team. The rookie meets an inspired mentor, who helps him balance his passion for the game with a focus on the fundamentals.
The mentor encourages the rookie to focus on the basics: catching passes, breaking tackles, and, most importantly, being mentally and emotionally prepared for the game. He tells the rookie, "Everyone thinks that success is complicated, but it's really simple. In fact, the best don't do anything different. They just do the ordinary things better."
In setting up new business analysis practices, I found myself on a similar path. I didn’t run all-day requirements workshops, and one of the most complex models I put together was a domain model using some basic UML. Instead, I focused on introducing the business analysis fundamentals:
- What problem are we trying to solve? (the question that leads you to requirements)
- What is the scope of the project and the detailed requirements? (the question that captures requirements themselves)
- Does everyone involved understand the scope and requirements? (typically accomplished through reviews)
This meant that sometimes my requirements deliverable was a click-through prototype with embedded requirements, much like the one Tony Heap discusses in "A Graphical Functional Specification." Other times it meant that I forewent a formal sign-off if I could validate understanding through nods of approval or even IM or email.
Sure, there are sophisticated techniques for answering these questions, and you could select any one of many methodologies to give you a path to discovering and documenting the answers. But asking and answering the questions, in any form, takes you a big step forward.
Is your organization doing requirements work and hosting the necessary reviews? Do you have answers to these basic questions? Or, do you find yourself more concerned with the latest modeling technique or software tool?
