Skip to main content

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 http://www.adrianreed.co.uk and follow him on Twitter at http://twitter.com/UKAdrianReed

Strings Attached: The Art of Adapting Templates in Business Analysis

I’ve recently started learning to play the ukulele. I made a decision early on that I’m not interested in learning ‘properly’, I don’t want to commit to formal lessons, I just want to try a fun new hobby. For that reason, the (very little) I’ve learned has been learned largely from YouTube.

When I say I’m not learning ‘properly’, I’m really just learning chords and tabs, I’m not reading sheet music and I’m pretty much just strumming along to the YouTube videos. That is perfectly fine for what I am aiming for, I never want to be a professional, I just want to play some simplified versions of songs I know.

 

In the dim and distant past I took piano lessons. Back then I could read sheet music (in treble and bass clef), knew about timing and some of the theory behind music. That knowledge has all gone now, and I have no idea how to play a piece of sheet music on the ukulele!

Now, you probably didn’t come here to read about ukulele playing, but there is relevance here, I promise! It’s all down to application within a context.

 

From Ukuleles To BA Templates

One of the things that I see a lot on social media is people asking for (and providing) BA templates. There’s a huge draw in using a template, it means that you don’t have to start from scratch. Things like templates and checklists can be very useful to make sure there’s consistency, and to make sure things don’t get forgotten.  (I have a travel checklist for that very reason.)

Yet a template without an understanding of the underlying theory and rationale can be dangerous. It can lead to slavish adoption (“well, I need to put this diagram in, because there’s a section for it… the template is ‘best practice’ after all”).  Just like my ukulele playing will always be restricted by my lack of music theory, someone who picks up a template without understanding why the template was created that way and what techniques can potentially accompany it will likely run into issues.

 

Advertisement

 

An Example: “BRD for the Financial Services Industry”

Let’s take an entirely fictional example and imagine that somebody produces a Business Requirements Document for the Financial Services Industry.  It is pitched as a document that will likely be used in a waterfall or incremental delivery environment, and includes a context diagram, use case diagram, scenarios, functional requirements, non-functional requirements and so on.

It’s hard to criticize any of those sections, there will be times when all of those are useful. But what if the person picking it up doesn’t know what a context diagram is? Even if they do, the whole act of eliciting information to construct a context diagram is an artform in itself.

Or, what about if you’re making a tiny change to the label on a single field? Are you really going to fill in all of those sections? You might, in some circumstances, but in all probability something more lightweight would be appropriate. In fact, a prototype alone might suffice…

Of course, this is a deliberately provocative example, but I’m sure you see the point. There really is no ‘one size fits all’ in business analysis. So much is down to context, and understanding the context is key.

 

However: Templates Can Be Useful

It is worth clarifying here that I am absolutely not arguing against templates, nor am I arguing against the appropriate sharing of templates on social media. They are extremely useful, when used appropriately by skilled practitioners. They can even act as a guide to less-experienced practitioners providing this is accompanied by a desire to learn the underlying theory and techniques.

However, templates are also most useful when they are flexible. What works in one situation won’t work in all, so cut a section, or add a section! It’s important to think about the purpose of the artifact, its consumers and how persistent it is (i.e. how long it is expected to remain current for).

Like so much in change, pragmatic and intelligent application is what matters.

Connecting the Dots: The Crucial Role of Synthesis

A few years ago, I was working in a fast-paced environment where we very quickly needed to achieve a shared understanding of a particular problem that existed, and then elicit and analyze requirements for improving things.

 

I’d spent a couple of days speaking to some of the key people, largely in back-to-back meetings, and I was working really late in the office, energized by the conversations I’d been having. I’d managed to find an empty meeting room where I could spread my notes over a large table to think things through. Over the past couple of days I’d had countless conversations, been given documents to read, been shown IT systems, processes and more… It was a lot to take in! Plus of course not everyone necessarily agreed on the nature of the problem, or even what a desirable solution would look like. So my thoughts went to “what next… how do I arrange and make sense of all of this ‘stuff’?”

