Author: Adrian Reed

As business analysts, we’ll often come across situations in our organizations where everything seems so siloed.

Processes fail because different teams fight over the work or, more usually, try to throw work over the fence without understanding the needs of other teams.  As change professionals, we strive to take a holistic view, looking across the organization to achieve the best possible outcomes.  We model processes, we navigate conflict and we balance tricky stakeholder perspectives.

It would be easy for us to think that these types of silos are things that are built by “other” people.  It would be easy to assume that as BAs we are somehow “objective” and would never build or reinforce invisible boundaries between teams or professions.  We might conclude that it’s those awkward stakeholders who cause all the problems, after all we see across teams and see a broader picture…

I’m sure nobody would really make this set of assumptions, but you might recognize elements that resonate with your work.  The idea of the BA being ‘objective’ and somehow detached is a fairly common one, but there are serious questions over how ‘objective’ anyone can really be. Ultimately don’t we all view the world through the lens of our experience?  In the dim and distant past I’ve conducted work in call-center environments that (in my view) utilized targets and incentives very poorly.  Management in many call-centers has moved on a lot since then, but I still find myself making assumptions based on my prior experience.  Would I see and observe call-centers in the same way if I hadn’t had that experience? Would I ask the same questions and frame the situation in the same way? Probably not, we all have cognitive biases that get in the way.

Of course, I’m at least aware of how this particular set of experiences might color my view, and being aware of a ‘lens’ is perhaps the first step to seeing past it.  However, this raises a further interesting question: Given we’re just as fallible and subject to cognitive biases as our stakeholders (we are human after all), what other ‘traps’ do we fall into?

Watch Out For Change Silos

If you want to make a group of BAs laugh, ask them “What does a Project Manager do?”. The ‘healthy tension’ between the PM and BA community exists for all sorts of historical reasons, and although I’m probably guilty of using that exact joke in the past, I’m coming to realise it’s a cheap and unhelpful shot. In project and program environments organizations need someone to manage the project, and need at least some elements of that ‘healthy tension’. Yes, many PMs do things that frustrate BAs (the number of times I’ve had a deadline imposed upon me, rather than discussed with me…) but I’m certain BAs do things that frustrate PMs too (see Christina Lovelock’s fantastic article ‘when BAs go Bad’ for a few examples).  Shouldn’t we seek to collaborate, share and cross-pollinate rather than build our identity around ‘not being PMs’? 

Realistically, in today’s change initiatives (whether they run as projects or not, and whether they are waterfall, agile or something in between) we’ll need to collaborate with a whole range of different disciplines: User experience, researchers, data scientists, business architects, testers and many, many more.  Having a clear delineation of responsibility is important—we need to know who does what—but does that really have to be down to someone’s title?  With an increasing expectation that we will be T-Shaped professionals, surely it’s beneficial for knowledge and experience to permeate into our world from others, and vice versa?  How exciting is it to ask “what happens when you blend business analysis and User Experience” or “How could elements of Systems Thinking be relevant for us as BAs?”. When ideas, experience and knowledge flow across the boundaries, surely everyone wins?

Thinking Outside of the BOKS

Ah, but what about the BOKs, I hear you say! The Bodies of Knowledge. Don’t they reinforce silos and drag us back towards tension and competition?  That certainly isn’t how I interpret the situation. Taking the Business Analysis Body of Knowledge (BABOK) Guide as an example, a business analyst is defined as:

“Any person who performs business analysis tasks described in the BABOK Guide, no matter their job title or organizational role”  (BABOK v3, emphasis added)

This implies that there may be many people doing elements of business analysis who don’t identify as business analysts.  It’s an inclusive definition recognizing that in reality roles blur and what is ‘best’ for a situation depends on context. Additionally, we might take our ‘BA hat off’ temporarily and borrow ideas/techniques from other disciplines. 

Let’s seize upon this inclusivity and invite others in, show them what we know but also consciously learn from them.  If we appreciate that in most cases the constraints and silos are in our own heads and with mutual will we can overcome them, perhaps we can become smarter and more effective change practitioners. 

