Author: Adrian Reed

A while ago, I was working in a team alongside a fantastic, capable and experienced Senior BA.

As far as I could work out he was far more effective at the job than I was, but he seemed to struggle to get put on the ‘exciting’ projects and this seemed to be wearing him down. Having worked with him, I couldn’t ever really understand why this was the case, so I tentatively broached the topic with him over coffee one day. I can still remember the words he said to me:

“I can do the job well, but there’s a perception gap and this means I don’t get the types of assignment I want. I need to get better at reputation management.”

I was really puzzled at what he meant by this and the importance of his words only really sunk in months later. The reality was that he was a capable business analyst, who would just get the job done. But think about the ‘heroes’ that are visible and who get rewarded in most organizations. Do organizations celebrate people who quietly navigate their way through the complexity, maneuver through seemingly impossible conflict and get projects delivered right, first time, every time? Or do they celebrate those who noisily and visibly navigate the ‘difficult’ project that is over-time and over-budget (ironically sometimes because expectations weren’t properly managed in the first place), those who heroically get the project over the line (exhausting a project team as they do so)?

Sadly, in many organizations it seems to be the latter—it’s the hero who pulls back the ‘difficult’ project who is celebrated. The quiet, almost stealth-like yet effective practitioner is easily overlooked. You can imagine a manager passing them over for a promotion, saying “Ah, but they’ve had easy projects… they’ve not seen the kind of conflict that our project hero has seen”. Yet when was the last time you saw an easy project? They are all, in my experience at least, difficult—just in different ways. My colleague had picked up on this perception gap, and was working on solving it.

Reputation is Everything

In most organizations I’ve seen, reputation is everything. Sure, there’s a formal organizational chart. And there are professional development plans, and reporting lines and all of those things are important. Yet there are also people who have influence who aren’t in positions of authority. As business analysts, we often ‘lead from the middle’—shepherd people from different areas together, to define and work towards a common goal. Without formal authority, we rely instead on our reputation and our interpersonal skills. We build relationships, we listen and we work up, down and across the ‘formal’ organizational chart.

Yet, most BAs I know (myself included) are somewhat reluctant to shout about our project successes. We’re happy for others to take the credit—after all, change is always a team endeavor. In doing so, we risk becoming quiet stealth-like practitioners who are inadvertently overlooked. This is the point my colleague so articulately made over coffee all those years ago.

Communication Is Crucial

Reputation management is important at multiple levels. It is important for us as individual practitioners, for teams, and even for our discipline (industry bodies such as IIBA have a huge part to play here). There are steps that we can take as individuals to be aware of, and manage, our own reputation. Here are a few ideas:

• Have a BA communication plan: Figure out who to communicate to, and when, on a project. Communicate not just what is working well, but also the bad stuff. Show how having a BA has led to positive outcomes.
• Build relationships: Working as a BA, we meet people all of the time. It’s useful to stay in touch with them—with little other motive than a genuine curiosity in what they do. They’ll likely be curious about business analysis too, and this is an excellent opportunity to ensure that they (and their team) know what business analysis is.
• Don’t suffer in silence: There’s an old expression “a lack of planning on your part does not constitute an emergency on mine”, and this applies just as much to business analysis as it does to others. Of course, we should pull together and help out in times of need. But where there’s a significant and ongoing lack of planning we should shout. We often have a unique perspective, and we can help keep things on the rails. A short, well-timed, pause can often save months of pain.
• Springboard off each other: Building a reputation as an excellent (individual) BA is great. Even better is enhancing the overall reputation of a team. Working together to enhance the perception of business analysis generally is even more impactful.
• Always be learning: Things change, a lot. We should all expect to be continually learning and developing so that we can serve our stakeholders as effectively as possible.
• Celebrate successes: Business analysis is a crucial discipline and we add so much to change initiatives. We shouldn’t be afraid of shouting about things that have gone well, collecting case studies and showing where our efforts made a real difference.