Luckily, the meeting room had a whiteboard. I instinctively started drawing the ‘problem’ that had been described to me. I drew people, IT systems, data and information flow, customer interactions, bottlenecks, problems.  It was a messy drawing that wasn’t intended for anyone but me.  If you’re familiar with the idea of a rich picture, it was very much like that. Crucially, it helped me make connections between pieces of information that different stakeholders had told me. This act of synthesis—bringing things together—helped gain a more holistic picture of what was going on.

I was midway through pondering whether two concepts were related to each other, when a very senior stakeholder walked through the door. He asked what I was drawing, and I talked him through my messy diagram. He started instinctively adding things to it, not only adding his perspective to the mix but also highlighting things I’d missed (or misunderstood). Even though this happened years ago, I can still remember parts of the diagram now….

 

Analysis Needs Synthesis

Of course, that drawing on a whiteboard was really just an interim work product. It wasn’t a deliverable, and although I recorded it by taking a photo, it wasn’t ever intended to form part of any user stories or requirements documentation. It was really just an exploration of the problem domain and the connections within it. It helped me to get my own head around the situation, so that I could ask better questions and know which areas to examine further. It also helped me to understand which areas and perspectives I was missing.

This highlights the importance of synthesis as well as analysis. Synthesis is described by the Merriam-Webster online dictionary as:

“…the composition or combination of parts or elements so as to form a whole…”

 

There are of course other definitions too, but this sentence is particularly useful for us as BAs. It’s very easy to think that our job is elicitation and analysis, capturing different viewpoints and pieces of information about a situation.  Yet without synthesis, those different pieces of information are of limited use! There will likely be contradiction, conflict, different views and more.  We all instinctively know this, but it is worth highlighting how important synthesis is in what we do.

 

Advertisement

 

Synthesis Techniques

Ironically, many of the techniques that we use on a day-to-day basis have synthesis, as well as analysis, built at their core.  I have already mentioned a rich picture, but many other techniques (when used with synthesis in mind) can help in bringing together different pieces of information and viewpoints.  Here are just a few examples:

  • Concept model and glossary: Bringing together (and reconciling) different terms, and the connections between terms
  • Process model: Creating a view on how the work should take place, taking into account a number of stakeholder’s viewpoints
  • Prototype: Bringing together and testing assumptions made, or a set of requirements assembled from varying stakeholders,.
  • Multiple Cause Diagram: After conducting ‘5 whys’ with different stakeholders, creating a combined diagram and presenting it back and saying “what else?” and “what’s wrong here?”
  • Workshops: Bringing people together to synthesis and discuss their views
  • … and many more besides

 

The Importance and Relevance

To do our jobs well as BAs, we need to consider synthesis as well as analysis, and this means making time for it. In my opening example, I mentioned I was working late in the office, drawing on a whiteboard. I was working late that night mainly because I was energized and excited about the project but also because time was so short and I’d focussed on planning the elicitation but less so the synthesis of the information I’d gleaned.

When you’ve conducted a whole number of interviews, read documents, seen processes and systems as they are operated, there are so many sources of information. It’s easy to just jump on to the next elicitation activity, or jump straight to writing a problem statement (or user story) or whatever. Yet, doing so robs us of the opportunity to see the bigger picture.

Building in time for synthesis—the sort that allows us to see connections—will help ensure we don’t implement a change in one area that inadvertently makes things much worse elsewhere. Of course, time is always tight… but if we don’t make time for synthesis, we might end up having to make time for rework. And that’s definitely best avoided!

 

Prints, Processes, and Pitfalls: More Than Just Process Design!

I was recently planning the logistics of an upcoming client workshop. I needed 12 copies of a document printed and spiral bound, and I visited the website of a printing company that we’ve used many times before for such tasks. The website had changed, and unfortunately I couldn’t complete the order.  For some reason the website was saying it couldn’t deliver to my address.

 

