Author: Adrian Reed

Typically when specifying and designing a product it is the functional requirements that get a lot of time in the spotlight. After all, it is what customers or users will be able to do with the product that is really important.  It is, to some extent, the functionality that people actually “buy”—and it is the functionality that enables them to achieve some kind of goal, complete a task, or solve a problem. You might buy a washing machine because you want an easy way of doing the laundry. A washing machine that doesn’t provide that functionality is not going to sell well at all!

Yet often functionality becomes a commodity, and non-functional elements act as a differentiator. I’m no expert, but as a consumer, I’d say most washing machines fulfill pretty much the same functionality. Some have more programs than others, but I’ll be honest, in our house, we only use about two of them. And when I’m putting the washing on, I pretty much choose one at random anyway. So the decision of which washing machine might end up being bought is based on a combination of price but also looks and quality. If the functionality is broadly the same, then I might buy the one that looks best and fits with the other appliances in the house. Or, I might buy the one that has the longer warranty (which implies the manufacturer is more confident about the quality).

Advertisement

These aspects (reliability, look & feel) are examples of two non-functional aspects of the product and they are vitally important. It is sometimes thought that non-functional aspects (and therefore the Non-Functional Requirements) are relevant only for automated or technical solutions or products, but in reality, they are relevant for just about any type of solution—even if that solution is entirely manual. Let’s take one specific example: Security.

Security of Manual Processes

Another well-known category of NFR is security. If we were to expand this category out, we would likely conclude that in large part it is referring to information security. Amongst other things, it is important that the organization’s intellectual property doesn’t ‘leak’ and that the company doesn’t inadvertently disclose confidential information to an unauthorized source.

Quite rightly, there is a focus on hardening computer systems to make them as difficult to hack as possible. However, how often is the security of manual processes considered? How often are staff trained on ‘social engineering, where an imposter attempts to get sensitive information by deception? The answer might be “not nearly enough”.

This might sound somewhat abstract, so let’s examine a hypothetical example. Think back to the last time you rang a service provider to ask a question or make a change. You probably had to “clear security” by answering lots of different questions. If you wanted to see information about an account you hold online, you probably had a series of passwords to enter. But, what about if you put a letter in the mail. Would the same processes apply, or would the request just get ‘actioned’? In some organizations, requests that come via mail get routinely actioned without much scrutiny. Sometimes the rationale stated for this is that “a letter contains a signature, so it’s authenticated”. To which I would ask “do you compare it against a sample of the client’s signature? If not, how is it providing any type of authentication?”.

This could end up being the first chink in the armor. A clever social engineer might change the address associated with the customer’s record, perhaps to an anonymous rented mailbox. They can then collect statements, which they can use as proof of identity. They might even glean information about the other types of accounts that the person holds. Better yet, after a few weeks, they can change the address back so the target never knows they were ‘hacked’. Yet this ‘hacking’ happened without any IT intrusion whatsoever—the ‘hacker’ simply wrote in and asked!

Conclusion: NFRs aren’t just for IT!

So, hopefully, I’ve convinced you that security doesn’t just apply to IT. What about other categories of NFR? They are usually just as relevant, elements like performance, back-up, disaster recovery… it doesn’t matter if your solution is entirely manual you still need to work out what would happen if something unexpected happens. The IIBA Business Analysis Body of Knowledge Guide (BABOK®) suggests 15 common categories of NFR (see BABOK® section 10.30), and this is the tip of the iceberg, it’s usually sensible to expand upon these based on the individual circumstances. Typically, many of these are relevant irrespective of the type of solution. We ignore NFRs at our peril!

In an increasingly competitive business environment, organizations seek ways to differentiate. Many companies focus on customer experience as a key area where things can be improved. In the past, customers may have put up with poor support and slow service, but when the competitive forces are high and switching costs are low it is easy for them to vote with their feet. In fact, they might also share their experiences on review sites and social media too, tarnishing the company’s reputation!

There are many ways that customer experience can be enhanced, but one way is to provide information to the customer to set their expectations throughout. This sounds so trivial but it can make a huge difference. Being told “your delivery will arrive sometime on Monday” is nowhere near as convenient and useful as being told, “your delivery will arrive between 9 and 9.45 on Monday. We’ll text you when the driver is ten minutes away”.