I’m willing to try. Are you?

“If you’re interested in meeting other change professionals from different industries and professions, check out the Project World * Business Analyst World conferences.  You can hear speakers from both the PM and BA professions!”

A while back I used to work for a large corporate organization.  I had a company-issued laptop that was heavily encrypted and locked down.

It wasn’t the greatest specification, and whilst it worked well most of the time, there were times when it would crawl along.  Perhaps you’ve had a similar work laptop—the type that suddenly grinds to a halt with its internal fan on overdrive just as you have that horrible realization that you hadn’t saved the document you were working on, or just as you try and access that vital document that you need to present in a project meeting….

Since it was a Windows machine, I’d do the CTRL+ALT+DELETE shuffle.  You know the deal, pressing that special combination of keys in a panic and accessing the mystical ‘task manager’ to see if there were applications or processes hogging the processor that I didn’t need.  After killing a few, the laptop would generally work well again, for a while at least.  This got me through until the company upgraded the laptops and upgraded the version of Windows, after which things consistently worked much better (I was lucky!).

Channeling Our Own Inner ‘Task Manager’

Of course, this blog isn’t really about laptops, but I was reflecting on these memories and it struck me how we fall into a similar pattern as practitioners.  Have you ever got to your desk, and felt that uncomfortable pang of stress as you know you have far too much to do, more than is actually achievable?  You’re on twenty projects, you’re trying to plan a requirements elicitation session but your attention is drawn to the hundreds of other tasks that seem urgent.  The irony seems to be that this leads to procrastination:  There’s too much to do, so where should we start?  Perhaps you find yourself looking through your lengthy to-do list for the hundredth time (we’ve all been there) still failing to choose a task to start on. Or perhaps you start a task, only to remember another is more urgent.  Then somebody instant messages you about another urgent task, so your attention is switched again… and so the cycle continues.

Situations like this can be extremely stressful.  Of course, we all have tough deadlines, and an achievable deadline can actually be quite motivating (who hasn’t experienced the great feeling when celebrating achieving an ambitious deadline?).  However, unachievable and arbitrary deadlines just seem to put us in ‘panic’ and ‘preservation’ mode.  As we flip-flop between tasks, desperately trying to put out all of the most urgent fires, everything takes longer.  Our attention is drawn from task A to task B and we end up with lots of things that are 95% done.  Sadly, in many situations “95% done” is a vanity metric, in reality it just means “not done”. It often means “not done, and blocking someone else”.  Sometimes it means “not done, and people are incessantly chasing…”, which makes things even harder to balance (as now there’s messages to respond to as well).

There are many reasons we can feel overwhelmed, and much like a laptop it might be that we are trying to process too many things simultaneously.  If there are too many things on our to-do list, then realistically we have a few distinct choices. For each item we’ll have options that might include:

• Doing it now
• Scheduling it and doing it later
• Agreeing a set of conditions when it’ll get done (e.g. “When team X complete task Y, we’ll do this…)
• Getting someone else to do it
• Automating it or doing it differently
• Not doing it (striking it from the list)

So when feeling overwhelmed as we all feel from time to time, why not (metaphorically) press CTRL+ALT+DELETE on our own operating systems? Why not take time to breath, reflect and to ask ourselves the hard (but crucial) questions: “Am I trying to do too much here?” and “Am I actually being ineffective by indulging in too much task switching?”.  By preserving our ‘processing power’ for those things that really matter in the short and long term, we can increase focus and shut out the noise.  Like a ‘task manager’ on a laptop, we can choose to shut down things that aren’t necessary and are slowing us down.

It Starts With A List

