The Crucial Art of Pre-Project Problem Analysis

Featured
26862 Views
1 Comments
31 Likes

Business analysis is a broad discipline and we have a whole range of tools and techniques at our disposal. We may get involved within projects, but also outside of them. Many BA teams are actively seeking earlier engagement—when we are engaged prior to a project being initiated we can work with our stakeholders to ensure that the problem space is thoroughly understood. We can encourage stakeholders to think about many possible solution options, and can work with them to ensure that the option that is chosen is the best fit and has the best chance of delivering maximum benefit. Early engagement also helps us avoid the 'first solution trap'.

The ‘First Solution’ Trap

I suspect we've all worked on projects where the solution had been decided upon long before a business analyst was engaged. Providing a relevant practitioner has undertaken the upfront analysis needed, this might be fine, but other time this may be a worrying symptom of a project that is at risk of going off the rails. In many contexts this can be a warning sign that the solution is driving the problem. Perhaps a stakeholder has seen a compelling pitch for a solution, and is now trying to find a problem (and launching a project) to make it fit.

I am sure we have all fallen into this trap in our own lives. I like 'gadgets', and went through a phase of buying kitchen gadgets. Trouble is, I rarely use any of them—and they sit there collecting dust. I recently gave away two beautiful, shiny juicers. Both looked great on the kitchen worktop, but if I’m honest they had probably been used less than three or four times. Whilst I loved the way they look, and the way they were marketed, they solved a problem (making fresh juice) that I never had (as there are plenty of local cafes and stores that provide this when I need it—for far less effort and with no utensils for me to clean!).

Admittedly this may seem like somewhat of an unrelated anecdote—but similar patterns exist in the corporate world but the stakes are much, much, higher. A project to implement 'New Shiny System X' should raise warning bells in our minds. We should ask questions including:

  • What problem is the project trying to solve?
  • What outcomes is the organization looking to achieve?
  • What are the dependencies and interconnections?
  • What other options (if any) have been examined, and why was this option selected?

After all, sometimes the first solution that emerges might not be the best. There might be another cheaper, quicker, effective option that we've not yet examined. By taking time to examine the situation further we may save money whilst also creating an even better outcome. Yet before we can explore potential solution options in more detail, it's important that we ensure there is a common view of the problem space.

What Problem Are We Trying Solve?

Most projects are initiated to solve a problem or leverage an opportunity. There are of course many ways of framing the underlying need that is driving a project, but I find that problem statements and opportunity statements help to create a healthy discussion amongst stakeholders. They often uncover different perspectives about the problem, and finding these different perspectives early means that they can be discussed and reconciled before too much energy and resources are expended. This can help create unity, and avoid the project (later) being pulled in different directions by different stakeholders.

There is no inherent right or wrong way of writing a problem statement, but a fairly useful and common way is:

  • The problem of...
  • Is affecting...
  • The impact of which is...
  • A successful solution would...

So, imagining that we are working for a contact center and there are increasing wait times. The call center manager is keen for us to install a new 'Interactive Voice Response' (IVR) menu system to help route customers to the right location more quickly and to enable them to automatically enter their account information. Yet, this is just one possible solution—and a problem statement might help us to open up the possible solution space. After some discussion and investigation we might settle on:

  • The problem of...increasing wait times (particularly those above 30 seconds) on the customer service line
  • Is affecting...Customers and contact center staff
  • The impact of which is... stress for staff and frustration for customers, leading to decreased staff & customer retention, lower sales volumes and increased complaints
  • A successful solution would... Enable existing customers to quickly resolve issues and/or make a repeat purchase, leading to increased customer satisfaction, reduced complaints and higher sales revenues and profits

With problem statements it takes time and iteration to achieve precision and consensus, but this is time well spent. It helps us tactfully nudge our colleagues away from the 'first solution trap'. Stating the problem in solution-agnostic terms helps us foster innovative and divergent conversations about a multitude of options. Indeed, I suspect that when you were reading the problem statement above you were imagining many possible options—increased web presence, process changes, further work to understand any failure demand, as well as changes to the IVR system. In fact, thinking about solutions may lead us to revisit the problem statement and nail it down even further—this is a positive thing.

