Why ‘Beyond BA’?

The world is evolving at pace – and businesses are facing more and more problems that don’t come with a standard playbook. While there are still some problems with clear solutions (we still need new payroll systems and the like!), the really important problems tend to be novel – and in this space a different skillset is required.

Having worked in consultancy roles over the last decade I have been focused increasingly within this ‘novel’ space, taming the big-hairy-undefined-problems; but I have been doing this under various labels that don’t differentiate clearly the special skills required to navigate in this space. Being described as ‘the Business Analyst’ on a project is a start – but this falls short in articulating the actual role that I play in Projects and Programmes.

‘Beyond BA’ is my term for a new discipline that moves beyond the traditional Business Analysis craft – specifically focusing on working in the world of ‘highly-undefined’ and strategic problems.

About me – Vaughan Luckman

The ‘defined-ness’ continuum

The key differentiator for what I classify as ‘Beyond BA’ lies around the concept of ‘highly-undefined’ problems. As the ‘defined-ness’ of a project changes, so does the skillset required to be effective.

In a ‘well defined’ project you might need someone who is detail-orientated and who works well in following a clear project plan (think of the implementation of a new SaaS tool for example). At this end of the continuum you would expect to find your traditional Business Analyst flourishing.

As we move up the continuum we start to see the areas where more open-ended thinking skills are needed. Here we have projects that are no longer ‘paint-by-numbers’ so they need a different approach to get to the root cause and find a solution. While challenging, there is generally a standard playbook for tackling these problems (or at least one that can be adapted).

And then we get to the ‘highly-undefined’ problems where ‘Beyond BA’ kicks in. In these scenarios progress often stalls as there is no playbook for how to attack these types of projects – so everyone stares at the problem for an age hoping that an approach magically appears!

The model below visualises this continuum – a tool that I find to be invaluable in ensuring that we put the right people on the right projects:

It is also important to note that a problem / project will change defined-ness over time – and so the project resourcing should change to match. There are fewer people able to operate effectively at the ‘highly-undefined’ end of this spectrum, so it is important to reserve them for those types of problems.

The ‘Beyond BA’ tipping point

The key thing to note about the diagram above is that it oversimplifies the line at which ‘Beyond BA’ kicks in. If all businesses were built the same, then this would be a nice clear cutoff-point based on complexity alone. But there are other scenarios that bring simpler projects into scope. These include:

• Project resets. Off-track projects bring their own complexities that rapidly drive them into the ‘Beyond BA’ territory. Often confidence has been lost (which needs to be won back), and strong leadership is required to drive the brave decisions required to get things back on track.
• Complexity. As highlighted above, this is the core factor that drives the ‘Beyond BA’ classification. Novel, highly-complex problems obviously need a different skill set to drive to a solution. In these projects my core role is to develop and execute a playbook that navigates us to a solution.
• Maturity of the business. For less mature businesses I often come in at an earlier point – effectively bolstering the ‘business owner’ role within the project. Here I become the voice of the business to represent their best interests – even when the decision-makers may not be able to clearly articulate what that looks like.
• Culture issues. It is hard to underplay the impact that company culture has on where this line falls. In a high-performing culture this line will be as close to the ‘highly-undefined’ end of the spectrum as possible – and even above it; but in a below-the-line culture (where you will be combatting silos, patch protection, inefficiency, and so on) a seemingly simple project can become incredibly complex. In this type of environment my role becomes about finding a pathway around the cultural roadblocks that are constantly trying to derail the project.
• Time constraints. Another tipping point can be time. When a project needs to be live ‘yesterday’, the approach needs to be responsibly ‘shortcutted’. In these sorts of projects I bring some key skills and experience that allow for calculated risks to be taken as we race through the project.

My approach

Focussing on the ‘highly-undefined’ end of this spectrum requires a different approach than normal. There is no ‘standard’ playbook to fall back on because I am often developing the playbook as we go! Despite this there are a number of go-to tools in my toolbox that I utilise to define a pathway through the unknown:

