Author: Adrian Reed

Business process modeling is an incredibly powerful technique, and one that is core to the BA toolkit.

Modeling a process enables us to understand how the work ‘flows’ between teams and makes it easier to spot process problems and bottlenecks.  Process models also enable us to standardize how work is undertaken.  This has a number of advantages: training becomes easier (as there is a documented standard) and we also get a more consistent customer experience.

However, a ‘more consistent customer experience’ isn’t always synonymous with a better customer experience.  An inherent risk awaits us in our rush to automate, standardize and speed up processes—there is a danger that we’ll create a process that looks great on paper but in reality is so rigid that it doesn’t survive contact with the real world.   Perhaps you’ve experienced these types of processes: they are the types that appear to have been built for ‘average’ cases and ‘average’ customers from the organization’s perspective.  Unfortunately, there is usually much greater variety out there in the world than organizations realize, and if processes are rigidly applied and enforced this can mean that front-line workers (however good intentioned) just can’t do the right thing for their customers.

I remember once being in a hotel reception and two guests wandered in and enquired about availability.   The receptionist informed them that they had plenty of rooms available–however bookings had to be conducted via the website or call center.  The guests explained they were visiting from Australia and using data/making calls from their cell-phones would be expensive. The receptionist sympathized but explained there wasn’t really anything they could do.   The guests walked away.

On paper having a standard booking process makes sense.  Channeling everyone through the website sounds like a great cost-saving initiative.  However it excludes some folks who might have genuinely wanted to spend their money buying a product or service.  Standardization makes sense providing thought is put into how any exceptions will be handled, and providing the impact on anyone who is deemed “non-standard” (a horrible phrase!) is considered.  As with many things, it works better with analysis!

Process or Principles?

Three questions that are perhaps not asked enough when we model processes are:

1. What is the ultimate aim of this process (what outcomes for the customer and for the organization are we trying to achieve)?
2. What principles should it adhere to?
3. Who should the process include and who should it exclude (if anyone)?

If we take a process to book a hotel room, we might assume that the ultimate aim is to record accurate reservation details, allocate the room, and send confirmation to the customer.  The customer’s aim is to get a room reserved and the hotel’s aim is to sell a room reservation.  These are nicely compatible aims. Yet it’s worth thinking about process principles here—is there a principle of ‘making it as easy as possible’ for the customer?  If so, it would be crazy to prevent reception staff from helping guests make reservations.  If the process principle was ‘reduce contact with reception staff to save money, but accept we’ll lose reservations’ then pushing people to the website might be fine.

There’s also the question of inclusion.  We might ask whether our process would be usable and appropriate for (say) someone who was partially sighted, or who has short term memory problems.  Certain ‘automated’ and standardized options may prove extremely convenient for some stakeholders but virtually impenetrable to others.  It’s important that we raise these ethical issues and ensure that the impacts of those design decisions are understood.

Flexibility

Whatever the process, there will inevitably be something unexpected that occurs.  A hotel might have a “no refunds” policy for pre-paid bookings.  Yet, if the hotel is forced to close due to an outbreak of coronavirus (something that few process-modelers were explicitly considering) then they might be legally required to offer refunds.   Of course, nobody can predict what will cause this need for flexibility but it is useful to consider the types of flexibility that will be required along with who is authorized to exercise them.  It would be a public relations disaster if a company can’t respond to public outrage just because it’s processes are ‘hard baked’ and unchangeable.

As BAs we have the ability to curiously challenge and intelligently influence.  Process modeling is certainly one area we can do this.

I was chatting to a taxi driver recently who was telling me about his previous fare.

He’d been taking a family from Portsmouth (on the South Coast of the UK) to London Heathrow airport—a ride that would normally take around 1.5 hours if there’s no traffic. Unfortunately on this occasion the traffic was bad, so the taxi driver asked what time the family’s flight was. He was somewhat dismayed to find that they hadn’t factored in anywhere near enough time for possible traffic delays, or even time for navigating through airport security. They had planned to arrive 20 minutes before the scheduled departure time.

As anyone who has ever flown from any major international airport will know, 20 minutes is not going to be enough, especially if you have bags to check in. It turns out that this was the family’s first ever journey on a plane. They’d never been to a large airport before, and had only a vague idea of how things worked. The taxi driver explained he dropped them off, hoping that they would somehow make it in time…

