Author: Adrian Reed

Adrian Reed is a true advocate of the analysis profession. In his day job, he acts as Principal Consultant and Director at Blackmetric Business Solutions where he provides business analysis consultancy and training solutions to a range of clients in varying industries. He is a Past President of the UK chapter of the IIBA® and he speaks internationally on topics relating to business analysis and business change. Adrian wrote the 2016 book ‘Be a Great Problem Solver… Now’ and the 2018 book ‘Business Analyst’ You can read Adrian’s blog at http://www.adrianreed.co.uk and follow him on Twitter at http://twitter.com/UKAdrianReed

Making the Most of BA Training

Written by Adrian Reed on January 24, 2019. Posted in Articles.

One topic that is relevant for us as BAs wherever we are in our career is the topic of professional development.

Professional development is relevant for those joining the profession, who need to get to grips with the core skills, as well as those who are experienced who need to refresh their knowledge or keep up to speed with new techniques or developments. Business analysis is an evolving field, and staying up to date is absolutely crucial. Continuing professional development takes a number of forms, both formal and informal, can include anything from reading blogs and articles (on sites such as BATimes.com), attending IIBA chapter events, participating in webinars, mentoring, running or attending ‘lunch and learn’ sessions and of course attending a specific BA training course.

At this point, those of us that have been around for a while will probably be rolling our eyes. I’m sure we’ve all attended or have been sent on the occasional training course that hasn’t been effective. It’s very easy to attend a training session that is logically designed, fun to participate in, but that makes absolutely no difference to our day-to-day practice. You might have even been on courses where the only highlight was the coffee and doughnuts.

It absolutely doesn’t have to be this way! Training, alongside other professional development activities, can be useful and effective, if we plan effectively. Here are some points worth considering.

Use BA techniques to establish the need: We have a whole range of BA techniques that can help us establish needs and requirements in an organizational setting. These same ideas can be used for an individual or team too. We can turn our analysis on ourselves and carry out a SWOT analysis, understand key skills gaps, and then translate these into requirements. If we notice a particular skills gap in our team we can then research, assess and decide amongst multiple options for plugging that gap.
Training isn’t the only solution: As discussed above, training is by no means the only ‘solution’ to a skills gap. It’s easy to overlook the wide range of resources at our disposal, and often there’s a wealth of experience that exists within organizations. If you are lucky enough to be part of a Community of Practice, it may be that you can use Community of Practice meetings to exchange knowledge and build skills in a safe environment. Training is absolutely useful, but it is most useful when blended with other techniques that support it.
Own the plan: As BAs we need to own our own professional development. Even if you are lucky enough to work for a company that will send you on training, it is still worth having your own (personal) development plan, based on your own goals. Of course, like all plans, it should be malleable and fluid—but it shows the broad direction of travel at any point in time, and this can help figure out immediate next steps.
Choose the provider carefully: If you are booking external training, be selective with the provider you choose. Ask questions like “will the trainer be an experienced BA?”, “When was the last time they worked on a project assignment?”. If you are running the course on-site for your team you might want to ask “Can you customize this course so that it is relevant for our context?”. Ask around your colleagues and network to find out which training providers they would recommend.
Training starts before the day itself: Training is likely to be even more effective if we are able to come prepared with ideas, questions and ‘real life’ dilemmas and situations to discuss. Keeping why we’re attending the training in mind, and assembling these ideas in advance can be very helpful.
Commit to action: During the training, after each technique or concept is covered, it is worth consciously considering aspects such as:
- In what situations can I use this?
- When is my next opportunity to use/practice this technique?
- What are my next steps?
  Using a brand new technique in a radically different way for the first time is sometimes tricky, so you might choose to use it in a team meeting, or some other ‘safe environment’ first. More routine techniques can be picked up straight away.
Ask ‘when will I revisit or re-read my notes’?: Learning can be great fun, and revisiting old training material can help us to refresh, reflect and jog our memories.

Training can be a useful professional development tool when chosen carefully and executed well. Questions such as the ones above can help us in choosing the right course and getting the most from it. I hope that you have found this useful, please do get in touch with any other tips that you have—I’d love to hear them!

The Courage to Ask the Obvious

Written by Adrian Reed on January 10, 2019. Posted in Articles. 2 Comments on The Courage to Ask the Obvious

One thing that Business Analysts are known for is asking questions.

We ask a whole variety of types of questions throughout the business change lifecycle—some help us understand why a particular change is necessary, others help us understand the nature of problematic situations and potential causes, others help us better understand stakeholder needs—and of course there are many more besides. Stated like this it sounds easy. After all, what could be easier than just asking a few questions? That sounds like trivial work, surely?

However, as I suspect most people reading this would attest to, it is anything but trivial and in some contexts it can be very tricky indeed. This can particularly be the case when we are dealing with a group of stakeholders who have a greater depth of knowledge of a particular domain than we do. Of course, as business analysts, it’s important that we have or gain sufficient domain knowledge for the particular assignment, but there will always be domain subject matter experts who have in depth knowledge that we don’t. We might have a good understanding of how a financial services company operates, but there will still be many specialists (including actuaries, compliance, legal representatives and many others) who have deep knowledge that we will need to tap into. This can lead to a nerve-wracking situation where we want to ask questions that we fear will seem so obvious to our stakeholders. Particularly if we are faced with a group of senior experts, we might hear our internal voice saying “You can’t ask that! You’ll lose all credibility”.

The Importance of Being Prepared: Research

Credibility is an important consideration, and it is crucial that we do our homework before engaging in these types of situations. If we’re parachuted into a new domain, spending time reading through everything that we can get our hands on can help us to get up to speed. This might involve scanning through existing project document, intranet sites and also broader internet research. Personally, I find it very useful to put together a personal ‘glossary’, highlighting terms that are relevant for the particular project, and also those terms that seem problematic. This is also a great place to capture department-specific acronyms that might cause confusion.

