Author: Adrian Reed

A while back I was out with a group of friends celebrating a friend’s birthday.

We met in a fantastic restaurant, and since we rarely meet as a group, we were very soon engaged in energetic and animated conversations as we caught up with the latest news from each other. The waiter came and took drinks orders, and we ordered a bottle of wine and carried on chatting.

The wine arrived a few minutes later, and perhaps because it was a far more ‘upscale’ restaurant than I would usually have chosen, the waiter engaged in what (to me) appeared to be a largely redundant set of ceremonies. The label of the bottle was proudly paraded to those on the table, a cork screw was produced and the cork was removed. An ice bucket was brought. Then comes the tasting. The waiter pours out a tiniest amount, to which I feel compelled to check the color and the ‘nose’ and pretend I know what I’m looking at. I awkwardly take a sip and say “lovely”, and then the wine is poured. Whilst some elements of this process make sense to me (it’s always good to see the label to make sure the right bottle has arrived), other parts just make me feel uncomfortable. It’s intimidating to have to taste the wine in advance; it’s part of ‘wine theater’ that I, personally, don’t enjoy. If I could have caught the waiter’s eye at the right time I would have said ‘no need to taste, just pour please, I’m sure it’s fine”.

Of course, for others this type of ‘wine theater’ is important—it is a symbol of quality and transparency—and it can add to the experience. But for a group of friends meeting up for an informal birthday celebration, it wasn’t really necessary. Frankly, I’m no wine connoisseur—I’m not sure I’d know a ‘corked’ bottle if it was served to me anyway—and providing its drinkable I’m probably not going to complain!

Wine Theater And Business Analysis

On the way home—after a couple of glasses of wine—I was thinking about how ‘wine theater’ might apply in other circumstances—particularly in our work as business analysts. And in retrospect, I think I may have been ‘guilty’ of this type of pattern myself on occasions. Put specifically, it’s very easy to engage in a set of practices because they are the ‘done thing’ rather than assessing what our stakeholders actually want and need.

I have certainly put together lengthy reports and documents with every piece of information that the reader could possibly want on the off chance that there’s a question. Perhaps there’s a danger in my eagerness to cover every possible angle, I end up diluting my core message to an extent that it’s hard to find. I can almost imagine a busy exec thumbing through the document (“Where’s the exec summary?”) as the message is lost in the ‘theater’ of beautifully produced pages I’ve embellished the report with. I’ve also spent countless hours zooming in on Visio to fix every line so it’s straight. I dread to think how many hours (or days) in total I’ve spent aligning boxes in PowerPoint to make sure they are accurately aligned. All part of the ‘theater’ of making things as flawless as they can be for our stakeholders.

Do these things matter? In true BA style, the answer (if there is one) is probably “it depends”. Much as there are undoubtedly some diners who enjoy ‘wine theater’, there are people who need the detail. There are people who care about lines being straight on diagrams, and a jagged line (to them) might indicate a quality issue with the work. If we are dealing with those stakeholders, then presentation is everything.

However, I’m coming to learn that those stakeholders aren’t the norm. Most folks, once they trust you, are happy with low-fidelity artefacts—as long as we set the expectation from the very beginning. Many people are ‘time poor’ and are switching between multiple priorities. The best gift we can give them is time back in their diary. Brevity, as hard as it is to achieve, is beneficial. Knowing the appropriate level of brevity means knowing and empathizing with those who read our artefacts (our ‘audience’) and this can only be a good thing.

I’m challenging myself, with every artefact I create, to ask whether there is unnecessary ‘wine theater’ and I’m striving for appropriate brevity. It’s a tricky subject, and I’d love to hear your thoughts or experiences!

As business analysts, we work on services, processes and IT systems that are used by (or relied on) by some kind of ‘end customer’.

If our organization targets its services at the general public, then our ‘customer-base’ might be very wide indeed, with a whole range of different people interacting with the organization with all sorts of different goals. If you are working within a governmental environment, you may find you have almost unlimited variation—government departments rarely get to choose their ‘customers’ (a tax department can’t easily ‘choose’ who to deal with and who not to), and the processes are often enabled or constrained by ever-changing policies and laws.

When looking to automate or improve a process, often the focus (quite understandably) is on volume. “Let’s look at the happy path first, and then worry about all of the ‘edge cases’”. This is a totally understandable approach, and in some instances will be the best approach, but in doing so this hides the stark reality that it is often the edge cases that create a disproportionate chunk of the work.

