I recently presented at the European Business Analysis Conference in London on the topic of understanding the business problem. This article is a follow up to that presentation which could be summarised as “OK, so now I understand the business problem, what do I do with it?”
By: David Beckham, Senior Business Analyst, Aviva Life, david.beckham@aviva.co.uk
In my long-ish career as a BA (16 years and counting) I have learnt many important lessons and one that is pertinent to this article is “To know what you are doing is good; to additionally convince others you know what you are doing is better”. I’ve learnt this through occasionally painful experience when I’d thought everything was going fine because I knew what I was doing, I had a framework, I had a plan and a goal to work towards. Unfortunately my stakeholders didn’t agree for the simple reason that I hadn’t taken the time to explain it to them. It’s no good being good at your job if you don’t assist people to see how good you are! So now I’m going to share a few ideas in the hope it will be of some help in your everyday activity.
Have a Framework
At the conference I was asked for my view on “what is best practice?” What a great question! My possibly not-so-great answer was “There is no such thing as best practice; you should think about what is the best practice for the moment you’re in”. It’s very easy to get dogmatic as a BA, relying on the same approach, method or technique that got results last time. However, things do not remain the same for long and what worked last week will not necessarily work tomorrow or even today. Having said that, most change initiatives go through the generic evolution of understand the problem, define the requirements, build the solution, test the solution and implement the solution. Each stage in this evolution has certain practical techniques that will work for you such as process modelling, CATWOE etc. So eventually you have a high level framework to work within which applies to both waterfall and agile projects. Remember, I’m not trying to use the exact words that a specific method uses, I’m trying to sketch a generic framework for your thinking. So you now have one component of your analysis framework, which I shall call the Delivery layer.
But the delivery layer is only one part of the framework you need to develop. In addition to all the delivery stuff i.e. process models, user stories, NFRS etc you also need to factor in all the stuff you have to do because you are doing the delivery stuff. In other words all the admin stuff like create backlogs or change control mechanisms, update benefits cases, attend budget gating meetings, review documents, create project websites, developing a requirements plan etc. It’s onerous and often invisible to the stakeholder but it is imperative it gets done. Let’s call this the Organisational /Method layer.
Finally you need to consider all the talking and schmoozing you need to do to get the project delivered. This includes explaining your approach to the PM and stakeholders, explaining the particular methodology of the moment to stakeholders, building a stakeholder map should you need one, devising a communication approach, explaining your communication approach, personally updating individuals if required, booking appropriate briefings or catch-up’s etc. I call this the Diplomacy layer and it is just as important as the previous two. Being a BA can be a Machiavellian task at times and whilst I’m not advocating a life of Renaissance intrigue you have to be aware of and navigate the local or global political and cultural waters you are sailing through. A good BA observes the landscape they are operating in and adapts their strategy accordingly.
So the final framework looks something like this:
Delivery is at the core of the framework but is surrounded by the organisational activities or those predicated by the method you use. Finally the whole thing is wrapped in the diplomacy skills you bring to the assignment, thus ensuring a coherent whole. Bear in mind that this is only a suggestion and I am not dogmatically advocating it for everyone. My point is that as a BA you need to get some form of framework that works for you and flex it as appropriate for your current assignment and deliver what the stakeholders really want.
So, what do stakeholders really want?
In my experience Stakeholders want the following:
- Someone to tell them their idea/proposal is sound
- Someone who can tell them how their idea/proposal can be improved to their advantage
- Someone who can tell them how to get it delivered
- Someone who can tell them how to get rid of the things that are stopping it being delivered Delivery Diplomacy Organisational/Method Someone who can tell them how close they are to getting it delivered
- Someone who can stop them looking bad
As you may appreciate, being the person who can do all this does not primarily rely on being a waterfall guru or an agile expert. It relies on having a framework that allows you to deliver all these aspects of their expectations of you which is a combination of technical, organisational and diplomatic. Each aspect of the framework is a part of a greater whole and should be balanced evenly; a delivery expert who can’t deal with his stakeholders is as ineffective as a consummate diplomat who doesn’t know one end of a requirement from the other.
Conclusion.
So to summarise, it is my contention that every BA should develop a framework based on their own (sometimes painful) experience that they can loosely apply to each situation they face. Such a framework should contain both technical and soft skills and should be constantly reviewed rigorously for improvements or additions that can make you an even better Business Analyst. But remember, there is no best practice, just the best practice for the moment.
About the Author
David Beckham has been part of Norwich Union/Aviva Life since 1986, starting off in various types of pensions administration before joining the project world in 1994. From there he moved into Business Process Re-engineering and subsequently a formal Business Analysis role when the BA Practice was formed in 2001. He became Practice Lead in 2003 before leading the business requirements analysis on several major change programmes including Pensions Tracker, Pensions Reform, Adviser Charging & Workplace Savings. He recently completed his second stint as BA Practice Lead after devising a coherent BA Practice operating model, instituting BA career development paths and building the capability of the Practice to match the current demands of the insurance industry and ever changing customer needs.