Author: Adrian Reed

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. He is a Past President of the UK chapter of the IIBA® and he speaks internationally on topics relating to business analysis and business change. Adrian wrote the 2016 book ‘Be a Great Problem Solver… Now’ and the 2018 book ‘Business Analyst’ You can read Adrian’s blog at and follow him on Twitter at

What Would Your Customers Say If They Heard You?

It may sound harsh, but I’d estimate that around 90% of the “big topics” that are discussed within the business change community wouldn’t interest end customers at all. This isn’t to say that the debates aren’t important, it’s just that the specific nuances that people get so heated about within the change community are just so unexciting to the folks who are actually on the receiving end of that change. If you’re trying to battle to book a train reservation and the website is so badly designed that you give up, you probably don’t care whether that website is developed and maintained using agile approaches, waterfall, “the Spotify model” or something else. You probably don’t care whether the webserver is “on-premise” or not and whether the development was conducted in-house or whether it was outsourced. You just want the website to work so that you can get on with your day—you just want stuff to work the first time, consistently. The technicalities of how that works (and how the tech and processes were delivered) are pretty uninteresting to most end-customers.

Of course, the very reason that the website doesn’t work well might be because of some kind of design issue which crept in because of mismanagement of one of those very issues I just mentioned, so there’s no intention to underplay them. However, in the same way, that you or I probably don’t think too much about the pipes that carry the water to our houses, customers don’t tend to think about the processes and technology that delivers a service to them until it goes wrong. The key then is to understand what is desirable from a customer’s perspective and consistently deliver it.


Customers are, after all, focused on achieving outcomes. They want to get something done, usually as effectively and efficiently as possible and then get on with their lives.

Organizational processes usually balance achieving something for the end-customer which also benefits the organization itself (e.g. selling a train ticket and operating a train service allows a customer to get to their destination while also generating revenue for the operating company).

Focus On Outcomes: The Jargon Doesn’t Matter

It’s really easy to lose sight of these business and customer outcomes. Buzzwords start to emerge and take on a life of their own. Projects get initiated to “create a profound digital channel shift on our legacy portfolio”. OK, I made that up, but it probably sounds familiar: the point is it is pretty meaningless to a customer. I’m not sure many customers of, say, an energy company have woken up and thought “I really want a profound channel shift today!”. They probably just want regular payments taken, on time, with accurate and predictable billing. If the organization isn’t doing the basics right, then it should probably focus there before it considers any kind of other major change.

Now it might be that providing an online presence is important. Certainly, I’m a customer that uses online services a lot, but the ‘win’ there is often convenience. The moment that convenience is compromised, I’ll revert to offline mechanisms.  We’ve probably all dealt with companies where the online route is just too complicated and long-winded, so what do you do? Pick up the phone…

This highlights the importance of knowing what different stakeholder groups value. Techniques like personas and proto-personas can be extremely helpful here, particularly when the goals of the stakeholder are clearly identified and shown. Empathy mapping can also be very enlightening.

Conclusion: Keeping The Customer (And The Outcomes) Close

In conclusion, it’s easy to get blind-sided by methods, tools, and approaches. These are all important, but they are a means to an end.  Keeping the customers and outcomes in mind, and gaining a deep appreciation of what customers actually want (rather than focusing on the internal jargon) is crucial.  There are many tools in the BA toolkit for this, and BAs are well centered to help keep outcomes front-and-center throughout.

Awkward Stakeholders Or Lack Of Engagement?

It’s no secret that people are key to implementing successful change.  Projects don’t happen in a vacuum, and there will usually be a wide range of stakeholder perspectives that need to be considered, and a broad range of people who need to be ‘on board’ with the change.  It’s unsurprising then that BAs and PMs spend a fair amount of time working with stakeholders, and with a wide range of stakeholders involved there can be conflict.  This conflict can manifest itself in all sorts of ways, in some cases an individual might choose to do everything they can to block a project and be as awkward as they possibly can.  Another stakeholder might say they support the project in public, but then do everything they can to thwart it in private (while also rejecting every meeting request so that progress stalls).

