Let’s face it. Projects, especially IT projects, have a high chance of failure. As project managers, we can do all the well-intentioned planning, scoping and effort estimation we want, but still our projects have a good chance of being delayed.
I’ve seen projects planned for delivery in 6 months, but go on to be delivered successfully only in 3 years (if they don’t get abandoned altogether).
This is particularly true in system implementation projects. It is said that 70% of all IT system projects will end in failure. I think that statistic is not far from the truth. In my experience, most of the projects I’ve seen in my years of system implementation experience have either been delayed or scrapped.
What’s the reason behind this? Well, here’s what I think. I think the single largest reason for project failure is …
Unrealistic management expectations.
Often, senior management in companies I’ve seen, particularly if they’re new to the job, want to show how capable they are by promising their board or whatever committees they belong to that they can deliver change / improve KPIs by X% within two years. They’ll say “Oh, here’s what I’ll do to achieve that – implement a new core system that will be delivered within six months.“.
I’m sorry if I’m being blunt here if you, the reader, are in fact a new CIO thinking of implementing exactly such a system change. This is a deep rooted problem in many institutions and from my experience, especially prevalent in banks and financial institutions, where “speed of change” and “revenue increase” has become such an important KPI.
Yes, we can go on about incapable project managers, the company culture not being ready for change, insufficient vendor support, bad weather or the sky being the wrong colour – but in my opinion, unrealistic management expectation is still the single LARGEST cause of project failure.
The world would be a MUCH better place, with IT systems delivered on time, to the correct expectations of users, if that CEO, CFO, CIO or whatever C-level acronymn you can think of – just pause and think about whether a new system initiative is at all realistic.
Come on, let’s be serious. Do you really think that an aging old mainframe that has supported millions of customer accounts for 30 years can be replaced by a new open architecture, standards-based platform like Temenos in one year? You’ve GOT to be kidding me. But that is what CEOs and CIOs are promising their boards. And they continue to do it despite knowing FULL WELL that core banking projects typically run 2 years or more. Especially here in Asia. And it annoys the heck out of me.
A Personal Story …
Let me share a personal story with you. I worked for an IT consulting firm and a couple of years back, we had a deal with a Malaysian bank to write up “functional specifications” for a new credit product they were thinking of selling to their clients. This product had been implemented in many European and US banks but was new in Asia.
The functional specifications were to be done within one month – a VERY challenging timeframe during which we, as the consultants, had to work with the credit system vendor and the bank’s users to write up the document. A milestone date was communicated and promised to many stakeholders sitting in the highest levels of management in the bank.
I felt the pressure to get the document signed off. My boss felt the pressure. Our sponsor in the bank felt the pressure. We convened a conference call with all the signatories and walked through the document with them. And if anyone surfaced a concern (e.g. a true requirement, without which the new credit system would have serious issues) – you know what we did?
We “bedded it down”. Or, rather, my boss “bedded it down”. When I say “bedded it down”, I mean he squashed the requirement. He’d say “Interface to the System X? That’s not in the scope of our document.” So what happens? The functional specification document got signed off by the deadline and everyone (especially senior management) was happy.
For a while. When we got to system development, gaps started to appear. “How do we draw down loans in the system? Oh, we key them into System X. But there’s no interface to System X catered for in our original user requirements“. Things like that started appearing and I started getting frustrated. We were in a state of – do we call off the whole thing or announce a 3 month delay to the project to visit missed requirements?
The answer was NO. Delaying the project was NOT AN OPTION (I don’t know how many times I’ve heard this in system projects and yes, it again annoys the heck out of me). So we plodded along, raising change requests to cater to the system interface to System X. That started blowing our original budget.
And the system vendor who developed the interface, who were already short of resources trying to deliver the original project scope, had to deal with all these new change requests. Since the changes were paid for by the bank, they gladly obliged to tack on the extra scope.
But guess what? They used the same resources. More scope with the same resources and the same deadline means only one thing in project work – poor quality output – it’s Project Management 101.
So during UAT, all the poor work starting popping up. The UAT failed, the project didn’t go-live. My team got booted out of the project and the system vendor spent MONTHS doing free work for the bank to make up for the project delay.
Why do I describe the story above? Well, I mention it because I want to drive home the point that an unrealistic delivery schedule, imagined by top management, will result in delivery failure. It is a known rule in project management. NEVER once have I seen this rule broken.
And yet, we have senior executives, in their suits and well-buffed cufflinks, promising the world to board members, çlients and shareholders. You know what was the delivery timeframe for the project I described? It was an eight month project – one month for functional specifications, two months for system development, two months for SIT, UAT, training and go-live.
You tell me whether that is realistic. Even junior staff can tell you can’t POSSIBLY do SIT, UAT and go-live in two months, for a new product on a new platform that impacts all existing operations and systems in the bank.
In case you’re wondering, I didn’t do the sales bit of this project. My boss and another team did it. Neither did I see who in the bank agreed to this kind of schedule. If I had a hand in it, I would have objected to my dying breath.
So What Can We Do About It?
So, given that unrealistic management expectations are the single biggest cause of project failures, what can we do about it? I’d suggest a few methods as follows.
- Hire better C-Level staff
- Get an independent risk assessment of the project
- Announce delays
Ok, let’s step through each of these methods in turn.
Method 1: Hire Better C-Level Staff
I’m sorry to single out the C-Level. But as the C-Level, you’re HAVE the responsibility to ensure the decisions you make are grounded on accurate and realistic facts.
Yes, you, the jacketed guy with the Ivy League MBA sitting in the restaurant in the Singapore Fullerton hotel talking about your upcoming Barclays Open golf game. Yes, you. I’m talking about YOU.
Seriously. I wish senior executives in the board rooms would step out of the golf courses and enter the production floor. See what Level 1, 2 and 3 buiness processes are flowing through the company. Yes, actually understand how the company runs and improve your domain knowledge (which is, erm, your job isn’t it?).
Talk to the bank operations staff. Talk to that forty-year old lady who has been slogging clearing trades on T+3 for you. That office boy who has to scan the account opening forms. Or that middle office girl who checks every trade put in by the traders against a physical deal ticket.
Once you understand all that, THEN you can make calls about whether a system can go-live in X months. If you don’t understand all that, at least at a high-level, then for Pete’s sake, tell me WHY are you in this job?
So to summarize – hire better C-level executives. Preferably the ones who have worked in operations and in sales. Seen both the frontline and the back. Those are the best candidates for senior management. Not some MBA touting fella who has never seen a deal ticket, cash payment screen or a SWIFT payment gateway or an interface failure error log.
Method 2: Get An Independent Risk Assessment Of The Project
Ok, on to the next point. In order to stop unrealistic management expectations on project delivery timelines, I suggest we all get an independent risk assessment of our projects.
Here’s the thing. Consider Person A. Person A is C-Level person whose job depends on the successful delivery of Project A within a totally unrealistic 6 months which he promised to the board just a week ago. He’s hardly spoken to any of the front or back office staff, system vendors or external consultants who are potentially impacted or working on the project.
The most detailed discussion or impact analysis he’s made is the $X millions / billons of revenue the delivered system will provide, much to the delight of his boss who managed to squeeze in a 30 minute conversation with him last week by scheduling his private jet to leave a bit later.
An independent risk assessment was not done at all. In some companies, there are PMO or project governance bodies who check the risk in projects. But guess what? Most of these guys can handle up to a hundred project requests in a month. All they have is some “generic criteria” and checklist as to whether a project is risky or not. They don’t have the functional expertise or domain knowledge to tell you whether that collateral monitoring project you’re implementating carries risk (although from my experience, most of them will try to pretend they do).
Oh, and in some cases, the system vendor or consultant ALSO does not do a risk assessment – especially if they’re hungry for the deal.
Case Study: I’ll tell you – in the example of the failed Malaysian banking project I described above, NO independent risk assessment was done at all!
Not in my company (which was rather small and in start-up mode, so it basically was hungry for deals). Not in the bank (which was a new division and somehow, a dedicated “system project risk assessment” team had not been formed). The standard generic, risk assessment done by the bank’s PMO consisted of obscure forms and documentation where you keyed in paragraphs of why the project should be done. Sections which indicated “Risk of This Project” were “conveniently” ignored or answers like “Not applicable” or “None” were filled without much thought.
The result? A double whammy – a risky project from the bank’s perspective was allowed to go through, and a risky project from the vendor’s perspective (i.e. my company) was allowed to proceed. What are the chances of this kind of project succeeding? You tell me.
Method 3: Announce Delays
The third way of mitigating what I call “Unrealistic Senior Management Expectation Risk” is to have the courage to say it like it is.
Come on, folks. As mature, educated adults, we’re all more than capable of recognizing immense project risks when we see them. More so for project managers / directors and senior executives who have most likely gone through many, many such projects.
So why are we afraid to indicate to our bosses that there is an unrealistic schedule and risk? I’m guilty of the same although I try to be more firm these days. If my boss tries to “sell” to a client saying something can be delivered in X months when I know we really need X+6 months, I’ll be upfront to him and the client. Stick my neck out and express what I feel. Who cares – it’s just a job anyway.
I think that this unwillingless to raise issues, delays or problems to our bosses has a very real rooting in Asian cultures. Here in Singapore, executives in banks are DEAD against raising issues and delays to their boards. Steering Committee meetings are usually hum-drum affairs, with project directors presenting “nice to hear” messages. “Yes, the projects are smooth, no worries, everything’s fine and dandy. You’ll have no problems meeting your KPIs, Mr CEO and thank you very much. Let’s adjourn to some beer downstairs.“.
Give me a break! I am furious at these things. I once highlighted to the CEO of the said Malaysian bank above that the project is at serious risk of delays because of missed requirements. You know what he said? He said “Oh, those are ground issues and should not be discussed in this forum.“. If major project delays and risks are not discussed in a Steering Committee meeting, then what’s the purpose of the meeting? It befuddles me till this day when I think about it.
The net of it is this – don’t be afraid to raise issues to senior management. If there is a delay in the project, there is a delay. You can’t hide or dance around it. Sooner or later, the system tests will fail and the delay will be inevitable. So don’t hide it. Let the board know about it early. And if your boss or your client doesn’t want to hear the bad news and continues to live in his beer guzzling, golf club touting world – then maybe they aren’t the bosses or clients you want to work with either.
Wrapping Up …
I hope the above has helped you understand that one of the biggest reasons why projects fail is unrealistic senior management expectations. Projects start out well-intentioned, business cases are drawn up, kick-off parties are thrown.
That’s all fine – but let’s ground everything in realistic terms. Don’t overpromise and underdeliver. Speak to your staff and understand the ground situtation. Then if you still think you can deliver a system in super speed – then fine. At least you’ve done the due diligence.
Get an independent risk assessment on your project. Ask someone who has done it many times to review the project and give an honest, no holds barred assessment. Can the requirements really be fulfilled? Are we asking for too much?
And during the project, if the danger signs of a missed deadline is there, don’t be afraid to highlight it to your boss. Delays can’t be hidden. If you hide them, they’ll appear during testing or in post-production. Then the damage control will take double the effort. Shed that “be safe” mindset and be transparent about project progress – truly transparent. It will pay off in the end.
That’s all I have for now. Until next time, stay focused and deliver your projects well!