THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Paul Nielsen

The Primary Cause of Failed IT Projects

During my career I’ve been a part of dozens of projects. Some I was on from the start, most I came in to help bail out. Some went smooth and were a pleasure to build and maintain and some projects failed (failed being broadly defined as projects that were not completed, or were completed but were a horrid mess – very complex, impossible to maintain, refactor, and a royal pain to keep running.)

While there are a number of factors that can contribute to a failed project, in my career it seems the primary cause of failed projects is managers making technical decisions. Not every manager making a technical decision is bad, but every failed project I’ve been a part of included a manager who made technical decisions and drove the project toward over-complexity. And, one of my regrets in my career is my failure to convince managers that simple is better than complex. Unfortunately, some of those failed projects were the ones I cared most about.

A corollary to this idea is that good IT managers listen to the technical experts, and let those technical experts drive the design. And, good IT managers are a rare and special breed.

Resolved: Managers making technical decisions is a primary cause of IT project failure. Agree? Disagree? What have you found in your career?  

Published Thursday, June 10, 2010 8:57 AM by Paul Nielsen



Jerome said:

I agree!!!!!

When they decide how the things "must" works, even when this doesn't answer the end user needs, produces really bad results.

Also, some/most of the times they decide to change the scope of the project during the project without asking for impacts. Or they decide to change the team members.

Or didn't listen the importance of a roadmap

Or another common mistake:

when the team says "we need to do an indepth analysis to identify the detailed needs and real functionalities, we also have to identify how to test, how to resell it, how to support it, who will be the team members... so creating a product" and the answer is "why? your proof of concept works, just develop it!"

I also seen this: develop like in a big team, like its a huge project, like you have an unlimited budget. (so create huge doc, setup dev, QA, stage & prod env., involve 10 persons etc...)  But you only have 1 server and just between 1000$ and 2000$ for your project! oups... something doesn't works here.

I have tons of examples on what to not do... And you resume this clearly: a manager must never take technical / functional / design / project plan decisions.

So you are right, in my life too, managers are the main reason of the failures and frustrations.

June 10, 2010 11:08 AM

Siddharth Mehta said:

Completely Agreed.

Getting an idea of the technical design is okay to gain confidence into the design decision, as many managers grow from a technical background than an organic management background. But dominating technical design as per one's own taste just coz one is in manager's shoes, it a suicidal decision for the project.

One should leave the design on the technical expert, and if the management lack confidence, they can arrange a technical evaluation/audit of the design by an external technical team.

June 10, 2010 4:17 PM

Marty said:

Worse yet (IMO), letting project managers make technical decisions!

June 10, 2010 6:22 PM

Marco Kleinert said:

I fully agree!

Only some rare projects start with a kick-off meeting or at least a conf call with all relevant teams. In my option that's one main reason why projects fail. Because nobody has all necessary informations...

June 11, 2010 6:00 AM

Hugo Shebbeare said:

Yes, certainly one of the principal reasons. Good post, and way to raise awareness.

And when you try to right them from wandering off in the wrong direction, they will probably ignore you. Hence my reason for pursuing Project Management Certification from to be able to do the PM work myself legitimately, or to be able to speak the PM's language when the risk of project failure it high.

June 11, 2010 4:29 PM

Andrew said:

In my experience, it's not so much managers making technical decisions as much as it is managers making decisions with technical ramifications without consulting the technical people with enough time and detail to come up with a sane answer that is respected. Which I guess is the same thing, technical decision by proxy.

Well, those are the worst, but more common is setting deadlines and scope creep's lack of effect on said deadlines. If I say the project will take four weeks, you give me three, then requirements change that adds another week, and one assumption made at the beginning proves false which adds another week, why hasn't the date changed? I swear people are scared of telling a client that a date has been pushed back.

June 13, 2010 12:10 AM

Subbu said:

I totally agree with you...

June 28, 2011 7:22 AM

Harsha said:

Yes the above explanation is totally rite...managers should do only management works not the technical works...also they should leave the design to designer/architecture....

June 28, 2011 7:38 AM

Ralph D. Wilson II said:

I have to agree with the stated resolution.  I also agree with Andrew's statement regarding managers making technical decisions wihout consulting techies.

I have been on some projects that went extremely smoothly . . . although those seem to be more and more rare these days.  Lately, I have been finding that I am more commonly on projects that involve someone making decisions regarding how long tasks will take without having any knowledge of what those tasks entail.  Then, when it becomes patently obvious to the least casual observer that the "deadline" is going to be missed, the project manager trades 5 new features for one more week of time.  The net result is rather like borrowing money to pay the interest on a loan without ever paying on the principle . . . the faster the Project Manager negotiates time, the behinder the project gets. ;-)

Managers who involve their technical staff (and then make an allowance for the fact that techies are usually a bit overly optomistic ;-) generally seem to bring in projects without the project becoming a Death March.  However, a very key factor is not only keeping the client/end user in the loop and appraised of progress and problems but also having the intestinal fortitude to stand up to a client/end user who is making unreasonable demands regarding deadlines.

December 2, 2011 12:07 PM

Ieuan Johns said:

Actually I tend to find the problem isn't that they try and make "technical" decisions so much as political ones.

Things such as stating the manpower and time-scales up front before consultation, overcommitting to projects and deadlines and then choosing to block any negative news in progress reporting to their superiors.

Occasionally certain managers try to get involved in a lower level of detail than necessary and cause the problems you highlight but they are outnumbered by those who simply never bother to delve low enough.

Which type they are is almost entirely correlative with their background, often the delvers used to be technical in some field or another but are horribly out of date.  They normally have kept abreast of the latest fashionable and good sounding ideas but have no grasp on whether such ideas are applicable or feasible.

July 12, 2012 6:37 AM

Stephen Wynkoop said:

I would agree with a combination of these.  I think a big contributing factor is not acknowledging and working with the political requirements too - while we like to work around them (heck, I prefer ignoring them outright) doing so means not hitting the goals and objectives of the stakeholders in the project... and the keepers of the budget. Then you can be left with a strangled project budget-wise, doomed to fail.

Yes, tech managers that don't know what they're doing can pointy-hair-boss the project into oblivion - and it's a huge risk.  They should typically be focused on managing the outcomes, not the process.

September 9, 2013 11:55 AM

MG said:

Hi Paul,As a past tech and a well established season project program manager I think the technical options that the decision to be taken on needs to be presented by the Tech. Stating what the advatages and disadvantage is of choosing the option so it is clear to the stake holder and if there are any Risk's involved.

If it is a Technical decision then the Tech must take the responsibility and recommend what to go with.

If it is Technical decision with business risk responsability then it should be a joint agreed with the stake holders decision.The project manager should not take any responsibility for any Technical desicions or make them off his own back.The project Manager is there to facilitate and get a answer so that the project can move on.I have managed many projects the ones that have been in trouble and needed to be recovered and ones that have been impossible for other project managers to deliver. In my 16 years of project management I happy to say I have not had one failed projects. Secret of my success listen to all and work as a team.  

December 1, 2014 5:52 AM
New Comments to this post are disabled

About Paul Nielsen

Paul Nielsen believes SQL is the romance language of data. As such he’s a hands-on database developer, Microsoft SQL Server MVP, trainer, and author of SQL Server Bible series (Wiley). As a data architect, he developed the concepts of Smart Database Design and Nordic – an open source O/R dbms for SQL Server. He lives in Colorado Springs.
Privacy Statement