The Ultimate Guide to Business Analysis Tools & Techniques for 2022

Preface

Hi all, I have wanted to put together a consolidated set of approaches and tools for sometime now so I've finally put it together; a few techniques I've learnt which when you put them together, are a comprehensive way of applying business analysis in a logical sequence to ensure you build from the problems right through to delivery.

‍

The focus in this article is around either process or technology based solutions but the methods up until that point are applicable to any type of opportunity to make improvements to your business.

‍

Identifying Problems to Solve

The HCD (Human Centred Design) method has been successful with google. The first step is identifying a group that we want to help solve a problem for. The session is not a sales pitch so we’re not trying to look at this prospect or customer through the lens of our own existing products and services, it's about empathising.

‍

Knowing that the customer doesn’t know what they want but they normally know what they don’t want and maybe in there lies the problem worth solving. Apparently, if the art director of Cirque Du Soleil had listened to what customers wanted, they’d have to do Swan Lake every year so, knowing that unless they’ve seen it before they can’t ask for it, it’s entirely up to you to create something original and surprising that adds value (a good definition of Creativity) is up to you and your team.

‍

Defining the Problem Scope

To articulate it on a page as a definition, I’ve found the IRCP method to be effective because it provides enough space to come at the problem from all angles including what it would mean if the problem no longer existed.

‍

Designing a Solution

Whether you are working in a group or by yourself, start with the HMW method (How Might We) so that you maintain focus on specific aspects of the problem that you’re trying to tackle. Beyond reaching a consensus within a team setting, try not to design by committee, the consensus approach (trying to please everyone) invariably results in the average of everyone (nobody really that pleased with the end result).

‍

Remember to try to be original, surprising whilst adding value - something that delights the user will mean they embrace it wholeheartedly and it does your brand the world of good.

‍

Draw, sketch, video, scribble, doodle - whatever it takes to describe what you’re thinking is the way of tackling how it behaves, breaths, performs and looks. Design is like composition, there are no rules of where you start - you could start with an interface (voice, message, page, form or whatever) because changing up the start position changes the rest of the concept. You could start at what the end result looks or sounds like then work backwards to how you produce the end result, it’s totally up to you.

‍

Testing your Solution

Critics are as important as advocates, all the feedback puts it through the wringer before it’s ready to present to your business stakeholders.

‍

It is also important that you get your original empathy group involved since they are the ones that helped you define the problem in the first place so it needs to meet the ideal (IRCP) in whatever way you thought would work and hopefully it will surprise and delight them.

‍

Kicking off an Initiative

Once you have proven the appetite and value, it is worth putting together a Lean Canvas which covers off all aspects of why, what, when and includes costs and expected revenues and quantifiable advantages from doing something.

‍

‍

Another thing to think of from a business case perspective is to be able to measure return on investment up front. If you can anticipate sales revenue over the next 1, 2,3 or 5 years and are happy to invest x% upfront and x% per year then you have just set your CAPEX and OPEX budget - people always forget about the OPEX, we live in a SaaS, DaaS and PaaS service subscription pricing world so make sure you’ve accounted for implementation costs AND ongoing costs.

‍

Writing Business Requirements

There are a few proven methods of writing business requirements (qracorp.com) which can be bundled together to provide not only the user perspective but also how a feature might respond to events and states. The requirements types described in this document originate from Mavin et Al EARS: The Easy Approach to Requirements Syntax.

‍

Depending on the nature of what is written will determine which statement is the requirement and which other statements are acceptance criteria. If you find yourself trying to create a user story where you cannot define a user but instead a beneficiary, consider an alternative requirement type.

‍

For example, if you have a requirement from a booking system to integrate the payments of confirmed travel bookings into the bookkeeping application, consider using an event-driven requirement instead of a user story if it has come from a beneficiary of a back-end system feature.

‍

It is also important in some cases to be able to measure how and when the feature is being used which should be included in the requirement. In many cases, a new feature replaces an old one, so knowing how to measure current and future state may be required to confirm the expected return on investment as a cost benefit, increase revenue, user engagement, customer satisfaction or efficiency improvement.

‍

In most cases, there are more than one features that are related to a capability and so it makes sense that they are grouped together for delivery and because they naturally fit together. For example, if you are delivering a card payment management capability, requirements for requesting bank approval for the processing of a payment need to go with the interface requirements to enter the card details otherwise it's been split up for no good reason.

‍

A collection of user stories is called an Epic story but that’s assuming the epic is only dealing with one specific business capability. You may find that there are other relationships and dependencies that are required from other components which either already exist or are also being defined as a part of an initiative. The context of all these together is required to design a solution that meets high level objectives and lower level functional requirements.

‍

‍

User Driven

The standard format for a user story is shown as follows:

‍

As a <user role> (optional; using <system>) I want to <perform task> so that I can <business value>

‍

If you are writing a number of tasks and the resulting business value benefit for the same user role then you can bundle them together grouped by the user role.

‍

The reason why it is specifically a user role and not user is because, there may be multiple users of a system who perform the same role in the context of the described capability.

‍

