Dec 7th, 2014 by admin .
The following entry is a record in the “ Catalogue of Catastrophe ” – a list of failed or troubled projects from around the word.
Christmas Wonderland (assorted) - UK
Project type : Temporary Christmas themed entertainment park
Date : Nov-Dec – 2008, 2013 and 2014 Cost : Unknown
Synopsis :
One definition of success is “meeting or exceeding expectations”. Satisfy expectations of the customer or stakeholders and the project is viewed as a success. Fall short of expectations and no matter how good the product produced, the project may still be viewed negatively.
As we approach the holiday season I thought I would pick up on a story that illustrates the point. For the third time in recent years, a project that attempted to create some holiday magic has fallen flat on its face. The “The Magical
Journey” event at the Belfry Hotel in Sutton Coldfield, Birmingham, UK told people that they would have a seasonal experience unlike any they had experienced before. The advertising conjured up images of festive cheer, snow covered landscapes and a magical encounter with Santa and the elves. On opening day reality and expectations unfortunately collided. Heavy rain in the period prior to opening hindered the projects finishing touches and the product as opened was a significant miss of expectations. Resulting negative feedback from the public forced the event to shut down again so that the event could be polished and refined prior to its reopening.
The Magical Journey is not the first such story. In 2009 a “Lapland Experience” in the UK’s New Forest shut after only a few days and in 2013 an Winter Wonderland event at Milton Keynes, UK also closed after a few days of unrelenting customer complaints. Between these three examples the following expectations misses were evident…
1.
Expectation: Tress laid low with snow – Reality: A few hastily erected plastic Christmas trees in a muddy field,
2.
Expectation: Elves working hard in the run up to Christmas – Reality: A bunch of disinterested youths wearing poorly fitting costumes who were caught smoking round back of the tent,
3.
Expectation: Interesting and exciting gifts – Reality: Cheap plastic toys inappropriate for the receiving child,
4.
Expectation: Beauty and splendour – Reality: A grotty grotto,
5.
Expectation: A sled over laden with gifts pulled by reindeer – Reality: a plastic loco borrowed from the local mall accompanied by a sad, solitary and soggy lama,
6.
Expectation: A meeting with the jolly guy himself – Reality: a four hour long queue (in the rain)
Although not many (if any) readers will be planning Christmas festivals, there is a broader message underlying the troubles and failures outlined above: the need to actively manage product quality and customer expectations. If
Project Managers or Sponsors allow the gap between reality and expectation to become too big, then they run the very real risk that the perception of failure will outweigh any positives they did achieve.
Updated 12 Dec 2014: In a further update to this sorry saga, an additional event, the “Magical Winterland” in
Yorkshire, UK has also closed its doors after a single day. Again poor quality is cited as the primary reason. The photo evidence for this one as supplied by Britain’s Daily Mail is particularly revealing ( Magical Winterland ). As with the “Magical Journey” organizers advise that they plan to reopen once the issues have been resolved.

Updated 16 Dec 2014: The Magical Journey did in fact reopen after a three day closure. Unfortunately, with just 9 days to go before Christmas, a key financial backer has withdrawn from the project and the event has now closed its doors permanently ( The Magical Journey Shuts Down ).
Contributing factors as reported in the press:
Poorly managed expectations. Lack of quality controls (allowing the events to open despite significant quality issues in the underlying product and its delivery). False advertising.

- France
Project type : New trains
Project name : Regiolis / Regio 2N
Date : May 2014 Cost : In the region of $15B Euro
Synopsis :
Even a single missed detail has the potential to cause significant problems. Having purchased 2,000 new trains
French Railway company SNCF found out how one bad assumption can ‘derail’ a project. Following the arrival of the first of its new fleet of regional trains, SNCF discovered that the newly designed trains are too wide to fit into many of the railway stations they were intended to serve. As the British Newspaper, the Independent put it “The country that brought the TGV high-speed train to Europe has accidentally created another first – the TFT, or the Too
Fat Train”.
A Regio 2N train (Source:Wiki commons) – click for larger image
While the trains are compatible with railway stations constructed in the prior 30 years, older stations were built to a variety of other standards. For many of those stations the new trains were too wide to fit into the station. Discovering the issue late in the project lifecycle (post delivery of the trains apparently), the French had the choice of modifying a
$15B Euro fleet of trains or rebuilding station platforms to make them compatible with the trains. To date more than
$68M has been spent adjusting platforms and reports indicate there are more than 1,000 stations still needing to be worked on.
Information provided by a French government spokesman indicates that the problem originated because the national rail operator RFF (the company operating the stations) gave the wrong dimensions to train company SNCF (there one running the train purchase project). According to reports from the BBC, Transport Minister Frederic Cuvillier blamed an “absurd rail system” for the problems. “When you separate the rail operator from the train company,” he said,
“this is what happens.” To me that sounds a bit simplistic. Such breakdowns can easily occur even within a single organization and the project stands as a reminder of the need to challenge assumptions and pay attention to the details.
Contributing factors as reported in the press:
Bad assumptions. Failure to address details. Communications breakdown between organizations.

