Defining and Distinguishing Between the Solution Effort and the Engagement Effort
There seems to be a great deal of confusion in describing what business analysts do, since they often seem to be doing such different things. I’ve confirmed this after having taken a number of surveys of business analysts. I’ve also seen close to fifty presentations on the subject, taken a training course, earned a certification, followed a whole bunch of discussion on LinkedIn and elsewhere, and reviewed job ads until my eyes bled. I’ve thought about this subject a lot over the years and the answer has finally become rather clear to me.
I’ve worked through a number of engagements of various kinds. They’ve ranged from small to large, quick to long-lasting, and very ad hoc to very formal. What I noticed is that the smaller, shorter, less formal ones all involved the same activities as the larger, longer, formal ones, it’s just that they didn’t include every possible activity. And therein lies the discovery. I call it the Unified Theory of Business Analysis.
The reason so many BA efforts feel so different is because many efforts either do not include every activity, or because any one BA may only be involved in a limited part of a larger effort. This is true with respect to the multiple phases of an engagement through time, and to the multiple components of a solution’s scope are addressed.
I’m convinced that all of the phases of a full scale engagement are actually conducted during even the most slap-dash, ad hoc analysis effort. However, in many cases the context is so well understood that many of the steps I define in my business analysis framework are addressed implicitly to the point where no special effort is taken to do everything you can do in every possible phase. You could have a big, formal effort with kickoff and close-out meetings for every phase, or you could hear that Dwayne in shipping hates the new data entry screen and why don’t Diane and Vinay shoot down, find out what the confusion is, and put together a quick fix for him. In the latter case the Intended Use and Conceptual Model model phases are obviated and the remaining phases can be accomplished with minimal oversight, time, and fanfare. If an effort is simple enough it doesn’t require the overhead of requirements traceability matrices, change control boards, and a bunch of documentation (though the right people should be involved and the relevant documents and systems should be updated).
This is why things look different to BA practitioners and their managers and colleagues through the phases of an engagement through time, but it’s also possible that BAs will only be involved in a limited part of the solution effort, as I discussed and defined yesterday.
In short, I wanted to introduce this discussion be distinguishing between the solution effort, which is the process of defining and implementing the solution, and the engagement effort, which is the meta-process of managing the phases that support the solution. It may seem like a subtle distinction but it seemed important to me as I prepare for the next part of this discussion.