If you open “task manager” on a laptop, you’ll notice it shows a list of everything that’s in progress.  This is a pretty good place to start if you feel that paralyzing pang of overwhelm.  You might even want to consider creating a personal Kanban board to see what you have ‘to do’ and what’s ‘in progress’.  Chances are you’ll find too many things ‘in progress’, and that can act as a catalyst for a conversation over which to focus on (and how to stop the situation occurring in future).    You might even choose to use the list above (do it now, schedule it, automate it etc) to work out how to handle each item whilst avoiding having too many ‘plates spinning’ at any one time.   When looking at a to-do list clinically, it can be amazing how many things don’t actually need to be done at all.  Their time has passed, they were once needed but they are now defunct.  

A quick exercise like this can help instill a sense of calm. This type of approach can help us get out of the immediate feeling of being overwhelmed, and focused on the immediate work. We should also consider how we got there in the first place and take any necessary corrective action.  Reflecting and changing ensures that we reduce the risk of becoming overloaded in the future, and also that we retain time in our diaries for the ‘important but not yet urgent’ items.  Things like professional development planning, making that dentist’s appointment that you’ve been meaning to do for four weeks might not be urgent yet.  When you’re in agony because your minor dental problem has escalated, or when you suddenly find some of your skills are considered out-of-date because you’ve neglected professional development for years, the urgency increases but the options are reduced.  Ironically, we’re back to ‘overwhelm’

In summary: If you feel that pang of overwhelm, why not imagine pressing CTRL+ALT+DELETE, pausing, and seeing what’s taking up your processing time? A short pause for breath now can help us prioritize for the marathon ahead.

When designing services, it can be very useful to create a set of personas. If you haven’t come across personas, it’s well worth checking them out and using them.

In essence a persona represents an archetypal stakeholder, a ‘fictional’ character representing a group of users with similar characteristics, motivations, attitudes or behaviors. Each ‘persona’ is typically given a name, a photo and some basic characteristics and it is a great way of injecting the ‘voice of the customer’ into the definition and design of processes and IT systems. Stakeholders start to ask questions like “Hang on, have we forgotten Dave—he values personal advice by phone—how would he feel about this change?” or “Have we considered Natasha’s needs here? She spends a lot of time on the road so will probably be accessing our web services on a cell-phone… have we covered this?”. It can create some great debates and shows the tensions that can often exist: Building something that is just perfect for one group often makes things worse for another if we aren’t careful…

To be most effective, personas need to be built on some kind of insight or data. IIBA®’s Business Analysis Body of Knowledge (BABOK®) guide states:

“Research is conducted to understand the user group, and the personas are then created based upon knowledge rather than opinion.” (BABOK® v3, p.357)

There is of course room for personas based on a hypothesis, these are sometimes known as ‘proto personas’, but we ought to be very wary of personas built entirely on conjecture. If we build them based purely on what the project team thinks, there is a significant danger that we’ll end up building a solution that works for the users we expect rather than the users that actually exist. Even worse, we might end up building the solution that we would like, rather than one that our users would find useful…

Watch Out For Unsubstantiated Stereotypes

A warning sign to look out for is when the personas appear very broad and appear to be based on anecdotes and popular buzzwords. Perhaps you see “Paula the millennial” who is representing the tech-savvy, time-poor, impatient user group, and “Bob the Boomer” who represents a retiree who is less tech savvy. This might be appropriate in some situations, but let’s step back and think about it for a second. ‘Millennials’ is often used to mean anyone born between 1981 – 1996 — that’s a fifteen year window. What on earth would make us think that the life experience of someone in 1981 is anything like that of 1996? In the words of Cee Lo Green “I guess he’s an Xbox and I’m more Atari….”.

Dig further and we’ll find even more inconsistencies. If we were defining services for a financial services company, someone born in (say) 1995 who grew up in the care system and has never had a bank account is likely to have a very different experience and knowledge of financial services to (say) someone born the same year who had parents who have paid into a trust fund. What on earth would make us think they have the same needs, just because they were born in the same year? The same is true, of course, of boomers—and the assertion that older people can’t use technology is a vast oversimplification. I’m sure many of us have seen our older relatives join the social media revolution.

A Key Question To Ask