Aug 18th, 2014 by admin .
The following entry is a record in the “ Catalogue of Catastrophe ” – a list of failed or troubled projects from around the word.
British Home Office - UK
Project type : Immigration controls
Project name : e-Borders
Date : Mar 2014 Cost : £224M
Synopsis :
With changing security threats, securing a country’s borders has become an ever increasing priority. The United
Kingdom’s efforts to secure their borders has suffered a significant set back after the now cancelled ‘e-Borders’ project has resulted in a £224M settlement in favour of the suppliers of the system.
Source: Wiki commons
Recognizing the threat to the UK the British Labour led government initiated the e-Borders project in 2003. Aimed at checking all movements into and out of the island nation, the project was intended to establish the levels of border control needed to address immigration and security concerns. Following project kick-off a pilot implementation was completed and in 2007 a contract was signed with a consortium lead by Raytheon Systems to develop the full scale system. Reports of problems emerged in 2008 as the British Home Office complained that key milestones were being missed. Problems continued for a number of years and following the election of the new Conservative government in
2010, the Raytheon contract was terminated. Although the project itself soldiered on, continual failures to deliver resulted in the project itself being cancelled in March 2014. The project’s requirements have now been reallocated to other ongoing initiatives or projects as the UK government continues its efforts to achieve the goals originally set back in 2003.
While the project itself clearly encountered significant difficulties, perhaps the most embarrassing misstep is the handling of the Raytheon contract. Following the contract’s termination in 2010, Raytheon threatened to sue the
British government. Claiming up to £500M in damages, Raytheon argued that the lengthy delays were caused by the
UK Border Agency’s mismanagement of the project rather than deficiencies in their own execution. Rather than going to court, the parties agreed to use binding arbitration. That process reached its conclusion in Aug 2014 with the arbitrators finding in favour of Raytheon. The £224M settlement includes £50m in damages, £126m for work completed prior to the contract being terminated, £10m to settle complaints relating to changes to the original contract and £38m in interest payments.

Contributing factors as reported in the press:
Lack of control over procurements. Failure to establish appropriate benchmarks against which to track project progress and vendor performance. Failure to engage appropriate Subject Matter Experts during procurements. Failure to define and stabilize requirements. Under-estimation of complexity. Politics.