I’m pretty sure I know why this is.  I live in Portsmouth, on the South Coast of the UK, and to the uninitiated, some Portsmouth postal codes look similar to postal codes used on the Isle of Wight. I suspect some courier firms don’t deliver to the Isle of Wight (or charge extra as it’s an island with no roads connecting it to the mainland). This leads to some online sites (incorrectly) lumping some or all of the post codes together and tag them as an ‘exception’.  This is really, really, bad design, but it definitely happens.

I was trying to place the order on a weekend, so I waited until Monday and went to contact the company by phone. I tried to phone shortly after 9, and then again at 9.30, and then again at 9.45. No reply.  So, even though I’d used this company many times in the past, I just moved on to another supplier. And in fact, I’ll probably use this new supplier in the future, too. So the original printing supplier has lost a customer and it doesn’t even know that. Plus, it missed the opportunity to get feedback about the defect on their website… I wonder how many other cities/postal codes are affected? How many other sales are being routinely lost?

 

Considering The Customer’s Pivotal Moments In Process Design

As a business analyst, this experience made me think about process and operational design. While the example above was an example of bad design, it is impossible to design an IT system, interface or process that truly caters for every situation, nor (in most situations) would you usually want to. Sure, some call centers might have a process which defines the detailed steps to take if the President of the United States calls from a satellite phone while onboard Air Force One and asks for a message to be passed urgently to the CEO… but not many!

The point here is that there will be certain types of situations that are:

 

  • Predictable, but very unlikely and/or uniquely complicated
  • Difficult (or impossible) to predict, with unknown levels of likelihood or complexity
  • Unintended, where with the best will in the world (and lots of testing) still something unexpected has happened which has led to an unintended consequence

 

The first set (predictable) are deliberately not fully catered for by a process as they are either so unlikely that spending time specifying them is overkill, or they are so uniquely complicated that anything beyond broad guidelines can’t be issued. I’d imagine that large companies have a “respond to media request” process which ensures that any inquiry from a TV station or newspaper gets to the right person. The broad process will be structured, and the response will likely be logged in a consistent way. However, how the response is formulated is probably somewhat variable, and more likely subject to guidelines and principles than a strict process. Responding to a request for a photo of the CEO to accompany a “top 10 CEOs” article is likely to be somewhat different to responding to notification that a documentary will be airing showing evidence of corruption within the company!

 

The second set of (difficult or impossible to predict) conditions can’t be catered for as they are unknown, or the effort of trying to predict them is so great that it is prohibitive.  The final set (unintended consequences) are, by their nature, unpredicted! The key here is to find them when they occur and rectify not just the individual case, but the root causes. Taking my printing example, had I got through to the first printing company, I suspect they’d have quoted me via phone and manually processed the order. Great—except the website is still faulty and swathes of other customers might be affected. Understanding what needs to change to prevent the issue happening again is key.

 

So, what aspects can be considered when designing customer journeys, IT systems and/or processes to cater for these types of situations?

 

Advertisement

 

Flexibility, Feedback and Responsiveness are Key Factors

Assuming an organization wants to handle these types of cases, it’s key to design processes with feedback mechanisms built in. Feedback should of course include opportunities for customer or user feedback, but it can also include feedback generated by the process itself.

Take the printing company example I mentioned earlier. As a nationwide printing firm, they are almost certainly finding that there’s been a minor drop in Sales (Portsmouth is a relatively big city, but probably not big enough that the drop in printing sales would ring any warning bells) and the distribution of where they are sending parcels has changed. A curious analyst diving into the data might say “hmmm, it’s odd, there are entire cities where we are no longer sending parcels… maybe we should look into that”.  Making sure diagnostic data is captured and examined is important, and this is so much more than just performance data.

It’s also important to ensure there’s a viable support option and, yes, this does usually mean ensuring someone can speak to (or communicate somehow with) a human being when they need to! That support person or team needs to have sufficient autonomy and be empowered to raise issues for investigation. A team that just “raises tickets” and passes them on to others is unlikely to cut it.

 