Advertisement

However, information like this only actually improves customer experience if it is reliable and accurate. I’ll give you a real example: I was waiting in for a grocery delivery due between 11 am and 1 pm and the supermarket’s app said that the driver was 12 stops away and would be at least an hour. Since I had at least an hour, I got absorbed with work and got into the flow. I was surprised when five minutes later the delivery driver arrived and knocked on the door.

It wasn’t a major problem, but I was curious so I asked the delivery driver how his day was going. “Oh, it’s been a nightmare. A whole bunch of customers wasn’t actually in. I don’t understand why people book slots and then go out”. I explained to him that the app shows a specific delivery time, to which he responded “oh yeah, I’d ignore that. It’s always wrong. I don’t know what they base that on”. I smiled, repressing my BA tendency to ask more questions!

Inaccurate Information Can Make Things Worse

In this example, it seems the company had tried to provide useful information to its customers but had actually done so in a way that made things worse for the customer and its staff. Think of the waste, all because the information provided to customers was not accurate:

● The delivery driver drives to addresses where people are out
● Customers don’t get their shopping
● Some food perishes as it isn’t delivered
● Other food has to be restocked back at the delivery center
● The customer services team have to contact the customers and arrange re-delivery
● Some customers probably just decide to switch and shop elsewhere
● And more besides…

This is just one example, you have almost certainly experienced similar situations yourself as a consumer. It is worth keeping these kinds of factors in mind when designing processes and services: asking what information customers need, but also ensuring that it can be provided accurately.

As the example above illustrates, giving inaccurate information can have a negative effect on customers and create waste too. This is something definitely best avoided, and an area where BAs can spot improvement opportunities!

One of the wonderful things about working as a change practitioner is the regular contact with stakeholders. Most change initiatives involve liaising with a whole range of different people, each having a different perspective on the potential change being discussed. Some will avidly support the initiative, and some are likely to be a little more, well, awkward. Some might actively oppose the change and might do everything they can to stop it.

A lot of very good material has been written about stakeholder analysis and engagement, in this article I want to examine a slightly different angle: that of stakeholder comfort.

How Comfortable Are You?

One phrase that BAs look out for is: “…because we’ve always done it that way”. Perhaps you’ve heard this phrase yourself, it’s typically given when stakeholders are undertaking a task or process in a particular way and don’t necessarily know the underlying reasons why. These tasks and processes are often ripe for improvement; there usually is a reason why the process was designed in a particular way, but it may well link to an old constraint that is no longer relevant. By querying the (now defunct) constraint we can look at simplifying, streamlining, and improving things.

Advertisement

Yet sometimes stakeholders get noticeably concerned or skeptical about such changes. As a change practitioner, this can be hard to understand. After all, if we are making things better for the process operator and the customer, while simultaneously saving money, surely this is a clear win/win situation? Well, yes and no… sadly things are rarely that simple.

One thing that needs to be considered too is whether the change is so radical that it would be vastly uncomfortable for those who are directly impacted by it. Things which seem relatively innocuous on paper (a desk move) can be hugely impactful to those involved (“but now I can’t sit next to the team I’ve been working with for 20 years”). Changes that seem like a “no brainer” to those specifying them (“let’s encourage customers to use the website to order rather than ringing by phone”) might cause genuine discomfort to people undertaking the current work (“does that mean I’ll be made redundant?”) and might even make some customers uncomfortable (“but I like using the phone as I can ask for advice”).

You’d be forgiven for thinking that the best option here is to “manage” the stakeholders, to “formulate communications to educate them” and “get them on board”. That is an option that can sometimes be appropriate. However, another, perhaps more human option is to actively work to understand the specific areas that are causing them discomfort. This is important because:

(a) They are unlikely to be truly ‘on board’ while that discomfort remains
(b) They might know something that completely changes the game (i.e. their objection might be well-founded!)

It seems that the word ‘comfort’, at least in the English language, is less pointed and blame-ridden than other words. Ask “why won’t you support this change?” and it might be assumed that you’re making an accusation. Yet a phrase such as “I sense you’re not 100% comfortable with the proposal, can you elaborate on why this is?” might gain a more productive response.

