Let’s face it, we’ve all been there. Whilst working on a project which will deliver some kind of change within an operational area, we face unexpected difficulties late in the delivery lifecycle. Perhaps we find out that something we were hoping to do is much more complex than we’d anticipated, or maybe time and budget are running out. The project manager and sponsor are on the case: We must deliver on time, so yet another round of prioritisation meetings are called. We need to take a metaphorical machete to our project and our requirements with a view to delivering something smaller and cheaper that is still “fit for purpose”. That is quite a challenge, but one that I’m sure will resonate with many readers!
A hypothetical example…
Let’s build on this idea and imagine for a moment that we work in a mid-size organisation that is progressing a project to launch a brand new customer self-service portal. The objectives are to encourage customers to submit changes online, rather than ringing through to the call centre. The project’s business case is built around efficiency savings, reduced number of phone calls and intangible benefits including better customer satisfaction. The original intention was that when a customer submits their information via the web, it’ll automatically feed through to the master customer database, updating the details immediately.
However, we face a sudden and unexpected problem — we’ve suddenly had our project budget cut by 30%, and there are pressures to deliver even quicker than originally planned. So, we convene an urgent prioritisation meeting. We take up our role as facilitator and start to discuss what we could do differently, or which features or functions we are going to de-scope from the project.
The conversation gets heated remarkably quickly – our stakeholders egos start to show themselves. Different stakeholders have different worldviews and are politically exposed in different ways.
The sponsor opens the meeting sternly:
“We absolutely must deliver on time. We’ve announced the delivery date to the press, and we simply can’t be seen to have yet another delayed project.”
Discussion continues. People start to ask how this situation has occurred. A range of potential re-scoping options are discussed, but it isn’t possible to get agreement. One stakeholder suggests that we should seriously consider cancelling the project altogether, but this voice is quickly quashed. The conversation is moving on quickly when one of the other senior stakeholders (who used to be an operational team leader 20 years ago) interjects:
“Right, I think I have a solution. We can deliver everything on time and within budget”.
The room’s attention is immediately drawn to the stakeholders face. She waits a moment and then breaks the silence.
“Let’s think tactically. Our solution was designed to offer our customers the ability to self-service via the web, and we’d aimed to integrate it with our back-end systems.”
There are nods from around the table
“Well, why don’t we create a smoke-and mirrors solution? Deliver the illusion that this is happening. We’ll meet the customer’s needs, but do it in a lower-tech way. We’ll capture the data online, but rather than interfacing with the system, we’ll print it off and get our operations team to manually key it in. We’ll e-mail them the individual customer updates, they can print them, and simply re-key it into the back-office system. We save significant time and effort in the technology development, and we’re only creating a few seconds work for each case. A few seconds extra work for our operations team is no big deal”.
In essence, a manual workaround is being proposed. Immediately, a Subject Matter Expert who knows the operational process inside out raises a concern:
“That sounds sensible, but isn’t that going to create quite a lot of extra work….”
The sponsor asks “Good point, we certainly do need to consider that. How much extra work would you estimate that this creates, per case?”
“Well, about 60 seconds, I guess, for a fully trained staff member. Per case. Probably”
The sponsor interjects “Great, thanks. I’m not going to worry about 60 seconds of extra work. Even if we multiply this by the number of transactions, it’s tiny. We only get around 200 of these a day. It’ll be tiny. Decision made. Let’s do it”. The meeting ends everyone seems happy…. But in reality the project has just been railroaded into implementing a manual workaround without fully analysing or understanding the impacts or consequences.
So what’s in a few seconds?
Now, clearly the example above is entirely hypothetical (any I should point out that any similarities with real projects is entirely coincidental!). However, I hazard a guess that many of us will recognise this pattern and may well have seen this pattern emerge on our own projects. On the face of it, it could be argued that a very rational and proportionate decision has been made – we’re sacrificing efficiency in favour of getting something launched. However, there’s a real danger waiting for us.
Often these types of decision are made without a thorough analysis of the impact that the workaround will make and how it will affect the business and customer benefit that the project is intended to deliver. In this example, the decision was made extremely quickly in a meeting without any time for reflection. But hey, it’s just sixty seconds, right? Even multiplied by 200, surely that’s still a small number?
Sixty seconds of extra work might sound acceptable, but just imagine if we discover that:
1. 60 seconds represents the “best case” with actual cases ranging from 60 – 630 seconds (the average being nearer 180 seconds)
2. It’ll take an additional 30 seconds between each case for the user to retrieve the relevant data and print it out
3. The business will receive an average 200 of these cases per day.
The numbers may still sound small, but all of a sudden the “60 seconds” mentioned in our meeting has become 12 hours of work per day. Here are the workings:
[180 seconds (the average) + 30 seconds (the time required between cases) ] x 200 = 42,000 seconds.
Or, put differently that’s around 1.5 days’ work, per day. That split-second decision in a project meeting has committed 1.5 full time employees to processing the ‘manual workaround’ which is required to ensure the customers’ needs are met. This is before we factor in the extra failure demand that could be caused if users mistype information into the system, or if a backlog accrues which means customers ring in to chase their updates.
All in all, that’s quite an unplanned expense, which changes the project finances! It would be essential to understand what these additional ongoing expenses meant, how this compares against the current situation, and whether it really was the right course of action.
It’s all about the impact and all about the business case
Manual workarounds might well be necessary on some projects, and projects might still create business and customer benefit even if manual workarounds are necessary. Sometimes it might be necessary for us to ‘defer’ functionality to later phases, with short term workarounds being introduced in the meantime. All of these things can be fine. However, it’s crucial to ensure that these workarounds don’t cripple the business. It’s vital that we understand the impact on the teams that need to undertake the work, and it’s important that we get realistic input to determine how long the work will actually take. It’s useful to know whether the complexity of the work varies, what the average time is, and also what the range is. Not only this, it can be useful to know whether there are any peaks and troughs – this might lead to backlogs or other operational problems. Plus, of course, it’s important that we fully explore any alternative options!
In essence, if we change the scope of a project – and that includes de-scoping requirements – we should ensure we assess the impact and re-visit the business case to make sure it’s still viable. In some cases, it might make sense to persist with the manual workaround. In others, it might be better to bight the bullet and pay for the full on functionality. In others, it might transpire that the project just isn’t beneficial anymore and should be fundamentally changed or cancelled.
So often this critical stage is missed…
Conclusion: What this means for business analysis and BAs
We should keep an eye out for “manual workarounds” creeping into our project. We should challenge the view that “a few seconds here and there is fine” and ensure that our stakeholders have the right data on which to base the decision. Small numbers soon become big and can cripple a business case!
Fundamentally, the project’s business case should be a living, breathing document that ensures the entire project team is focussed on delivering business and customer value at every stage. If we change scope, we need to understand the impact.
How do you handle challenges like this in your projects? I’d love to hear your views and insight, so please keep the conversation going add a comment below. And if you like my blog, don’t forget to subscribe!
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions
