Leadership

IT projects fail most often due to organizational issues

Here's an example of an IT project that went horribly wrong and perhaps didn't have a chance from the start. One project management expert says that technical glitches are almost never the main problem with a project failure.

Here's an example of an IT project that went horribly wrong and perhaps didn't have a chance from the start. One project management expert says that technical glitches are almost never the main problem with a project failure.

-------------------------------------------------------------------------------------------------------------------

In this week's Workforce.com's newsletter, there was a piece about a nightmare HR IT project that went horribly wrong:

In January 2007, the Los Angeles Unified School District flipped the switch on a $95 million system built on SAP software customized by Deloitte Consulting. The system was intended to replace a mishmash of outdated technology with a streamlined system for tracking earnings and issuing paychecks for 95,000 teachers, principals, custodians and other district employees.

But it was doomed from day one, done in by technology glitches, inaccurate and often conflicting data from the old system, inadequate employee training, and infighting and lack of internal oversight within the district, among other problems.

The trouble was apparent from the first month the new software went live. Some teachers were underpaid, some overpaid and some had their names completely erased from the system. It took a year and another $37 million in repairs for the school district to work out the kinks. In November 2008, the district and Deloitte settled a dispute over the work, with the contractor agreeing to repay $8.25 million and forgive $7 million to $10 million in unpaid invoices to put the matter to rest.

According to the article, HR IT projects have a pretty high rate of failure. Michael Krigsman, who writes the IT Project Failures blog for ZDNet, says, "Depending on the statistics you read, 30 percent to 70 percent of these projects will be late, over budget or don't deliver the planned scope."

