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:
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.
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: