Why do IT Projects fail?

Good blog! I genuinely love how it's easy on my eyes and also the data are well written. I am wondering how I may be notified whenever a new post has been made. I have subscribed to your rss feed which should do the trick! Have a nice day!

messages-noreply@bounce.linkedin.com; on behalf of; Juha Kämäräinen (Linkedin Answers) [answers@linkedin.com]

Juha Kämäräinen wrote:

You mention poor planning and lack of business involvement and commitment. I agree. For me both of them are sides of the same coin labeled: "What is this project all about?" As library and information services guy I would like to ask: How projects become informed about the context and organizational environment? What are the very methods used for this orientation? Are these methods really relevant, valid and reliable? It seems to me that many people with IT background believe that they are very skilled and capable in all types of information gathering. Actually they - as all of us - are limited by their world views including their views towards the nature of information and how to collect and handle it.

messages-noreply@bounce.linkedin.com; on behalf of; Mark Dantche [dantche@gmail.com]

Mark Dantche wrote:

In my experience lack of easy to understand documentation that has been approved by both business as the "what they want" and Dev as the "yes that can be done by this date and will cost this much" is always the key. Especially in todays world of offshoring a lot of the dev work, if that phase is skipped or not detailed enough you are destined for failure and unneeded expense.

messages-noreply@bounce.linkedin.com; on behalf of; Kevin Scandrett (Linkedin Answers) [answers@linkedin.com]

Kevin Scandrett wrote:

Hi Peter,

IT project success is quite possible if you don't forget the basics, such as scope, leadership, management and people. The reason most projects fail is not because of some big hairy problem. They fail because the basics have been neglected.
In order to have a "failure-proof" IT project, you need to confirm that the project is aligned with organizational strategy. Ask yourself: are the deliverables of the project aligned with the direction of the company?". Secondly, establish strong project governance structures, and make sure the business is engaged and that the right people are on the steering committee. Define the project clearly and make sure all stakeholders know their roles, as well as the goals and objectives of the project. There is usually a period at the beginning of a project when everybody is excited and disagreements seem far away but then, few months down the track, things can get ugly unless roles, goals and expectations of the project were clearly articulated at the start. It is also important to identify the appropriate success measures and strategy to maximize business benefits.
The project should be about delivering the benefits, not about the process. Also, you need to be clear on when the project is over; establish how to define when it is finished, and how to realize and maintain the benefits, he said. Planning is everything. Learn to love risk-identification and reward people who identify risks early and don't ignore problems,
Getting a balanced team with the right skills for the job, different personality types are essential. Consultants can be very helpful, use them wisely, and define how consultants can add value to the project, and lastl but not least! Communication is crucial! It is better to over-communicate than to not involve stakeholders,

messages-noreply@bounce.linkedin.com; on behalf of; Paul Walsh (Linkedin Answers) [answers@linkedin.com]

Paul Walsh wrote:

I agree that "why do IT projects fail" is not the same question as "why do software projects fail". Some IT projects are heavily Political (with a capital P) and the technology elements are the least consideration. And software projects don't necessarily fail as make huge mistakes that cause them to run late, under achieve and generally disappoint.

The mistakes that make software projects fail are usually mismatches of expectations. People confuse business goals with targets, and targets with estimates. "We need that feature before we launch in January" isn't an estimate, let alone a plan. Amazing how many product schedules out there have milestones 'agreed' on that basis. Many business goals are grounded in wishful thinking, and there is no 'previous best' used as a benchmark.

I think this is the core problem that Agile can solve - at least it breaks the big project (>1 year to final delivery) down into something manageable (e.g. 1 incremental release per quarter) so that the dis-connect becomes obvious quickly.

Sometimes you get hurt by leaving QA until too late. It all looks on track until you realise that actually, it just isn't working. In many embedded software projects where there is a novel hardware / software dependency it isn't always possible to do a lot about this, but again some sort of continuous integration is your best shot.

Lastly, and it is a minority case, there is a tendency for well-intentioned R&D managers to 'carry' an under-achiever or not admit one has been over-promoted too quickly. Again, the more often you test the health of your deliverables, the easier it is to bring these issues to the open and discuss them.

