Avoiding ‘Technique Fatigue’

One of the great things about being a practitioner of business analysis is that we have access to a whole range of tools, techniques, methods and approaches. 

There is a vast ‘toolkit’ that we can tap into, and there are many excellent resources out there that we can refer to in order to learn or remind ourselves of each tool or technique.  We can assess the context of the situation, understand the constraints, and choose and blend together the relevant analysis techniques that we believe will work best.  We can seek regular feedback, and if something isn’t working, we can pivot and utilize another approach.  For example, if we unexpectedly discover that user-interfaces are an important element of the solution and we have stakeholders who think visually, we might re-plan and use wireframe prototypes alongside other techniques.

Yet the sheer variety and number of techniques can be overwhelming.  Searching through the many excellent books and resources will uncover hundreds of techniques, each of which typically has multiple different options or notations within in.  From Acceptance Criteria, to Process Modeling, to Real Options, to Use Cases to Value Chains, there are a lot of options for us to choose from.  It is unlikely that a single practitioner is ever going to be an ‘expert’ practitioner of every single possible technique (although experienced practitioners should of course have awareness and knowledge of an extremely broad set of techniques).

Here a danger awaits the unprepared.  It is very easy for us to become familiar with a ‘favorite few’ techniques, and revert to these time and time again.  We use the same old tired techniques to the point of fatigue, even if this means inadvertently shoe-horning them into a situation.  If we are completely honest, we have probably all fallen  into this pattern from time to time.  I know that I certainly have—being a fan of use cases means I’ll often revert to these automatically.  Yet, it’s important that we ask “what are the other techniques that I can use here?”, and “which is the most appropriate set of techniques for this context?”

Advertisement

So how can we avoid these dangers and avoid ‘technique fatigue’?  Firstly, it’s absolutely crucial that we make time to stay fresh.  Continuing professional development is absolutely crucial as it ensures that we don’t stagnate, and provides us the opportunity to keep our skills sharp.  This might include classroom based training, but it equally might include reading blogs, articles, books or watching relevant webinars and videos.  In the heat of a busy project, it is easy to neglect ongoing professional development—but this can actually make things worse.  Taking one hour out to learn a new (relevant) technique might mean you can conduct the analysis in the project more effectively and efficiently, shaving time off overall.  Professional development is an investment of time rather than a cost.

It’s also valuable to have resources at your fingertips.  If you’re looking for inspiration for the best technique to use in a particular situation, it is very useful to be able to flick through a few books for inspiration.  IIBA’s BABOK (and Agile Extension) are two possibilities, but there are many, many others out there too (and if you are an IIBA member, be sure to check out the IIBA members’ online library).  I personally find it is useful to create an organized list of bookmarks and references that I can refer to, so that I don’t get lost ‘Googling’ particular techniques.

If you are a member of a team of BAs, it’s also great to share knowledge with colleagues.  This might be at formal Community of Practice meetings, or it might be informally over coffee.  If you use a new technique, why not write up a quick one or two page ‘practitioner guide’ and pass it on to someone else?  This will consolidate your knowledge and experience, making it really ‘stick’, and will also create a relevant artefact for you and others to refer to in the future too.  Colleagues also make great ‘peer reviewers’, able to critique a proposed approach and the relevant deliverables too.

Finally, it is so important to match the approach and techniques to the context.  Just because a set of techniques work well in one situation does not mean they will work somewhere else.  There is no such thing as ‘painting by numbers’ when it comes to analysis, and it is important that we choose appropriate techniques from our toolbox based on the situation we find ourselves in.  Factors such as urgency, number and attitude of stakeholders, type of project, delivery approach and so forth will play a part.

Business analysis is an inherently creative endeavor.  We have so many techniques at our disposal, it’s important that we don’t get stuck in a rut!