Business Context and Environment
Working as a contract business analyst for many years now, I have seen my fair share of different size and shaped businesses. As much as I think I have seen it all before there is always something that surprises me when I start working for a new client.
Luckily one of the key skills of any Business Analyst is to land on 2 feet no matter what is thrown at them. When I used to interview staff at one of the most “flexible” companies I ever worked for, I would ask the potential business analysts the following question – If you walked into a scoping workshop and asked the sponsor what the objective of their new project was and they answered “Awesome Invoicing” – what would you do? The most common answer I received from skilful applicants was that they would start to work through the current state and ask what would need to happen to make their current invoice an awesome invoice (future state) – i.e. defining awesome.
Unfortunately, this situation happened to me on my first day at a new company and no matter what angle I tried or technique I pulled out from my business analysis hat, the best response I was ever going to get from this person was variations of the word “awesome”. A few weeks later I found out the sponsor of the project had previously worked with a large consulting firm who had analysed and predicted huge savings if invoicing was made awesome. The only issue with this report was we now knew what the problems were and how much they were costing the business but had no idea of what the detailed current state was and no analysis or design to resolve these issues. In addition to this piece of business context, I also found out later that this sponsor didn’t think there was any value in going over what they wanted again with a new BA (I had replaced a previous staff member) and all they wanted to do was go straight into talking about delivery. It was clear to me, being the most experienced BA in the company, that business did not know what BA’s did and how they could help.
Secondly, being a team in IT meant that whatever method we tried we were allocated once a project started to implement a solution – not defining the outcomes or upfront requirements. Knowing the personalities, environment, financial position and culture of the business you are working for is vital if you wish to gain understanding and insight into the enterprise. This can be vital to maintaining your own existence on a piece of work or at least your integrity.
Understanding the specific business context is not mandatory initially but can speed up your analysis and help you gain the respect of the business users you are going to be working with. When first assigned to a specific piece of work it is important to know how your cog affects the machine.
We as Business Analysts exist to facilitate, analyse, elicit and translate requirements into solutions but I equally think we are organisms of the enterprise that need to appreciate how our future state changes impact other projects and the business environment not just within our project scope. If we are to do this effectively, we need to define our requirements using the building boxes of any business – in the next blog post we will talk about business entities!