Jan 21st, 2014 by admin .
The following entry is a record in the “ Catalogue of Catastrophe ” – a list of failed or troubled projects from around the word.
Avon Products - Canada
Project type : Product sales and ordering system
Project name : The “Promise” project
Date : Dec 2013 Cost : $100 to $125M
Synopsis :
Ding-dong – Avon calling. According to reports, a significant number of the Avon sales team in Canada will no longer be pressing any doorbells. One of the world’s most established direct sales companies, Avon leverages the multi-level marketing strategy to distribute its products through a network of agents who sell direct to family, friends and their personal contacts.
In such a business your sales agents are a critical link in the chain. If they loose faith in you, then your distribution channel has gone. Unfortunately reports indicate that Avon did indeed loose the confidence of its Canadian sales reps by introducing a new sales order management system. Introduced as part of a global “Service Model Transformation”
(SMT) project, the new system was intended to streamline the ordering process thereby allowing Avon to reduce costs and better meet customer needs and expectations. Utilizing a new back-end ERP system and a new tablet enabled e-commerce front end, the SMT system was intended to allow sales agents to use their tablets to showcase the products and then immediately check inventory and secure orders online. Dubbed the “Promise” project the SMT initiative was intended to save approximately $40M per year.
According to a Securities and Exchange Commission (SEC) filing made by Avon on 9 Dec 2013 the project has now been abandoned with a write-off of between $100 and $125M. According to the filing, the system was piloted in
Canada but “caused significant business disruption in that market”. The SEC filing reveals that the system “did not show a clear return on investment” and that the decision to stop the project “was made in light of the potential risk of further disruption”.
Reports available in the press indicate that the issues were with the front-end e-commerce components rather than the back-end systems. Basic functions such as logging in, saving orders and checking inventory were not working properly. Furthermore, complaints about usability have surfaced. Users of tablet devices have become accustomed to easy to use apps that can easily be navigated with the touch of the finger. Reports indicate that the Avon user interface was poorly structured and did not meet the expectations users have of a modern tablet app. While back-end systems are typically more clunky and more difficult to use, apps are becoming ever simpler and easier. In yesterday’s applications it was typing, pick lists, fill in forms and multiple stages. In today’s apps, its get the job done in as few steps as possible using graphics, images and icons to make the journey from start to end as simple as it can possibly be. Although the intent was there it appears that design issues resulted in a system violated the agent’s expectations of how an app should function.
The net effect was drastic. One senior sales executive reported that she lost more than 300 of her sales agents as a result of the project (1/3 of her total sales team). Although many of those many have been the smaller volume agents whose lower levels of income may not have warranted battling through the deployment glitches, the SEC filing reveals that the impact was clearly enough for Avon to decide to back-off further deployments.

Note: Although the “Promise” project did not live up to its promise, Avon did at least reduce risk by testing the product in a smaller market before going global. That decision may have saved the business. If you contrast this staged release approach with
J.C.Penny’s
disastrous all-in approach to its business transformation project in 2012, it is a good illustration of how different approaches can lead to very different outcomes.
Contributing factors as reported in the press:
Quality flaws. Lack of stakeholder analysis and the failure to understand the sale’s agents expectations of an app.
May 28th, 2013 by admin .
The following entry is a record in the “ Catalogue of Catastrophe
” – a list of failed or troubled projects from around the word.

Ministry of Education - New Zealand
Project type : Payroll system
Project name : Novopay
Date : Sep 2012 – May 2013 Cost : $30M NZD
Synopsis :
A 2010 report by accounting firm KPMG shone a spotlight on ineffective Project Management practices in New
Zealand. Reporting that a shocking 70% of organizations included in the survey had experienced a failed project over a 12-month period, the report raises serious questions about the leadership capabilities in some of the participating organizations. This week’s entry into the Catalogue of Catastrophe is an illustration of one such failure in New
Zealand.
The Novopay system was intended to be a tool that would streamline payments to the 110,000 teachers, administrators and staff throughout New Zealand’s educational system. The project had its origins in a 2005 decision that the existing payroll facilities needed modernization. Following a bid process Australia’s Talent2 was selected to both implement the new system and then operate it on a service contract basis until 2020. The original project called for the system to be implemented in 2010, but following a number of delays the project only reached operationally status in Aug of 2012.
Immediately following its operational launch problems were encountered. Some school employees reported receiving incorrect payments while others were paid nothing at all. Those problems continued to grow and the issues became headline news in New Zealand as affected employees struggled to maintain their personal finances in the face of the cash flow problems the systems failures were causing. Dubbed the Novopay debacle, at one point affected staff had reported more than 18,000 payroll errors and the operational staff supporting the system appear to have been overwhelmed by the amount of manual intervention needed to correct those errors.
Tracking and analysis of the errors identified after the launch, identified more than 500 distinct defects in the system.
Of those 44 were deemed to be very serious. In Aug of 2012 when the system went live reports indicate that only 147 defects were known meaning that Quality Assurance testing had failed to identify several hundred problems in the system. Many of those problems were traced back to errors in the original project requirements and the design of the new system that allowed incorrect data to be entered into the system thereby leading to incorrect payroll payments and related problems.
A Mar 2013 review performed by Deloitte raised serious questions about the stability of the system and outlined a 1year remedial plan that needed to be followed to ensure the operational stability of the system and that the originally planned business benefits were realized.
Contributing factors as reported in the press:
Requirements problems and poor system design (a – usability issues, b – failure to establish appropriately robust data validation steps to ensure the quality of data input into the system and c – poorly designed reports that inhibited management oversight of the system’s use). Failure of quality control tests (failure to identify data corruption issues and logic flaws). Implementing the system with a high number of unresolved defects. Lack of control over manual intervention processes used when problems were encountered.