When situations like this occur, it’s very easy to sink your head into your hands and shout ‘Those awkward stakeholders! Why won’t they just get with the program!’.  It can be particularly frustrating when an individual has had (seemingly) hundreds of opportunities to raise a concern, yet the time they decide to raise it is twenty minutes before go-live on a Sunday afternoon where everyone is already under extreme pressure.  As frustrating as these situations are, and as tempting as it is to blame the stakeholders themselves, it is usually more valuable to take a step back and say ‘how did we get to this situation?’


Assume The Best Of Intentions: They’re Not Trying To Screw-Up Your Day!

In most organizations, it’s fair to assume that the vast majority of people want to do a good job.  Hopefully very few people come to work to actively sabotage the company, and those that do will (hopefully) get weeded out through the company’s HR and monitoring processes. Some stakeholders, particularly those outside of the organization, might have agendas and objectives that differ from those of the organization, but they will have objectives that make complete logical sense to them.  A school might focus on ensuring the best possible outcome for an entire cohort of students; an individual parent is likely to care more about the outcome of their child.  Both perspectives are logical and understandable, but could occasionally lead to conflict where the needs of the individual child are opposed to the wider cohort (“My child is so far ahead, why can’t you go quicker!”).

As hard as it is to do when the pressure is mounting, it’s usually best to assume that our stakeholders are acting with good intentions unless we can categorically prove otherwise.  That compliance manager who decides to butt in with a new regulation 5 minutes before go-live probably isn’t doing it for kicks, they are probably doing it because they’ve only just ‘joined the dots’ and have seen how relevant it is.  For every business analyst that says “That stakeholder is really awkward, they always raise objections too late…” there is probably a stakeholder saying “That BA is really awkward, they bombard me with useless information, and then when I do raise a concern they complain!”.

This comes back to the crucial discipline of stakeholder engagement.  If we don’t engage and communicate with stakeholders in a way that works for us and for them, we’ll likely end up talking cross-purposes with assumptions (or misunderstandings) on both sides.

Helping People ‘Connect The Dots’

As much as stakeholder engagement is important (and it really is important), an aspect that is sometimes overlooked is why it is done.  Is it really done just to elicit information and ‘get people on board’?  If so, isn’t that a little one sided?  Surely it’s important to consider what’s in it for the project, the organization and the stakeholder (or group) themselves? Otherwise it’s not two-way engagement at all, it’s just a self-serving and time-sapping project monologue, something that I’m sure we’re all keen to avoid!

One aspect to this that often isn’t talked about enough is the way that good quality engagement and communication helps people ‘connect the dots’. For example speaking with a wide range of stakeholders will help the project team understand different perspectives, how different parts of a process work and so on.  Equally this helps the stakeholders themselves connect the dots and figure out how the change will affect them and how they can contribute to its creation.  By truly listening and empathizing we can proactively help others to make these connections, while also making them ourselves.  By actively listening and asking probing questions we can preempt where later conflict might emerge.  By getting concerns and issues on the table early, we can ensure they are discussed and escalated and that the person is genuinely heard.

Traditional stakeholder identification and categorization approaches such as the stakeholder interest/impact grid, stakeholder rainbow, stakeholder onion and others are helpful (to an extent) in helping us figure out who we need to engage, when and how often.  Yet how we engage and the content of our communication is harder.  Actively asking questions such as “how can I help join the dots… for me and them?” and “What’s in it for them?” can help frame the conversation.

And perhaps, just perhaps, ‘connecting the dots’ is a key part of the BA role that we do by default and need to talk about more….

What are your views? Do you ‘connect the dots’? I’d love to hear your experiences. Please feel free to connect with me on LinkedIn and keep the conversation going!

Project Reporting: The Illusion of Control

As a business analyst, I’ve been fortunate enough to work alongside some excellent project managers in my career.  I’ve always considered the BA/PM relationship to be crucial for success; there will typically be some creative tension between the two perspectives, but it is that tension that means that the BA is free to challenge, with the PM ensuring that we don’t get drawn into any unnecessary ‘analysis paralysis’.  The two roles are different and complementary, and it’s crucial that open and honest communication takes place between the two.