Tool 1: What does good look like?

I start every engagement with the same exercise – asking ‘what does good look like?’. In this I work through with the team to clearly articulate what ‘success’ will look like when we look back at the end of this project (aligned with the organisational strategy). This achieves a number of key outcomes:

• It makes ‘vision’ & ‘strategy’ real. Before focussing on the issue at hand, I get the teams to zoom out and articulate the ‘why’ of the business as a whole so that we have a clear context to work from. We can then probe to the core of this to take the jargon-filled ‘vision’ and ‘strategy’ and rework them into something practical that we can apply in real life (or define if this is missing …).
• It gets everyone on the same page. It is suprising how often teams think that they are in agreement around what they are trying to achieve – until we run this exercise! Ahead of this there are often a lot of assumptions around scope and purpose (because it’s obvious, right?) – but these assumptions are pulled out and challenged until we can get a common agreement.
• It provides a decision-making framework. As we later work on solutions it is important to have a framework for understanding that we are actually achieving what we set out to achieve. It is too easy to be seduced by a shiny solution, so having a definition of ‘good’ enables us to evaluate these options to understand if we have gone far enough and addressed the right points.

Tool 2: Balanced decision-making

Most BAs are highly analytical – which is mostly a great attribute when the core of your job is look at the options and de-risk decision making! But there is a tipping point where the analysis stops adding value – and this is especially evident when we are faced with novel problems, where it is very easy to get stuck in ‘analysis-paralysis’.

With novel / agile projects the cost of delaying a decision (while we check and check again …) is far more than the risk of pushing forward. We generally don’t know what we don’t know – and may never know until we test an approach. There is no ‘right’ answer, just a series of options that align ‘better’ or ‘worse’ with where we are trying to head.

I am a firm believer in doing ‘just enough’ analysis to de-risk decisions – and then committing to an approach. What we learn from moving to action will always be far more valuable than sitting and crystal ball gazing for an eon about what ‘might be’. The diagram below visualises this sweet spot:

Obviously the scales in this diagram will be dependent on the context (ie, a ‘quick’ decision on one project might be a couple of hours, and on another a couple of months) – but the principal remains the same: act fast with just enough due diligence to ensure the outcomes are value-add.

In each decision we are trying to prove the following to validate the commitment to move forward:

• Is this what ‘good’ looks like? Firstly, we need to confirm that this solves the problem we set out to solve. If we assess this against our ‘good’ checklist, will it deliver the outcomes we need?
• Does it solve the things that make us unique? A key part of balancing decision making is focusing on proving that this will work in the scenarios that make your business unique – and taking ‘as read’ some of the common elements. For example, if you are choosing a new CRM then you can take ‘as read’ most of the common scenarios (lead capture, opportunity management etc), and focus your time on proving that the fringe-cases will work (integration to your bespoke ERP, tiered licensing etc).
• Are we working in partnership? Another critical component to moving forward in decision making is ensuring that this is done in partnership with your vendors. For highly-undefined problems in particular, ‘moving forward’ needs to be a collaboration – not a 100-page draconian contract!

What I can bring to this decision-making process is a wide-ranging history that can help to accelerate this decision-making process (and a strong intuition around where the right pathway lies …).

Tool 3: Always questioning the ‘scope’

There are two key things that I am always questioning around ‘scope’ throughout a project:

• Are we working on the right problem? This is always the first thing to prove (and to keep proving) – ‘Is the problem that we are working on the right one?’. Someone might have had the great idea that this ‘issue’ was killing the business; but if we look at this objectively there may be better ways to be using the resources of the company. The model below is the thought process I run through when making this check. If the answers start to get vague then it’s a great sign that this might not be the ‘right’ problem to be solving.

