Slashdot Mirror
Identifying (and Fixing) Failing IT Projects
Esther Schindler writes "Often, the difference between the success and failure of any IT project is spotting critical early warning signs that the project is in trouble. CIO.com offers a few ways to identify the symptoms, as well as suggestions about what you can do to fix a project gone wrong. ' The original study (which is still sometimes quoted as if it were current) was shocking. In 1994, the researchers found that 31 percent of the IT projects were flat failures. That is, they were abandoned before completion and produced nothing useful. Only about 16 percent of all projects were completely successful: delivering applications on time, within budget and with all the originally specified features. "As of 2006, the absolute failure rate is down to 19 percent," Johnson says. "The success rate is up to 35 percent." The remaining 46 percent are what the Standish Group calls "challenged": projects that didn't meet the criteria for total success but delivered a useful product.'"
I have to feel that this number would be much higher if project managers would just learn to allocate an infinite budget and an unlimited timeframe.
Badass Resumes
at least a large part of the problem are the incompetent masses that we refer to as "IT specialists". I'm surrounded by them.
Your consultants are all Elbonian
That 31%-flat-failure rate sounds just about right; about a third of the projects I've worked on over the last 15 years have been complete flops (with the usual list of various reasons from "bad idea to begin with so it needed killin' " to "we changed bosses and since your project wasn't the new boss' idea..."), but I'd have to challenge the notion from TFA that they "produced nothing useful", because I've learned something I didn't know and wouldn't have otherwise known from each of them -- in other words, I'd count them all as at least partial successes because I personally gained something from them.
This space intentionally left (almost) blank.
Seriously.
Most IT projects I've been involved with that got to some difficult points suddenly had no one willing to discuss them, much less do anything.
Woe is the girl/guy with no authority brought in to get the project back on track.
Got Trader Joe's? friendwich.com RSS feeds work now!
When management wants a project that IT knows is bound to fail, our company will sometimes hire an outside consultant to run the project. That way, half way through the project, as we miss milestones, we can fire the consultant and blame it all on him. He gets paid, and we get out of the blame. Win-win.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Half of all outgoing port 80 requests are to slashdot.org.
The cake is a pie
From TFA: "Small, discrete and often" are the guidelines for the milestones for a successful project. And from the Agile Manifesto: Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale. From TFA: "Make sure everybody really agreed to what the project is going to do," he says. "Make sure everyone has the same goals even when they have conflicting agendas." And from the Agile Manifesto: Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done. This is just another shoddy example of "journalism" from an IT rag whose job it is to produce buzzword-laden tripe that can be used to get advertisements in front of tech weenies. Ultimately, the actual value of the articles in mags like CIO.com are marginal at best, and usually only slightly more interesting than the advertisements!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
'Twas the night before implementation and all through the house,
Not a program was working not even a browse.
The programmers hung by their tubes in despair,
with hopes that a miracle would soon be there.
The users were nestled all sung in their beds,
while visions of inquiries danced in their heads.
When out in the machine room there arose such a clatter,
I sprang from my desk to see what was the matter.
And what to my wondering eyes should appear,
but a super programmer (with a six-pack of beer).
His resume glowed with experience so rare,
he turned out great code with a bit-pusher's flair.
More rapid than eagles, his programs they came,
and he cursed and muttered and called them by name:
On update! on add! on inquiry! on delete!
on batch jobs! on closing! on functions complete!
His eyes were glazed-over, fingers nimble and lean,
from weekends and nights in front of a screen.
A wink of his eye, and a twitch of his head,
soon gave me to know I had nothing to dread.
He spoke not a word, but went straight to his work,
turning specs into code; then turned with a jerk;
And laying his finger upon the "ENTER" key,
the systems came up and worked perfectly.
The updates updated; the deletes, they deleted;
the inquiries inquired, and closings completed.
He tested each whistle, and tested each bell,
with nary an abend, and all had gone well.
The system was finished, the tests were concluded.
The users' last changes were even included.
And the user exclaimed with a snarl and a taunt,
"It's just what I asked for, but not what I want!"
I haven't read the article but I would bet good money that they are allowing clueless managers and CEOs who gave very bad requirements in the first place, to determine if something was a success or failure. In other words, software is only as good as the initial requirements and design. If your client / customer is clueless then they will give you some hand-waving description of what they want ... something like "Listen, we need a new computer system that kind of does what the old one does, but just works better and makes more profits for us! Now hurry up and make it work, Code Monkey! Now excuse me while I retire to my executive suite / relaxation salon and get my manicure."
6 /01/30/dilbert20060121046729.jpg
( Not that I'm bitter or anything. )
http://blogs.warwick.ac.uk/images/steverumsby/200
I can throw as many stones as I wish; my house is made of transparent aluminum.
> Step 2: Figure out what that problem everyone admits is wrong really is
1. We admitted we were powerless over this schedule -- that our project had become unmanageable.
2. Came to believe that a Power easier to blame than ourselves could restore us to schedule.
3. Made a decision to turn our will and our lives over to the care of the Consultant as we hired Him.
4. Performed an overreaching and mindless team-building exercise.
5. Admitted to the Consultant, to ourselves, and to the CEO the exact nature of our incompetence.
6. Were entirely ready to have the Consultant take over our jobs duties.
7. Humbly paid the Consultant to fix it for us.
8. Made a list of all persons we had harmed, and became willing to make suck up to them all.
9. Sucked directly up to the CIO wherever possible, except when to do so would involve our beating him at golf.
10. Continued to perform team-building exercises, and when we thought it was silly, we still faked it to HR.
11. Sought through kickback and corruption to improve our friendship with the Consultant as we understood Him, paying only for Coverage of Our Asses and the budget to carry that out.
12. Having had a Machiavellian awakening as the result of the project's inevitable failure, we fired the Consultant and resolved to carry the blame to other departments, and to re-hire the Consultant next year so that we can practice these principles when the next project goes off the fucking rails too.
Spotting a failing IT project: If it's a project, and it involves IT, then it's failing. (The summary's cited statistics bear this out).
Fixing a failing IT project: Rewrite the laws of economics. (My experience bears this out). This may involve fiat, chemical means, or founding a new religion.
I gotta say, I always take this kind of stuff with a grain of salt. As an IT manager (director, or whatever the hell you want to call it) I've got a little perspective on it.
There's quite a few projects that we arguably start (probably even close to the figures quoted) that we don't finish. They're not failures, often I (me, not the department or project managers) had no intention of completing them anyway. Here's why some don't get done:
1. I can't get it past the budget process. There's a time and place to pick your battles. Maybe throwing HR's new whiz-bang software project under the bus to make the operations manager's project swim along is worth it. It doesn't mean HR's project is a failure.
2. We start a project to investigate a new technology. Hey - sometimes (dare I say most of the time?) the new stuff doesn't work as advertised. Sure, we've got an older 802.11b network running side-by-side our 802.11g. We looked at ripping it out and starting to get into the 802.11n, but it's not worth it right now. But the exposure to 802.11n was worth it. We'll revisit it next year (when Cisco gets an n product.)
3. The "nice to do" list also creates some "failures". Boy, right now we need a strong asset tracking system. Well, screw it. We can track the licenses on paper as we've been doing. We've got more important things to worry about.
However, the shit that needs to get done, gets done. That new accounting system? Hell yeah we're going to get that right.
----- obSig
If you aren't part of the solution, there is much money to be made in prolonging the problem. (My second favorite de-motivator)
Seriously, though the classic problem with IT projects are two-fold: 1) Unclear Requ2irements and, 2) Scope Creep. Unfortunately, while IT is bemoaned as incompetent, the truth is that most of the users are even more incompetent, yet the IT departments ask the users for INFORMATION.
IMHO, You have to assign someone from IT to LEARN THE BUSINESS before trying to create solutions. For example, if you are creating an application for a Shipping Department, send people from IT to go work in shipping for a week and UNDERSTAND how the department operates and how it can be improved. Asking the users what they need without true understanding leads to disaster and inefficiency. If you gain understanding and insight into how to create a solution, you can make real improvements and possibly even eliminate inefficient/useless tasks and save labor.
Scope Creep.... The old, hey while you are at it, could you just add one more feature to the program? You have to respond NO, but we will add that to the feature list for version 2.0 of the application. Imagine if Henry Ford tried to add all the features we have on the modern automobile to the Model-T. The Model-T wouldn't have ever been delivered. Creating software is an iterative process and just like car models you have to stop adding features at some point.
Good Luck! Just remember, the problem is rarely technical.
All projects from civil engineering through to social engineering exercises and time sheet programs can fail if not well designed and well executed.
How many civil engineering projects are planned by someone with someone with little to no experience and implemented mainly by fresh graduates? Software's often lack of physical safety issues and low visibility of mistakes make the seat of our pants approaches way too common. My personal favorites are the schedules that assume no one will ever get sick or take vacation plus introduces tools and technology team members are not familiar with.
> "As of 2006, the absolute failure rate is down to 19 percent," Johnson says. "The success
> rate is up to 35 percent."
They redid the study excluding government projects?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
You make it sound like a such a bad thing. I don't necessarily think it's just about "lowering the bar", but instead an issue of having realistic expectations. In 1994, having a dedicated IT department was still relatively new for many companies. To put it in perspective, people were still using Windows 3.1. The Internet wasn't even a blip on the pop-culture radar, and (IIRC) Netscape was just being released around that time. Most people understood practically nothing about computers and networks. In a lot of colleges, CS was still a relatively new major, and many colleges didn't even offer IT-specific majors yet. For a long time, the "computer experts" came out of other majors relating to math, engineering, and science.
So it wouldn't surprise me at all to learn that the managers of IT projects in many companies had practically no idea of what they were doing. I wouldn't be surprised to hear that they had silly expectations about how things would work or what their new systems would allow. After 13 extra years of seeing the reality of computing and being frustrated by computers, one would think their expectations would be lowered somewhat.
One problem I see, is that many IT projects begin with the goal of making the project manager look good.
The proper way to start a project is: How can we fix BAD THING. Instead of the usual "We should migrate this to SAP cause that would look so cool on my review".
Many times IT projects become a destination, instead of a method to reach the companies destination be it ( manufacturing / sales / service ).
- High Tech workers, please say NO to Union Carpenters, their Union sees fit to control our compensation.
As a contractor (aka freelancer) software engineer and analyst i have over the years learned to spot a number of indicators which are usually associated with the kind of groups/companies where software projects tend to be late and/or not deliver what the business needs. Here's a couple of indicators for that kind of place:
- The bigger/more-complex projects have little or no analysis.
- There is neither a formal Requirements Gathering stage nor (in Agile Programming) an easilly available user/user-representative with which to discuss business features.
- Delivery of a project to a client is an unstructured process. In other words, there is no list of standard types of documents and deliverables to deliver which is common across projects.
- Project planning does not have a built-in margin for unforseen problems and sometimes relies from the start in people working extra (unpaid) hours to make the budget.
- Sales dictates the deadlines without consulting (or consulting but then ignoring) the technical side.
- There are no specialized Testers.
- There are no standardized software components, software frameworks, good practices or documentation for use across the company.
- There is a vast number of software languages, software libraries or frameworks of different versions used across the projects done in the company. Similar projects use different languages/libraries/frameworks and/or use different major versions of those. Developers are totally free to choose the languages and libraries they want to use for the projects. Maintenability is not taken into consideration in the choice of languages/libraries which instead are chosen on the basis of "cool sounding", "fun" and "CV enhancing".
- The project manager has little formal or informal power within the company beyond his subordinates (this is harder to spot but a surprisingly good predictor of failure).
There's quite a lot more, but these are some of the more obvious ones and i've seen all of them already more than once.
More in general, what software development environments where late or failed projects are common share is a failure to organize and/or a failure to prepare and/or lack of "soft skill" from project management and/or ignorance of the characteristics of the software development process.
I find this article very annoying.
.. and conclude that things are improving, and then attribute the improvements to things like .. This awesome new, expensive, proprietary project management software.
.. excuse me, but I have NEVER seen a project that was conceived AND executed solely by any number of 'project managers', using any form of project management tools, meetings, and other justifications for their existence.
.. after 1994, an SQL engine is something tangible that you can download of the internet and get your hands dirty with the source code. Ditto with 'internet enabling' your applications - Ditto with having a real freely available and portable C compiler - ditto with having a raft of languages (perl, PHP, etc, etc) that open up new possibilities.
.. software projects are more successful. But can you simply attribute that to a small selection of expensive, proprietary project management tools ? WTF, I dont think so.
So a bunch of companies (who all sell expensive proprietary project management software) get their heads together and conduct a study on project success/failure ratios
Umm
Projects are successfully delivered by good coders with good tools, and a thorough understanding of the requirements. There have been RADICAL advances since 1994 in the way that software is built, and its these advances more than anything else that lead to successful projects.
Coincidentally, Prior to 1994, if you were working in software, you were working blindfolded with one hand tied behind your back. By 1995, this Linux thing starts gaining momentum, and very quickly we see this massive rise of open source projects in a huge number of areas. Prior to 1994, an SQL engine is some mythical binary blob that you have to purchase from Oracle or others
Suddenly, as a software coder, the blindfold is removed and you have both hands free to work. Whatever problem domain you are likely to encounter, you can easily find open source projects that have already dug very deep into that problem domain, and have code and design discussions open for general peer review.
So its no surprise that in this new and extremely fertile post-1994 world
Another thing to note is that the core developers in a lot of projects are older and wiser now. Many are well past the wrong side of 40 and still coding day and night for the sheer joy of the art. Perhaps they have also grown more politically savvy, and know how to take management speech, distill the essential elements out the mouths of managers, and then go away and do the project their own way regardless. Except this time, they know how to twist it so the 'managers' can feel like they deserve some credit for the project as well, whilst at the same time keeping them discretely out of the way - so that the project itself can move forward smoothly.
Maybe that is one benefit of shiny new project management tools - it gives the managers something to occupy their time with, so they can keep out of the way.
Try planning a project that will take 5 years and $10 million.
People WILL leave the organization during that time. They will be replaced. If it was a tech, will the new tech do things the same way as the old one? Will you have hammered down your process so that s/he will HAVE to do it the same way?
Will any tech worth his salt WANT to do things the same way as the old guy without questinging anything? Personally when I enter a new company, a large part of "getting adjusted" is fighting every foreign idea tooth and nail. I come to terms with them shortly, but I can't accept them as useful until I see them.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.