Of course, there are many other possibilities too. The main thing is to avoid being the stealthy, silent and ‘quiet’ practitioner, to avoid being the ‘hero’, but to consciously choose to be one that delivers effectively whilst communicating appropriately. Reputation management can play a key part of that.

Episode 10: Data analytics: What does it take to be a BA with Adrian Reed

Key learning points:

Help individuals recognize the opportunities of a career in business analysis. Provide insight to professionals looking to start a career in business analysis and help them understand the skillset necessary to support a career in business analysis.

Listen here:
{source}

{/source}

Bio:

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’

It always amazes me how much information is captured, processed and conveyed during the process of checking in, boarding and flying on a plane.

I’m sure there is much more that happens in the background too, that we don’t see, as pilots co-ordinate with air traffic control to agree the flight path and get a take-off or landing slot.

I recently reflected on a journey I’d taken and it struck me how important when designing any service, process or system that we truly understand our customers, stakeholders and users, and in particular that we identify their information needs. If we bombard people with information, they’ll tune out (and may miss something important). If we don’t communicate enough, then people often get frustrated, confused or anxious, and tend to call in or contact a representative. Of course, it’s easy to say ‘we need to communicate just the right amount in our processes’, but it’s quite another thing to actually do this. There will be some information that we need them to know, and other pieces that they want or need to know. It’s a tricky balance, and layered on top of this is the fact that these types of considerations can get clouded by traditions of communication. This probably sounds rather abstract, so let’s take an example:

Traditions of Communication: Who cares which runway we’re taking off from?

Think back to the last time you travelled on an airplane. I’d guess that at some point the Captain or First Officer made an announcement to introduce themselves, and they may well have told you a whole range of details about the upcoming flight. I’m not entirely sure why they make this announcement, and I wonder if it is some type of aviation tradition. Perhaps there was once an important reason for the passengers to know this, or perhaps it is just for interest or courtesy. On a recent flight I was on, the announcement included which runway we’d be departing from, the initial direction we’d be heading, the fact we’d be taking a ‘turn’ mid-way through the flight and so on. These are details that are crucial for the pilots, but perhaps not so crucial for an average passenger to know.

If you’re anything like me, it’s very easy to tune out during those types of announcement. I guess that some people are interested in which runway we’re taking off from, and whether we’ll be approaching the destination from an Easterly or Westerly direction, but since I’m not an aviation enthusiast, this is information that flows straight over my head. In fact, three things I generally do want to know which aren’t always mentioned are:

• Will there be a food service, and if so roughly when (so I know whether to have that chocolate bar I bought in the terminal now or later)
• What will the approximate time be that we get into the terminal (flight time is useful, but what I really want to know is what time I’ll be at the terminal collecting my bags. In fact, I really want to know the estimated time I’ll be leaving the terminal so I can check my onward plans still work!)
• Roughly what time will we be landing (so I can make sure I finish any work up and put my laptop away before the seatbelt signs go on—nothing worse than having to frantically save a document mid-thought when the air steward is asking you to urgently put all bags under the seat in front of you!).

Now, I realize I’m probably not a typical traveler, but I can’t believe I’m the only one that would find these pieces of information useful. Of course, providing them requires co-ordination with other organizations (e.g. the destination airport), so providing them might be tricky, and even then it’d be tricky to provide the information only to those that wanted it. However, a broader point here is that there is a process communicating information that at least some service users are tuning out from, and there is other information that isn’t being provided that some service users would find useful.

The Relevance for Business Analysis: Understanding Customers, Users, Stakeholders and Beneficiaries

This is a general pattern that seems to exist in processes and services (whether online or offline) more generally. Check in to a hotel and the receptionist will often launch into a pre-prepared script about the features of the hotel, rather than asking what the traveler wants to know. Log in to many online systems and there are confusing dashboards of information that provide every conceivable piece of information, ironically making any one specific piece of information virtually impossible to find. (We’ve probably all used platforms where the navigation is so poor you have to go to the ‘search’ or ‘sitemap’ or ‘FAQs’).