We have probably all heard of the Pareto Principle, or the 80/20 rule, which is often interpreted to mean that in most business situations 80% of the work comes from 20% of the cases (and 20% of the work comes from 80% of the cases). This is actually a rather simplistic view of Pareto—it turns out that the 80/20 percentages were based on land ownership in Italy in the early 20th century, so it seems ironic we still use these approximations today, but that is a topic for another time. However, the underlying principle that the majority of work comes from the minority of cases would suggest that there would be benefits in understanding, and building for, the ‘edge cases’ early. Of course, to be more robust, we’d have to crunch the numbers and do a full and proper Pareto analysis.

An unexpected reality: Inclusive design benefits everyone

One thing I have been personally discovering as a practitioner is that inclusive specification and design actually benefits everyone. Designing well for so-called ‘edge cases’ probably means that you specify and design a process or service that is more intuitive and easier for everyone. It often means that your process is built to cater for more variety—so it can adapt when something unexpected happens. Of course, we need to design with the ‘plain vanilla’, the ‘exotic’ and the ‘edge cases’ in mind.

Let’s take one example. Imagine a bank develops a process where someone with Dementia, who can’t remember long passwords, can still use an online service (perhaps through some kind of biometric authentication). As their condition worsens, the service can be adapted to show less information, and eventually to prompt other family members if there are strange transactions being made. This feature might be designed with one specific need in mind—but I’ll bet a whole bunch of other customers would use biometric authentication, and others may well want family members to receive notices of any unusual transactions (for example, folks who regularly go away on business trips might want their partner or spouse to see any unusual transactions so that they can resolve them).

This is just one theoretical example, but I am sure there are many relevant examples in your (and my) organizations. As BAs we should question the assertion that we should always ‘go for volume’ and think of the happy path first. There is a danger that by considering the ‘happy path’ we end up carrying forward certain design assumptions—after all ‘edge cases’ are only ‘edge cases’ because our current processes, IT systems and so forth treat them that way! By considering these types of needs up front, we might be able to fundamentally re-design the service to be more inclusive for all, creating better outcomes all round.

A long time ago, in an organization far, far, away, I was working as a lead business analyst on a major ‘transformation’ program.

This program had all of the traits that these large, monolithic work efforts seem to have—a fixed (arbitrary) deadline, a scope that somehow seems to keep expanding, and a sense of urgency that led people to work late into the evening.

To assist the program’s work, a number of external consultants from a specialist change consultancy were brought in, specifically within the program and project management arena. The BA team found itself in instant conflict with these colleagues; they appeared (to me at least) to have been brought in to ‘deliver the program’ at all costs and weren’t interested in engaging with BAs. I was responsible for a workstream and would provide estimates of how long the work would take and the resources required—I’d be told by a project manager that I had less time and resources and just needed to be ‘innovative’. “I’m sure you’ll figure it out—now get to work” seemed to be the mantra.

At the time I felt trapped. These folks were excellent at managing up—they could produce Power Point decks like you wouldn’t believe. Expensive stock images, artwork—their decks were a masterpiece. I feared they would start to own the narrative: The BAs in my workstream and I would be submerged in work, gasping for air, whilst they simultaneously manage the message that “The BAs are uncooperative and unhelpful”. This wasn’t helped by one particular senior member of the consultancy who would often talk us down in meetings. We’d make a point and he would jovially, but in quite demeaning way, overrule it and suggest that we’re worrying over nothing. We were slowly, but systemically, having our collective voice taken away. It was a slow creep, almost so slow it wasn’t visible, and I nearly missed it.

I was working late one night, alone, in a meeting room overlooking the city. I paused, stared out at people walking over to the city center, dressed for a night out. It was a Friday, it must have been 7pm (or later) I don’t remember. I slumped down, and had a strangely reflective moment:

“This isn’t OK. People are acting in a way that isn’t OK. And I haven’t called it out”

I immediately packed up what I was doing and got the train home. I had fantastic managers outside of the project who I knew would be supportive. I waited for the particular ‘senior’ consultant to act in that way again, and after the meeting I took him aside. I was so scared, and that discussion is still imprinted in my mind, many years later. I can still remember the pattern that I used:

• I want to give you feedback about something that is important to me, something you’ve done (and keep doing) that isn’t OK
• I absolutely do want your opinion, but it’s best that you wait for me to completely give my feedback before you respond
• I do this because I value what you do, and value our working relationship
• Here is the feedback, here is how it makes me feel
• Please can you stop doing this, I realize that you are probably doing it without knowing
• If you agree, let’s shake hands and grab a coffee
• And of course, if you have feedback for me at any time, I’d be grateful

I was almost shaking, but I hid it well. He was his normal, shall we say ‘assertive’ self when the conversation started. Yet as the conversation went on his face changed; he looked really distressed. Not angry, but almost embarrassed. He explained it was absolutely not his intention to put anyone down, he was just trying to ‘lighten the mood’, but he understood what I was saying. It turns out I hadn’t been effectively communicating some elements of my message either—he had misunderstood my intention. We were talking at cross purposes, and this was our chance to ‘clear the air’. We shook hands, and walked out as colleagues that could work together.