My first reaction to this story was one of bemusement. ‘How could someone have no idea how an airport works?’. Yet I am approaching this from the perspective of someone who has travelled fairly frequently. It’s hard to imagine what it might be like if I’d never experienced an airport before, so I then started to wonder how much information airlines and travel companies actually give passengers on how airports work. The answer in many cases is probably both ‘not enough’ and ‘far too much’: booking an airline ticket often leads to getting lengthy e-mails with T&Cs, information on bag sizing, timings—so much information that knowing what is ‘important’ would be really hard to judge for someone who has no frame of reference. In fact come to think of it, look at many of the e-mails, letters and websites that companies produce—there is often so much information it’s hard to see the ‘wood for the trees’. In an attempt to be informative, customers are flooded with information and don’t know what to do.

Empathize with Newbies

This experience reminded me of how important it is to try and avoid being blinkered when we are carrying out business analysis. When we’re defining requirements for processes, services, user interfaces, etc, it’s very easy to project our own knowledge onto the situation. This can lead to us falling into a trap where we think that something will be ‘obvious’ to our customers, users or stakeholders because it’s ‘obvious’ to us. However, this might not be the case, especially for folks who are completely new to the process or service, as the example above illustrates.

This is one area where user profiles or personas—when they are based on insight or data, or at the very least a well-considered hypothesis—can be extremely useful. These tools help us to switch our thinking, and put ourselves in the shoes of different types of service user. We can ask “what would they value?”, “how would they respond?”, “would they understand?” and “how can we best communicate with them?”. This can help to find ways of serving up the right information at the right time, rather than flooding people with all conceivable information they might need.

Building upon this, whether we use personas or not, it is worth considering what kind of pre-existing knowledge, expectations and mental models will exist amongst our service users. For example, regular airport users will have certain expectations of how airports work. This might be quite different from how, say, an airstrip at a military base works. That might be very different again from a helicopter landing pad on private land. Knowledge and experience of one of these things does not equate to knowledge and experience of all of them. Imagine we are re-designing the claims process for a car (auto) insurance company. We might assume that the client will know roughly what is covered, and how to claim. After all, there is lots of information provided during the sign-up process—there’s a whole downloadable PDF (with tens of pages) explaining all the perils that are covered. How could they not know!

Perhaps some people read every word of every insurance policy, but I suspect some people buy insurance quickly and put it in a drawer and forget about it. If they ever need to claim this is a ‘moment of truth’ for them—they are probably stressed, upset and possibly even angry. Knowing what expectations they are likely to have, and designing a process that is easy to navigate even if you’ve never done it before will be crucial. Building in opportunities for signposting, expectation setting and anticipating queries is important. If the customer has to ask “how do I do this?” or “what happens next?” then this shows an opportunity for potential improvement.

Accepting that not every user will be an ‘expert’ or a ‘regular’ user, and empathizing with ‘newbies’ as well as experienced users can really help.

I might be late to the party, but in the last few years I’ve found that I’ve been occasionally creating and using videos (e.g. ‘screencasts’) in my role as a business analyst.

When used well, a video can be an excellent way of unambiguously communicating fairly complex information to a wide and geographically dispersed stakeholder group.  Not only this, but the barriers to creating video are lower than ever—you are probably reading this article on a device that is capable of creating and editing a whole range of different types of videos.  A well-made video explains and engages in a different way than a document.  You’ve probably found this to be true out of work.  Imagine you need to change the headlamp on your car: You could find the manual, and there will probably be a step-by step guide… but if you’re anything like me you’ll probably ignore the manual and go straight to YouTube and find a practical demonstration.   And when it comes to learning, who hasn’t watched a TED talk, a webinar recording or an e-learning course? We consume lots of video outside of work, so why shouldn’t we create and consume video inside of work too?

My interest in using video as a BA communication device started a few years ago when I needed to present a BA approach to a busy group of senior executives.   The challenge was finding a common time in our diaries.  This was a fairly high-stakes situation: without approval of the approach, the work couldn’t start.  Try as I might, I just couldn’t find a slot in our collective diaries that would work… well, not for about three months (which was far, far too late).