• Are we addressing the root cause? It is critical to always be evaluating whether what we are working on will actually solve the problem. The challenge here is that making a truly honest evaluation often requires large amounts of bravery – particularly when you can see that the true root cause is a much more complex problem than the one you are currently working on! I am a firm believer in taking a project where it needs to go to achieve long-term success (not just short-term gains).

I once witnessed this scenario played out in an organisation after they stood up a project to address data quality issues. The ‘scope’ was to fix the existing data which was a great idea (on the surface) – but when you dug deeper, what they weren’t willing to tackle was why the data was in the state it was (ie, the broken processes around how the data entered the system).

So, the project was delivered to great success (on time, ‘scope’ completely met) – only to have everything they had achieved be undone within six months as the same root-cause problems continued and corrupted the data again.

By always having ‘what good looks like’ in mind throughout the project we can keep assessing these questions – and make the brave choice to do what is ‘right’ instead of what is ‘easy’.

Tool 4: Understanding the context / defining the edges

Solving these highly-undefined problems requires context – context that can only come from understanding what the business does, and how it does it.

Another early step for me in a project is to rapidly map out the value-chain and high-level processes of the business. There are three key outcomes from focussing on this:

• We can work in the best interests of the whole business. Understanding this context gives a framework for evaluating the full impact of any solutions that we begin to design. If we only look at one area in isolation it is too easy to end up making decisions that aren’t in the best interests of the business as a whole (eg, we adopt new technology when we could have used something already in use in another part of the business).
• We know where the ‘edges’ are. When we set out to solve a problem without knowing where these ‘edges’ are it is easy to take on too much (or too little!). By defining the boundaries, we can be clear on the entry points into and exit points out of the problem.
• We can involve the right people. This exercise often highlights that the thread we are pulling on goes far and wide. By clearly understanding this context we can ensure that we involve everyone who is impacted (not just everyone who is interested …). Having the right voices at the table will ensure that we go far enough with our solution.

A critical step here is also involving the key stakeholders in the playback of this work. By establishing a common understanding of the ‘what’ and ‘how’ of the business we ultimately speed up decision making as we go.

Tool 5: A phased approach

Working on novel problems can be overwhelming. Where do you start? And then where to next? Planning out this journey is key to making the outcome deliberate and to ensure that each step derisks the next decision.

To make this manageable we need to phase the approach. Designing the approach to tackling a highly-undefined problem is a bit of an artform – a lot of intuition combined with massive amounts of brute-force logic! That said, there are some key principles that I follow when designing and implementing the approach:

• Zoom out then in. There is no point in jumping into the detail unless we have a high-level plan that takes us through the whole journey. While some parts of the high-level approach might be vague initially, they give clear signposts to tell that we are on track.
• Don’t over-commit to an approach. With novel problems we don’t yet know what we don’t know – so we need to ensure that we don’t develop an approach that locks us in too tight (such that we miss much better opportunities that we couldn’t have planned for). The phasing needs to be planned in a way that encourages the evolution of our thinking.
• Remove the distractions. Projects like these can be overwhelming if we don’t know what is and isn’t important – and focus our attention accordingly. I am very protective of the capacity that I have (mental capacity and time) to ensure that I use this in a way that will support getting to the best outcome. Often this means parking a problem until later to ensure that the right challenges are worked on first (and in the right order).
• Deal with the big-ticket items first / focus on what’s unique. Similar to above, we need to understand dependencies when solving problems. Generally, this will mean that there are some key areas that need to be investigated and solved first (or else we will need to rework everything anyway!). I will normally focus on the areas that make the business / problem unique – as once we solve these well, the ‘common’ elements normally fall into place by default.
• Only add detail to the approach when it is needed. In a well-defined project play-by-play Gannt chart / project plans are really useful – but in novel projects it is an absolute waste of time. Instead, I build out a high level (and visual!) plan with clear stage gates but only add the detail to each phase of the project as we approach it – and have enough answers from the previous stage to know what will actually happen.
• Pilot and test on the way. Everything looks good on paper! I had a great manager early on in my career who helped me to understand the value of testing everything as soon as possible in the real world. It doesn’t matter how many whiteboard sessions we have, and how well we test in lab-like environments, we will never think of the reality that will be thrown at us once we ‘go live’. For this reason, I always like to build in as many ‘reality-check’ moments throughout the project journey as possible (through pilots and the like).

