Organisations that initiate projects generally do so to embed some kind of favourable change into their operation. The types of outcome and benefits desired will vary depending on the organisation’s situation and strategy, but might involve increasing revenue, reducing costs, achieving regulatory compliance, improving customer service or any other combination of goals. Let’s imagine that a financial services organisation decides to streamline its ‘customer sign-up/on-boarding’ process. Possible benefits might include providing enhanced customer service (leading to an increase in sales) and lower processing costs (leading to higher profits). There are likely to be many different ways of achieving these outcomes—and those options are likely to be examined in some form of business case. For small projects this might be a very lightweight document, with larger projects and programmes needing a more thorough and formal document. Either way, the relative pros/cons of various approaches will be considered—including the tangible and intangible costs/benefits, and also the risks.
The business case is often the gateway to getting a project off the ground. In many organisations it is like a key to the cheque-book—until the business case has been signed off work cannot start with any vigour. This leads to a useful focus on a business case early in the project lifecycle—which is a good thing of course—but once the cheques have been written, interest can start to evaporate very quickly. There is a danger that the business case will fester away, collecting dust in a document repository rather than being seen as a ‘living document’ that is central to the project and change initiative. This can lead to some very unfortunate outcomes.
A business case shouldn’t be “one and done”
Continue reading Benefits Realisation Shouldn’t Be A Witch-Hunt!
Problem solving is a skill that is relevant for just about every role within an organisation. It doesn’t matter whether you spend most of your time working with colleagues internally, or whether you work for a managed services provider (MSP) that offers services externally, it is likely that dealing with problems takes up a significant part of your day. Whether you’re a CEO, receptionist, or contact centre worker, chances are that you are involved with solving a wide range of problems. These can range from small, well defined and well scoped problems (for example, a customer not receiving a parcel) right through to tricky, messy and ill-defined problems (for example, revenue dropping due to multiple unrelated yet volatile conditions in the business environment). Sometimes, our problem solving activities are so ingrained in our daily activities that we do them without thinking. Other times, for larger problems, we might use formal business analysis, creative thinking or problem management techniques. Entire methodologies and practices have emerged which help us liaise with relevant stakeholders and analyse different potential options for solving organisational problems.
One important element of problem solving that is rarely discussed is problem ownership. Even the smallest problem is likely to need coordinated action from a range of people within the organisation to resolve. The problem owner works with others to ensure this cohesive and coordinated response. Significant problems can occur when a problem isn’t ‘owned’.
Continue reading Good Problem Solving Needs Good Problem Ownership!
Imagine the scene. It’s 5pm on a Friday. It’s mid-summer and the air is humming with heat – but you’re stuck in a hot, stuffy conference room with no air. You’ve been up since 5:45am, and are only surviving because you’ve downed 17 cups of coffee and 3 energy drinks throughout the day. It’s been a long day and you hope it’ll be over soon. You’re sitting in an uncomfortable chair watching a visitor give a presentation. You’re trying to stay focussed, but your attention is wandering… your eye is drawn out of the window to a colleague getting into their car and heading home for the weekend. “Lucky”, you think to yourself. You start to think about what you’re going to have for dinner. You start to think about the traffic on the drive home—“I wonder if those road-works have finished?” Your mind is wandering. You make a mental effort to focus.
Your attention is drawn back to the presentation—the presenter is speaking in a monotonic voice that can only be described as ‘dull’. They are uncovering bullet point after bullet point after bullet point—and really they are just reading their slides. They move to the next slide and an undecipherable and unreadable diagram is displayed. They look at the diagram, and turn back to the audience:
“I know you won’t be able to read this diagram as it’s too small—but let me talk it through it”
They proceed to do so. Your eyes drift in and out of focus—you are trying to stay awake. You notice a number in the corner of the slide “25 of 118”. It’s going to be a long evening…you take a final swig of coffee.
Recognise this situation?
I bet we’ve all been in that conference room. We’ve all experienced that mind-numbing and spirit crushing pattern of death by bullet point. I suspect that many people reading this will have experienced it many times. And, if we’re truly honest, probably most of us have been on both sides of the podium. We’ve probably all given presentations that have lost the audience’s attention as well as endured them…
Communication is crucial
Continue reading Death by Bullet Point: The Antidote
I recently heard a really intriguing story about how a massively successful and well-known online retailer conducts its meetings. The CEO reportedly ensures that there is an empty chair at the conference table when key meetings are being held. This empty chair is an important symbol—it is used as a visual reminder of the firm’s customers. Although they are physically absent, the empty chair reminds the meeting attendees to think about customers’ views, needs, wants, fears and aspirations. This straightforward but powerful gesture ensures the voice of the customer is injected into decision making, and presumably acts as a reminder to go out and consult with customers when needed. It ensures the customer is at the heart of the discussion.
There is no doubt that understanding our customer (and our customer’s customer) can help create a competitive advantage. Yet in the rush to deliver projects, orders, changes or innovation it can be easy to forget our end-customers and end-users, or make sweeping assumptions about what they will find valuable. This leads us to dangerous ground: if we fail to really understand our customers, there is the danger that we’ll try to deliver exceptional service but will unwittingly fail. We’ll go “all out” trying to delight the customer, and will be confused when rather than thanking us, they complain.
This may sound counterintuitive, so let me give you an example:
Continue reading Do You Know What Your Customers Really Want?
I’m guessing that many readers of my blog spend their lives working on projects. Whether you’re a business analyst, project manager, or architect, chances are that you’re working on at least one project right now. And whatever type of project you’re working on, you almost certainly have to estimate work as well as comment on estimates that other people have produced. If you work in an internal business analysis/change team, your estimates are likely to be around effort and time. If you work for a managed service provider (MSP) or vendor, you may well be delivering estimates to clients that relate to cost as well as time. As hard as we try to highlight that we are providing an estimate (rather than a final concrete figure), the stakes can be extremely high. As soon as a number is agreed upon it tends to be seen as the definitive number. And if it changes, we’ll find ourselves in a very difficult situation!
Estimation often feels like a dark art. We often need to estimate very early on in a project, long before we have a full and thorough understanding of the scope. If we’re unlucky, we’ll find ourselves bartering with our stakeholders. I’m sure we’ve all seen or been involved in dialogue that goes something like this:
Estimator: “This is a pretty big task, it’ll take 4-7 weeks with the resources we have”
Manager: “Great, thanks, but we need it done in two weeks. You’ll find a way, I have every confidence!”
Estimator: [Walks away thinking “not again!”]
In fact, there are many good Dilbert cartoons around this dilemma.
Breaking the estimation doom-loop
The good news is that this cycle of estimation and disagreement can be avoided—although it takes a change in tact. Here are some tips:
Continue reading Six Tips to Break the Estimation Doom-Loop
As much as we’d all like to work in an organisation where resources are unlimited, time is unimportant, and our competitors move slowly (allowing us ample time to respond), the reality is often vastly different. In many industries, new technologies are allowing nimble start-ups to enter the market with different and sometimes disruptive business models. New channels mean that our competitors can reach clients in new ways—and our clients can interact with each other faster and with more transparency than ever before. Markets move and develop with increasing momentum. Just ten years ago, letting a smartphone ‘suggest’ a local hotel and taxi firm would have seemed insane. Today, it’s possible to book an entire journey with a smartphone, figure out which of your connections are nearby, book dinner and see what’s on at the local cinema all before you’ve boarded your flight…
In this constantly changing environment, utilising external environmental analysis techniques like PESTLE or STEEPLE becomes crucially important. Smart organisations will continue to regularly adapt, experiment and implement change with increasing speed. These changes can be small (perhaps a new incremental change to an existing website) or massive (cannibalising an existing product in favour of launching something completely new). These changes can affect any part of the business eco-system—the IT systems, processes, organisational structure, facilities, plant/machinery, products or proposition and so on. And increasingly this will involve liaising with skilled partners—internal or external—to help build, customise or buy elements of the final solution. It may involve procuring IT from selected vendors or services from managed service providers (MSPs), as well as engaging a wide range of internal stakeholders. It may even involve outsourcing or insourcing a capability.
In this race to get change implemented, so often, constraints get forgotten about. Or rather, with the fire behind us and with a strong sense of urgency, it is easy to delay a discussion about what will constrain us. Yet as alluded to in my opening paragraph, it is highly likely that we don’t work in an organisation where time, budget and resources are unlimited.
Leaving our constraints un-discussed and un-stated is akin to locking them in a dark, dank cupboard and just hoping they won’t affect us. We become like ostriches, with our heads firmly in the sand. Even worse, different stakeholders have different views over which constraint should be compromised. It is worth considering the traditional triple constraint of project management here. The Sponsor may hold budget as the most important unbendable constraint. The customer service team may feel that quality can’t be compromised on, with the marketing team advocating time as the most crucial factor. This is before we even discuss the rocky issue of scope as well as any other business or technical constraints.
Bringing constraints out into the daylight
Continue reading Let Constraints See Daylight
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.
See you there?
PS — if you can’t make it to London, you can also catch me at BBC Conference in Las Vegas, USA on 2nd November, running a workshop entitled “Strategic Business Analysis: Identifying the Business Need Before the Project Starts” November and again on 5th November with a session entitled “Strategy: The Crucial Enabler”. You can also catch me at BA Camp 2016 in Vienna, Austria in May 2016.
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:
Continue reading Two Useful Additions to a Requirements Package
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).
Continue reading Avoiding the ‘Honeymoon Period’ When Procuring Solutions
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:
Continue reading The Art of a Difficult Conversation