The reason I tell this story is that it’s all too easy to ‘put up’ with behavior that really isn’t professional. It’s particularly hard when something is ‘borderline’ or could be interpreted in multiple ways. But if something causes upset—then whether that was intended or not—surely it’s worth a conversation? Crucially, we also ought to call out behavior that appears to be upsetting others. The source is rarely malicious, and uncovering any misunderstandings might just create a better shared understanding and a better working relationship.

Enter (and exit) the “Project Hero”

A heroic “doom loop”

Business analysis is a rewarding profession, but like most disciplines there are also times of stress.

When the chips are down, when the deadlines are looming and stakeholders are pushed for time things can get tense. In these types of situations it is more important than ever to clearly articulate the value that business analysis brings to projects, as people will often confuse “done soon” with “done well”. There is often a pressure to just get stuff done, and this can lead to immense pressure being put on BAs to stick within a very narrow remit. Perhaps you’ve heard stakeholders say things like “We don’t need all this analysis, we already know what we want!” or “We’re getting stuck in analysis paralysis! Just write down what the users tell you then we can get going!”. It is very easy to get pushed into the role of a ‘requirements scribe’, when in reality we have so much more to offer than this.

Understand Where the Pressure Comes From

There can be many reasons that stakeholders make these types of statement, but it’s often because there is pressure being applied on them from all angles and they don’t (yet) appreciate the benefits that business analysis will bring. So that we can articulate the value of analysis, it’s absolutely crucial that we understand the pressures, constraints and our stakeholders’ needs and perspectives for the project as well as the outcomes that the project will enable. Perhaps an executive manager is incentivized on getting the project ‘over the line’ by a particular date. Knowing this is crucial—if time is an ‘unbendable’ constraint then we can have meaningful conversations about what else can flex. Perhaps we can find a way of delivering early, by flexing the scope. Working collaboratively with the team and using an adaptive approach, we can get something launched (even if it isn’t the ‘full’ solution) so that we can start to measure the benefits and get real customer feedback. Rather than being seen as ‘analysis paralysis’, we show how some up-front prioritization work can help us deliver a partial solution quicker so we can realize benefits earlier.

It’s also important that we realize that the source of the pressure might be outside of our direct control, although it may still directly influence us. Unfortunately, sometimes others might indirectly displace work onto us to hide problems elsewhere. Imagine working on a ‘waterfall’ project with an external supplier. The external supplier has (inadvertently) underestimated the job as they didn’t fully understand the complexity of the situation pre-sale (perhaps no BAs were involved!). They are desperately trying to get things moving, but they are in a dilemma: They can’t assign more resource, as the contract is already likely to be unprofitable. They can’t be seen to be ‘late’ as there is a penalty clause in the contract. Whilst they may want to work collaboratively, they may get caught in a rut where the contractual wrangling mean they have no choice but to focus on the analysis. They might reject requirements artefacts, asking for more and more detail, to the point where they are really asking for both requirements and functional design. Perhaps you’ve even been in this situation before….

These types of occurrence can be significant signs that the trust in the relationship has gone. It might often coincide with ‘robust discussions’ over what is in scope (“Well, that’s absolutely in scope, it’s in the Request for Proposal (RFP)”…. “No, it’s ambiguous in the RFP, and look at point 173 sub point 3.2.5 in our response, where we use the term ‘likely’ rather than ‘definite’. It’s not included, it’s a change request’”.). Of course, there is a lot that could be said for what got the relationship here in the first place, but that is best saved for a future article. It’s crucial to avoid the ‘blame game’ and find a way of navigating through the situation that works for all parties. A key area where we often have unique insight as BAs is that we can call out early warning signs when relationships are souring. We are often on the ground, speaking to stakeholders at all levels. If we see a pattern of mistrust emerging it’s really important that we highlight it. It might be time to hit ‘pause’, to call out the issues, and collaboratively work on ways of getting it resolved. Whilst this might not initially seem a ‘core’ part of the BA role, it is an area where we can use our skills to facilitate agreement between stakeholders to help enable value for our stakeholders. A little investment in the short term can yield significant benefits in the long term.

There are many other sources of pressure besides these, and the key thing for us to do as BAs is to spend time understanding where the pressure comes from—an important point being that the place where the pressure is released (i.e. a stakeholder asserting a deadline) probably isn’t where the pressure started. Much as we seek ‘root causes’ in our project analysis work, we should do the same within our projects too. That way, we can work with our stakeholders to improve the situation and ensure that the project is valuable and successful.