The problem statement can be incorporated in other documents (for example a Project Charter or Business Case) and will act as a useful guiding beacon throughout the project. When we reach more detail we can ask 'how does this detailed requirement help us solve this problem?'. If it doesn't, perhaps it should be de-scoped... or perhaps the problem space has changed and we need to revisit the purpose and scope of the project! Either way, it is crucial that we know. We may also find that different stakeholders have very different perspectives on the problem: driving these discussions through a problem statement can be an excellent way of highlighting these and working to achieve consensus. It should be noted that, generally speaking a problem statement focusses on the effects rather than the causes of the problem—these can be further examined using a multiple cause diagram as explained below.

Incidentally, if it is an opportunity that is being addressed, the format works equally well:

  • The opportunity of...
  • Would benefit...
  • The impact of which is...
  • A successful solution would...

What Are The Desired Outcomes?


Another important aspect of a problem is to determine 'what will the world look and feel like when it is solved'?, or put differently what outcomes are we striving for? How will we know when the problem is solved or the opportunity has been leveraged?

When we are involved early in the business change lifecycle it might not be possible to put a number on each of these factors, but defining a scale of measure is still useful. It is useful, for example, to know that the aim is increasing sales revenue in a particular product line. Or reducing administration costs on a particular process.

An extremely valuable tool for eliciting and analyzing these outcomes is the balanced scorecard. I was extremely pleased to see that this well-established technique made it into BABOK® v3. The balanced scorecard, originally conceived by Kaplan & Norton, can be used in many different contexts and at many different levels within an organization. It can be used to set measures that help track success of the entire organization, a department, a project/initiative/change or even a team. When undertaking pre-project problem analysis we'll be concerned with the success of a change—or what BABOK® v3 would call a change strategy.

The traditional balanced scorecard has four dimensions, and encourages us to consider success from multiple dimensions. Although we might immediately focus in on the financial objectives of a project, there may well be others that need consideration too. Indeed, companies that focus too heavily on cost reduction without considering the situation holistically might find that they inadvertently reduce customer service—which has a knock-on negative impact to revenues that they didn't want. Examining the outcomes from varying perspectives helps avoid our stakeholders and us thinking too narrowly.

The traditional four dimensions, with some adaptation, are shown below, with some very high level hypothetical goals/objectives shown:

Area/Explanation
Examples of Goals/Objectives
Financial

What are the financial outcomes of solving this problem/seizing this opportunity?

Increased profit

  • Increase profit in product line xxx by y% over one year, and z% over three years
And/or

Reduction in processing costs

  • Reduction in the cost of processing a sale from $x per sale to $y per sale over one year, with no reduction in sales numbers
Customer

What impact will the change have on our customers? How will we measure that impact?
Improved customer satisfaction

  • Increase in customer satisfaction rating from an average of 70% to 90%, measured by a survey of x customers, within one year
  • Increase in net promotor score from x to y within two years

Or

Sustained customer satisfaction
The change is implemented with no negative impact to customer satisfaction, measured by survey and net promotor score

Internal Business Process

What internal business processes will we have to monitor or measure in respect of this problem/opportunity?

Efficient stock control

  • No more than x% 'out of stock' orders within 1 year

And/or

Efficient order picking, packing & dispatch

  • x% of orders dispatched within y hours of order
  • No more than z% returns due to picking/packing errors
Learning and Growth [incorporating "future proofing"]

Traditionally, this element of the balanced business scorecard dealt with learning, growth and innovation. In a project context we can ask what needs to be flexible, and how can we ensure that the organization has adapted (i.e. learned) so that the problem does not occur in the future?

Scalability

  • The organization, and its underlying systems/processes, shall be able to scale in order to meet the projected increase in business volumes from x to y within z months


Figure 1: Examining Goals & Objectives with an Adapted Balanced Business Scorecard

Adapted from Kaplan & Norton (1996)

When eliciting and documenting these high level goals and objectives it is noticeable that there are significant 'grey areas'. For example some financial goals also have a 'customer' element. Many internal business process measures also have a financial element. We should be pragmatic and remember that the technique is useful for prompting us to think about the different areas, and we shouldn't 'force' a fit. Equally, in some contexts it might be appropriate to adapt the dimensions of the balanced business scorecard—particularly where there are different types of 'customer' (take a public sector agency for example, who has one 'customer' (the government) and another (the taxpayer), both of whom have very different measures of success!)

Again, the value in this exercise is both in the discussion with the stakeholders—and the iteration until a consensus is gained—as well as the final documented outcome.

What Is The Current State? Understanding the Problem (And Its Root Causes)