In one sentence: the gaps between wishful thinking and engineering reality are not tested until the project has racked up many, many months and huge expense; at which point no one wants to point out that the emperor is a nudist.

messages-noreply@bounce.linkedin.com; on behalf of; Deborah Jukes (Linkedin Answers) [answers@linkedin.com]

Deborah Jukes wrote:

Hi Peter,

I would suggest the answer is in the question;

First and foremost 99% of projects that are labelled 'IT Projects' are not IT projects; they are in fact 'Business Projects' that have a technical element.

On a recent large project I ensured that the emphasis on 'Business Project' was pushed at every opportunity. It helped to a small degree but was not the total answer.

I concur with your experience; the collaborative approach has been the most successful for me also.

A stong point that I must point out is the importance of the end user training in an ERP Project for example; even if the project team are successful in the delivery and implementation, if you fail to train the end user sufficiently the overall project suffers.

Best regards,
Deborah

Links:
http://www.ittoolkit.com/assessments/assess_eutrain.htm

messages-noreply@bounce.linkedin.com; on behalf of; Simon Gall [linkedin@simongall.com]

Simon Gall wrote:

Good to receive your question Peter!
Many IT projects fail, because they don't find and dedicate the cash to use experts such as yourself to ensure the job is done properly in the first place. Too many companies plod along with a make do and mend approach or go radical without having an independent assessment on feasibility.

Links:
http://www.simongall.com

messages-noreply@bounce.linkedin.com; on behalf of; Harco den Bremer [hdenbremer@hotmail.com]

Harco den Bremer wrote:

Hi Peter, Main reasons I have seen is lack of communication, lack of funding and high expectations (be it reasonable or not) the kill projects. The other is that many projects are called projects but are no projects at all. They may be based on a simple memo but have no project structure around them.
After a succesfull start a project will also fail because other projects are more important. In these cases you should stop a project. Not just continue and fail due to unsufficient funding and fail...

regards,

Harco.

messages-noreply@bounce.linkedin.com; on behalf of; Radwan Olabi (Linkedin Answers) [answers@linkedin.com]

Radwan Olabi wrote:

Hi Peter,

Usually the company board is not IT literate, and their only concern is numbers. Why should they release capital on a project if their actual situation is working smooth?

Just focus the project presentation in a non technical way that the board can understand, highlighting the benefits for the company, and specially the savings in long term the project will bring to the company if any.

Best regards,

messages-noreply@bounce.linkedin.com; on behalf of; Steve Howe [steve_howe@talk21.com]

Steve Howe wrote:

Hi Peter

My experience has been as you have described, basically the lack of understanding by the business that just a new IT system will solve all ills.

One of the key messages is that IT systems are there to support the business not drive it. Whether they are bespoke or application packages they have to be built / configured to support the business processes.

Businesses have to have commitment from the top down to drive the change through from the opportunities that a new IT system presents and this inevitably costs money that many organisations wince at. Change management is critical to the success of any large program and unless this is driven through the "barriers of resistance" that will always be there at some level, it will just be an IT system replacement where there will be little or no benefit and will be seen to be a failure.

messages-noreply@bounce.linkedin.com; on behalf of; Stewart Wright (Linkedin Answers) [answers@linkedin.com]

Stewart Wright wrote:

Why do IT Project fail?

What a great title and I if I put my business hat on I can sympathise with nearly all of the comments on one way or another.

We all know that commitment, infrastructure, effort, resources etc are essential to any project, however I know that even with all of this projects can still fail. However there are many projects that deliver more than the original expectation if not on every aspect of the original specification. One reason for failure is as individuals we still find it difficult to put down “my specific agenda” in favour of someone else’s project. Company or Departmental verbal buy in is not enough. Billions of pounds are spent on projects where no “psychological” buy in is received. It’s really not difficult to look at a business project team and see where the problems are. It’s then the responsibility of the solution provider to cut the crap. We as solution providers also have to take responsibility and deliver.

BELIEF is a key requirement to any project and should be a main focus for any self respecting Project team.