I considered writing a document instead.  I’d put a lot of time into formulating the approach, and I realized if I were to create a document it would be huge. Explaining the complexity using written words is hard—and I worried that the document would end up being ignored or skim-read at best.  I considered just sending the slides from the presentation that I wanted to give.  However, the slides were very visual and would mean very little to anyone without a verbal commentary.  That’s when it hit me: why not send the slides and a verbal commentary?  Why not use screen recording software to record myself giving the presentation, and then send the video file?  We can then discuss follow up queries via e-mail, and if we do need to get together, it’ll likely be for a much shorter duration as we’ll all be ‘on the same page’, so it’ll be easier to schedule.

The Reluctance and the Recording

It sounded like a good idea, but it suddenly felt risky and I initially felt reluctance.  Is sending a video to senior executives much of a too curve-ball? Will they actually watch it?  I reflected on these questions and decided the only way to find out was to try it.  I knew the stakeholders well, they were fantastic leaders who understood business analysis.  Using video was a risk, but a calculated risk, and if it can help us get ‘on the same page’ early, I figured it was worth it.

So, I recorded the video.  I decided to record it ‘screen-cast’ style (e.g. I captured my screen as I was presenting, and my voice, but didn’t use my webcam).  There are plenty of software packages out there that will do this, and if you have a virtual meeting account which allows you to record, you may well be able to use this (e.g. Zoom will allow you to set up a meeting and record it).  I did minimal editing (I chopped off the silence at the beginning and the end), and I sent a link to the video.  

The Expectation Setting and the Reaction

I thought it would be really important to set expectations with the senior executives who I made the video for, so I got in contact with them to explain why I’d done it, and explained that it will hopefully save us time in the long run.  It’ll enable us to get ‘on the same page’ and progress far more quickly than if we had to wait until we had a common slot in our diaries.

Then came the tense nervous wait.  Would it work? Would they watch?

The first response I got back was along the lines of “Fantastic video, this approach makes total sense to me, can we just grab a few minutes to discuss [a tiny clarification]”.  The other responses were similar.  An unexpected bonus, that I later discovered, is that one exec had used the video to explain the approach to their colleagues/peers too.  From their perspective it was a win: they had a ‘presentation in a box’ which succinctly explained the BA approach.

Reflections and other Uses

After this successful experiment, I’ve used videos in other situations too.  My biggest takeaway is to make sure there’s a way of getting the file onto the corporate network.  E-mailing a video file often isn’t possible, and clearly putting confidential information on YouTube isn’t a good idea….  However, there are normally legitimate and approved ways of getting the file in.

I’ve predominantly used video to create short presentations/walkthroughs of approaches and ideas, I’ve used a video to highlight an issue with a customer journey.   I’ve also created a few limited ‘training videos’.  However it strikes me that video could also be useful for many other things too including prototyping, walking through scenarios, etc.  In my view it is particularly useful where a different type of engagement and discussion is sought.  A disadvantage is that videos are less searchable than a document, so they are certainly a tool that has specific uses (and probably aren’t something that we’ll use every day).  The art is using the right mix of tools for the context.

I’m going to continue to use/experiment with videos.  If you have used videos in your role as a business analyst, I’d love to hear how it went/what you used it for, so please do get in touch.

Whatever context you happen to work in, one common feature of business analysis work seems to be that there is never quite enough time.

Perhaps this is a good thing, in that it keeps us sharp and encourages us to innovate, although of course the flip-side is that we need to carefully balance our time and resources to make sure we don’t work too long or burn out. One relevant facet of business analysis work is that we collaborate closely with a range of stakeholders. As is the nature of human beings, each stakeholder will have a slightly different perspective and may even have a personal set of goals or motives that they are pursuing. Some stakeholders might be spreading their time between a whole range of change initiatives, and getting access to them at all can be challenging. If we’re not careful we can find ourselves in a perfect storm: We can’t proceed as the stakeholders don’t have availability to collaborate with us, yet to those up the food-chain the delay is seen as a business analysis related delay. Not a good place to be!

Urgency and Busyness

If we zoom out from this situation, then we might argue that the real problem is that the stakeholders are overloaded with work, and that there’s a resourcing/management issue. This is likely to be the case, but when an initiative is ‘in-flight’ and the pressure is on, this will give us little comfort. There will certainly be larger lessons for the organization to learn, but the first priority is likely to be putting out the immediate fire. This leads us to the question: “How can we get the attention of a ‘busy’ person?”