One thing I’ve always found challenging though is reporting, particularly on projects where (by their very nature) some hefty upfront work is required.  Imagine creating a specification for an Invitation to Tender (“ITT”) or Request for Proposal (“RFP”) process—there needs to be enough certainty about the detail upfront for the vendors to create an initial quote and proposal, which means there’s a chunk of up-front work, even if the detailed elaboration and design work is done in an agile way.

Reporting in these situations can be troublesome because it’s really hard to know how close to ‘done’ we really are. Imagine a project manager coming to you clutching a Gantt chart and saying:

“According to the plan, you should be 72.6% complete with your high-level requirements. I just wanted to check that you are, in fact, 72.6% complete?”.

This is a very difficult question to answer honestly; let’s face it, with the best will in the world you might think you’re 80% done, but all of a sudden a stakeholder has a flash of inspiration and realizes that some crucial element of scope has been forgotten.  It’s great to catch it early, but all of a sudden you’ve gone from 80% complete to 20% complete…

Let’s face it, progress reporting of this type gives the illusion of control.  Unless the environment is stable, predictable and you happen to be working on a completely predictable repeatable project where there’s historic data, then any estimate is really just an informed guess. And reporting progress in percentages is highly suspect—I mean, how can anyone really know if they’re precisely 72% and not 71% or indeed 68% complete?  So what happens in reality is people just say “yes”, and you get a task that appears to be on track until suddenly it really isn’t.  It becomes like a taskbar on a computer that works steadily up to 99% and then stalls, with the final 1% taking 10 times longer than the previous 99%…


Gaming the Numbers

Similar games get played on agile projects.  I remember once hearing somebody who was under pressure to improve a team’s velocity say “I can double our velocity overnight—I’ll just double our story point estimates”.  The point was semi-facetious but also deadly serious: Assuming the right mixture of people with the right expertise are involved, the work is going to take the time the work takes. Asking people to “work faster” is, at best, a temporary fix and, at worst, a way of completely burning out a talented team.

This reminds me of the classic film This Is Spinal Tap which parodies a rock group documentary.  The group famously has amplifiers that ‘go up to 11 rather than 10’ thinking they are louder.  Of course, in reality, the amps generate exactly the same volume, there’s just an extra number on the dial… In organizations, we need to be careful that we don’t fall for a similar fallacy.