Believe that the project is true and the right thing to do.
Belief that the right change is a positive one.
Belief that the projects goals will have to be flexible within reason.

Sometimes our desired goals may have to change, as long as the end results meets the key elements then success is assured. Judge success on three key elements!

1. Will our customers / employees see the benefit?
2. Does it save us time?
3. Does it make us money?

These can be placed in any order but a good project should always have these at its heart.

messages-noreply@bounce.linkedin.com; on behalf of; Tim Cuffel (Linkedin Answers) [answers@linkedin.com]

Tim Cuffel wrote:

In my line of work, I see projects fail for 3 main reasons:

1. Doing it on the cheap

One of the main reason a company undertakes a project on their out is it is less expensive than bringing in an outsider. This might make good business sense, but often leads to other "cheap" behaviors, like:
o relying on underskilled employees instead of hiring experts or using consultants
o allocating resources only part time
o having resources "figure things out" instead of providing training
o reluctance to purchase new hardware and/or software

2. Failure to get buy in

A new project means an existing problem needs to be solved. The concerned parties need to agree what the problem is, what the solution will look like, and what to pay for it.

3. Lack of will to implement

When it comes time to implement the solution, all too often involved organizations don't want to feel the pain of transition, dragging their feet until the implementor gives up and goes away. Instead of solving the problem, the project become yet another parallel system unnecessarily draining resources.

messages-noreply@bounce.linkedin.com; on behalf of; Robert Bigdowski (Linkedin Answers) [answers@linkedin.com]

Robert Bigdowski wrote:

Dear Peter,

I agree with Tony, shameless promotion / lack of honesty. If you buy a product it can do everything and if you use it... it's different.

And then there is bad project management too.

Best wishes,
Robi

Links:
http://www.exinfm.com/training/pdfiles/projectPrimer.pdf

messages-noreply@bounce.linkedin.com; on behalf of; Jeremy Lattimore (Linkedin Answers) [answers@linkedin.com]

Jeremy Lattimore wrote:

