The value of analysis comes from the Analyst

I broke my collar bone when I was twelve after a somewhat innocuous crash on my mountain bike. Arriving at the hospital the doctor asked what had happened? "I broke my collar bone" I stated with boyish pride, "no, that's my job to provide a diagnosis, I want to know what happened" came the reply.

That was my first memorable encounter with what I would later come across regularly in my career, namely being provided with solutions when searching for the route cause.

Despite my career evolving within different companies, job titles, and even countries over the last twenty years, I have essentially performed the same role, specifically communicating the current situation, and the requirements needed to be realised to achieve a desired state. Below is a somewhat abridged version of that journey.

Very early on in my initial consultancy assignment for a large insurance company, I was given a plastic template for drawing flow charts and process diagrams and asked to investigate what a particular system did. The role of Systems Analyst, which I was there to perform, was heavily focused on the software and as such the level of detail I was expected to elicit was system centric. Database tables, primary keys, and field lengths were the order of the day, communicating with end-users less so. I was the human face of a system that was kept operational but had long ago stopped receiving meaningful updates. Being able to document the current state of the system meant the knowledge now in code form written by developers long gone was able to be understood and communicated.

<< Sparx EA course >>

Much later, and with a different client where the systems were understood and documented, the concept of Business Process Re-engineering had taken hold. I had the role of Business Analyst this time and was asked to document through process flow diagrams and root cause analysis, what the users wanted to achieve versus what the system did. The difference between the current state and the desired state being the change that needed to happen for a benefit to occur. This was still very much an IT task because the outcome of the work was to optimise the IT system supporting the user's needs. The remit I had did not include looking into the entire business flow or even the system of systems supporting these needs. Everything put the system at the heart of the operation and this focus garnered a very IT vs business approach to systems development with each group appearing to speak different languages. At the time I used to describe my role as translating between the two groups.

During this period both the Rational Unified Process and Unified Modelling Language came to the forefront of systems development and the split between the requirements work and the system design was more pronounced with the definition of multiple Analyst and Developer roles in RUP. The Business Process Analyst wrote Uses Cases, Business Rules, and most interestingly the Vision document. Suddenly the focus of my role also included looking at the wider organisation and the state that that business needed to be in to successfully receive the system being developed.

<< Business Analaysis in Practice course >>

As my experience and skills within the various Business Analysis roles increased, I started to look at the impact business strategy had on the IT systems that were required to support them. So now my focus had moved from what do the systems do and how are they built, to what end users want, through to how should they be configured to enable the business to reach its goals. Frameworks like Zachman and TOGAF heightened the role of Enterprise Architecture and suddenly the Business Analyst was a strategic role within the organisation. Looking at the problem from the "Owners" viewpoint was again a different perspective than I'd previously viewed it from, and the normal questions of What and How had been replaced with Why, When, and Where, however the role was fundamentally unchanged. Requirements were documented upfront and a clear picture of what was to be delivered was in-place at the project kick off.

<< TOGAF® course >>

The advent of Agile raised several questions about the need for the Business Analyst role given it wasn't mentioned in the Scrum team. Who would now perform the requirements and analysis work?

Now that "projects" had been replaced with "products" and functionality was delivered in smaller chunks on a more regular basis the Product Owner role I found myself working in meant interfacing directly with both the development team and business. Developing roadmaps and prioritizing the backlog together with these parties in the same room meant I no longer needed to translate one perspective to another, rather simply facilitate the dialogue. Having specialist BA's developing user stories that would be taken into the backlog once they reached a certain maturity, (Definition of Ready), meant that my role was to orchestrate the flow of requirements in alignment with our capacity to deliver the roadmap.

<< SAFE Product Owner / Product Manager course >>

My latest evolution is to the role of Product Manager, where the focus is again aimed at the wider picture. I'm now using competitor and market analysis to predict the medium to long-term strategy needed to keep the product relevant within the industry and as an essential part of our clients' operations. User needs have grown to encompass market segments, and future IT trends are helping dictate the architectural runway, which in turn influences corporate policy.

One step removed from the immediate demands of the user community and systems requirements this role is a long way from the introduction I had into the business analysis world as I've seen in my career to this point. However, having now worked in various BA roles, using multiple frameworks and methodologies, through different industries, from documenting the current state, communicating the desired state, or to truly understanding the minutia, it's clear that the art of analysis remains an integral part of successful systems implementation.