I’m not sure that there’s any easy solution to this dilemma. There are some who advocate avoiding certain types of estimation at all (see the #noestimates movement on social media). Some things I have found personally useful when it comes to estimating analysis work are:

  • Show progress not percentages: Breaking work up into modular parts and getting artefacts reviewed (and on to their consumers) sooner helps progress get tracked. For example, an initial context diagram and problem statement might be useful artefacts on their own.
  • Estimate effort remaining: Rather than saying ‘I’m 72.6% through’, I’m much more comfortable saying “based on what I currently know, and the progress and interaction with the stakeholders, I’d estimate another five to seven days effort, spread over ten to twelve working days to allow for stakeholder availability”.
  • Estimate in ranges: You’ll notice that I included ranges in the estimate above, the wider the range the less confident I am. The more I know about the situation, and the more stable and predictable the situation, the narrower the ranges.
  • Separate effort from duration: Neither you or I, realistically, can do ten days effort in ten days’ duration if we need input from others. The chances of them being available exactly when we need them is low. Plus, there are probably other things in our diaries (team meetings, training, etc). So best to be open and transparent.
  • Make it clear it’s an estimate: As is commonly (and sensibly) said in the agile world ‘this is an estimate, not a commitment; it’s my best guess but if the existing situation is a heck of a lot more complex, then we’ll need to revisit it.
  • State assumptions and revisit: By stating assumptions, we make it clear what the estimate is based on. One thing that is often overlooked is that (on any complex piece of work) it’s useful to revisit What initially has a very wide range will become narrower when more is known.
  • Never estimate the work of others: If somebody needs to know how much development time something will take, then it’s time to ask a developer…

Like so much, this is very much about transparency and communication. The relationship between the BA and project (or product) manager is crucial, and this open dialogue enables us to jointly learn and collect data that may be useful for future estimates.  It isn’t ever going to be easy, but by having the difficult conversations early, we avoid having to disappoint people later on!

What are you experiences with creating estimates for analysis work? I’d love to hear from you. Feel free to connect with me on LinkedIn and let’s keep the conversation going.

Keeping Customers Happy: Understanding Information Needs

One of the many perspectives that need to be balanced when conducting business analysis is that of the customer. Quite rightly, tools like personas and journey maps form a part of the BA toolkit and these (and other) tools can be deployed to gain a representative understanding of what customers or other stakeholders want. As well as understanding what they want, another angle that is worth consideration is their pain points or frustrations. Gaining an understanding of what isn’t working now can be incredibly helpful when figuring out how a particular journey should change.

Within their current frustrations, one area to probe is their information needs. Quite often an otherwise perfect service might feel frustrating just because a customer doesn’t know what is happening, or when it will happen. Imagine you ordered a product online and no indication was given over when it would be delivered. You’d probably form an expectation based on your experience with other online retailers and might expect delivery in 2 or 3 days. If the product hadn’t arrived after 6 or 7 days, you’d probably chase. This creates frustration and works for you, and it creates additional work for the company (as they have to deal with unhappy customers chasing their products). If, however, a clear expectation of the delivery was set at the outset before you purchased the product you’d have been able to make an informed choice. Perhaps the company might add a line to its website “Our products are bespoke, and made to order. This means they take 7-10 days to be delivered, we’ll provide you with an estimated delivery date when you order”.


This probably sounds like a trivial example, but it illustrates a wider pattern. Sometimes a journey can be improved by the selective and timely provision of information. This provides confidence to the customer (“ah, I know when it’ll be delivered”) but also cuts down on queries and chasers. These are the types of incremental change that can increase satisfaction while simultaneously reducing rework and the associated costs. Some examples are shown below:
Pattern Example
Confirming Texting confirmation of an appointment, so a customer doesn’t feel they have to ring and confirm
Committing Emailing confirmation of a key commitment which had been verbally made over the phone
Preempting Predicting common queries and providing information at an appropriate time (e.g. a hotel might email the check-in / check out times and details about parking 24 hours before a customer is due to arrive)
Providing Visibility Letting someone calling with a query know their place in the queue
Allowing Scrutiny Let the customers view all of the information you store about them so they have confidence that everything is correct.

There are many other possibilities, of course, and the ones that are relevant for you will depend a lot on the environment and context that you’re working in.

How To Find Information Needs

The question becomes “how do we find out what information our customers value?”. Ironically, providing too much information at inappropriate times can create problems too (I’m sure we’ve all been victims of ‘information overload’!). There is no easy answer to this question, but one key thing to do is to ask them.

 Of course, if you have thousands of customers, it won’t be possible to ask everyone. Yet surveys, workshops, and focus groups are ways of getting insight into what customers really want.  It may be that an internal team such as marketing has already commissioned detailed customer research and we can piggyback from that.  There may be a goldmine of information in other places too, such as:

  • Complaints logs: Some complaints may be due to a mismatch of expectations, which might indicate an information need
  • Operational logs & statistics: If there are high volumes of a particular type of query, this may indicate an issue. However, statistics should always be treated with caution until their validity and accuracy are known.
  • Front-line staff: People who actually speak to customers often have a very good idea of common queries and gripes. If there’s absolutely no practical way of speaking to customers, speaking and observing front-line staff can provide a useful proxy.

Once potential improvements have been identified, they can then be sketched out/prototyped and feedback can be sought.  Nothing beats actual feedback from those that are affected, and this might refine other areas for improvement too!

How do you handle customer information needs? I’d love to hear your views.  Feel free to connect with me on LinkedIn and let’s keep the conversation going!

How Do Your Stakeholders Evaluate Success?

Change initiatives work best when they are outcome-focused, as opposed to focusing purely on predetermined deliverables or solutions.  Focusing on desired outcomes allows a team to tease out and understand the perceived problems with the current situation, analyze and evaluate different courses of action, and then carry out a series of experiments to determine which way forward is actually the best.  Working with the team to further understand the situation might uncover a completely different understanding of the current issues, which leads to new and innovative options for change being uncovered.  Techniques and approaches such as pre-project problem analysis, business cases, prototypes, proofs-of-concept, or other similar experimental approaches can be extremely useful.

While being outcome-focused is undoubtedly beneficial, rarely is the question asked “outcomes from whose perspective”, meaning the outcomes are defined internally, often by just a few senior stakeholders. There is nothing inherently wrong with this, yet in reality, processes that are efficient and effective tend to balance different sets of needs and wants.  Put differently, to be successful a process or journey has to meet the needs of a whole range of different stakeholders, each of whom may evaluate success differently.

One place this tension can be seen is anywhere there is a backlog of queries or a queue of customers.  I’m sure as a customer you’ve spent hours on the phone on hold, waiting for someone to pick up.  As a customer this feels really inconvenient—it often involves sitting with a phone against an ear while listening to the same 30 seconds of music interspersed with someone proclaiming ‘your call is important to us’… we’ve all been there!  Yet from the organization’s perspective, it might actually be seen as desirable to have a queue of customers waiting.  If they are focusing purely on “maximum efficiency” and if they define that by “number of calls cleared per agent per day” then it makes sense to have a queue. After all, you wouldn’t want your call center agents sitting idle… or would you…?

It’s Not That Simple: Bring On Other Perspectives

There are at least two other perspectives that would need to be considered here, that of the customer (and in reality, there would likely be different customer groups), and that of the call center workers themselves.  It’s likely that both of these groups would have quite different aspirations over what a good ‘outcome’ looks like.

In a customer’s ideal world, they wouldn’t need to wait at all. In fact, they’d probably have the direct number of a named representative who they could call on whenever they needed.  This illustrates that the customer values convenience, and getting their job done with the minimum amount of fuss.  Making a call to a call center is a distraction in their otherwise busy day.

Employees probably hate situations where there are long wait times on the phone too.  Customers are angry when they get through to them, this creates a reinforcing ‘doom loop’: customers are angry, so they take longer and make complaints that take time to deal with, meaning that more time is taken for each call, which means the waiting time increases….

There would likely be many other perspectives beyond these; however, this illustrates the point that different stakeholders will evaluate success in different ways. Put differently they are seeking different outcomes, in this case:

  • Organization: Wants to maximize profits so employ fewer staff (MONEY)
  • Customer: Wants convenience and just wants to get on with their day (TIME)
  • Staff: Want an interesting job, and don’t want hundreds of angry customers shouting at them each day! (VARIETY/MORALE)


It’s All About The Balance

One reason that gaining a sense of how different stakeholders will evaluate success is that it can help to determine different possible solution approaches.  If we know the different criteria, we can ask, “How can we improve the situation in a way that balances the need to increase efficiency (save money), whilst also being more convenient (saving time for the customer) and also improving the lives of the staff (giving them more variety)?”.  This leads to a very different set of options than if any one of them were examined individually.

When they are looked at in this balanced way, we might (for example) start by examining the reasons that customers are calling.  We might find that the automated letters and e-mails sent out are confusing, and there’s a ‘quick fix’ which reduces cost and increases convenience by reducing the need for them to call at all!  We might delve further and propose a shift to online servicing for certain transactions, customers to self-service at their own convenience.  The call center workers could then focus on the more complex cases, as well as providing support to those who don’t want to (or can’t) access the website.

Of course, these are just examples but I am sure you get the idea.  Simply projecting the organization’s outcomes as if they are paramount is dangerous.  It leads to an internal focus and robs us of the chance to understand the wider stakeholder landscape. As analysts, we are perfectly placed to ensure that stakeholders’ voices get heard.

What are your views? I’d love to hear about how you have approached balancing different stakeholders’ needs.  Feel free to connect with me on LinkedIn


Don't forget to visit our Exhibit Hall and meet hundreds of companies.

Exhibitors are standing by to chat.

Sign up for a live demo and talk directly to engineers!