Moving Away from the Omniscience of Project Managers – the Road of the Business Analyst and Their Toolkit, Less Travelled…

Silo busters, change advocates, critical thinkers and absorbers of the pains and confusions of complex operations; business analysts are all these, but foremost for me is the part of the project that I believe makes or breaks its success – requirements. A BA works on the requirements of a project with the aim that everyone involved has a stake, understands what’s being asked and can trace prioritised needs and decisions (which change as limitations and opportunities arise). So much gets asked of a set of requirements and so it should, the requirement set will be used to validate whether the final project is ‘done’. Where previously the project plan was the focus and thought to be the means to achieve a successful project, agile has shifted us to autonomy and away from the omniscience of project managers to getting what we deliver right.

How does a BA get to that hallowed set of requirements? The toolkit I’ve  built through experience includes:

·        Stakeholder Analysis & Management

·        Investigation Techniques

·        Gap Analysis

·        Process Mapping

·        Requirements Engineering

Stakeholder Analysis & Management

The journey begins by identifying the key people involved in the process. Once you have a good level of confidence that the key majority have been found (which can grow as you understand more, but doing a RASCI and coms plan so you don’t have a cast of thousands present when a targeted group is required), then the collaborative group or ‘we’ has been established. The next step is to communicate – listen, inform and challenge in equal measure, the aim is to get agreement: on definitions, on processes, on scope. Conflicts can pop up, that’s where negotiation skills come into play to keep the boat steady. After that, it’s all about engagement – getting stakeholders actively involved and feeling heard, breaking down the boundaries to always get attendance from the delivery team at stakeholder meetings and support them to be heard – it’s a quick way to identify ambiguity, identify red flags and clear up confusion. This is all before we start the workshops, where we bring everyone together and diligently record what comes out of these productive sessions.

Investigation techniques

The business analyst’s bread and butter is to investigate business situations and determine where the issues and problems lie. We do that mainly via collaboration but there are a number of useful methods to help uncover and analyse root causes before we jump to workshops and focus groups. Surveys offer a scalable method for gathering quantitative data and trends. Observation allows for the unobtrusive study of actual work processes, unveiling hidden issues and opportunities. Shadowing grants an intimate view of individuals’ activities and experiences, offering empathy-driven insights.

Document Analysis allows for a comprehensive review of existing materials: streamlining information and improving document management. Activity Sampling provides valuable insights into the frequency and duration of tasks, helping to identify areas for optimisation.

Storytelling brings qualitative data to life, this is often called the ‘user journey’ or the ‘customer journey’ but is not restricted to users alone, it offers a rich narrative for analysis. I think this is a great leveller as we can all tell the story of our job and the conversational tone is accessible, I believe it’s a humane approach to asking questions.

Prototyping enables the visualisation of concepts and is a really useful thing to take into a workshop, as not many thrive when faced with a blank page.

Gap Analysis

We begin by assessing an organisation’s current state (AS IS), thoroughly examining its existing processes, performance, and capabilities. We then review the vision of the desired state (TO BE), where objectives and ideal scenarios are clearly defined. The core objective of gap analysis is to bridge the gaps, discrepancies, or misalignments between these two states, identifying the critical areas that require intervention, improvement, or change to achieve the envisioned future state. This is frequently done at the beginning of a project but is even more useful when done as part of the business case for the work before it starts.

Process Modelling

Some work begins and ends at the activity level, what we do and how we can do it by shedding light on the intricacies of workflows and systems. By visually mapping out processes, the ‘how’ of day-to-day activities can be demystified, and bottlenecks and inefficiencies are exposed, which clarifies the steps that need to be taken to do things productively. Being able to show a process model provides a shared language for stakeholders to understand and discussion can be had in the same, understood terms.

Requirement Engineering

All this activity and we haven’t even mentioned a very big challenge of any organisation looking to improve through change. There is an anecdotal phrase that gets repeated often, that 80% of errors are introduced at the requirements analysis stage. So we know we need to pay attention that all of the good work we have done to this point gets represented correctly. Agile has gone a long way to address the analysis paralysis then can choke any change work before it starts, but if we know that silos exist then we also know that the time and effort to get trained up and apply agile consistently impacts getting things delivered. So whether we see requirements in terms of User Stories, Use Cases, General Requirements, Technical Requirements, Functional Requirements, Non-Functional Requirements, User Requirements Documents, or System Requirement Documents your BA will seek the clarity that’s needed and guide all involved to be using the same terms and work with all parties to ensure delivery and positive change.

Deploying an individual equipped with a business analysis toolkit introduces a range of skills, techniques, and methodologies for an effective and honest analysis of your current state of play (AS IS) which can lead to identifying fast business process improvements (‘Oh we do it like that? I had no idea! Why? We can change that tomorrow first thing’), and the identification of longer-term improvement opportunities (‘Once we have changed that process, we can finally access the information we have been struggling to get for years!’). Recommendations for solutions to enhance organisational performance become more than high-level business strategy, they have real-life examples underpinning them. Your stakeholders have somewhere to go with questions, and suggestions and get the engagement, and change is managed, communicated, has strong decision-making at its core and is not imposed, confused, or not communicated. Your PM no longer has to do all of this on their own, switching from detail and activity plans to high-level process and strategy. Having a BA signifies an organisation’s dedication to continuous improvement and adaptability, which should allow an organisation to seize new opportunities, but more it makes clear why the journey is being undertaken in the first place.

Reading through these methods might well highlight some of the pain areas you are feeling in your organisation, so consider that a business analyst could help, and if budget doesn’t allow a new hire then there’s always a project manager looking to diversify their skills. I was.

#ba #businessanalysis #businessrequirementanalyst #ils #integratedlogisticsupport #logsiticsupportanalysis #lsa #integratedproductsupportanalysis #ips #productsupportanalysis #psa #businessprocess #businessprocessanalysis #businessprocessanalysis