May 28th, 2013 by admin .
The following entry is a record in the “ Catalogue of Catastrophe ” – a list of failed or troubled projects from around the word.
Ministry of Education - New Zealand
Project type : Payroll system
Project name : Novopay
Date : Sep 2012 – May 2013 Cost : $30M NZD
Synopsis :
A 2010 report by accounting firm KPMG shone a spotlight on ineffective Project Management practices in New
Zealand. Reporting that a shocking 70% of organizations included in the survey had experienced a failed project over a 12-month period, the report raises serious questions about the leadership capabilities in some of the participating organizations. This week’s entry into the Catalogue of Catastrophe is an illustration of one such failure in New
Zealand.
The Novopay system was intended to be a tool that would streamline payments to the 110,000 teachers, administrators and staff throughout New Zealand’s educational system. The project had its origins in a 2005 decision that the existing payroll facilities needed modernization. Following a bid process Australia’s Talent2 was selected to both implement the new system and then operate it on a service contract basis until 2020. The original project called for the system to be implemented in 2010, but following a number of delays the project only reached operationally status in Aug of 2012.
Immediately following its operational launch problems were encountered. Some school employees reported receiving incorrect payments while others were paid nothing at all. Those problems continued to grow and the issues became headline news in New Zealand as affected employees struggled to maintain their personal finances in the face of the cash flow problems the systems failures were causing. Dubbed the Novopay debacle, at one point affected staff had reported more than 18,000 payroll errors and the operational staff supporting the system appear to have been overwhelmed by the amount of manual intervention needed to correct those errors.
Tracking and analysis of the errors identified after the launch, identified more than 500 distinct defects in the system.
Of those 44 were deemed to be very serious. In Aug of 2012 when the system went live reports indicate that only 147 defects were known meaning that Quality Assurance testing had failed to identify several hundred problems in the system. Many of those problems were traced back to errors in the original project requirements and the design of the new system that allowed incorrect data to be entered into the system thereby leading to incorrect payroll payments and related problems.
A Mar 2013 review performed by Deloitte raised serious questions about the stability of the system and outlined a 1year remedial plan that needed to be followed to ensure the operational stability of the system and that the originally planned business benefits were realized.
Contributing factors as reported in the press:
Requirements problems and poor system design (a – usability issues, b – failure to establish appropriately robust data validation steps to ensure the quality of data input into the system and c – poorly designed reports that inhibited management oversight of the system’s use). Failure of quality control tests (failure to identify data corruption issues and logic flaws). Implementing the system with a high number of unresolved defects. Lack of control over manual intervention processes used when problems were encountered.

Disasters 2014
1.
SNCF / RFF – France – $68M
2.
IBM – Worldwide
3.
British Home Office – UK – £224M
4.
Berlin’s Brandenburg airport – Germany – 5B Euro
5.
State of Oregon – USA – $254M
6.
State of Minnesota – USA – $150M estimated
Disasters 2013
1.
Avon Products
2.
Department of Health and Human Services – USA
3.
British Broadcasting Corporation – £100M
4.
J.C. Penny – USA – $1B
5.
New Zealand – Ministry of Education – $30M
6.
State of California – $254M
7.
Marin County – $33M
8.
Boeing Commercial Aeroplanes – up to $18B
Disasters 2012
1.
Northern Rock Asset Management – $400M
2.
U.S. Air Force – $1B
3.
Mitt Romney 2012 Presidential Campaign
4.
Department of Transport – UK – £40M to £100M (estimated)
5.
Knight Capital – $400M
6.
7.
Sanctuary of Mercy Church – Borja, Spain
8.
G4S Security – £60M

9.
Victoria Health Authority – $566M
10.
US Army – $5B
11.
British Home Office – UK – £105M
12.
Dept. Homeland Security – USA – $45M
Disasters 2011
1.
Victoria Police Department – Australia – $100M
2.
J.P Morgan Chase – $6B
3.
Department of Defence – Australia – $40M
Disasters 2010
1.
BSkyB/EDS – £200M GBP
2.
City of New York – USA – $540M cost overrun
3.
UK Fire Services – £650 GBP
4.
Queensland Health – Australia – $64.5M
5.
Dept. Homeland Security – USA – $1B
6.
Microsoft – USA – Undisclosed
7.
Department of Primary Industry – Australia – $2.25B AUD
8.
National Health Service – UK – $24B
Disasters 2009
1.
Sydney Water – Australia – $70 AUD
2.
Canadian Payments Association – Canada – $300M
3.
Westjet – Canada – Update from 2007 failure story
4.
London Stock Exchange – UK – $68M