All of this points back to an important facet of business analysis—that is the importance of understanding the customers, users, stakeholders and beneficiaries of a particular system, process or service. We need to call out and challenge traditions of communication. Just because we have ‘always done it that way’ doesn’t mean that it’s the most efficient or effective way. We ought to keep our customers front-and-center and ask what information they need and want.

In fact, we are rarely specifying and designing a service for one ‘generic’ customer type—there will be many. Researching and understanding their goals and also their information needs is key. By doing so, we can ensure that we ‘serve up’ appropriate information to them at the right times, so they feel fully informed and comfortable. This will also reduce the amount of failure demand where people ask for clarification of unclear information. Techniques such as personas and journey mapping are useful tools for us to utilize in these circumstances.

I suspect that many of us in the business analysis community have extremely hectic day-jobs.

We shuttle back and forth between meetings, working to efficiently elicit and articulate business and stakeholder needs. We navigate political conflict and aim to get our stakeholders ‘on the same page’ so that we can facilitate the delivery of effective change. It certainly isn’t always a 9 to 5 job, and with pressing deadlines being a seemingly constant feature of life, finding time for any kind of ‘extracurricular’ activities can be difficult.

When the pressure is on, it can be very easy to put personal, professional and career development to one side. I suspect many people reading this will have delayed or ‘parked’ going on a training course or attending a conference because pressures from the day job prevented it. In many cases this is completely understandable, after all there are often crucial reasons why deadlines must get met. However, it is all too easy for this to become a recurring pattern. When things are seemingly always chaotic, when there are always fires to put out, it can seem impossible to take time out for these types of developmental activities.

Learning from Terminator

Now, I admit that 1980s Sci-Fi isn’t a usual source of inspiration for business analysis…but…the following phrase from the 1985 film Terminator always sticks with me. There is a scene where the lead protagonist (Sarah Connor) is serving in a restaurant, and a child drops ice-cream down her apron. Fellow server Nancy says:

“Look at it this way, in 100 years, who is going to care”

In the whirlwind of change that we live in, it is all-to-easy to sweat the small stuff. Let’s face it, we’ve probably all worked on projects that have had their funding pulled, or have been cancelled half way through. Some of us have probably worked on processes and systems that have been replaced shortly after launch due to other, bigger organizational changes such as mergers or some kind of other major change. You know that work-related thing that you (or I) am worrying about right now, that’s (metaphorically) keeping us up at night? Chances are nobody will remember it in one year let alone one hundred. Some things will be distant memories in a few months.

The harsh reality: Assignments (And Jobs) Are Temporary

Over the years, I’ve been fortunate enough to be in teams that are led by very inspirational managers and team leaders. I remember one leader reminding me, in a one-to-one, of the temporary nature of jobs. He was very clear that sometimes it’s important to focus on individual needs even when things are seemingly ‘busy’. There is probably no good time to take a few days out for training, a conference, or even vacation. Yet if we work for an organization where (for example) we have to cancel professional development activities that were booked months in advance, what does this say about the planning and management capabilities? What does it say about the long term prospects for that organization? There may be very good reasons, but it would at the very least be a concern.

Whilst it’s crucially important that we contribute as much as we can to the organization, we mustn’t forget that jobs and projects are ultimately temporary. I suspect almost everyone reading this will have, at some point in their career, been put at risk of redundancy (or will know someone that has). Whilst loyalty to our employer or client is crucial, loyalty to ourselves is equally important. Dependence on an employer (where the employee feels they have no other option) can be toxic; having an independent relationship (where you know you have the skills and qualifications to walk away but choose to stay because you love it) is surely a better model.

Owning Professional Development

It’s also important that we note that that well-chosen and well-planned professional development activities don’t just benefit us as analysts, they help us develop new competencies that we can use in our day jobs. Perhaps we can work with our stakeholders not only to put out the (metaphorical) fires, but also to get to root causes. We can stay fresh, stay sharp, and be ready for any assignment that comes our way.