Getting OK With Discomfort

Now, it’s important to say at this point that some discomfort should be expected with change generally and there won’t always be a clear reason for it. Ever bought a new pair of shoes? Even though you knew they were better than the last pair, they probably rubbed for a while. You might have craved your old pair, and perhaps you even slipped back into them a few times. A similar pattern is to be expected with any kind of change within an organization, it often takes time (and support) for everyone impacted and involved to get on board and get up to speed. This is where regular engagement, listening, and connection with those involved and impacted are so important. Over time, it’s possible to gain a deeper understanding of the discomfort, which will make formulating effective support easier.

In summary: stakeholder analysis and engagement are crucial, and an important aspect of this is understanding how comfortable stakeholders are. Asking this directly can be an effective way of understanding objections and working to resolve them.

What are your thoughts? Do you consider stakeholder comfort levels? I’d love to hear from you, feel free to connect with me on LinkedIn and we can keep the conversation going!

It may sound harsh, but I’d estimate that around 90% of the “big topics” that are discussed within the business change community wouldn’t interest end customers at all. This isn’t to say that the debates aren’t important, it’s just that the specific nuances that people get so heated about within the change community are just so unexciting to the folks who are actually on the receiving end of that change. If you’re trying to battle to book a train reservation and the website is so badly designed that you give up, you probably don’t care whether that website is developed and maintained using agile approaches, waterfall, “the Spotify model” or something else. You probably don’t care whether the webserver is “on-premise” or not and whether the development was conducted in-house or whether it was outsourced. You just want the website to work so that you can get on with your day—you just want stuff to work the first time, consistently. The technicalities of how that works (and how the tech and processes were delivered) are pretty uninteresting to most end-customers.

Of course, the very reason that the website doesn’t work well might be because of some kind of design issue which crept in because of mismanagement of one of those very issues I just mentioned, so there’s no intention to underplay them. However, in the same way, that you or I probably don’t think too much about the pipes that carry the water to our houses, customers don’t tend to think about the processes and technology that delivers a service to them until it goes wrong. The key then is to understand what is desirable from a customer’s perspective and consistently deliver it.

Advertisement

Customers are, after all, focused on achieving outcomes. They want to get something done, usually as effectively and efficiently as possible and then get on with their lives.

Organizational processes usually balance achieving something for the end-customer which also benefits the organization itself (e.g. selling a train ticket and operating a train service allows a customer to get to their destination while also generating revenue for the operating company).

Focus On Outcomes: The Jargon Doesn’t Matter

It’s really easy to lose sight of these business and customer outcomes. Buzzwords start to emerge and take on a life of their own. Projects get initiated to “create a profound digital channel shift on our legacy portfolio”. OK, I made that up, but it probably sounds familiar: the point is it is pretty meaningless to a customer. I’m not sure many customers of, say, an energy company have woken up and thought “I really want a profound channel shift today!”. They probably just want regular payments taken, on time, with accurate and predictable billing. If the organization isn’t doing the basics right, then it should probably focus there before it considers any kind of other major change.

Now it might be that providing an online presence is important. Certainly, I’m a customer that uses online services a lot, but the ‘win’ there is often convenience. The moment that convenience is compromised, I’ll revert to offline mechanisms.  We’ve probably all dealt with companies where the online route is just too complicated and long-winded, so what do you do? Pick up the phone…

This highlights the importance of knowing what different stakeholder groups value. Techniques like personas and proto-personas can be extremely helpful here, particularly when the goals of the stakeholder are clearly identified and shown. Empathy mapping can also be very enlightening.

Conclusion: Keeping The Customer (And The Outcomes) Close

In conclusion, it’s easy to get blind-sided by methods, tools, and approaches. These are all important, but they are a means to an end.  Keeping the customers and outcomes in mind, and gaining a deep appreciation of what customers actually want (rather than focusing on the internal jargon) is crucial.  There are many tools in the BA toolkit for this, and BAs are well centered to help keep outcomes front-and-center throughout.