A question that we should become comfortable asking is “What customer data or insight are we basing this decision on?”. Quite often this will be met with a blank stare—that’s OK. Sometimes our colleagues might not have had the opportunity to do any research yet. We can help them assess what data already exists, what questions need to be asked and how we might assemble any data or insight that’s needed. We can help spot the gaps in data and discuss how to address this, or if this isn’t possible we can at least ensure that the decision makers are aware of the risk. Either way, we can work with our stakeholders to build early customer validation into our delivery process so we get early and regular feedback so that we can adjust.

Keeping the various types of users and stakeholders in mind enables us to define a service that works well for the broadest range of people whilst also delivering the outcomes our organization needs. We shouldn’t be afraid to ‘raise the red flag’ and ask probing questions if the data is lacking.

Information security is a crucial consideration for just about every organization in existence today. 

In a world where there is an increased expectation for transparency, privacy and that security breaches will be strictly punished, security should be at the forefront of our minds not just with what our projects deliver but also how we run our projects.

Customers often expect to be able to interact with organizations digitally and this creates additional concerns and risks.  Whilst we should of course keep the clear and present cybersecurity risks front of mind, we shouldn’t ignore the broader information security risks which might have nothing to do with the particular technology or process that we’re working on.  In fact, it’s an opportunity to ask some crucial questions about existing processes that may have emerged years ago that are no longer fit for purpose.

When The Website Is Secure But The Phone Line Is Not…

More years ago than I like to admit, I worked on a project for a company that was developing an online portal for its customers.  Understandably there was a lot of interaction with security experts and architects, some very robust non-functional requirements, and lots and lots of testing.  However, in retrospect we probably made the online processes so secure that even authorized users couldn’t access them!  Having a password that expires after (say) one month is probably pretty irritating if an ‘average’ customer accesses their account once or twice per year…

This created somewhat of a dilemma in the team.  There was a group of internal stakeholders representing customers who wanted to focus on ease of use.  There were another group of stakeholders who had an interest in ensuring compliance and managing risk who wanted to focus on impenetrable security.  The challenge, it turns out, is to find a sensible balance between the two.  Perhaps you’ve experienced this on your projects too?

In examining this dilemma, two very pertinent questions were asked:

• “How else can customers engage with us?”
• “What security protocols are there via those channels?”

This turned out to be a very enlightening line of inquiry!  A bit of digging found out that if a customer (or someone purporting to be the customer) rang, they’d be identified based on pieces of information that were held on file—typically things like full name, address, postal code, date of birth and so on.  This sounds sensible, doesn’t it?  But think broadly: who knows this information about you?  Probably many of your neighbors (particularly those who you’ve invited to your birthday party) and a proportion of your colleagues too!

This wasn’t even the worst of it.  The second channel of communication was post.  This was a good few years ago now, and post was regularly received from customers.  It turned out there was no validation whatsoever on instructions sent by post.  “Ah, but we have their signature!” a stakeholder might say.  “Great, and what do you compare that against, is there a master signature for each customer…?”. Awkward silence.

Cybersecurity Is Crucial: But Don’t Forget Broader Information Security

Here we were in a situation where new processes were being subjected to very sensible checks and balances that didn’t exist on other channels.  This creates a useful opportunity to ask: “are we being too risk averse here?  If not, do the same risks exist for other channels? And if so, shouldn’t we strengthen them too?”.

In many cases, it’ll be completely sensible to continue with a focus on cybersecurity on new stuff whilst also tightening up older processes that might not have been examined for many years.  In doing so we help promote a more holistic view on risk, and help reduce the risk of fraud or information leakage.  Whilst large-scale IT system breaches might mean that a huge quantity of data is compromised, and of course we should protect against this, we shouldn’t underestimate the reputational damage of one or two personal records being misappropriated for fraudulent reasons.

As with so much of what we do as business analysts, ensuring a systemic and holistic approach, working with our stakeholders to zoom out and see the ‘wood’ as well as the ‘trees’ is where we earn our crust.

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.