For example, in the context of a booking system, you might have the user role “booking agent” but there may be a set of users who are internal (customer service) and external (travel agent). A booking agent user role is used to describe a task which can be performed by either group of users.

‍

If you are writing a user story which is specific to a feature which can only be performed by the internal user group (customer service) like apply discount to booking or process customer booking refund then the user role in this case would be customer service not booking agent.

‍

When writing the business value it is quite easy to lose patience in explaining why you want to perform a task but it is important that you’ve been able to articulate it in a quantifiable way. Keep away from subjective terminology like quicker, easier or intuitive as this is left to interpretation and when that happens, you leave it wide open to ambiguity.

‍

As a booking agent, I want to be able to process customer card payment when booking travel so that I can supply the booking confirmation details to the passenger when the booking process has completed.

‍

‍

Event-Driven

This type of requirement is especially useful where you are writing behaviour in the context of an event-driven architecture where each requirement is to listen for specific events and react appropriately..

‍

An event is something that occurs like a change to a document status (like a booking changing state from CONFIRMED to CANCELLED or a sale being VOIDED before completed) or anything that is measured which produces some sort of alert (broadband usage has just reached 80% of the subscribed data allowance).

‍

WHEN <trigger> <optional precondition> the <system name> shall <system response>

‍

Any event can be a trigger for something else to run. It can in turn create a set of other events which individually are triggers to a set of other events.

‍

In order to avoid knee-jerk reactions to events, you can create logic within the system response that verifies not only the trigger but also other contextual information to determine whether it should run or not. Understanding this concept will help you to provide the right level of detail to describe the behaviour you require. For example, if a travel service was cancelled, it would be better to send each booking agent a notification which had all the impacted bookings together rather than sending notifications for each and every booking.

‍

The event-driven requirement below would be the primary requirement however, although it alludes to the acceptance criteria (all affected bookings) there may need to be other subsequent requirements to compliment this to remove any ambiguity of the expected handling of the event. This might include automatically reserving the next best service for each customer’s requirements which turns a rebooking exercise into simply confirming the new travel arrangements with the individual customers which a booking agent may automate with a digital platform.

‍

When a travel service has been cancelled, the booking system shall supply a notification to the booking agent which includes details of all affected bookings that require exception management.

‍

‍

Behaviour-Driven

This type of requirement is how to handle both wanted and unwanted behaviour of either the system or the users. It helps manage exceptions like a failed card payment which prevents the completion of a customer order.

‍

IF <unwanted condition or event>, THEN the <system name> shall <system response>

‍

The example of the payment card being declined is shown below and shows only two possible conclusions. In reality, no business in their right mind would allow a booking to be abandoned so maybe it would allow the booking to be held against an email address for x amount of time and a reminder and link be sent to prompt a user to complete their order, lol, it was only an example.

‍

If the payment card is declined by the payment gateway, the booking system shall request an alternative payment option until payment is successful or the booking is abandoned.

‍

‍

State-Driven

State-based management is one of my old favourite topics, many years ago I wrote a white paper on exactly this in the context of managing and facilitating multiple service orders in order to fulfil a customer order. The premise is that every order has a lifecycle which includes a happy path and unhappy path. As one system gets to a specific state, it could be the right time to initiate an action in another system. Remember to reference business rules by name (standard reservation period) rather than entering a specific value (24 hours) so it can be managed centrally.

‍

WHILE <system state>, the <system name> shall <system response>

‍

While the customer booking is in an unpaid state, the booking system shall reserve the travel booking for the duration as specified in the standard reservation period or until the state has been changed.

‍

‍

Feature-Driven

This is an interesting type of requirement, it is either a feature (vehicle has cruise control) or a conditional parameter (flexible travel options). You reference this feature which may or may not exist and where the feature is included, the system can do something that it otherwise would restrict.

‍

WHERE <feature is included>, the <system name> shall <system response>

‍

For a customer travel booking where flexible travel options are included and conditions are met, the booking system shall allow a customer to apply changes to a booking to new available travel dates.

‍

‍

Ubiquitous

For all non-functional requirements and constraints, it is very clear that there are things that must always happen or be available at all times. This includes support, security, performance, scalability, availability, etc.

‍

The <system name> shall <system response>

‍

The booking system shall be available between 07:00 and 21:00 NZT Monday to Sunday, 52 weeks to the year.

‍

‍

Business Process Mapping

A business process provides a framework of activities and gateways that relate to the business requirements described above. There is also decision modelling which relates to event, state and behaviour requirements used to apply defined business rules to ensure the effectiveness of a process and its handling of different data parameters.

‍

For each step in a process, there is a requirement of the right information available at the right time to provide the context required to inform the actor involved in the current activity what they need to complete it. This may be to change the state of an activity or enter more data so that it can proceed to another step in the process.

‍

With this in mind, it is important to look at a business process as the electrical wiring required to carry electricity around a circuit allowing users to plug in/out devices, turn things on and off and react when it is overloaded.

‍

Process without defined data as inputs and outputs doesn’t achieve anything.

‍

