In my experience as a Project Manager, I've seen many projects fail. In fact, according to the Cranfield School of Management in the UK, 68% of projects are destined for failure.
Given this, I've just two questions in my mind.
Let's try to answer the first question before moving to the second one.
To me, projects fail for many reasons. But the top 7 reasons usually are:
Let's run through these one by one.
When I gauge a project's chances of success, all I need to do is look at whether a senior stakeholder is involved.
Nope, I'm not talking about the project sponsor. I'm more likely talking about the project sponsor's boss. That person is usually the guy who has signatory rights on the project finances.
And that person is usually a C-level person - CEO, CFO, CIO, COO, etc.
If that person is not actively involved in a project, that project is doomed for failure. Why? Because people disagree in projects. Requirements need to be prioritized. Hard decisions need to be made. If there is no senior management person to decide, then who will?
Case Study: The worst project I have been in as a project manager saw a rather insidious case where senior management support was lacking. This "Senior Management Person" (call him "SMP") in question was the CEO of Retailing Banking for Singapore and Malaysia at the time for a large regional bank.
I was project manager in charge of delivering a banking system to the bank. During Project Steering Committee meetings, the SMP would appear, ask some clever questions but never worry about the real issues in the project. When I surfaced serious scope creep issues to him and that users were being unrealistic, he would say (in front of his senior vice presidents, etc) - that my team and I were hired to manage all of these things.
Wrong! Projects are a team effort. A team effort between the client (in this case the bank) and us (the vendor). The SMP continued to ignore my pleas for executive support to tone down user requirements.
So guess what happened to the project? Yep - it was an epic failure.
In the context of IT projects, poor requirements are one of the major culprits causing project management failures. Poor requirements result in poor development and design. A software program will end up doing the wrong things for users - resulting in massive rework and re-tests.
Which begs the question: Why do we have poor requirements?
I attribute it to two things.
Unrealistics schedules are the bane of projects. I HATE them. I hate it when some senior executive says "We must have the best, fastest thingy within the next 2 weeks".
Look, projects should NOT have unrealistic schedules. In fact, I think the mindset around project delivery is messed up (especially in Asia). We need realistic schedules to build small, incremental successes in project deliveries. Instead, people are asking for massive changes in ever shorter timeframes.
Tip: Always assume that your timelines are too demanding. Ask for more time in your projects upfront. Especially in the requirements stage - it is important to spend time documenting exactly what the user wants instead of discovering a mis-alignment way later in the project.
Ok, what about requirement gathering techniques? To me, gathering requirements is a craft.
Many people in my line think that its just common sense but it's NOT!
There is a technique to gathering good business requirements and I think every Business Analyst out there should learn them.
I'm talking about requirements elicitation techniques, use cases, reports, interface and user screen design specifications. I'm talking about business rules, functional and non-functional requirements. Learn these techniques well.
I'll give you an example. Suppose you're working with a user to design a screen in a software to open a client's account. At face value, it seems easy - I need the client's name, address, identification number, etc. to be captured, then I submit the details and save the record.
But wait ... what about any interfaces in the backend that get triggered when the client account is opened? Should this record be listed in a report showing the list of client accounts opened for the day? What sort of validation checks should be done on the client when the new account request is submitted? What if his record already exists? Or what if he is a bankrupt?
See what I mean? There are so many exceptional details to capture in the requirements area. Make sure your BAs are trained to do it.
Ok, this is another point which makes my blood boil as a project manager. And sadly, this is also very prevalent in Asia where most of my projects are.
Users of the systems I deliver want the world. Give them a list of a hundred requirements, they'll say ALL HUNDRED of them are important for the system launch. No prioritization allowed. All of them are important.
Isn't that ridiculous? I think users need to be educated in terms of what a system should deliver in each phase of the project. We always, always deliver a basic, working system FIRST. Get that stablized, then we introduce Phase 2 with more advanced features.
That's what Zuckerberg did with Facebook. It's what Bill Gates did with MS-DOS. Basic product first - then add advanced features later.
The problem is that in many projects, users don't see that - they want all the bells and whistles immediately.
And this is also linked to a lack of senior management support. If senior management drills the mindset that the project has to be phased out to reduce risk, then users will fall in line. However, very sadly, most senior management folk don't do that.
This one I've discussed before. Scope creep is a serious issue in many of my projects. Scope creep means an increase in what you have to deliver, without a corresponding increase in resources or an extension to the project timeline.
You recognize scope creep when you interact with your stakeholders and they go "Hey, what about this feature?" or "Am I going to get that feature?"
Watch for cues like that.
And nip them in the bud.
You must always clarify with your stakeholders if a feature is not going to be in the deliverable of your project. And you need to document that communication. Otherwise, memories are short and people forget. And you end up with the wrong expectations in the end product.
It is very tempting for a project manager to assume. To assume that something is what the stakeholder or user wants (when it's not). To assume the user will buy into something (when they won't).
Users are the "ground level validator" of project outcomes. When you successfully deliver a project, the end product (and it's usability) is determined by the user. If he or she fails to see value in what you've delivered - guess what?
You've just spent all your project effort for nothing.
User involvement and buy-in for a project is ABSOLUTELY CRITICAL. Some project managers I know think that after the project is delivered, they're home scot free.
Not true. If users aren't satisfied, will they consider having you back as project manager for the next phase or another project? No!
I'm not saying we have to please every whim and fancy users have. But we need to generate enough buy-in and satisfaction among them so that the end product will be used and appreciated.
I used to work for a large US multinational IT services company. The project managers in this organisation managed huge projects - some of them up to $50 million in contract size and with "armies" of resources. The fate of governments and companies literally depended on the success or failures of these project managers.
Now, I've seen a number of good project managers in that company. But I've also seen weak ones. And I'd say these guys are the ones who, like it or not, contributed to the failures of many projects.
It takes a special kind of person to be a project manager.
You need to make decisions under stress. You need to understand project financials. You need to manage tasks, resources, human issues, stakeholders and users. You need to communicate well. You need to negotiate well. You need to argue well. And most important of all, you need to have dogged determination to see things through.
It's not easy. Many young project managers force things through, make assumptions or deliver a low quality product.
To avoid project failures, you need an experienced person managing the team. Don't find an inexperienced person and risk having everything crumbling down before the project goes live.
For the life of me, I cannot understand why certain projects have resources underestimated and end up being failures.
Resources are what get things done in a project.
Typically, I find that the guys up there (i.e. management), in order to save costs, promise the project sponsor to deliver such and such by X date and put in only the bare minimum (or worse) team of resources.
Case Study: A living example of this was when I was posted to Malaysia to run a banking system implementation project. I was given two junior Business Analysts. We had to deliver the system in 6 months and run requirements and testing, with development done by the vendor. TWO resources and a PM? You have got to be kidding me.
"Management" would give excuses like "Yeah, I'll get you another two resources" or promise resources in the form of interns. But those "suggested measures" either never came to fruition or simply did not work.
It is exactly situations like these which cause projects to fail. The project I mentioned above? It ended in epic failure due to our team's inability to cover all grounds during delivery.
Now that you understand why projects fail, it's useful to understand why companies continue to let them fail.
Let me tell you why.
The reason why companies continue to run projects and have them run at an insane failure rate is because of ...
The need to impress.
I'll tell you how projects are initated or conceived in organisations.
Some C-level person will tell his Number Two "Hey, bud, we need to replace that old system running our bank's operations. I want to show the board that we can achieve 180% ROI by June next year. Then by Dec next year I want the same rolled out to all our countries in Asia. It shouldn't be too hard to do that once the initial country is done".
Mr Number Two, will usually say "That's a great idea. I'll round up the team to draw up an action plan".
Number Two's need to impress his boss will probably cause him to draw up unrealistic timelines, round up an unrealistic team and promise insane deliverables to stakeholders.
THAT'S why projects continue to fail out there. The need to impress. Number TWO impressing his boss. His boss impressing the board. And so forth.
I say stop this kind of approach and BE REALISTIC. Deliver projects against timelines but make sure the scope is reasonable. Drive it down from top management down to the ground level. Continuously drive home that message.
Then your project has a much better chance of succeeding.
All projects have a high chance of failure. Learning to recognize the tell-tale signs of project management failure will put you in good stead for successful deliveries in future. Until next time, good luck managing those projects!
Are you wondering how to break into a Project Management?
Would you like to understand how others have successfully switched to a PM career?
Or discover what skills, certifications and domain / industry knowledge are required to excel in a PM role?
I’ve written a practical, easy-to-read guidebook that will help you find your best path to Project Management – one that leverages your unique skills, experiences and career background to your advantage.