The Workforce article outlined several reasons for the specific failure of the above project. The reasons included not having a high-level executive with IT experience dedicated to the project (the district's original point person was a COO with little computer experience) and the old system was riddled with errors. Also, HR IT projects are very complex.

But Krigsman made an interesting point when talking about such projects. He said the reasons for the problems are usually not technical; they're "organizational, political and cultural in nature in almost every case."

I agree with that statement; also, I know that organizational, political, and cultural issues are the hardest to pinpoint and to fix. In my experience, poor communication among stakeholders and project principles is the underlying disease of all bad projects.

What do you think: Do organizational aspects of a project cause failure more than the technical ones?

About

Toni Bowers is Managing Editor of TechRepublic and is the award-winning blogger of the Career Management blog. She has edited newsletters, books, and web sites pertaining to software, IT career, and IT management issues.

145 comments
wmkrayer
wmkrayer

Because the scope is not well defined. Because the stakeholders do not understand that the nuances of an IT project must be kept in check. I often see gold-plating occur from a key sponser.... at a time where it jeopardizes the critical path and puts the project manager in an situation they cannot win. This is for all projects.... it is the concept of project management itself is not been accepted for the discipline it is.... it is used as an excuse to get funds allocated and pet "incentives" injected after the point of no return. Good project managers struggle with senior managers whose interest that often conflict with the project objective. This struggle can easily become a slow walk to the unemployment line. The fix is tenacity of purpose by the project managers, combined with a sense of ethics to the PMI that dictates our code. It is the compromise to powers that can, and often will, derail a career that jeopardizes most projects. The fix is not easy, but the cause is painfully apparent.

thrugar
thrugar

I just got done reading another article about "Think Time" for a single project manager for a single project. Once you expand it to the level that this article is speaking to you must have not good but great communication between the customer and the consulting group. I believe that the consulting group should have done a better analysis of the data involved to begin with have sign off from the different regional managers that all the data was present or have an online forum for the EU's to check thier data prior to roll out. The check process should have been monitored and enforced by the regional managers that signed off on the basic data form to begin with. Thats my 2 copper

njackson
njackson

Based on this article only, I would say that organizational aspects causes more failure. And then again, it appears that this was money politics here.

BogMeadow
BogMeadow

"Organizational Issues" is a pretty broad brush. Lack of training, funding, etc are all "Organizational Issues". However I do agree that technical issues are rarely the problem. The problems revolve around the current notion of a project manager. Especially the notion that the PM needn't be "technical". The only effective PMs that I have ever seen knew everyone's job better than the persons holding them and had absolute authority over the consultants and the clients. If the PM can't detect BS answers and can't punish those who give them then on-time, on-budget projects will be random occurrences.

reisen55
reisen55

Here is quite a tale. Lockheed has filed a lawsuit asking it to be released from a $250 million contract with the New York City MTA. Project was to be a post September 11 implementation of over 2000 cameras at critical junctions. A project from hell. Courtesy of the MTA Lockheed has been denied a schedule of access to East River tunnels. Rooms for computer equipment are not empty YET and some show extensive sign of water damage. Of 2000 cameras that were to be working LAST YEAR, only 300 are actually up and running. Now the fault can be blamed on both side at the time of this writing, but given the current state of the MTA .... probably 80% their fault here. Read this and weep.

HighTechAngel
HighTechAngel

Absolutely true. The most ridiculous complaint I have ever heard: the Accounting manager telling me (very angrily) that I was trying to pull the carpet off his feet because I was trying to automate his area, which was so full of innacuracies and inconsistent information among other things. Another one, a CFO (of a small business company) asking me to implement a combo box on a data entry screen only to choose numbers 1, 2, or 3. She could not tell me (she didn't want to) what those numbers were for, I just had to deliver it and that was it. It's a shame that our country is trying to move thru 21st century with such a bunch of dinosaurs still with the reins in their hands.

sermic
sermic

Having been the lead on a few IT projects, I've seen organizational issues doom projects right from the start. Of primary importance is Executive support and stakeholder buy-in. I'm referring primarily to large projects of course. Second, is cultural change, the project management, then the tech stuff. I wouldn't agree that the exec stakeholder need understand the complexities of technology. That really doesn't matter. What does matter is that the project lead and subordinate team leaders know internal processes, procedures and requirements. If you don't know what you have, and what you do everyday, then how will you apply this to the new system? Also, people need to be held accountable for deliverables. Often times, some team members may not have that same sense of urgency you may have. Lastly, a phased implementation in this particular case would have made much more sense, rather than cutting loose all of your old systems for one new one. Test, Test, test I say! :)

mwmentor
mwmentor

I have yet to meet a pm system that really works - there are inevitable delays to any project that affects either the deliverable or delivery date. I think that the primary task of any project management is learning to manage client expectations in business terms which usually boils down to expense/return at the end of the day. I have a friend who has the beginnings of something that I like - he never puts an overall delivery date on his projects - he works it task-by-task. Seems to keep the client happy most of the time.

bygcee2000
bygcee2000

I agree totally. I am currently experiencing the implementation of a new network management IT system where I work and first and foremost you must get your buy-in or blessing from higher echelon before even thinking about moving forward with the project. Without an IT knowledgeable leader they will never fully understand what you are proposing or the benefits of the new system against the legacy system. You must have management dedicated to the success of the project or it will be doomed from the start. Organizational culture will also play a big part on the success of a IT project. If your legacy system has been around for many years and a lot of time and effort has been put into upgrades, improvements and tweakings plus you still have many of the same employees maintaining this system then you are taking away from them something they now very well and throwing them into the unknown. I believe change is a positive thing and when you have full support from management to back you up and employees are notified well in advance, kept informed, properly trained, provide feedback and feel like they are key players in the implementation of the new system (which they are) then more IT projects won`t just die or be subject to constant scope creep which can greatly increase the cost of the project.

squolth
squolth

One could suggest that they fail due to 'people' issues. The most painful, and the most rewarding, part of project management. The 'project' part of the title 'PM' is pretty easy - ticks in boxes - methodology up the wazoo. But the 'management' element - to quote Borat - 'this one, not so much'. Leadership is where the gap is - IMHO.

mhwallace01
mhwallace01

My project management experience taught me that this is a critical issue in most IT projects. When executives with little IT experience pick platforms, languages, tools, and timeframes without listening to their technical experts. When technical people make decisions about business requirements or data conversions specs (in the absence of direction from the business) -- trouble is not far behind. An IT project is really a business project being implemented using IT technology. When the business side abdicates, and lets the technical folks make business decisions (which is all too often the case), the results is not "as expected" -- because expectations were not clarified. When technical people choose really new technology, it may be great for their resumees but not so wonderful for the business if they pick the wrong horse in the technology race. Basically, organizational problems are at the root of this set of problems. All parties must be clear on the business and technical impact to the organization of the decisions made. Sharing responsibility among groups is an organizational problem that needs to be tackled to make any project (IT or otherwise) more successful.

Osiyo53
Osiyo53

"Do organizational aspects of a project cause failure more than the technical ones?" Hmmmm. Certainly these organizational aspects do have a major impact. Especially when dealing with any significantly large organization. Made worse when said organization consists of many disparate and diverse subgroups with specialty functions/missions. And when the organization has, over time, absorbed other formerly independent groups. What's new about this? You have departmental jealousies and competitiveness with each other, this or that group clamoring for the most attention or exercise of power. Special groups who'd formerly been able to operate pretty much as they pleased who're now being told they must toe the line, conform, and operate in some standard fashion. Groups that were formerly independent of the parent organization, but which have now been absorbed by it. The employees and personnel in such formerly independent groups having done what they did, the way they did it, for many years previously ... perhaps very successfully so. So on and so forth. I've seen this many a time. When I worked for a major telecom that corporation actually consisted of what had formerly been dozens of previously independent, smaller telecoms. Each having formerly had their own rules, their own methods, and their own cultures. Getting all of them moving in the same direction, following the same rules, etc was pretty much like trying to herd a pack of cats. The same applies to where I work now. "The Company", consists of what were formerly several smaller companies. Who're pretty much integrated now, following the same rules and procedures, but it wasn't easy or quick to accomplish. When I deal with our customers, all very sizable organizations, I quite expect that there will be communications and misunderstanding issues between this subgroup and that. That on any particular project you'll meet foot dragging and resistance, disagreements, and someone getting his or her skivvies in a bunch, and one or more who'll try his or her best to claim that some exception be made, or that such and such should be changed, or whatever. Just part of doing business. In such cases I'm pleasant, I listen, I take notes ... and then tell whomever that he or she must take the matter to "The Big Boss". That being whomever it is within the organization that's in charge of overseeing the project ... and signing the check that'll pay us. In the meantime, I'm following the plan as written and signed by the parties concerned. Yah can't please everybody, and I don't even try. I go by what the contract says. Until whoever has the authority to do so amends the contract. And that's gonna cost em. Too many efforts made to modify and amend the contract? We're likely to put a halt to that. Tell customer to forget it. Or, wait until the current contract as written is complete and online and running. And THEN we'll address the subject of making changes. Of course, sometimes whoever is in charge ... isn't all that good at what he or she does. And has trouble dealing with the folks I direct his or her way. i.e. Not so good at saying "No", or "We'll deal with that later." But that's the customer organization's problem. Sometimes, when "The Big Boss" is having trouble with his or her spine, we help him or her out. We have had times when we've brought our own lawyers into play, and had them explain in polite legalese that if this or that mid-project revision is insisted upon, we believe that the project is in jeopardy, now would you kindly sign this piece of official looking paper which absolves us of all responsibility and blame? Or we just look at the mid-project revision, say we'd be happy to accommodate them .... here is the price tag. And we make sure the price tag is so stiff that somebody reading it is gonna faint on the spot. As contractors, we bear some responsibility for managing not only the work being done, but also the contract. Letting a customer steamroll over you, insisting upon addendum's, modifications, exceptions, and so forth willy-nilly is a great way to have a failed project and/or lose your a**. I'm not sure that in the example case you cite that the problem was that the guy wasn't technically savvy. I think it might be more of a case that his management skills were not up to the task, and/or the school district did not give him the power and authority he needed. I deal with schools districts all the time, my bet would be that the later case was the most likely. Dealing with school districts is always problematical, anyway. Too few people within them have any true understanding of economics, business, money management, and so forth. And too many PhD's in this or that, who think that because they're expert in something, they're expert in everything. I'm not exaggerating in my last comment. I wouldn't even be able to remember how many times I have the conversation where some school official asked for or demanded this or that. To which I replied something to the effect that it was infeasible, wouldn't work, wouldn't actually solve the problem, or whatever. Just to have that person employ words to the effect of implying I wasn't qualified to question his or her judgment/knowledge/decision. Chuckle, one particularly troublesome PIA once swelled up, turned red in the face, and reminded me that she had NOT ONE, but TWO PhD's and felt she was quite qualified to tell me I was wrong and her solution was better. ROFLMAO ... at the time we were discussing an issue about which she'd already established, via things she had said, that she did not know as much about it as a first year student in the subject. I refrained from calling her dumber than a rock. But it was what I was thinking. I just resorted to my old standby. "Madam, THIS is the way it is going to be. As per the contract. If you have an issue with that, please take it up with the District's manager in charge of overseeing the contract and it's completion." and I handed her a card with his name on it and walked out. Later that fellow, after she'd had her chance to vent at him, make her demands, and so forth called me up and called me a SOB. Politely. With a big sigh at the end of it. And expressed his pleasure in the fact that he only had a year to go until retirement. Oh, he'd not bent to her will. But he was sure hearing about that. Besides the fact that she was a major department head, she had a close alliance with numerous key players in the school district (a large one with a couple billion bucks in annual funding). And he'd had to defend his decision to not let her have her way repeatedly. And in some cases, heatedly. We still do business with that school district. In the end the performance of our services has met or exceeded all their contract requirements. So that lady and I do upon occasion have our paths cross. When that happens, I smile, am polite, wish her a good day, etc. She ignores me as if I don't exist. "The trouble was apparent from the first month the new software went live. Some teachers were underpaid, some overpaid and some had their names completely erased from the system." The trouble I have here is that I have seen, and experienced this precise problem. Numerous times, within numerous organizations. Happened when I was in the Navy (I retired from that service) several times as they changed their pay and accounting systems. Happened a couple times after I retired from the Navy and worked for a major telecom for 10 years. Has happened once since I started working for my current employer as they switched over their software. Know of it having happened in numerous other organizations that friends and family have worked for. So what's new? Is it being suggested that it's not ever really the IT people's problem or failure? Give me a break. BOTH sides have significant culpability and responsibility for such failures.

raedskaf
raedskaf

Change management is very important point success the project. secondly having the processes built it correctly prior to project initiation would be very important factor as well.

bherbac
bherbac

Toni, I would add to this the current fast track development strategy that issues Purchase orders first and comes up with a design second. I worked for a company that did this and found that almost every project had similar problems. The source data was always a mess with major projects added to clean it up. Implementations would be at the 50% point and someone would realize that the new system had to connect to another system that no one had thought of. In my case I was in the IT department, but the business had grown, changed and staff had turned over. So you always seemed to at the beginning of the learning curve. No one seemed to know the all of the pieces that made up the company's IT/Data infrastructure. Upper level management always wanted these projects done yesterday. So design time was always to short. My two cents.

frherndon
frherndon

Correct: I have 43 years in IT. Overheard in the halls of IBM offices -- State of Florida Bureau Chief: "Build the project and don't bother us until it is done and delivered". Huh! No design criteria and meetings. Air Force Budget System End Users: "We love your design and Live Demo", end of discussion, no sign off on specifications, forced into creating the project or default on Million Dollar contract (Saving grace: Wrote the Air Force a PO Letter stating, "Thank you for your verbal de facto approval", here's your delivery, pay us! Argument but nothing in writing. Incidentally this project was a success. International Longshoremen -- we've spent 1/2 million already and you are telling me that the project is dog sh-- and going down hill -- Price Waterhouse pailed, the developer fainted, and I the consultant was hired to fix the problem which was to convince the group to do a Business Area Analysis and buy a $2,000.00 off the shelf accounting system (Successful then). Other than that Mrs. Lincoln, my Project Management Course includes an MS-PROJECT exercise to help Grandma create thanksgiving dinner with a cost buildout - both forward and backward scheduling to get dinner on the table at 1:00 Pm on thanksgiving day. Only women can pass the exercise! frherndon@bellsouth.net.

dbecker
dbecker

1. It is pointless to argue with a crazy person. 2. People fail. 3. People lie. 4. It is impossible to be competent in a dysfunctional organization. 5. These days, most environments are dysfunctional -- on a rather grand scale. In the end, the Los Angeles Unified School District is probably better off, in spite of the rough transition. The reason? Government has adopted the worst of the corporate model and implemented badly with the expectation that they will reap the ROI exhibited by the corporate model. The problem is that government has not stood around long enough to see what the real ROI is -- and is now paying the price by issuing terribly administrated bailout money which will be proven to be going to no particularly good end. Politics means that the fools will only listen to what they want to hear -- which always generates the most awful judgment. The competent consulting sales person capitalizes on fools, particularly those in government because, even with penalties and pay backs, they still earn hefty revenue. SAP won. D&T won. And, after all that is said and done -- even with the pain of loss by many of the innocent and sometimes witless victims -- the end result was likely the best outcome that could ever be expected with such grandiose schemes playing out over such a long time. Which brings us to the ethics involved: 1) The end justifies the means; 2) Don't get caught; 3) Silence the critics by ruining their credibility up front. So folks, both technology and organizational issues are again irrelevant and, in the end, the best use of time is to use the "Assertive Incompetence" methodology to always insure that any and every project is a success (and this means that no project ever has to fail): Declare the project a success. Go back to rule number three to prove this correct. One also needs note that project entropy is involved: Competent participation becomes less and less available as the project progresses. Oh, you know: The sun produces energetic photons, which are absorbed by trees, the trees are chopped down, cut up for fire wood, burned in the fireplace. Now. Take the ashes and try to burn them. The same thing happens in projects, but with burned out people. The real winner is the public official who had the vision to buy the SAP software in the first place. If it worked out the same as Ray Corpus in the Tacoma City Light Project, the public official either ended up as a salesperson for SAP consultants and / or ended up in a sweet deal in another government agency where they "liked his style". Stop whining about organizational issues producing failed projects. Go where the money is. Lie, cheat and deceive. Be prepared to pay penalties. As long as you have the chutzpah to objectify arrogant fools without pain from your conscience, there is so much money to be made capitalizing on the confusion of beaurocratic buffoons who will leave it to someone else to pay the bill. It's a win-win situation. For you at least -- and the Devil can take the hindmost 1/3rd of the misfortunate.

cantis
cantis

There may be a fundamental issue of scale - humans have for most of their history worked at the 'village to town' scale. We naturally create around ourselves communities of a hundred or so people that we interact with on a regular basis. Technology extends this but really can anyone talk to 300 friends in a meaningful way? How can we expect to install complex technology systems responsible for working with and for 100's of people, we don't think like that. It may be that project successes at this scale are the exception. We might be better off in the end to move - deliberately - back to distributed systems. Teachers could be paid out of school offices, errors and omissions in their pay would be handled by empowered local administrators. Yes this will have inefficiencies but maybe that would lead to more robust and resilient systems that would exist at a scale that we could really work with because we can grasp them.

franklinharbin
franklinharbin

what i've encounted is counflicting data on a mishmash of outdated technology, systems operating 2 to 3x's their life cycle

jimmeq
jimmeq

I could write a book about projects that don't get off the ground due to egos. In government, there is no bottom line to make a profit plus there is no limit to the spending.

jmarkovic32
jmarkovic32

This is what happens when organizations put IT on the back-burner and add oversight of it to someone who oversees another department, spreading him or her thin.

tom.moffatt
tom.moffatt

Technical glitches are real. The reasons that people build bad technology are many, and need to be addressed at the project management end, as you say. Poor communication between stakeholders and designers is one problem that you mentioned in your article. Poor testing methodology is another. Several large library software projects have failed in North America due to problems of scale. The software tested well in smaller environments, but as soon as it was rolled out to a large, multi-node regional library system, it failed completely, negating years of development work.

Frantz11368
Frantz11368

The biggest issue with IT these days is that it has been too politicized; IT is supposed to research, find and apply the best technology for the overall achievement of the organization strategic goals. Nowaday most organizations have gotten rid of their CIO. Furthermore the great majority of companies have placed IT under the VP of Finance, whose main concern is to save every penny that he can for the company. IT is sort of a Research and Development entity for a company. Hence IT should never a fixed budget allocated to it. IT needs to be run by technical people with an open mind. WHAT EVER HAPPENED TO THE SYSTEM DEVELOPMENT LIFE CYCLE, THE SYSTEM ANALYST? WE NEED TO GO BACK TO BASICS, THE OLD DAY OF THE INFORMATION SYSTEMS DEPARTMENT. It is time for the Finance department to bud out of IT.

tkean
tkean

I've been in the Technology Integration business for over 25 years and have delivered hundreds of projects in that time. I can say from experience that when projects fail it is generally attributed to communication issues either on the client end, the integrators end or both. In most cases the clients are not experts on the products that they need (that's why they come to us) and in many cases neither are the people that are selling the products (had to clean up the work of many other VARs over the years). (bad combo) With staffing turnover on both ends and the length of the planning process, lack of fully documented needs etc.. its no wonder a project can be doomed from the start. The responsibility lies on both ends. You really can't blame the technology, its people that pick it and its people that configure it, plain and simple...

cd003284
cd003284

I can't if organizational issues are the most common cause for failure, but they're certainly one of them. My "favorite" is maybe the oldest error of all: making tech decisions based upon political criteria. Ex. Choosing the wrong product/service in order to satisfy management's ignorance, prejudices, fears, or personal relationships with vendors. But this isn't just an IT thing. It's a classic and virutally universal organizational pathology.

derrek.kim
derrek.kim

Absolutely organizational issues are bigger than technology issues. In the case defined in the article, the fact that there was already a mishmash of technology and it was riddled with errors is a giant red flag for this. In this day and age it doesn't take $95 million to have aligned and accurate systems. This shows that the organization did not put enough emphasis on managing thier information in the first place. Putting in new technology will NEVER make all those problems go away, unless it is done along with sweepting changes to the business culture.

Meesha
Meesha

". . reasons for the problems are usually not technical; they?re ?organizational, political and cultural in nature in almost every case.? This has been proven time and time again and not just with HR IT projects. However, the last HR project I was involved with was as the project manager in a "weak matrix" organization. To keep this short, there was no proper oversight or support for the initiative from executive management and the Director of HR was a grand technophobe assigning others in his HR department who could not or would not commit to the endeavor simply because he did not really support the goals. Needless to say the project costs ballooned and they still did not get what they needed. When fingers were pointed, it was the PM (me) that carried the brunt since all I was empowered to do was report on the "negative" results to the functional managers who really didn't care anyway. At the end of the day, this organization paid twice for something that could have been delivered through a better structuring (strong matrix) along with political and cultural will. IT was never the issue.

jperick.mbei
jperick.mbei

Project failure can be attributed to a number of factors. Project complexity can just be the tree that hides the forest. Small projects do fail, too. I think that some reasons might might be more obvious than other, and both, or all actors share the blame. In the following lines, I will venture into identifying some of the key factors that may affect project failure/success: (1). Poor Communication: Communication is a key factor that can significantly affect project success. In larger projects, IT and non-IT projects, the more communication channels, the more complex communication becomes and, by the same token, managing the project and people becomes more challenging. To determine the number of communication channels, use the following formula: Cc = n(n-1)/2 (where n = number of people involved and Cc = communication channels). Thus, good project managers must also be good communicators. They must consider many factors (e.g., the size of the team, the cultural setting, the type of information, and much more), then apply the appropriate communication medium (e.g., e-mail, face-to-face meetings/presentation, telephone, etc.). This is even more important with a huge project that includes stakeholders with potentially conflicting interests. (2). Organizational Culture: This factor is just as important as communication. To communicate effectively, you must tailor your message well. And tailoring a message that produces the desired result requires knowing the audience, the cultural environment, including organizational structure, the political landscape, and much more. A project of this magnitude is likely to ignite deeper infighting. Knowing the potential sources of resentment or disagreement and taking pro-active steps can be of greater help. Unfortunately, not all project managers are fine "managers", let alone people managers. Not all are great negotiators. In fact, like someone said in this thread, many PMs are more "technology managers" than people managers. Yet, we all know that--and I do agree with the author--that technology per se is not fundamentally what causes projects to fail. It can be, but more too often, technical factors have less impact than do non-technical, i.e., human factors. Thus, I have seen consultants come in, attack the technical part of a project without first giving themselves enough time to "learn" about the organization, its culture, its people. Have you seen any project plan that mentions "Environmental Learning" as one of the project steps? In fact, this step should come first. In soccer, for instance, before a team like Barcelona FC plays with, say Bayern or Chelsea, they are going to find videos of their opponent's previous games, watch them, study each player, analyze the team's strategy and tactics. Then, only then will the coach determine his team's strategy and devise tactical changes based on the knowledge of the other team. Why can't IT Project Managers do the same? OK, pressure to deliver "fast system food". But do they always assess the risks associated with delivering ill-cooked food to the client? (3). Executive Sponsorship: I do not think that project success depends upon the CIO/CTO being technically savvy. If the CIO is technical, then great. But that aspect really will not impact much. All you need from this senior manager is active support, active sponsorship. Thus, the key factor here is Effective Executive Sponsorship. This factor is key especially in projects of this magnitude. Without effective and active executive sponsorship, you will have a hell of a time navigating the hot and potentially troubled organizational waters, trying to obtain vital information, trying to obtain horizontal support. I would even say that this factor is the number one factor with high stakes projects. I suspect that the school district had silos of systems that each housed the needed data, and this data may have been in different formats, under the stewardship of different people. Mind you, it takes more than technology to bring these people together (especially if there was existing infighting), convince them to share the data/information they each has. So, as you can see, effective executive sponsorship, communication, organizational culture, and the PM's ability to communicate effectively, manage people--not just technical processes, negotiate effectively, and communicate both effectively and efficiently are factors that, I dare say are going to be critical. Jean-Pierre

Craig_B
Craig_B

I think many of the complex projects fail due to people who don't fully understand the entire process and goals. I have seen politics, scope creep, uninformed decision making, ego, etc. doom well intentioned IT projects. People need to understand what is the reason for the project, what is the end goal and what will it take to reach it. The more complex the project the more planning required, then once that plan is in place, it needs to be communicated and should not be changed without a full review. Too many times people are working in opposite directions or by making a "simple" change have added cost/time to the project.

fidlrjiffy
fidlrjiffy

Ask ten people involved in IT projects what is the most challenging aspect and I assert that no more than one or two will answer that the answer is organizational. People reading this argument will disagree but go to work and try it. I also guarantee that the readers of this article will be skeptical. The most interesting thing about this is why, if you actually go out and ask, this is true. A technologist will, of course, focus on the technical aspects of the project and will state that finding the time to do the work is the toughest thing. A business stakeholder will most like shrug his or her shoulders and also state the technology is the hardest part mainly because they are not familiar. We perhaps can forgive the technologist but not the stakeholder who should know better. But why is it so and why isn't it recognized. The first part is easy; the majority of the time IT projects are grafted onto the existing workload of people on the business side and, presumably, they're engaged in their jobs fulltime. They simply don't have the time nor, more importantly, have the option of allowing the project to exceed the priority of their day-to-day work. If something has to give it's the project 100% of the time Business people also woefully underestimate the time they need. IT projects are also not something they are often familiar with. They don't have time, interest, or the inclination to answer a lot of questions. And when it comes to acceptance testing, forget it, something else is always more important, usually with complete justification. Upper management contributes by simply assuming that a 24 hour day is just not part of natural law. On top of that we have unrealistic expectations, arbitrary deadlines, insufficient resources, churning priorities, the list goes on and on. These are the reasons but why since it happens far more frequently than not why do we not see this? Someone said that insanity is expecting that no matter how many times a thing is done that somehow a different, and better, result will occur the next time. Basically, we are very, very bad at being honestly realistic about the bad things that have occurred in the past and will occur in the future if we do the same things. We simply refuse to believe it. There is also the maddening experience of upper management, chiefly, simply asking for what they want to hear. How often is a realistic estimate simply rejected out of hand? Pretty often, right? For all our love of process companies cannot come up with one that works (perhaps because there's no such thing) and then descend into more comfortable chaos where at least they can feel that they're doing something. After the immense and unnecessary effort everyone can pat themselves on the back that they went through hell and back to accomplish the tenth of what they had planned. Lastly, there is the absence of accountability and the absurd notion of matrix management. Project managers who nowadays are assumed to be masters of process are burdened with project teams that are not accountable for following the process. No where in the job description or yearly objectives of the director of HR, for instance, will you find completing such and such project on time. Virtually anyone on a matrix team can say no to a PM with no consequences beyond getting written into some issues log. Technology is the easy part; organizations seem built to fail.

jscott
jscott

I recently wrote an article on this topic and of the 6 ways I listed to fail a project, not one was based on technical reasons: http://ciomojo.com/?p=96

Chief Alchemist
Chief Alchemist

Pardon me for stating the obvious but to succeed: 1) Properly defined goal(s) and an agreement of what defines success. 2) Commitment / buy-in from all to #1 3) Ongoing communication 4) Setting and managing expectations 5) Accountability and responsibility 6) Wisdom and agility to adjust course as necessary Unfortunately, too many projects begin (and try to carry on) that lack an awareness of these elements, let alone an agreement. For example, consider the divorce rate.

gavinwun
gavinwun

organization is an issue, but i think more importantly is communication between the client's requirements be made clear to the development team, which also means constant tracking, updating and reminding the development team (preferably by the same overseer/project manager). A good relationship between the client and firm developing the system is also very important from my experience.

reisen55
reisen55

Nothing else here, internal information technology professionals generally KNOW the infrastructure, protocols and people far better than an outsourced consultant does. How many firms such as CSC and ACS totally botch Medicare and Medicaid systems in states? Did you know that the Census was to be a Computer Sciences Corporation triumph, but the government is back to PAPER because CSC totally wrecked that one too. Look up the IRS relationship with CSC. OUTSOURCING FOLKS!!!!!!!!!!!!!!!!!!!

ziffr
ziffr

I agree, sort of. The main problem is that there is a huge time gap between concption and implementation. I have solved this problem. If you would like to see how go to http://www.dbssb.co.uk and click "dataByZed and the Application life-cyle" at the botto m of the page

jkameleon
jkameleon

So, the answer to the last question would be: Not that organizational aspects of a project cause failure more than the technical ones- they cause ALL failures. IT makes organization more effective in all aspects, good and bad. It's sort of amplifier, like a bullhorn. If speaker has something articulate to say, bullhorn will help hit get his message to larger audience. If not, bullhorn will help larger number of people realize he's a bumbling idiot. Similarily, IT will help a good organization become better, and bad organizatin worse.

jean_mbadi
jean_mbadi

Usually a technical issue is easy to fix than a culture, but in this case both were involved in a failure. When talking about middleware, SAP is not the leader in integrating legacy systems into new ones with SOA and web services, but what happened to the leaders in that field, and why the project manager did not have a clear choice to make this a priority, did he lack time to analyse every issue that might harm its work, what a waste of money.

kazmiasim
kazmiasim

I agree on the notion partially. However, its equally important to note that technical glitches are the most horrible ones, only to be found out at some later stage of the project. Organizational Managers may see everything working out fine untill the project is nearing delivery, only to find out some lack of technical insight on Technical leadership part made project into a hazard which was successful now. I think for an IT project to be successful a balance of honest and competent technical as well as Organizational leadership is required. To sum it up: IMHO the following are the main reasons of a project being a failure or atleast not as successful as it was required to be. - Lack of Future vision in the Organizational Leadership - Lack of Honesty and commitment on the management's end - Lack of Technical Leadership - Lack of snappiness in technical reviews - Team Politics - Cultural differences - Requirements Clarity - Selecting the right methodology to undertake the project.

jignesh23
jignesh23

thanks for sharing such a wonderful topic over IT project failures. Being a part of IT industry and after working on various project here are few reason which may affect the project: - Lake of expertise - Few agencies sign up project without having such expertise and work force - Lake of analysis (few prediction made without acknowledging the client requirement) - Over confidence ( this may also affect the work) and so on..

stewart.watson
stewart.watson

Three points: 1 The trouble with the definition of what causes the failure is that even technical failures can be tracked backed to organisational failure - choice of the wrong technology, poor requirements etc. 2 With the big ticket projects I would argue that the main fault is just that they are too big and complex to succeed as originally envisioned. Nobody can adequately describe the problem space and so the project starts with failure as an inevitability. Only those ones that are broken down to lots of related projects have a chnace of success. 3 Finally - big projects can never be about just technology - they encomapss massive organisational change. And without addressing both adequately (and probably change more importantly) - failure is an inevitability (failure being defined as being unreasonably distant from the original goals).

wijngaarder
wijngaarder

Surely true but I also believe those project start off with too big a scope. Such large projects can always never be controllerd (due to organizational issues). My advise: Don't start off with to large objectives, create many smaller projects, and have a program manager with IT knowledge AND political skills (I know, those are hard to find).

mdimmick
mdimmick

My experience has shown that communication and understanding is predominately the issue. A clear and well documented understanding of what is required. A clear communication of the solution against those requirements and then managing the exceptions. And finally talk with the customer not at the customer.

Tony Hopkinson
Tony Hopkinson

system for collecting reasons for delays in a manufacturing process. I got told there was something wrong with my work, because the number of minutes delayed went up and the amount of production per available minute went up as well. Took me ages to explain either they were under reporting before or over reporting now. I'm positive they were massaging the figures to look better. Mill manager wanted to check my math! One of the first systems I worked on was replacing the a manual system for recording how much stuff got returned by the customer and why. That went up as well. Not due to accuracy, but because the manual system only reported those customers who complained in that month in it's year to date figures.... Quite strangely once the real figures started getting reported, some of the issues got resource and our customers, started to like us a bit more. The sudden jump in complaints was considered highly suspicious, as though IT had again f'ed up...

singerap
singerap

And if you think it works any different in business you are incorrect.

jbaker.it
jbaker.it

Both are equally important. When IT mgmt and staff doesn't understand the Organization and Communication it requires for HR it's not as effective. When HR mgmt and staff doesn't understand the Organization and Communication is requries for IT its not as effective either. I used to intern for a large community school system. The IT had a strict organizational system for deploying computers. There was an organized way we built computers and even a way to get rid if PC boxes. Everything had its own place.

Devans00
Devans00

What you say is true Chief Alchemist. Unfortunately even with all these elements in place, there are still some co-workers who actively or passively block or undermine projects. I can empathize that they feel threatened that their status in the office will change or they will "lose power". The inability to see the big picture is maddening, still. If the project or company fails or does poorly, then how safe is their job? Hard to play silly games from the unemployment line. Luckily, these types of people are in the minority. Most employees are professional and mature enough to do good work and do their best to contribute to any success.

asics447
asics447

Funny I used to work for one of those type of companies and they had tons of PM's who constantly failed and had to pay the customer for the failure and took no accountabilty.

john.jelks
john.jelks

I saw the line "This page intentionally left blank" on 5 of the 11 *chapters* of a D&T project manual for a State of Delaware software project. D&T was applying a mindless boiler plate template to a complex conversion, instead of doing a proper analysis at the outset. Very Scary.

caryl.forrest
caryl.forrest

Project managers are generally action-oriented people. To take time, particularly at the beginning of a project, to carefully assess the organisational environment and culture, is seen as a waste of time. They want to deliver something. Anything. By rushing in at the start important clues are overlooked. For example, you are told System Y is being replaced because "it's useless." Sometimes System Y is actually okay but (a) users haven't been trained to use it properly (very common) or (b) sometimes minor modification to the user interface is all that's required, rather than a new system, or (c) existing business processes are flawed and/or ambiguous. So the question here is, is a new system needed at all? As the correct answer to this question might lead to loss of contract (project managers) and loss of face (project owners), it is rarely asked.

IBM5081
IBM5081

Many of the projects I have seen founder resulted from each party using terms not based in a common understanding of them. Each player has a slightly different meaning attached to the same concept. The "ah ha" moment occurs when someone reviews the project plan (implying that it must be written in the first place) and notices that the five blind men are describing an elephant.

Tony Hopkinson
Tony Hopkinson

Improve the systems to .... is one where the PM legitimately say, lets spend some money on training, or tweak this or sack that pointy head over there. If as is usual the scope is replace system X with idea Y using technology Z so it runs on this 286 I was using as a footstool. F'ed grom the get go. Seen it all to often, so many contraints already in place, that all you can do is manage the failure. So a couple of nice dashboards, tell everybody it's going great while surfing for another job. The current economic situation is going to stop some of the f'wits moving on, which should be interesting, not to mention hilarious.

Editor's Picks