Finally, it’s important to note that processes will need to change and this should be expected. Building in responsiveness to the environment is important. Expectations will change, the way people communicate will change and so forth. By designing processes with this in mind, and ensuring they are owned, reviewed and adapted when needed, is a small but important step towards agility.  As BAs, we can often nudge towards this way of thinking, and every step in the right direction is a good thing!

 

 

Editing for Success: Applying Hollywood Wisdom to Projects

I’ve long been a believer that a good movie is 90 – 120 minutes long. Sure, there’s the occasional storyline that can keep my attention for longer than that, but generally speaking after a couple of hours I’m getting pretty restless. One of the reasons I rarely go to the movie theater these days is that films seem to be getting longer and longer, and unlike watching at home I can’t press ‘pause’ in the theater!

 

It turns out that I’m not alone. Celebrated film director Sir Ridley Scott, who directed films including Alien, Gladiator and Blade Runner recently spoke about the ‘bum ache’ (‘butt ache’) factor of films. Too long sitting down and apparently movie-goers will get uncomfortable, and this is something that he takes account of in his editing. A classic case of “less is more”, and a director being empathetic to his audience.

 

Less Is More

I know virtually nothing about movie production, but I’m guessing that it is probably technically easier to produce and distribute a long film than it was, say, 40 years ago. I gather that in the past films came on multiple spools, all of which had to be physically duplicated and distributed. Apparently since the early 2000s, films have been distributed digitally to theaters. With fewer constraints, you could have a ten hour film if you really wanted it.

Yet being unconstrained isn’t a good thing. I’m guessing few people are lining up to watch the ten hour film “Paint Drying” (which is a real film, but was a protest against the cost of censorship). The fact that it’s possible to do something because a constraint is removed doesn’t mean that it’s actually a good thing to do. Sometimes constraints can foster creativity.

 

From Hollywood To Projects: Time As A Constraint

I’m guessing that you probably don’t work on Hollywood movies, but there’s a direct parallel with projects here. After all, a Hollywood movie brings together a collection of specialists for a period of time to create a deliverable that will generate benefits for its sponsor… which sounds strongly analogous to a project!

One constraint that you and I probably come up against frequently is time.  There never seems to be enough, and time is always the thing being squeezed. It is easy to become somewhat jaded to this, and either just accept the deadline (but implicitly know that it’ll never be met) or rally against it.

Certainly, calling out unrealistic deadlines is an important thing to do. Yet, in some circumstances an alternative approach is to test the constraint and see how it balances against others.

 

Advertisement

 

Let’s imagine that a sponsor has set a deadline of 1st January for the launch of a product or project deliverable. We feel there’s a risk that this is an arbitrary deadline, so we start to tactfully ask “if it was two weeks later, but 10% cheaper, would that be beneficial?”.  If the sponsor says “Absolutely, yes!” then we know that they probably value the budget over a fixed deadline.  Or we might ask “How about we delivered it on that date, but the quality was lower?”. They might answer “No! Absolutely not”, at which point we know quality is paramount. We might ask these types of questions about all sorts of things, including scope, timeframe, deliverables, style of delivery and so on.

What we’re doing here is understanding which are hard constraints that genuinely can’t change (or, there would be a significantly negative impact of breaching) and those that can potentially bend. Not achieving regulatory compliance by a mandated date, where the regulator is strict and there’s a significant fine, might be an example of a hard deadline. It’s better to pay more now, and dedicate more resources to ensure compliance. Other things which appear to be constraints might be more malleable.

 

Product Management and Business Analysis as Film Editing

Once the hard constraints are identified, it’s tempting to be deflated. Rarely are we dealing with a situation where there’s too much time, resources and budget. Yet another way of looking at this is to think about the movie theater experience… sometimes less is more. Much as an ambitious scriptwriter might have a scene cut because it’s not essential to the story (or the location is too expensive to hire), we can ‘edit’ elements of a project or product in or out.

This probably sounds obvious, I mean scoping and prioritization is crucial. Yet, too often scoping and prioritization are carried out somewhat in isolation. It’s easy to end up with an incoherent set of features, or (worse) to find that only the person who shouts the loudest gets what they want…

 