I like to adhere to the BPMN 2.0 standard because it is a visually descriptive language which you can use at a high level or extremely detailed - it is important to know how to make a process usable by an audience and the difference between procedure and process. A process is specific to a part, like a car part - it is a component that is used to make up something else.

‍

The below process is an abstraction higher than a detailed view of an end to end Lending application process. It leaves the main detail to be described in a decision step (Assess Application for Lending) and through SOP (standard operating procedure) documentation which describes the steps of each of the human process activities.

‍

By not putting all the detail into the process itself, it not only declutters the process but also has less amendments to be carried out over time - the steps in a SOP may change as user interfaces are improved or systems change but the process remains the same - the business process is there to define sequential business value and who is responsible for delivering it.

‍

‍

As a process is a component, you should only need to define it once and assign an owner and make it reusable in other processes. For example, an ordering process may include a Manage Customer Card Payment which is done to complete the order. However, the steps of how the card process is performed is probably owned by someone in finance along with Manage Customer Refund and Register Payment Card.

‍

Where there are rules and multiple parameters to consider, DMN is the preferred method of describing one or more nests of considerations and conclusions to arrive at a final outcome which can be used in the process. Above screenshot shows that from the Assess Application for Lending, there were three outcomes which are then used by an exclusive gateway to route the process based upon each outcome.

‍

Decision Modelling Notation (DMN)

Decision modelling techniques allow for the nesting of the conclusions of decisions to be the input of an overarching decision in a clear and concise manner. This replaces the need for a multitude of decision gateways that take you on a wild where's Wally goose chase.

‍

The considerations and conclusion gives a dev team enough information about how to build out the logic and where to get the necessary data from and encourages a configuration approach to dev rather than customisation at a code level which might make incremental changes more challenging.

‍

‍

Centralising of Business Artefacts

The ideal is that all business artefacts are stored together with various permissions applied depending on whether you own, develop, manage or consume business artefact content in order to perform your role within the business.

‍

The reality is that different types of artefacts live in different places and not all of them can be easily interrelated and displayed together in the same place. The mock-up below is simply an illustration of how that might look like if there was an off the shelf solution for exactly that.

‍

‍

Since it doesn’t exist, it is up to each company to reach a consensus on how this can be achieved using the tools readily available like Confluence, Jira and various document creation tools like Creatio or Microsoft Visio for business processes, InVision or JustInMind for UI/UX prototyping and the usual suspects like Excel, Word and PowerPoint (great for creating any type of image or diagram when other tools aren’t available - all images in this document came from PowerPoint).

‍

Combining Events and States

Below is an example of how individual events can transition between different controllers that are triggered by an inbound event and outbound event created to be picked up by other controllers. Unlike a linear process, the outputs and the handling can happen at any time during any component’s processing capability.

‍

‍

You have controllers which are triggered by different events and the contained state. Each control service in here to process an event of one state into another state which includes normal and exception processing.

‍

Data Transformation

When you are defining data for a new system which originates from a 3rd party, it is important not to fall into the trap of adopting a vendor’s naming convention and taxonomy. I remember working at a company where in their application it had fields dedicated to salesforce_id and zendesk_id instead of naming by the purpose of that column like customer_identifier and issue_identifier.

‍

Source data is data which arrives for use in the ideal state. The process of converting origin data into source data is called data transformation. Transformation is not only the standardisation of the format (csv, XML, JSON, etc.) but also the values contained in a payload of data.

‍

This is done by either substituting a value (Example, where expense_type equals “COGS” then set value to “Sales Expense”) or by enriching using lookups and rules which can be processed with the payload of data and some other static reference data sets.

‍

Break the Mould Limited has a business user friendly stripped down yet powerful product whose sole purpose is data transformation, how you extract or receive that data is up to you. Also, where it goes next is up to you. This tool iXO competes with monolithic ETL tools like Informatica and Talend and due to its ease of use by a non-technical but analytically savvy user, is the best friend of those who view data as a business commodity that enables and drives smart business decisions and a punch to the kidney to departments and businesses who believe that data is only the domain of the most esteemed technical user groups.

‍

‍

‍

‍

Impact Mapping

An impact map is a visualisation of scope and underlying assumptions, created collaboratively by senior technical and business people.

‍

Project plans and requirements documents are often shopping lists of features, without any context why such things are important. Without a clear mapping of deliverables to business objectives, and a justification of that mapping through impacts that need to be supported, it is incredibly difficult to argue why certain items should or shouldn’t be invested in. In larger organisations with many project stakeholders or product sponsors, this leads to huge scope-creep as everyone’s pet features and ideas are bundled in.

‍

‍

Go to https://www.impactmapping.org/drawing.html for an excellent article providing more in depth explanation.

‍

Conclusion

I hope this has proved to be a useful article, there was a lot in there. If the only things you take away are the links to the various resources collected in here, I'll be happy to have shared. Also, check out IXO, to be released soon under my company, Break the Mould as a subscription based service available in the could or as locally installed service for your own infrastructure needs.

---

Connect with and follow Matt Lightbourn on LinkedIn to stay up to date with his latest thinking.