How to Choose What to Use (and what not to lose)

 

As Cheryl most excellently – and tastily ::-) –   described in her recent blog, the business analysis standard will provide an abundance of business analysis practices for consideration.  These practices will be described in terms of business analysis thought processes which have inputs, tools and techniques and outputs.  When practitioners have a chance to consider so many possibilities, one of the first things that might come to mind is “How do you choose what to use?”  As a consultant, when I have been asked that question in the context of customizing a methodology, I usually start off with the classic, unsatisfying answer, “It depends”.  When the business analysis standard is available, that answer will not change, but the standard will be very, very, very helpful when you make your choices, precisely because it will be organized in terms of processes – things to think about and to do – rather than as a less structured inventory of tools and techniques or concepts. Looking at process-sized chunks will help you choose how to customize them!  And here are some other thoughts which will help you:

• In working from Cheryl’s wonderful analogy, consider the “appetite” of your project or organization for using the processes. In my own experience, I’ve seen many a well-thought-out methodology arrive in an organization and later get discarded or diminished not because it was not a good approach, but because we humans were skeptical or uncomfortable or fearful in some way about adopting it. If the appetite is low and the need is great, it’s important to think about ways to increase the appetite as well as to choose what to use. As Daniel Mezick noted in his book “The Culture Game: Tools for the Agile Manager”, it is really, really important for people to consciously “opt in” when becoming part of an agile team. I absolutely agree and I’d also offer that consciously opting in – at a personal or organizational level – is important for the adoption of anything!
• Consider how much latitude in customization is appropriate for your project or organization. I’ve sadly observed folks who used a tool or technique in a way which was not intended, and then when it did not produce the desired results, they blamed the tool or technique or the methodology which included it rather than how they customized it; soon afterward, the tool or technique or even the entire methodology disappeared. This is not to discourage customizing how you use a process to support your project or organization: after all, the processes which you will find in the standard are meant to be customized ::-) .Instead, take care that the way you customize still provides the value which you expect to get.
• Consider the costs associated with your choices for tools and techniques and how or whether you will formally document outputs.  As analysts, we usually love to be very precise, but sometimes “good enough” really is “good enough” ::-). If you are dealing with problem spaces involving health, safety or finances, your choices may need to be more formal or constrained or regulated, yet you may be able to find less costly ways to comply sufficiently, while still getting the value you expect from a process.
• Together, all the processes which you will find in the standard represent “business analysis thinking”. All are needed. Please do not totally “lose” any of them, although some may be used so very, very lightly that all that is needed is to say “yes, we thought about that” ::-).