A broad desk-based fact-finding exercise can often help shape the questions that we ask. We start to get a sense of the context, the goals of the projects and the stakeholders. We start to uncover ‘unknown unknowns’ (things that were completely off our radar), and we can better prepare for workshops and interviews.

Having the Courage to Ask

It is far easier to feel confident with this type of adequate preparation. As the old adage goes “to fail to prepare is to prepare to fail”, and it is amazing the effect that quick, targeted preparation can have. In particular, having created a ‘rough and ready’ personal glossary (which may end up forming part of a project glossary), it can be easier to spot when people are using a particular term differently than we expected. This might mean that we have misunderstood the meaning or that different stakeholders have different understandings. This is one example of where asking the obvious can be very beneficial. Take a term like “customer”. I mean it’s obvious what we mean by customer, isn’t it? Or is it…?

In reality this is one term that is often used very loosely in organizations, and there can be inadvertent clashes in communication. Imagine a hotel that hires meeting rooms to a training company. Who is the customer? Is it the person that makes the reservation (the administration team at the training company), the person that is invoiced (the accounts payable team at the training company), the person who runs the training (a freelance trainer) or the people attending the training (independent delegates). Depending on your perspective it could be any—or all—of these. If different stakeholders were using this term it would be important to determine which they meant! This is anything but obvious.

Of course, seemingly ‘obvious’ questions are not limited to clarifying terms and stopping crossed communication. Sometimes asking seemingly simple questions (“Can you tell me who uses that output?”) will uncover that certain tasks can be optimized for efficiency (“Turns out nobody does, let’s not produce it!”). When these types of questions are asked sensitively—with a foundation of domain knowledge and research—it can help increase our credibility as we add clarity to the situation and help co-create improvement.

So, whilst some of us might find it nerve-wracking to ‘ask the obvious’, it is absolutely crucial that we do so. We might just prevent a major miscommunication and help facilitate a much better collective understanding of the situation!

Avoiding Analysis Paralysis

Written by Adrian Reed on November 27, 2018. Posted in Articles. 1 Comment on Avoiding Analysis Paralysis

As practitioners of business analysis, we have a wide range of tools at our disposal.

A quick internet search will uncover hundreds of tools and techniques that we can use to understand our organization’s current situation, diagnose any problems, search for opportunities, understand organizational and stakeholder needs and help to achieve the outcomes that our stakeholders are aiming for. Some of these tools are very lightweight, others are far more detailed and structured. Our organizations might mandate certain approaches or methodologies that suggest or imply certain techniques are used in a certain order, but it is still for us as practitioners to choose the right tool for the context we find ourselves in.

With so many techniques at our disposal it is very easy to find ourselves like the metaphorical ‘kid in a candy store’, there is always more analysis that could be done! It is always possible to draw another model, or to refine an existing model. Or to polish an existing document or think of another exceptional scenario that we should plan for. I know I am certainly ‘guilty’ of zooming in to a diagram time and time again to straighten every line and align every single box. Perhaps this is valuable in some contexts, but in many this really is overkill.

This is a difficult balance that many of us face as analysts. It seems that we are inherently ‘wired’ to embrace the detail. To polish further, to ask ‘what if…’ and ‘what could go wrong?’. Yet there is a law of diminishing returns. Doing any appropriate analysis well will de-risk a project. Doing more analysis will likely de-risk it further, but eventually we get into ‘analysis paralysis’. The additional effort required to reduce risk is so great we actually create more risk by causing unnecessary delays (which delays any potential benefit and risks our competitors overtaking us). Ever had stakeholders express skepticism about business analysis because it will ‘slow things down’? Perhaps they’ve experienced ‘analysis paralysis’ in the past…

Focusing on what stakeholders value

In order to avoid this pattern occurring, it’s crucial that we spend time truly understanding the outcomes that our organization and its stakeholders value the most. This includes understanding the type of change being proposed and the amount of risk that they are prepared to take. If we’re making a small, low-risk, predictable change to a single process, the best approach might well be to do some quick impact assessment and providing the business accepts the risk, then just do it. Quickly defining and implementing the change in a controlled way will be our best way of learning and understanding how customers react to it. If the project involves safety-critical changes to a manufacturing process then more detailed analysis is likely to be appropriate.

A key point here is that it is absolutely crucial that we spend time not just talking requirements but also talking outcomes and risk appetite. After all, it’s crucial that we remember that stakeholders don’t particularly want our requirements artefacts. They don’t want story cards or well written entries on a requirements management system. They want delivered, valuable change… and the approach that we take should navigate them towards this. Carrying out just enough analysis at the right time is crucial. However, this is easier said than done!

It’s all about context

The analysis approach that we take and the tools that we use will affect the level of project risk. What is appropriate depends a lot on the organizational context. As practitioners we need to ‘own’ these decisions. It is easy to assume that ‘we’re following xyz methodology therefore we must use << a particular technique>> and we must do << a particular set of activities >>’. Yet in the vast majority of cases, these methodologies provide a guide, a ‘backbone’ on which we can add to (and subtract from) depending on the particular circumstances. Considering the two outcomes below, I’m fairly sure a sponsor would value outcome X over outcome Y:

Outcome X: A project that delivers all anticipated outcomes and benefits, delivered on time

Outcome Y: A project that rigidly followed a prescribed methodology

Of course, these are not mutually exclusive outcomes and I am not arguing against structured approaches. However, we should use structure deliberately and when it makes sense. In complex and complicated environments there is no ‘one size fits all’ approach. Along with our project colleagues, we need to be prepared to adapt, learn, and have a laser-like focus on the outcomes that our stakeholders want.