A classic (and good) approach would be to find a way of showing them the benefits to them and their team of being part of the initiative/work that’s being undertaken, but that in itself is hard to do if it isn’t possible to get any time in their diary. A different angle is to ask the question “What does busy really mean?”. Does it really mean that the person is working on critical, non-deferrable and non-delegable tasks 100% of their time? Probably not. Let’s face it, most of us get distracted, spend hours every week processing e-mails that don’t really need to be looked at immediately, and find ourselves in occasional pointless meetings.

Imagine yourself when you were at your busiest, when you had no way of fitting in another meeting or responding to another e-mail. If somebody said to you “We need you to fill in this ten page form so we can update our internal HR systems”, you’d probably have scorned the form and put it to the back of the queue. If they’d added “…and since this affects the payroll, if you don’t fill it in by the end of the week your salary will be delayed” then you’d probably have found the time. This is a deliberately provocative example but it illustrates the point: If something is perceived as important enough, people will find a way of deferring or delegating other work to get the crucial task done.

Communication and Consequences

The consequences to us or a stakeholder are unlikely to be as severe as delaying a salary payment, however the general pattern of highlighting consequences is a useful one, and one that can be observed elsewhere too. If you’ve been to an airport, you’re probably familiar with the different levels of urgency they place amongst passengers. It seems that there’s an in-built tension between airport retailers, passengers and airlines. Passengers often want to shop/enjoy refreshments as long as possible, airlines want to get them to the gate on time. This is managed carefully: there is regular communication via screens and announcements, and a clear set of ‘stages’, each getting more urgent.

• Gate will be announced at 12:30 (“Relax! But keep an eye on the screen”)
• Go to gate (“Start thinking about moving…”)
• Boarding (“Stop shopping immediately and get here!”)
• Final Call (“You’re about to miss your flight”)
• Final Call + Paging passenger (“We’re about to unload your bags”)
• Gate Closed (“You’ve missed your flight”)

As BAs we can springboard from this airport example and take away the need to communicate and signpost the consequences of inaction. It’s also important that we don’t suddenly ‘dump’ a deadline on someone who isn’t expecting it. Business Analysis Planning & Monitoring is a core area in the Business Analysis Body of Knowledge (BABOK®) guide for a reason, and it’s important that we do what we can to foresee and manage the demands on our busy stakeholders. We could even take inspiration from the airport statuses and build our own communication approach:

• Gate not yet announced: Hey! We need X, for a project which will be really beneficial to you and your team. Are you the right person? Can we call you when we need it?
• Go to Gate: Thanks for agreeing to do X, we’ll likely need it a by Y, can you commit to that?
• Boarding: Go to gate: The project is really picking up pace, just checking you’re still willing and able to provide it by the agreed date? Is there anything else you need from us?
• Final Call: Unfortunately, we’ve not received X, which is going to lead to XYZ consequences (a delay in delivery/cost overrun) — is there anything we can do to help you, or is there anyone else that can provide X? We’re keen to keep things moving!
• Final Call + Unloading Bags: A key workstream is now being delayed, which has led to a delay of Y so far and additional costs of Z, and we’re incurring increasing delays/costs every day.
• Gate Closed: We’ve had to escalate the issue.

Of course, these are all short and overly-simplistic examples and I wouldn’t suggest communicating so bluntly to stakeholders, but the pattern is a useful one. By getting early commitment, communicating consistently and highlighting consequences we help create the conditions where issues are spotted early. This, alongside regular BA planning & monitoring, will ensure that we can work well with our stakeholders and keep the collaborative dialogue going.

I recently attended the Building Business Capability conference, near Fort Lauderdale, Florida. 

On my return journey, I was reflecting on everything I had learned at the conference, when I had an experience that reminded me how important it is for us as BAs to really understand our stakeholders and the goals that they are trying to achieve.

I arrived at Hollywood tri-rail station, and went to an automated machine to buy a ticket to Miami International Airport.  As someone from outside the area, and from a different country, these machines were alien to me.  Of course, I’ve used automated ticket machines before, but not these ones and although they were fairly intuitive it took me a few seconds to work out how to operate them and what ticket I needed.  I figured out I needed a ‘two zone’ ticket, so I selected the relevant option and put in my payment card.  This is when the ‘fun’ began…