I recently wrote a blog post (http://refocusing.wordpress.com/2008/09/11/technical-people-vs-business-people/) that I think describes a few of the big problems with IT projects.

In my opinion, many times there is an inherent distrust between IT and the business unit. This is typically caused by a lack of understanding on both side (sometimes militant) and bureaucracies of CYA. Too many times both sides are so busy with CYA that they don't spend the necessary time to find a solution. IT focuses on the technology they want to use and the business unit just wants the system done without spending time to outline what it will do.

After this happens a few times the standard mantra is that IT "can't finish projects" and the business unit "doesn't know what they want". In many cases, both statements are incorrect but without the proper communication and understanding the projects are doomed.

Links:
http://refocusing.wordpress.com/2008/09/11/technical-people-vs-business-people/

messages-noreply@bounce.linkedin.com; on behalf of; Steve Giovannetti (Linkedin Answers) [answers@linkedin.com]

Steve Giovannetti wrote:

I think most IT projects fail because for most companies IT is not a core competency. Businesses should develop good requirements for what they need to improve some aspect of operations or business development and then they should outsource the work to trained professionals. There may be cases where the requirements dictate that certain technical competency must be brought in house but that should be infrequent. This isn't a new idea. Most companies to not build their own offices, generate their own electricity, or craft their office furniture. They probably shouldn't be implementing complex IT projects when they should be in the business of creating, marketing, selling, and supporting a product or service for their customers.

messages-noreply@bounce.linkedin.com; on behalf of; Octavio Ballesta (Linkedin Answers) [answers@linkedin.com]

Octavio Ballesta wrote:

Hi Peter,

I have worked in different transformational initiatives along my professional career, and based on my experience I have to agree with you regarding to that most of the technologic initiatives will run into difficulty in fulfilling its promised benefits, particularly if the cultural impact is dismissed or ignored.

The perspective that you have posed in your question is a fact of common occurrence in big IT projects where requirements, critical path, scope and resources have not been thoroughly analyzed because of relying fundamentally in aspects relevant to the project management discipline instead of considering as prerequisites the technical demands, competent talent, sourcing of resources, partnership, financial strategies, procurement and possible critical paths affecting to big IT projects that may be professionally challenging, with high technical complexity and with possibility of being affected by imponderables not considered in the project management plan.

One of the most frequent failures in large projects is the lack of a true commitment from Senior Management around the scope, financial outcomes, and organizational impact that this project could pose over organizational culture and climate. If there is no executive sponsor, this transformational project could lost its relevance and pertinence as one of the medullar projects of the corporate strategy and finally could languish due to of lacking from the required commitment and support.

Usually, when a project requires from external contractors to be executed; introduce innovative processes, approaches or systems or is developed in partnership with other companies or contractors, the management of such project can be a nightmarish experience, when unexpected delays arise, when the scope was ill-defined or when the inherent complexity of the project was underestimated in the project planning phase.

If we considered that the organization is developing its core business processes applying a cross-functional approach and schedule its operations by applying a perspective of effective system’s integration, a transformational change derived form the deployment of transformational technologies as SAP, CRM or Knowledge Management will pose a tremendous impact over the functional dynamics of other managers. In such perspective Human Resources or Human Talent department should be instrumental to ensure that the process of cultural change is being developed as expected, a positive corporate climate is preserved and that all the managers will be faithful and successful adopters of the proposed changes.

When you are considering the deployment of transformational projects with enterprise-wide scope, visible impact in corporate culture and climate and potential of increasing enterprise’s profitability, I would prefer hiring a world-class consultancy service (McKinsey, IBM) with proved experience in applying the best business practices for transformational projects worldwide, effective application of change management practices and willingness to provide business value by assuming a business calculated risk.

When we are managing transformational projects, sometimes we mistakenly concentrate our focus in details of the execution and we may forget that there is a dynamic business context that introduces continuous changes to the strategic framework on which this project has been conceived generating a progressive lost of strategic alignment that may lead to a resounding failure.

Collateral to this interesting theme, I am including links to 3 questions that I have posted time ago in Linkedin Answers:

1. How would you find strategic misalignment of a corporate project?

2. When has the passion turned into indifference, which has been the flaw?

3. How does Technology impact on Management Practices?

I hope this helps you.
Octavio

Links:
http://www.linkedin.com/answers/management/planning/MGM_PLN/187543-933031
http://www.linkedin.com/answers/management/change-management/MGM_CMG/179163-933031
http://www.linkedin.com/answers/management/change-management/MGM_CMG/152573-933031

messages-noreply@bounce.linkedin.com; on behalf of; Bill Gates [bill.gates@fscan.co.uk]

Bill Gates wrote:

It simply isn’t true that all IT projects fail, their are as many successful projects as failures. In any complex development project (IT, aerospace, automotive etc) their is an element of risk - hence the high rewards for success. The trick is to learn from each failure and improve the process used.

messages-noreply@bounce.linkedin.com; on behalf of; Neil Gunnell [ngunnell@gmail.com]

Neil Gunnell wrote:

Projects need business owners who should understand the business requirement and be responsible for "readying" the business for the change.

Good risk and issue management

Benefits management is often forgotten. The business case is signed off on a benefits case and then the scope (and/or cost) of the IT change grows while the benefits often drop (particularly if they were overstated in the first place to get the project approval through). Good benefits management remembers to regularly check that there is still a case for continuing. If/when there isn't, the project should stop.

Don't assume that sunk costs are forgettable costs. If you're not going to get ALL of your money back, think seriously about STOPPING! (Lots of projects I've seen come to a conclusion that for just a bit more spend we'll get SOME return. I guess there's a case for that... but a project should never get into that position with good benefits management). I only ever saw one big project stopped (well, in theory it was frozen for 3 years, as a "come back later"). Brave decision.

Stakeholder management requires good business SPONSORS at Leadership level too... together with appropriate governance meetings/reviews.

Some quick ideas. Cheers.

messages-noreply@bounce.linkedin.com; on behalf of; Yann Gourvennec [ygourven@visionarymarketing.com]

Yann Gourvennec wrote:

Hi Peter,

I managed IT projects for the best of the past 20 years but also other change management projects in other areas. In fact, I agree about the 60% rule in favour of Change Management although I would push up the cursor up to 80%. Having said that, once you have got the 99% right, you still have to get the remaining 20% right, and if you don't, all previous efforts are wasted. My thoughts on the subject in random order:
1. get the name right. A good project has always got a good name. helps people remember it and focus on the issue
2. don't skip the middleman. middle managers are important in the process. Change Management is NOT about getting top management to send an angry e-mail to all and sundry. It's about convincing people, it's about negotiating, it's about getting the buy-in. Once you've done that, then and only then can you go and get Management back up. Of course, if your Management is not behind you, just don't bother launching the project at all. But if it is, then you've only solved half the problem
3. start with what's easy to change. Don't go for the most difficult bits. Keep it simple and stupid, implement the easy changes, prove your point, establish best practice, get to the next point and evolve your project
4. the serenity prayer: change (only) what you can," [...] accept the things I cannot change; [have] courage to change the things I can; and wisdom to know the difference." http://www.cptryon.org/prayer/special/serenity.html
5. Planning is of course of the essence. Very few people know how to do that. They think it's a matter of tweaking Ms Project whereas in fact it's all about managing people. And managing is about listening and negotiating
6. Implementation has to be thought of even before the project starts. That means Organisation, process, people and rules, usage, training, deployment, coordination and (application/infrastructure etc.) change management

Most of these rules are applicable to any kind of project, be they IT or non IT projects in my mind.

Hope it helps

Yann

PS a lot more stuff available on this subject in my old Visionary Marketing brochure (check link)

On 9/30/08 11:41 PM, Yann Gourvennec added the following clarification:
Note: 99% should read 80% :-D

Links:
http://www.visionarymarketing.com/htmlabs.html

messages-noreply@bounce.linkedin.com; on behalf of; John Leo (Linkedin Answers) [answers@linkedin.com]

John Leo wrote:

Lack of
Planning and
Failing to Identifing Risk upfront.

messages-noreply@bounce.linkedin.com; on behalf of; Jayant Joshi [jayant@vsnl.com]

Jayant Joshi wrote:

Hi Peter

I do agree with you that Change Management & Alignment of Business Process with IT are important factors.

However there are few more parameters for success in IT projects, I can think

- Top Management Commitment ( not just funds but best resources)
- Clear Requirements & Expectations
- Budget
- Organisation Readiness
- Best Project Manager
- Excellent Implementation Team
- Realistic Project Planning
- Project Monitoring
- Ready to accept changes
- Audit what you have achieved

Pl feel free to contact me if you need any more info.

Thanks,
Jayant

Paul,

You are, of course, absolutely right. We are now using Business Process Diagrams to describe business processes. Fortunately a standard has emerged (BPMN) that allows us all to start to speak the same language when creating BPDs. There are several tools out there including Aris and Lombardi Teamworks internal authoring environment. Up till recently, most of these tools have either been proprietary or have had sufficient deviation from the standards as to be non interchangeable. However, I did read a recent article (http://findarticles.com/p/articles/mi_m0EIN/is_2006_Feb_13/ai_n16061811) where it was announced that Lombardi Teamworks can now ingest Aris diagrams. I have since investigated this great news further and found that this is achieved by a Teamworks add-on that parses an XML file saved from the Aris environment. One wonders what happens when XML structure changes due to an upgrade? Does the ingestion process break? There is clearly a long way to go yet but at least it is a step in the right direction.

messages-noreply@bounce.linkedin.com; on behalf of; Paul Wallis (Linkedin Answers) [answers@linkedin.com]

Hi Peter,

We all know that a picture speaks a thousand words.

Engineers successfully communicate complexity to the business using diagrams. So do architects.

But something that has been missing until now is the easy to understand “big picture” of the relationship between business services/processes, IT assets and flows of data.

Think about this: “IT exists for one reason – to manage the flow of data between business assets”.

The increasingly complex modern enterprise is reliant on flows of data to perform, and IT’s role is to enable this flow. If we think this way then with the appropriate tools we can model and for the first time fully document IT and its relationship with the business. And we can create the ‘big picture’ to communicate exactly how the business and IT are (mis)aligned and how IT adds value to the business.

We can then sit around the table with our IT and business colleagues and SEE exactly what we need to do before a project even starts.

At that point the likelihood of project failure is greatly reduced.

What do you think?

Paul

messages-noreply@bounce.linkedin.com; on behalf of; Tony Greenberg [tony@ramprate.com]

Tony Greenberg wrote:

Shameless promotion: When you get heart surgery go to the doctor that does the most of them. So often project teams rest upon the shared experiences of internal teams and do not always bring in a balanced opinion and someone absent of political factions. This third party should be objective at all costs and be able to align interests succesfully from the onset, providing valuable data from similar successful projects in multiple industries

Links:
http://www.ramprate.com

messages-noreply@bounce.linkedin.com; on behalf of; Andy Zmolek (Linkedin Answers) [answers@linkedin.com]

Andy Zmolek wrote:

Your answer is nearly always rooted in the dysfunctional relationship between the business units an IT organization is chartered to support and deep-seated differences within each group's respective execution culture. Bridging that gap is a high-risk activity with a questionable personal cost/benefit for anyone that doesn't already have a strong track record in that area (which for those rare few is often rewarded via much more lucrative opportunities elsewhere in a company or an industry--often with lower initial risk factors to complicate that initial commitment process).

Most IT projects never muster the critical mass of cross-organizational and interpersonal commitment required to force enough players "all-in" so absent that critical mass the result follows natural and predictable paths of least resistence. Consequently, a program with a well-defined technical soltion and well-understood business need can be propelled forward to sucess on that momentum alone while others that lack such native alignment will require significant leadership to arrive at a successful conslusion.

Some companies have such a strong culture of execution that such leadership shows up almost on its own from both sides but the more likely scenario is that the business side wants to monopolize the business needs discussion and leave all the messy technology decisions to IT, who more often than not is willing to entertain the idea that program success begins and ends with delivery of the right technology. Such parochial thinking is reinforced by reward and other feedback mechanisms that place a very low value on long-term success metrics which are harder to measure and rarely distinguish between planning and operational failures.

It could be argued that by labeling any bona-fide business program an "IT project" is the very first step in consigning said program to limited success, as it allows all players to view the program as somehow separate from core business imperitives and tracked primarily as a cost to be controlled within an IT cost center rather than an investment whose value will be directly reflected in a business profit center. I'm not quite that cynical myself but I have to admit that I regularly see that mentality color technology investment decisions at many of the customer organizations I work with. Same underlying technology, but the business-unit-driven program somehow takes off and becomes a big success with a 1-2 year ROI whereas the IT infrastructure purchase ends up adding little new value and the whole dynamic becomes driven by a cost reduction mentality that rewards inertia.

messages-noreply@bounce.linkedin.com; on behalf of; Phil Lauro (Linkedin Answers) [answers@linkedin.com]

Phil Lauro wrote:

Territory, most large corporations are like little globes, everyone has and protects their business practice. Internal competition versus internal teamwork kills the best IT projects

messages-noreply@bounce.linkedin.com; on behalf of; Kirit Goyal (Linkedin Answers) [answers@linkedin.com]

Kirit Goyal wrote:

Here are some observations from my experiences:

1) Wrong tool selection and then trying to fit the square peg in a round hole. Sales teams say that every thing is possible and the decision makers believe that. To avoid this situation make the vendor do a prototype demo with some key functionality.

2) Cutting corners while selecting resources to deliver the project. while we all understand the importance of keeping the cost low, what we dont foresee are the total cost of ownership in the long run will be higher if we use less experienced resources to implement the tool.

3) You talked about less involvement from the business - The root cause is weak project or program management. Getting the committed engagement and escalation to steering committee is the job of the Project Manager. They are weak in this and lack the guts to put the project on hold if sufficient response is not obtained.

4) Stake holder buy in - I have seen occasions where the IT project was initiated by a group that thought "this is how the process will work" without consulting the actual process stake holder.

5) Weak scope change management - Scope creep has the potential to derail the delivery of the original scope on time on budget.