If we reframe this as a process of ‘editing’, then we are keeping in mind the coherence and desirability of the product as a whole. Imagine asking twenty people for their favorite ever scenes in movies. Perhaps one mentions a scene from Wargames, another from the Barbie movie, another from Love Actually and so on.  Now imagine making a film out of these ‘best’ scenes… it wouldn’t make any sense.  The same can be true of a product too. If the features aren’t coherent it can become somewhat of a Frankenstein’s monster that is difficult to use and doesn’t really serve any single purpose well.

Another thing about editing is that it involves compromises and making difficult decisions. I’d guess actors probably hate having their biggest scene cut. And script writers probably hate being told they can’t have that on-location scene in Barbados due to budgetary cuts. But, it is the editing that means that the film makes money (achieves its financial outcomes) while also providing an experience that the consumer wants (achieving another of its core purposes).

 

I suspect this is a balance that we all tread on our projects and products, and bringing it to the fore and making tradeoffs transparently and purposefully can only be a good thing!

Beyond the Finish Line: Understanding the Art of Value Enablement

We recently needed some repair work done to the roof of our house, so called some local roofing firms. Understandably, roofers don’t always answer their phones immediately (I guess they are often out on site working), so we left voicemails for three different roofers.

Out of the voicemails we left, only two of the roofers replied. Both came round, inspected the roof, and explained what needed to be done. They both said they had availability and would send over a quote showing how much the work would cost. However, only one of the roofers actually sent a quote. We accepted the quote and I’m pleased to say that the work is now complete.  But this got me thinking about business, business analysis, and value-enablement more generally.

 

Close, But Stopped Short

Let’s examine the approaches that the different roofers took. The first one didn’t reply. We might argue that this is bad customer service, but if they knew they were busy and had no shortage of business, then not replying might be an acceptable thing to do. It might not be a good long-term approach, but it doesn’t waste any of my time or their time. So while I might have preferred them to drop over a quick reply, I can understand why they didn’t.

The roofer who I really don’t understand is the one who came out, inspected the roof, but didn’t follow up with an estimate. They were so close to actually getting the work, but they failed because they didn’t carry out the final task. They’d spent time (and gas) driving out to see the roof, only to implicitly ‘give up’ by not following up. I found this really puzzling!

 

Advertisement

 

When Is Value Enabled?

This led me to think about value in a broader context, and I think it has some interesting parallels with business analysis. The roofer did all the work to potentially enable some value for him (payment) and for me (a fixed roof), but stopped just before a crucial moment.

In a project or product context, usually we are building (or changing) something with the purpose of enabling value for a range of stakeholders. The value that is enabled may vary for each stakeholder group. A retail bank releasing an app might provide convenience for its customers, while also saving money (and increasing profit) for its shareholders. For the app to be a success, it needs to balance the different perspectives on value. If it’s inconvenient, or hard to use, it’ll backfire—it might actually increase the number of times people call the call center, meaning operational costs increase. Knowing what different groups value is important so that this balance can be struck.

Yet as well as knowing what value can be enabled, it’s important to know when that happens and what the precursors are. Imagine a bank released a self-service banking app but didn’t advertise it to its customers. Sure, some early adopters might find it in the app store, but there would be a range of people who would use it if they knew about it that probably aren’t actively looking for it. Delivering the app without a communications and engagement plan alongside might end up being similar to the roofer who didn’t send a quote… it stops just short of the line for value enablement.

 

Finding The Finish Line

It is worth fostering discussions over what needs to happen not just for a product or project to be delivered, but what needs to happen for value to be enabled. It is too easy to stop just short of the finish line and declare success prematurely. “On time” and “on budget” are important aspects, but “on strategy” and “on benefit” are things that make a long-term difference. In the fog of urgency, it’s important that we don’t lose sight of these.

As James Clear comments in his book Atomic Habits, there’s an old saying that “the last mile is the least crowded”. Perhaps that’s just as true in a project and product context, and by focusing on the last mile and cultivating conversations about value we can help achieve better results for our stakeholders and communities. And surely that’s worthwhile?