Time really does fly! I can’t quite believe it’s just two weeks until the start of the Business Analysis Conference Europe 2015 (#BA2015). As I plan a final few practice runs of my presentation, I can’t help but get a little excited about the event – it’s always a real highlight of the BA calendar. Every year the conference attracts such a wide variety of delegates and speakers, it’s such a great place to meet people and hear new ideas.
The conference gets bigger every year and, and I’m pleased to say that there are still tickets available — so if you’ve been thinking about attending, it’s not too late! You can find out more details about the conference by clicking the link below. And remember, IIBA UK members are entitled to a 15% discount.
I highly recommend attending the conference, if you can. There are fantastic presentations from real-world practitioners, and there’s also the opportunity to relax and chat over a beer (or two) after the conference has closed. If you haven’t been before, I’d highly recommend taking a look.
If you’re attending, drop me a mail or tweet and we can catch up.
When implementing a new solution within an organisation, communicating and gaining a common understanding of the requirements is crucial. One way of achieving this level of common understanding is to put together a requirements package. The content and style of that package may vary dramatically depending on the organisational context, the nature and size of the problem being solved, and whether the initiative is being delivered in a predictive (waterfall) or adaptive (agile/evolutionary) fashion. Either way, the requirements package is crucial as it helps communicate what the organisation needs.
The focus, quite rightly, when putting this together will be on capturing, analysing and validating the needs of the organisation’s stakeholders. The focus will be on articulating these requirements precisely and succinctly – and it is very tempting to focus purely on the requirements. Yet there are other useful items that we might choose to include that can help to remove ambiguity and create clarity.
In this article we’ll examine two other items that we might choose to include in our requirements package to help aid understanding. Both are relatively simple, but are easy to overlook:
Procuring solutions from third party vendors can be a beneficial way of implementing change without having to build a solution from scratch. When in need of a specific system or IT based solution, an organisation might investigate procuring an ‘off-the-shelf’ solution from a specialist vendor or managed service provider (MSP). When in need of a new capability, they may choose to outsource specific business processes to a trusted third party. Looking externally can help an organisation to avoid having to ‘re-invent the wheel’, and can enable them to utilise the expertise of teams that have implemented similar solutions many times before.
However, procurement of this type—particularly on large scale initiatives—can be tricky. It will often involve a formal vendor assessment phase where the client organisation will liaise with a range of potential suppliers and will assess which solution is a best fit for their needs. It is likely that they’ll run an Invitation to Tender (ITT) or a Request for Information (RFI) and Request for Proposal (RFP) process. Third party vendors will respond and will bid for the business, and the client will make their selection based on the vendors’ proposals.
This initial phase is normally run on a very tight timescale. The client is (understandably) keen to ‘hit the ground running, and they will quite rightly issue a tight deadline to the vendors. Each vendor will put together a team to assemble a proposal and pitch to the client and will be keen to ensure they are offering the right solution to the client, and will be keen to give the opportunity to showcase their solution’s features. The client will be keen to ensure that their requirements are understood, and each vendor will be keen to showcase the alignment of their solution to the client’s needs (as well as highlighting any unique selling points).
Implementing any kind of meaningful change in an organisation is rarely easy. Even the most successful project is likely to hit a rough patch now and again where something unwelcome and unexpected happens. Good risk management can minimise the problems, but even with this in place there can be unanticipated situations that hit us from the left-field.
Colin Powell is quoted as saying “Bad news is not like wine. It does not improve with age”. In situations where problems occur, it’s crucial that we assess the impact, understand the available options, engage and communicate with our key stakeholders, sponsor or client. This can often be a difficult conversation – but much better to have a difficult conversation early than an awkward conversation later! Bringing issues to the table early allows us to discuss a range of options that might not be available if we hold fire until the fire burns out of control. The longer we wait, the more time we burn – and the options we have start to evaporate.
However, when working as an internal business analyst, or even when working for a vendor or managed service provider (MSP) delivering a solution for a client, situations can be complicated. Some environments can be politically charged, and there might be the perception that speaking openly can be rather career limiting. When working with an external client there may be the added risk of losing an entire series of contracts—which would not land well!
Yet, in most circumstances it is best for us to heed Colin Powell’s advice. A diplomatic, open and honest conversation now, while the news is fresh, is better than an awkward and embarrassing conversation in six months’ time when the situation has festered.
So how can we ensure that these conversations are fruitful? The following tips can be useful:
One common activity to outsource is the development, maintenance and configuration of software applications. This might involve buying a standard package “off the shelf” and gaining help to customise it, or in other cases it may necessitate the design and development of a completely bespoke system from the ground up. The effort required can range from a small enhancement requiring a few hours development and testing, right through to gargantuan projects requiring large multi-disciplined teams.
I’m sure everyone reading this blog will have had some involvement in a project of this nature—whether on the supplier or client side. Perhaps you’re a developer, a business analyst, or a subject matter expert that helped input to the project. And if you’ve been on a project of this type, I’d bet that at some point something didn’t go to plan. In fact, if you’ve worked on a large and high-profile project, there were probably times of stress when unexpected problems emerged from the shadows like sinister spectres from a Hollywood horror movie. Whether waterfall, agile, incremental or iterative—the one certainty with projects seems to be that something unexpected and unwelcome will happen. And whilst good risk management may help us mitigate the impact, we’re unlikely to eliminate it completely. That’s before we start to talk about the unknown unknowns.
It strikes me that there are two very different ways an organisation can respond:
Response A: Play the blame game: When trouble emerges, a deliciously tempting option is to immediately apportion blame. Typically, the client and vendor or MSP blame each other. Things soon get heated. You can imagine a client saying;
“Why are there so many delays in getting this simple feature implemented? The supplier is in breach of contract!”
The vendor may have a different view;
“There are good reasons for the delays. None of their stakeholders were available for interview, we never got any requirements from them, and they forgot to mention the 27 other legacy systems we’d need to interface with!”
In reality, both perspectives may be valid. Yet, apportioning blame just entrenches people in a lose/lose turf war where political games are played for pure political gain. People start spending more time sending e-mails and writing extensive documentation to “cover themselves,” rather than undertaking productive work. Documents become unnecessarily heavier, communication becomes unnecessarily formal and this clogs up the development process. The schedule slips further…
Very soon, relationships deteriorate further. Dialogue becomes confrontational, and everyone works long hours. After several weeks working 14 hour days, the key stakeholders burn out and quality suffers. Everyone resents the project, everyone is blaming everyone else. The project is just about pushed over the line—and when it is the vendor and client walk away from each other. Both are left with a sour taste in their mouths, and all their staff are in serious need of a vacation.
Response B: Acknowledge the root-cause, pivot to deliver: This is at the opposite of the spectrum. When trouble emerges, the client and vendor or MSP have an open and frank dialogue. Each works to understand each other’s point of view. Discussions about blame might need to be held—but these are deferred. What is important now is to understand the root cause, generate options, get things moving and prevent problems recurring.
These conversations aren’t easy or comfortable—but, when carried out ethically and with integrity they work. Conversations are held often, allowing potential problems to be discussed as soon as they are identified. Problems are kept in plain view for all to see—nobody tries to subvert the truth or paint a better picture of progress for political advantage. There is no hiding of bad news.
Collaborative task forces work to resolve issues. When an approach isn’t working, the team pivot rather than doggedly sticking to an ineffective path. This pivoting happens at multiple levels—from the everyday detail (“That two hour status meeting is pointless, couldn’t we find another way of staying in touch that doesn’t burn our diaries?”), right through to the fundamental (“Our business environment has changed and we need a significant change to scope, but we need to manage it within our existing budget. What can we achieve within that constraint?”)
The culture and leadership directly cultivate the environment in which this choice is made, but as practitioners of change, we all have the ability and responsibility to ‘nudge’ our projects one way or the other.
I know which environment I’d rather work in…
So, what’s it to be? Response A or Response B?
How do you help avoid the blame game? What are your experiences and tips? I’d love to hear from you. Please add a comment below.
This post was brought to you by IBM for MSPs and opinions are my own. To read more on this topic, visit IBM’s PivotPoint. Dedicated to providing valuable insight from industry thought leaders, PivotPoint offers expertise to help you develop, differentiate and scale your business.
As many of you know, I’m enthusiastically believe in the value that good quality Business Analysis can bring, and I love speaking,writing and presenting on this and many other topics! In a break from my normal ‘blog style, I have a very quick update for you.
The conference is always a highlight of my year, as it provides a real melting pot of ideas. It’s a great place to meet other BAs and exchange knowledge. There are fantastic presentations from real-world practitioners, and there’s also the opportunity to relax and chat over a beer (or two) after the conference has closed. If you haven’t been before, I’d highly recommend taking a look.
The conference is being held in London, from 21 – 23 September. You can find full details of the conference here:
In today’s blog post, we break from our usual format to bring you an interview with Paul Ranson of Smash Thinking. I first met Paul at an innovative business conference a few years ago, and I’ve really enjoyed hearing about his innovative approaches to leadership and getting things done.
Paul has been managing development and programming of graphically rich applications (mostly video games) since the 1980’s. He has been the go to resource for blue chip organizations across the planet making innovations for companies as diverse as Nissan, British Aerospace and Tesco. He is a passionate reader of business books and has introduced new techniques such as Agile, Lean development or Visual Communication at the businesses he has worked at.
I recently caught up with Paul for a ‘virtual’ chat, and Paul shared some really interesting insight:
1. So your background was games design and development — that sounds exciting! What challenges did you face, and what techniques did you find to overcome them? Are these challenges specific to the video games industry?
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.