Tool 6: Communication is key / make it visual

When working with the types of projects that fall into this ‘Beyond BA’ category, communication and clarity are critical. Often, we are taking people on a journey that they have never been on before – and asking them to trust us about everything from the way we will get there to why it is a great idea in the first place.

When constructing any documentation or messaging around a project I come with two key approaches:

• Give the answers before they are asked. At every stage I am always working to understand the stakeholders who will be receiving the information, and writing it from their perspective / to address their needs and concerns. This often means highlighting information in different ways, or even exploring some concepts further to ensure that the concerns that the audience brings to the table are addressed.
• Make it visual. It is critical to let diagrams and visual aids do most of the heavy lifting if we are going to successfully take people on this type of journey. I know that we are successfully communicating when the project sponsor whips out the one-pager diagram to brief their peers, or when the project phasing diagram is pulled out at the start of every standup.

Tool 7: Design solutions that are grounded in reality

I often play a Solution / Business Architect role within a project – assessing and designing an overall solution that will address the points above. When developing this (eg, choosing the right software, designing future-state processes etc) it is key to ensure that the solutions are grounded in reality from the outset. The key things that I consider and use to shape the solution design process are:

• Understand the budget first. The budget is a key constraint that will shape what solutions are even on the table to begin with. This will generally define a ‘bracket’ that the design is limited to (eg, integrated SaaS tools vs an ERP etc).
• Understand the current landscape. Most projects are not ‘green fields’ – they are happening in an environment with existing tech commitments in place. Given this, the solutions need to be able to live in this world (eg, I won’t recommend adding in a Google product to a company that has adopted Microsoft etc).
• Let software capabilities moderate business requirements. It is important that we start setting the right expectations early and don’t over-promise what the project will be able to deliver. I normally go into a requirements session with some idea of what potential solutions may be appropriate (based on the budget & landscape) – and I use this to both accelerate the requirements gathering (eg, “the sorts of systems that you will be looking at will normally operate like this …”), and to set expectations (eg, “given the budget, these systems will likely not be able to do that …”).
• Actively manage trade-offs. There generally won’t be a ‘perfect’ solution – but there will be something that comes close on most fronts. In these scenarios there needs to be careful management of the tradeoffs (both articulating these, and getting considered signoff), and pragmatic decisions made. Within this it is important to also be really clear on the non-negotiable items to ensure that we don’t make the wrong tradeoffs (eg, security & compliance elements, integration capabilities etc).

Rates and availability

About my chargeout rates

The nature of the ‘defined-ness’ spectrum is that the number of people able to work effectively at each level drops off as the problems become more uncertain. So, while there are many BAs suited to working on a well-defined project, these numbers drop off rapidly as we get to the highly-undefined end of the spectrum. Once we get into the ‘BeyondBA’ territory the numbers get even smaller.

I have made a very conscious decision to be working exclusively on these ‘BeyondBA’ types of problems to ensure that I am adding the most value possible. Pricing plays a key part in making this a reality as it protects me from being hired for the wrong type of work (ie, if the pricing feels too high for what you need me to do then it is probably the wrong type of work and you should hire someone else!).

My current rates are:

• Longer term engagements = $220/hr + GST
• Short term engagements / workshops = $2,000/day + GST

Get in touch

If you have a great ‘Beyond BA’ type of project then I would love to chat! You can reach me through the following channels:

• Email: vaughan@luckman.nz
• Phone: 027 4166 177
• Linkedin: https://nz.linkedin.com/in/vaughan-luckman-4a764351