When implementing a change in an organisation—whether it’s a process change, an IT change or even an organisational change—it is good practice to map out the stakeholder landscape and understand who the key players are within the organisation. I’m certain everyone reading this article will have read many useful articles in the past about how to identify, categorise and manage stakeholders. This discipline encourages us to think about who is impacted by a particular change or initiative, and who has some kind of power or control over it.
When identifying stakeholders in this way, it will inevitably be important to identify the customer. Clearly the end-user of the product or service being developed or changed is paramount. Yet who we class as the customer might not be clear-cut, and is likely to require additional thinking. In fact, there may be unforeseen pitfalls awaiting us if we don’t consider this thoroughly. Take the following example scenarios:
When an organisation needs a specialist skill, product or service, it may be more effective to look outside of its organisational boundaries. Perhaps a company needs a special IT application, a training course, or perhaps it is looking to outsource an ancillary function. In these situations, it is common practice to “go out to tender” issuing a tender document such as an Invitation to Tender (ITT), Request for Information (RFI) or Request for Proposal (RFP). These documents typically provide an outline of the organisation’s requirements, a list of structured questions, and provide instructions on how the supplier should respond. Responses might be invited from vendors, Managed Service Providers (MSPs) or other types of specialist provider.
These tender processes enable an organisation to compare and contrast a short-list of suppliers, and enable them to assess which is most likely to suit their needs. Often a formal scoring process is used to weigh up the pros and cons of each supplier (for more information on a weighting and scoring approach you can download a white paper I wrote on the subject). The RFI/RFP will be followed by meetings and product demonstrations where the scoring can be tweaked and finalised. This is a very sensible approach, and helps to remove any unintentional biases that may emerge. It can be very easy to inadvertently favour the product that has the salesperson with whom you have warmed to the most, or with whom you’ve built best rapport — and a more formal process reduces the likelihood of this happening.
Whilst these formal processes are extremely useful, there is a common pitfall waiting. Fundamentally, this type of structured tender process assumes that the client knows enough about their requirements — and the likely solutions — to ask the right questions. In many cases, the client will be extremely well informed, particularly if the RFI and RFP have been prepared by a professional business analyst. To borrow an expression from Donald Rumsfeld, but what if there is an “unknown unknown”, a piece of information that the client needs, that they don’t yet know they need?
This probably sounds cryptic, so let me give you an example. A few years ago, I wanted to replace my car. I have never particularly enjoyed driving, and I’ve always driven boring (but economical) cars. I was looking on a used car website, and I found one that I wanted to look at. I started to formulate a list of questions I should ask and things I should look for when I took it for a test drive. I was discussing this list with a friend, who gave me a piece of advice:
So, it’s confession time. I’m embarrassed to admit that I love Karaoke. I really enjoy the atmosphere in pubs and bars on karaoke night, and I really enjoy hearing the good (and bad) renditions of songs that people sing. I don’t actually sing myself (with a few rare exceptions), but I try to get to a karaoke night once every few weeks and soak up the atmosphere.
A couple of weeks ago, I wandered into a karaoke night at my local pub and ordered a round of drinks for me and my friends. As I was queuing at the bar, I noticed that the singer seemed really good—which seemed a sure sign that we were in for a good night! Then, singer after singer came up and they were all really good. This came as a surprise to me. Normally once the beers start flowing, there are some—well—less than good performances. I was intrigued…
I got closer to the front and I watched the karaoke DJ closely. As I got closer, I noticed the DJ was making subtle adjustments to his sound deck. As a singer started, he added echo (reverb) to their voice. He decreased the volume of the vocals and increased the backing track. At certain points, from behind the scenes, he sang along into a second microphone, ‘filling out’ the singer’s voice. In some cases, he turned down the singer’s vocals quite a bit and turned the backing track up a lot! The karaoke DJ was doing everything he could to make each singer sound as good as possible—even if they had no natural singing ability—to avoid embarrassment and ensure everyone had a good time. And he was doing this seamlessly, unnoticeably and in the background.
Sure, you could still tell the really talented singers from the less talented ones, but the DJ’s work ensured that nobody got embarrassed and everyone enjoyed themselves.
As I thought about this an ordered another round of drinks, it struck me that we fulfil a similar role as business analysts. OK, we’re unlikely to DJ in a karaoke bar (unless we’re on a very specific type of project!) but we often work in the background, tirelessly to make sure that our stakeholders get the best outcome. Not only this, if we do our job right, our stakeholders will probably be the people that (quite rightly) step into the limelight. But for every person in the limelight, there are countless others supporting them in the wings.