The machine rejected the first card I tried to pay with, so I tried a different one which it duly accepted.  The system then asked me to input my zip code before it could take payment, allowing only numbers to be input.  As a customer, I felt that frustrating moment of confusion that we’ve all felt from time to time when our personal circumstances don’t fit the ‘standard process’.  I don’t have a zip code because I don’t live in the USA – I do have a UK postal code but this is made up of numbers and letters.  I quickly went through the options in my head:

• Fake zip code: The only zip code I have memorized is 90210, but I’m not sure anyone would believe I live in that area. I could try using this, but there’s always a risk the system might block my card if it actually tries to validate it.  This would be an issue given I need to get to the airport.
• Hotel zip code: I could use the zip code of the hotel I’ve been staying at. But this would mean fumbling through e-mails and reservations to find it, and I’ve still no idea whether it would validate it.
• Numbers from my UK postcode: If it is trying to validate postal code, I could just enter the numbers from my UK postcode (ignoring the letters)
• Pay with cash: As a last resort, I could go ‘old-school’ and pay with that awkward, retro, paper ‘hand money’ that is still in circulation.

Crucially, there was no indication on why a zip code was being collected, which made it hard to know what to do. I decided to use the least-risky option and paid with cash.  The machine then helpfully dispensed the change entirely in dollar coins. This surprised me again, as a foreigner I had no idea dollar coins even existed, but I now have a pocket full of them!

Better Stakeholder Understanding Brings Clarity

In this situation, whilst the ticket machine was easy to use, it appears an entire group of customers had been forgotten—international visitors.  For a service that starts in a tourist hotspot and terminates at an international airport, this seems somewhat of an oversight, but it highlights a consideration that is relevant for all of us (irrespective of the industry we work in): The services we design are probably going to have to cater for more variety than we initially think.  With this in mind, stakeholder analysis absolutely cannot be a check-box or a one-off activity—it’s crucial that we understand the types of direct and indirect ‘users’, ‘customers’ and ‘beneficiaries’ of the service, and get to know their needs, wants and constraints. 

This will often involve ‘zooming out’ to understand the actual goals of the stakeholder.  As a ‘passenger’ of the tri-rail it might be tempting to assume my goal was to ‘buy ticket’.  Whilst that is true, the ticket was just a means to allow me to travel to the airport.  That was a means of getting me back to London Heathrow.  My overall goal was to ‘travel home’.

At first glance, this might seem unimportant.  Why would the designers of a ticket machine care about stakeholder goals that are outside of their control?  Surely they should focus just on effectively and efficiently selling tickets.  Well, yes and no….  Of course, efficacy in dispensing tickets is important.  Yet knowing the broader stakeholder goals might fundamentally change the way the machine’s interface is designed.  Perhaps, if a ‘user’ selects the airport as their destination, it asks whether they’d like additional help (and if they accept this, the machine tells them the time of the next train and the platform it’ll leave from).  It might also tell them the estimated time of arrival, and maybe it could even integrate with the departures board of the airport to show them any cancellations (after all, if the flight had been cancelled, maybe there’d be no need to travel at all).  In any case, it ought to provide a way to input a non-US zip code.

Feedback and Adapt

Even with the best insight and research and the most robust stakeholder or persona analysis, there will quite likely be something that gets missed, or a need that changes over time.  Even with piloting and prototyping, it’s not until we put a service ‘live’ that we’ll know how it really works.  It’s therefore important to ensure that there are mechanisms to get feedback—ideally qualitative and quantitative—to see if things are working well.  This isn’t primarily about measuring ‘performance’ in the traditional sense, it is more about measuring whether the stakeholders can get whatever they want to get done, done.  For example, if we monitored the tri-rail ticket machine, we might find that a significant proportion of people ‘drop out’ at the zip code stage of the payment process.  This might lead us to ask ‘why’, and look for ways of improving.  It’s also important to get qualitative feedback from people actually using the service.

In summary, understanding stakeholders who are directly or indirectly involved or affected by a product or service that we are creating or changing is crucial.  By ‘zooming out’ and understanding broader goals, we collaboratively specify and design services that will balance their needs and help them effectively and efficiently do what they need to do.  This is an area where business analysis can contribute significant insight.