Many organizations are extremely supportive of these types of activity, but the ultimate responsibility and accountability rests with us as practitioners. There are so many professional development opportunities out there, whether it’s attending courses, conferences, IIBA Chapter events, reading or writing blogs or many of the other options that exist. It doesn’t have to be time consuming or expensive, and there are many cost-effective (even free) options that we can pursue even if our current employer won’t support us.

After all: If we don’t own and control our own professional development, then who does?

A few weeks ago I was working away from home, and I was able to attend an IIBA UK event in the evening.

It was a really enjoyable event, and after meeting a whole bunch of new people and chatting about all things BA related, I went and checked in to my hotel. As I was checking in, the receptionist asked me how my day had gone. I explained that it had been busy, and I’d spent a few hours networking late into the evening. As much as I enjoy networking (I love meeting new people and sharing/learning), I do find it exhausting. As he handed me my key, the receptionist said something that really surprised me:

“Ah, I used to do a lot of networking. Kills the hands, doesn’t it? All that terminating. I used to work for a communication company so I did a lot of networking”.

Perhaps it was because I was tired, but I did the typically British thing and just smiled and accepted the statement that he’d made without questioning it–but on my way to my room I was puzzling over what he’d said. Why would networking hurt his hands? Too many handshakes maybe? And why would you terminate something at a networking event… that sounds pretty serious! And why is the fact he worked for a communication company important…

Then the penny dropped. Networking has different meanings, and I suspect he was referring to laying physical networking cables in a data center or communication room, where cables have to be crimped and (presumably) ‘terminated’. Perhaps using some of the tools is uncomfortable after a while. “An evening networking” to me means meeting other BAs and having a coffee. To him it meant navigating cables in a comms room ‘out of hours’ getting everything ready before people arrive the next day.

The Illusion of Communication

As William H. Wyte once wrote “The great enemy of communication, we find, is the illusion of it.”. This is often the case inside organizations and between organizations too. With our plethora of acronyms and words with ‘special meanings’, it is easy to appear that we are agreeing on a particular issue, idea or requirement, only to find out that each person at the table has a subtly different understanding of what is being discussed.

Even words that appear, on the surface, to be obvious can have different meanings depending on who you ask. The word ‘customer’ might seem clear and obvious, but it is quite possible that different people attribute different meanings to it. Who is the ‘customer’ of a training course? The delegate who attends it? The company that employs the delegate (assuming they are paying)? Probably both–although both will have subtly different needs and requirements, only some of which overlap. This is made even more complicated in intermediated industries where there might be an end customer, and one (or many) intermediaries. If a financial service company sells products via brokers, some might refer to the broker as a ‘customer’, others might refer to the end investor as the ‘customer’. Again, they’ll have very different needs and requirements.

This can lead to all sorts of crossed-communication throughout the business change lifecycle, not least when it comes to requirements. Whether we’re writing user stories, use cases or even a heavy-weight requirements catalogue, it pays to think about terminology. This is where the good, old, trustworthy glossary comes in.

A glossary perhaps isn’t the first thing that springs to our minds as business analysts. It’s something we know we probably should do, but with the pressures of a project it can be easy to let it slide. This simple experience, with a misunderstanding over the word ‘networking’, reminded me how important they are. After all, with a clear glossary, writing just about any type of requirement artifact becomes easier. If there is a clear and agreed meaning of “Investor” and “Broker”, for example (rather than using a term like “Customer” that might mean either, or both) we can be concise and precise in our requirements writing.

This potential for misunderstanding also highlights the need for techniques that don’t rely on the written word. Visual techniques, including formal modeling, can help explore the problem space and requirement scope too. All of these activities help us cultivate conversations and help us ask “what exactly do you mean by ‘x’?”. Not only this, but a well-defined glossary can help inform the production of other artefacts such as a concept model (these are clearly different things, but defining terms up front helps a great deal).

In summary

A glossary might take some time to create and maintain, but it’ll help avoid ambiguity and ensure we can create concise and precise requirements. It is an investment in time worth making.