With a completed problem statement and balanced business scorecard, we have a very good understanding of the scope of the problem and why it would be desirable to solve it. Yet we haven't yet delved into the problem-space itself. Unless we are starting from a completely blank canvas, there will be an existing set of processes and systems interacting to deliver services, intermingled with a wide range of stakeholders. Disentangling the problem from its cause or causes can be challenging.

One technique that we can use is the fishbone diagram, this helps us to consider a problem from a range of dimensions, and how varying causes might impact us. However, an alternative technique that can work particularly well for very messy and tricky problems is a multiple cause diagram. This diagram is utilized within the systems thinking and systems practice arenas, and is equally well suited to business analysis. A multiple cause diagram requires very little (if any) explanation, so I have included an example below:

Figure 2: Multiple Cause Diagram (Example)

This partial example shows how the richness of a problem (and its causes) can be represented. We might often start with a suspicion that the cause of the problem originates from one area, only to find that there are many others too. In these cases it can be useful to denote scope on a multiple cause diagram, by indicating which elements of a problem are considered candidates for further examination (either by color coding or by drawing a boundary of scope). This also helps us bring any potential differing or competing perspectives forward, so that we can discuss and reconcile them early (before the project gets going).

As you can see, conceptually this type of diagram has similarities with a fishbone diagram, but it is a more fluid form. Of course, we are not restricted to using one or the other in our analysis—these are just two potential tools in our toolbox. We might use either, both, or something different! I often find I start out with one technique in mind but then adapt when I find that the problem is simpler/more complex than I first thought. This ability for us to adapt to our context, and draw from a wide range of tools, is what makes business analysis such a fascinating career (in my opinion at least!).

Conclusion

As BAs we can add a huge amount of value throughout the business change lifecycle, and we can add value inside and outside of projects. We have a rich and varied toolkit, and this article has summarized just a few techniques that I hope you'll find useful.


Author: Adrian Reed, Principal Consultant and Director at Blackmetric Business Solutions

Adrian Reed is a true advocate of the analysis profession. In his day job, he acts as Principal Consultant and Director at Blackmetric Business Solutions where he provides Business Analysis consultancy and training solutions to a range of clients in varying industries. Adrian is a past President of the UK chapter of the IIBA® and he speaks internationally on topics relating to Business Analysis and business change. You can read Adrian's blog at http://www.adrianreed.co.uk. Follow Adrian on Twitter @UKAdrianReed.


Readers of this article may also be interested in Adrian’s 2015 book ‘Be A Great Problem Solver…Now!’


References & Further Reading

Kaplan, R. and Norton, D. (1996). The Balanced Scorecard. 1st ed. Boston, Mass: Harvard business school press.

IIBA®, (2015). Guide to the business analysis body of knowledge (v3). Toronto : Ontario: International Institute of Business Analysis.

Like this article:
  31 members liked this article
Featured
26862 Views
1 Comments
31 Likes

COMMENTS

Robin Goldsmith posted on Saturday, February 8, 2020 4:51 PM
Adrian, as usual well-thought-out and describing some useful techniques. I find a problem with the notion of problem analysis being pre-project, which I realize is BABOK’s model and what does happen in some organizations. I also find that problem identification and analysis is done much more poorly much more frequently than generally recognized, especially by BABOK. Although not the only dysfunctional scenario, too often projects are initiated by executives or managers who assume their position and/or general background suffices to define needed projects and often too the specifics of their deliverables.

Let me suggest a more useful model includes problem identification and analysis as the starting point of any project and that it be based on meaningful analysis that discovers suitable sufficient information to more accurately and reliably identify and analyze the REAL problem/opportunity/challenge.

Let me also caution against relying on conventional problem statements, which I find too often fail to identify the REAL problem. Instead, they tend mainly to vent about how awful whatever they’re concerned with is and mask leaping to solutions which seem reasonable until they turn out not to solve the REAL problem, because it wasn’t identified adequately.

I think you’d find my Problem Pyramid™ overcomes such weaknesses, applying important disciplines to get right the REAL problem, value measures, causes, REAL business requirements deliverable _whats_ that provide value when satisfied, and only then a product/system/software way _how_ to satisfy the _whats_.
RobinGoldsmith
Only registered users may post comments.

 



Upcoming Live Webinars

 




Copyright 2006-2024 by Modern Analyst Media LLC