5.
Veterans Affairs – USA – $41M
6.
Foundation for student life – Norway – $14M + some very smelly students
7.
US Navy – USA – $13B
8.
National Offender Management Services – UK – $375M
9.
MI5 – MI 6 – UK – Reported to be tens of millions of pounds
10.
City of Vancouver – Canada – $250M cost overrun
11.
Air Canada – Canada – $67M cost overrun
Disasters 2008
1.
Department of Homeland Security – USA – $500M
2.
Edinburgh Fringe Festival (World’s largest arts festival) – Scotland – Ticketing system
3.
HM Revenue Collection – UK – Child tax credit systems – $5,600M
4.
Rate Collection Agency – Northern Island – Local tax collection system
5.
Ministry of Defense – UK – Helicopter upgrade – $1,000M
6.
Justice Dept – Australia – Court proceedings management system – $54M
7.
Transport Ticketing Authority – Australia – Smart card system – $350M
8.
Department of Transport – UK – $160M
9.
Census Bureau – USA – $3,000M
10.
British Airways PLC – Move to T5 – $32M
11.
Waste Management Inc – ERP System – $100M
12.
Qantas – Australia – $40M
Disasters 2007
1.
New South Wales Government – Australia – $370M
2.
Service Personnel and Veterans Agency (SPVA) – UK – $100M
3.
Lhufthansa Systems – Germany

4.
Social Insurance Agency – Japan
5.
Junior Doctors Recruitment System – UK – $12M
6.
American LaFrance – USA
7.
General Register Office – UK – $12M
8.
State of Wisconsin – USA – $23M
9.
Centrica PLC (British Gas) – UK – $687M
10.
Los Angeles Unified School District (LAUSD) – USA – $95M
11.
West Jet – Canada – $34M
Disasters 2006
1.
Department of Homeland Security – USA – $20M
2.
Airbus A380 – $6.5B
3.
Justice Department – Canada – $1,000M
4.
University of Wisconsin – $28M
5.
Defense Department – Australia – Helicopter upgrade – $1,000M
6.
Department for Environment, Food and Rural Affairs – UK – $610M

1. One in six IT projects have an average cost overrun of 200% and a schedule overrun of 70%.
(Source:
Harvard Business Review )
2. The United States economy loses $50-$150 billion per year due to failed IT projects.
(Source: Gallup Business
Review )
3. 75% of business and IT executives anticipate their software projects will fail. (Source: Geneca )
4. 50% of all Project Management Offices (PMOs) close within just three years. (Source: KeyedIN )
5. Fewer than a third of all projects were successfully completed on time and on budget over the past year .
(Source: Standish Group )
6. Barely over half (56%) of project managers are certified. (Source: Wrike )
7. An astounding 97% of organizations believe project management is critical to business performance and organizational success.
(Source: PricewaterhouseCoopers )
8. The median salary for project managers is $87,500 in the U.S.
(Source: Glassdoor )
9. There are projected to be 15 million new project management jobs within the decade.
(Source: Project
Management Institute )
10. 33% of projects fail because of a lack of involvement from senior management.
(Source: University of
Ottawa )
11. Businesses identified “capturing time/costs against projects” as their biggest project management challenge.
(Source: The Access Group )
12. Reliability, ease of use, and ease of integration are the top three requirements project managers look for when shopping for software.
(Source: The Access Group )
13. 66% of project managers identified level of support as the key decider in investing in a new software.
(Source: The Access Group )
14. 44% of project managers use no software, even though PWC found that the use of commercially available
PM software increases performance and satisfaction.
(Source: Pricewaterhouse Coopers )

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.
1.
Why do projects fail?
2.
Why do companies continue to let them fail?
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:
1.
Lack of Senior Management Involvement
2.
Poor Requirements
3.
Unrealistic Expectations
4.
Scope Creep
5.
Lack of User Involvement
6.
Inexperienced Project Managers
7.
Lack of Resources
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.


Unrealistic schedules
Poor requirements gathering techniques
Unrealistics Schedules
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.
Poor Requirement Gathering Techniques
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!