It’s no secret that people are key to implementing successful change.  Projects don’t happen in a vacuum, and there will usually be a wide range of stakeholder perspectives that need to be considered, and a broad range of people who need to be ‘on board’ with the change.  It’s unsurprising then that BAs and PMs spend a fair amount of time working with stakeholders, and with a wide range of stakeholders involved there can be conflict.  This conflict can manifest itself in all sorts of ways, in some cases an individual might choose to do everything they can to block a project and be as awkward as they possibly can.  Another stakeholder might say they support the project in public, but then do everything they can to thwart it in private (while also rejecting every meeting request so that progress stalls).

When situations like this occur, it’s very easy to sink your head into your hands and shout ‘Those awkward stakeholders! Why won’t they just get with the program!’.  It can be particularly frustrating when an individual has had (seemingly) hundreds of opportunities to raise a concern, yet the time they decide to raise it is twenty minutes before go-live on a Sunday afternoon where everyone is already under extreme pressure.  As frustrating as these situations are, and as tempting as it is to blame the stakeholders themselves, it is usually more valuable to take a step back and say ‘how did we get to this situation?’

Assume The Best Of Intentions: They’re Not Trying To Screw-Up Your Day!

In most organizations, it’s fair to assume that the vast majority of people want to do a good job.  Hopefully very few people come to work to actively sabotage the company, and those that do will (hopefully) get weeded out through the company’s HR and monitoring processes. Some stakeholders, particularly those outside of the organization, might have agendas and objectives that differ from those of the organization, but they will have objectives that make complete logical sense to them.  A school might focus on ensuring the best possible outcome for an entire cohort of students; an individual parent is likely to care more about the outcome of their child.  Both perspectives are logical and understandable, but could occasionally lead to conflict where the needs of the individual child are opposed to the wider cohort (“My child is so far ahead, why can’t you go quicker!”).

As hard as it is to do when the pressure is mounting, it’s usually best to assume that our stakeholders are acting with good intentions unless we can categorically prove otherwise.  That compliance manager who decides to butt in with a new regulation 5 minutes before go-live probably isn’t doing it for kicks, they are probably doing it because they’ve only just ‘joined the dots’ and have seen how relevant it is.  For every business analyst that says “That stakeholder is really awkward, they always raise objections too late…” there is probably a stakeholder saying “That BA is really awkward, they bombard me with useless information, and then when I do raise a concern they complain!”.

This comes back to the crucial discipline of stakeholder engagement.  If we don’t engage and communicate with stakeholders in a way that works for us and for them, we’ll likely end up talking cross-purposes with assumptions (or misunderstandings) on both sides.

Helping People ‘Connect The Dots’

As much as stakeholder engagement is important (and it really is important), an aspect that is sometimes overlooked is why it is done.  Is it really done just to elicit information and ‘get people on board’?  If so, isn’t that a little one sided?  Surely it’s important to consider what’s in it for the project, the organization and the stakeholder (or group) themselves? Otherwise it’s not two-way engagement at all, it’s just a self-serving and time-sapping project monologue, something that I’m sure we’re all keen to avoid!

One aspect to this that often isn’t talked about enough is the way that good quality engagement and communication helps people ‘connect the dots’. For example speaking with a wide range of stakeholders will help the project team understand different perspectives, how different parts of a process work and so on.  Equally this helps the stakeholders themselves connect the dots and figure out how the change will affect them and how they can contribute to its creation.  By truly listening and empathizing we can proactively help others to make these connections, while also making them ourselves.  By actively listening and asking probing questions we can preempt where later conflict might emerge.  By getting concerns and issues on the table early, we can ensure they are discussed and escalated and that the person is genuinely heard.

Traditional stakeholder identification and categorization approaches such as the stakeholder interest/impact grid, stakeholder rainbow, stakeholder onion and others are helpful (to an extent) in helping us figure out who we need to engage, when and how often.  Yet how we engage and the content of our communication is harder.  Actively asking questions such as “how can I help join the dots… for me and them?” and “What’s in it for them?” can help frame the conversation.

And perhaps, just perhaps, ‘connecting the dots’ is a key part of the BA role that we do by default and need to talk about more….

What are your views? Do you ‘connect the dots’? I’d love to hear your experiences. Please feel free to connect with me on LinkedIn and keep the conversation going!