Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Identifying (and Fixing) Failing IT Projects

ScuttleMonkey posted more than 7 years ago | from the if-it-aint-baroque-don't-fix-it dept.

Software 144

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.'"

cancel ×

144 comments

Sorry! There are no comments related to the filter you selected.

Looks like (0)

Anonymous Coward | more than 7 years ago | (#19906719)

Captain Obvious is writing articles again.

With Major Hopeful's help (1)

EmbeddedJanitor (597831) | more than 7 years ago | (#19906945)

A fatally flawed project can often not be recovered or redirected. There is nothing special about IT projects. All projects from civil engineering through to social engineering exercises and time sheet programs can fail if not well designed and well executed.

The phases in a doomed project seem to be:

1)Can we ignore it? Maybe the probelms will just go away and our asses will be saved.
2)Can we fix it? Take some corrective action to save the day.
3)The project is doomed. Can we reuse some of it? At least then we didn't waste all the time and money.
4) Reuse disk space. Find a scapegoat.

Where the FUCK is iLife '07??? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19907013)

Come ON you homosexual deviants in Cupertino. QUIT FUCKING AROUND and update your fucking software every so often. You mincing faggots are worse than Debian...

Re:With Major Hopeful's help (3, Insightful)

spazLizard (1093769) | more than 7 years ago | (#19907343)

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.

Re:With Major Hopeful's help (5, Insightful)

ElectricRook (264648) | more than 7 years ago | (#19908187)

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 ).

Mod parent +1 insightful (1)

Dan Ost (415913) | more than 7 years ago | (#19909327)

I wish I hadn't wasted my mod points this morning.

That was one of the most insightful posts I've ever seen on Slashdot.

Re:With Major Hopeful's help (0)

Anonymous Coward | more than 6 years ago | (#19910437)

In government contracts to write software, it is usually a lot worse. All too frequently, especially on time-and-materials contracts, the man with the money has friends that are likely to loose a job if they don't get some work to do. The money man invents a project (this is nothing new) for the contractor to do (the lead contractor is an old friend or former government from way back when). The contractor silently develops this product. Eventually, they finish phases of it and the money man has to show the money providers what the money got them, so they do a review. No one ever writes a bad review of software they paid good money to have custom written. It always slices bread too. Money man believes this software is so good, he convinces the local chief scientist or CIO-rep that this software should be mandated by the enterprise. Other departments hear about this project and cry foul because this software only (poorly) solved problems A and C. In fact, this contractor did it so poor, that outsiders recognize why the contractor was in fear of losing their job: they suck at what they do, they charge too much, and everyone had moved on to having their problems solved by other means or software developers. But, this contractor is a "big industry player" and shouldn't be embarassed, and the political structure won't tolerate embarassing either the contractor who mostly did what was asked, even if poorly, nor the money man who did it only to see that a friend didn't lose his job. Eventually, they get it talked up nice and good and the project couldn't die if you tried.

An indirect reference to the project name: Congressional Hearing [globalsecurity.org] , look for the phrase "multilevel access". A paper on the software has been written, all glossed up to make a one-trick piece of software, doing a half-assed job at multilevel access (NOT ACCREDITED BY ANYBODY), and is available as a PDF [mitre.org] .

Re:With Major Hopeful's help (1)

Wiseman1024 (993899) | more than 6 years ago | (#19911383)

A project going the wrong way is often easy to identify. It's made of a pointy/creamy haired suited manager who hires low-paid novices and talks in business-speak(*), and wouldn't tell a computer from a bag of walnuts in his life. Naturally, he chooses Java, because he read about it in a magazine full of buzzwords and three-letter acronyms.

(*): Professional enterprise scalable object-oriented XML-based AJAX-based mission-critical business solutions that create synergy between your business departments through best-practice industry standards and allows you to deploy a Web 2.0 infrastructure that will reduce operating costs, maximize your profits, and convert visitors into customers, reducing the total cost of ownership.

Re:With Major Hopeful's help (1)

AKAImBatman (238306) | more than 7 years ago | (#19908851)

A fatally flawed project can often not be recovered or redirected. There is nothing special about IT projects.

I have to wonder, though, if the growing "success" of IT projects isn't related to more inhouse development. Back in 1994, large projects almost always relied on external consulting agencies like Anderson. These services were very poor at delivery, in part because of their lack of understanding of how each business worked. Staff employees usually had a better understanding, but even in large corporations there was limited number of people to obtain access to. Things were not helped by the common "waterfall" methodology, not because waterfall is inherently flawed, but because the flow of information was too tightly controlled.

Fast forward to today and the challenges facing businesses require an online presence. Because these presences usually require a larger staff to maintain, it makes sense to also do most (if not all) of the development in-house. This neatly sidesteps the internal resource issues previous faced by large IT projects, and thus the very reasons for outsourcing.

I won't comment too much on the situation of Indian outsourcing other than to say that my experience has been a matter of keeping enough local staff on hand to do a lot of command, control, and repair to the project on the fly. I simply won't comment on whether that results in a realization of the supposed Indian outsourcing savings or not.

Re:Looks like (1)

umghhh (965931) | more than 6 years ago | (#19911193)

Thank god there are still plenty of managers (majority?) that are commited to such things that not only violate common sense but provide me a system tester with job that (apparently) could not be easily off-shored to China. Sometimes however (quite often recently) they are so dumb that they do not even realize that failure costs money. Apparently the fact that products have to work so that they can be sold for money avoids some people completly.

Only 16 percent? (4, Funny)

Reverend528 (585549) | more than 7 years ago | (#19906737)

Only about 16 percent of all projects were completely successful: delivering applications on time, within budget and with all the originally specified features.

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.

Re:Only 16 percent? (1)

Doctor Memory (6336) | more than 7 years ago | (#19906991)

My feeling is most of these "successful" projects were small-team, hands-off affairs. It's easy to do good work when you have a fixed goal (or set of goals), a responsible team and nominal oversight. The big projects fail because they take long enough that people change their minds (so requirements don't stay fixed) and because there's too much communication overhead (the old "management wants status reports more often, because we're falling behind" situation).

Not just "minds". But also people. (1)

khasim (1285) | more than 7 years ago | (#19907125)

The big projects fail because they take long enough that people change their minds (so requirements don't stay fixed) and because there's too much communication overhead (the old "management wants status reports more often, because we're falling behind" situation).

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?

What about management? Does this project suit the goals of the new manager? Manager usually have to "solve" a "problem" to justify their salaries. Coming in and seeing a project this big ... that's a serious bonus if s/he can position it as a "problem".

Will the business even NEED a project that was designed 5 years ago? It doesn't take that long to put up a office tower.

Re:Not just "minds". But also people. (3, Interesting)

j-pimp (177072) | more than 7 years ago | (#19908793)

The big projects fail because they take long enough that people change their minds (so requirements don't stay fixed) and because there's too much communication overhead (the old "management wants status reports more often, because we're falling behind" situation).

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.

Re:Only 16 percent? (1)

RalphSouth (89474) | more than 7 years ago | (#19907517)

Capers Jones has some real data. If you aren't familiar with his work look it up. He reported a range of success rates based on the types of projects. It seems reasonable to believe that large abstract projects will have more chance of failure because of the complexities that large numbers of people introduce and the difficulty of keeping something funded that the executives don't understand.

Re:Only 16 percent? (1)

Chris Burke (6130) | more than 7 years ago | (#19907913)

Based on those numbers and my own experience, my question is: Instead of trying to "fix" all these broken IT projects, why not just shit-can them before you've spent X many man-years on them? So many of them fail, but the failure of the project does not cause the failure of the company. In other words, they were non-essential to begin with and whatever benefit they might have added is offset by their cost. Dump em.

Kinda like when my company decided to replace their functional but distinct HR, travel, and inventory database systems with a single "enterprise" system that cost $millions per quarter, and ended up being far less usable and reliable than what we had before, with the supposed benefits of integration never appearing because we canned the project after a year and a half because we didn't have the money to pour into it anymore. Not naming names, but to purchase this vendor's system you would have to be "a fool or dupe".

Should this project have been fixed? Or never started at all? You decide.

Re:Only 16 percent? (1)

Vancorps (746090) | more than 7 years ago | (#19908657)

You wouldn't by any chance have tried to deploy Navision have you? hahaha... your post actually made me laugh. I had to inherent a Navision deployment, imagine my surprise when I wanted to replicate the data to another server so I could have an online backup. Whoops, the GUID column getting added stops the Navision client from being able to do anything!

Re:Only 16 percent? (1)

Blackhalo (572408) | more than 7 years ago | (#19909399)

Who are you, the PjM for Duke Nukem' Forever?

Re:Only 16 percent? (1)

wharlie (972709) | more than 6 years ago | (#19910897)

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.
Like the Egyptian Pyramids, slaves help too.

Re:Only 16 percent? (1)

theshowmecanuck (703852) | more than 6 years ago | (#19910993)

Anything is possible given enough time, enough money, and someone else to do it for you.

problem (3, Funny)

SolusSD (680489) | more than 7 years ago | (#19906741)

at least a large part of the problem are the incompetent masses that we refer to as "IT specialists". I'm surrounded by them.

Re:problem (1)

Duhavid (677874) | more than 7 years ago | (#19907771)

So the spontaniously appear, or did someone ( incompetently ) hire them?
Idiots will seek jobs, perhaps idiots will hire them?

Or to make a direct statement, management needs to own the issue of
who they hired.

First sign (3, Funny)

Anonymous Coward | more than 7 years ago | (#19906745)

Your consultants are all Elbonian

AA meeting? (2, Insightful)

disasm (973689) | more than 7 years ago | (#19906767)

This reads like an Alcoholics Anonymous meeting:

Step 1: Get everyone to admit the project has a problem
Step 2: Figure out what that problem everyone admits is wrong really is
etc...

Sam

Re:AA meeting? (4, Insightful)

Tackhead (54550) | more than 7 years ago | (#19906929)

> Step 1: Get everyone to admit the project has a problem
> 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.

Re:AA meeting? (1)

networkBoy (774728) | more than 7 years ago | (#19907863)

Bravo!

Re:AA meeting? (1)

Kjella (173770) | more than 7 years ago | (#19909153)

Sounds remarkably familiar, expcept I'd replace "re-hire the Consultant" with "hire a new Consultant". We hire out professional ptoject managers, and it's common enough that it gets covered. As in, things that indicate you're the fall guy, what do to if you're the fall guy etc. To me it's surprising how many projects are recogniaed early as being crap, yet still go on. Once you've committed to a project, it's always hell admitting you made a mistake even when it's painfully obvious.

Re:AA meeting? (1)

mrdarreng (1120603) | more than 6 years ago | (#19910445)

If I had karma then I'd modd your post funny. But only because there's no scary mod, and that's what I find the twelve steps to be. Scary.

Sounds like MY career, anyway... (5, Insightful)

The_REAL_DZA (731082) | more than 7 years ago | (#19906781)

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.

and you also got older and closer to retirement! (-1)

Anonymous Coward | more than 7 years ago | (#19906903)

I disagree with the "but we learned something" philosophy. You are supposed to learn stuff all the time. You learn while working on failures, you learn while working on successes. You get paid while working on failures, you get paid while working on successes (most of the time). If you go to prison, they let you have (some) books, you learn while you are there.

So, how about getting your learning done while working on something that is worthwhile to your company, or at least in some way, society in general ?

The "but we learned something, you can't count it a total failure" attitude just means you are planning to fail again.

Re:Sounds like MY career, anyway... (1, Insightful)

Anonymous Coward | more than 7 years ago | (#19907575)

Well, sure, you always learn something.
But did you pay for all those projects?

I'm going to make the wild assumption that was not the case, since you mentioned org changes ('new boss'), etc. as apparently external factors.

In general, the judgement of whether a project is a success or not rests on the hands of those who put in the capital / resources.
The project is typically started with a particular goal, expected cost, and time of opportunity.
For the investiors, a failure to move towards that goal and the corresponding loss of investment is almost always worse than not starting the project at all.

As an employee, you (normally) get paid whether the project succeeds or not - your risk factor is a matter of time, and perhaps reputation. Your main goals are to get stable pay, and increase your worth in terms of skills / experience, and perhaps better remuneration as a consequence of consistent success.
From an employee's point of view, even the most abject failure is a partial success: you get paid for your time, and you typically get lots of hard-won experience and skills (since the sky is always falling).
It is not easy to make the case that it was better not to do anything at all - rent, food, and other minutae of life are good motivators.

I'm not minimizing the value of the learning experience for everyone involved - it's just that it is both trivially true and besides the point.

Re:Sounds like MY career, anyway... (2, Insightful)

jafac (1449) | more than 7 years ago | (#19908339)

well, the project lead should have known whether his team had the critical skills necessary to accomplish the task, or whether his team was going to have a 'learning' experience. Of course, you're always going to learn new things on almost any project. But if the project failed BECAUSE of that - then that is the fault of the person who planned it - and also, IMO, the fault of Project Planning methodology in general (or what they're calling "Systems Engineering" these days) - which has, as a specific goal, removal of the planner, from the details of the implementation. If the planner does not know the details, then he does not know the technology, and does not know what kinds of licensing and proprietary corners he could be painted into, and does not know whether his team has the critical skills necessary to accomplish the task.

I'm more of a low-level guy myself, so I'm not sure I understand what the benefits are of removing the architect from the implementation details are, but the downsides are pretty strongly evident. I see it happen all the time.

Re:Sounds like MY career, anyway... (0)

Anonymous Coward | more than 7 years ago | (#19907633)



I don't think anyone can necessarily think they've been in successful projects, time-in and time-out.

Unfortunately, those who are mediocre in a conceptual ideas and are made to be a lead or project manager. It's kind of like baseball: the people who have been around the longest, regardless of the quality of their tenure become the manager because they have insights to the game. There seems to be a lot of correlation between the previous things they've done -- but have no idea what they're talking about. Granted, there are those who are working up the ladder and their technical skills suck but they can spend a lot of time keeping their boss happy, but forgets to play buffer between mgmt & the worker bees.

Businesses which claim to have a "challenging environment" tend to be the projects which are on or ahead of schedule. Someone passes word upstairs with some happy news but the project participants haven't heard yet: they pull the project completion date up so far it'll require a Death March to complete it. When that happens, the suits will be happy with the manager because they managed to get the project done on or ahead of schedule.

There's a statement in the book "Good To Great: Why Some Companies Make the Leap...and Others Don't": "Get the right people on board, then figure out what seats they should be sitting in.

In the tech world, getting the right people on the bus means "someone who has worked this long, has experience of languages or OSes to a specific level, etc." There are plenty of people who are largely incompetent about what they are doing but could be loaded onto the bus. They've been in the environment desired for 10+ years but are clueless with all of the important points.

That overlooks the people who can learn something a lot faster, preventing the need for long searches.

I've heard from a number of sources (that) there's a trend underway in some cities where businesses no longer have an attitude, "we want this person. Let's negotiate to get them onboard." Now, it's, "Here's the price range we're willing to pay. Now, let's find the best person who is willing to work for "this" much money.

A lot of businesses will fess up, "We want you (or "this person" if it's a head hunter"), but we don't think we can keep them challenged enough and we're afraid that's when we would lose you.
Now: that's sad. If someone is that skilled, why not let them put your company into a technical position other businesses can't because they don't have the same ability.

For many years, I've asserted: "In this business, you don't have to be good, just good enough.

And as Collins says in his book, good is the enemy of great.


Re:Sounds like MY career, anyway... (2, Informative)

Dan Ost (415913) | more than 7 years ago | (#19909389)

I agree completely. The successful projects I've been on recently were all successful because of things that I and other team members learned on previous projects (successful or otherwise).

Why Aren't You Jumping Off the Sinking Ship? (4, Insightful)

asphaltjesus (978804) | more than 7 years ago | (#19906809)

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.

Re:Why Aren't You Jumping Off the Sinking Ship? (2, Insightful)

cromar (1103585) | more than 7 years ago | (#19906955)

Woe is the girl/guy with no authority brought in to get the project back on track.

Hey, at least I get good salary and benefits! Coding a huge web application by myself for 7 months wasn't so bad: I like coding and money. Now I just hope they find something else for me to do... I hate being underworked.

Responsibility without authority (1, Insightful)

Anonymous Coward | more than 7 years ago | (#19908345)

"Woe is the girl/guy with no authority brought in to get the project back on track."

It's called "responsibility without authority". That's a key concept. If you recognize the situation, you learn to either change it or get out fast, as this situation ALWAYS leads to disaster, with your name on it.

consultants (4, Insightful)

Lord Ender (156273) | more than 7 years ago | (#19906813)

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.

As long as you're up front about it (2, Insightful)

Doctor Memory (6336) | more than 7 years ago | (#19907303)

That's all part of the consulting game, but you have to play fair. Offer a fixed-price contract with no early termination penalty, or provide an escape clause that pays some fair amount if the contract is terminated early. I've known a couple of projects that badly burned some consultants, because management knew the project was going to fail, but they still put the contract out light on the rate but heavy with incentives. And what really sucks is, you'd like to say "Boy, you'll never catch me working for someone like that", but when they're one of the major players in town, you know you may have to play. Unless you're happy writing VB front ends to Access databases...

Re:As long as you're up front about it (1)

RajivSLK (398494) | more than 7 years ago | (#19908805)

but when they're one of the major players in town,

Or moving to a different town?

Re:As long as you're up front about it (2, Interesting)

Dan Ost (415913) | more than 7 years ago | (#19909419)

Marry a doctor. I really do like what I do, but I also like the fact that what I do is OPTIONAL.

Number one symptom (4, Funny)

ucblockhead (63650) | more than 7 years ago | (#19906843)

Half of all outgoing port 80 requests are to slashdot.org.

Re:Number one symptom (1)

networkBoy (774728) | more than 7 years ago | (#19907909)

And the other half are to monster.com

-nB

Re:Number one symptom (0)

Anonymous Coward | more than 7 years ago | (#19908551)

You realize that outbound doesn't work that way right?
If not: http://en.wikipedia.org/wiki/Ephemeral_port [wikipedia.org]
If you were truly joking then LOL.

Re:Number one symptom (1)

ucblockhead (63650) | more than 7 years ago | (#19909829)

If!? If it was in doubt, it was a shitty joke.

Re:Number one symptom (1)

aadvancedGIR (959466) | more than 6 years ago | (#19911627)

Curreently, I'm on Yahoo news, /., The Register, two other (french) tech blogs, Dilbert, Penny Arcade, WTF and DamnInteresting, so I guess I'm OK.

Article is self-contradictory (4, Insightful)

mcrbids (148650) | more than 7 years ago | (#19906861)

The article starts out by stating that "agile project management is notoriously least effective on very large projects." but then goes on to propose using Agile Programming techniques to fix it! Such as:

From TFA:

"Small, discrete and often" are the guidelines for the milestones for a successful project.
And from the Agile Manifesto: [agilemanifesto.org]

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!

Re:Article is self-contradictory (1)

Doctor Memory (6336) | more than 7 years ago | (#19907101)

Ultimately, the actual value of the articles in mags like CIO.com are marginal at best
Not so! Without these articles, how would CIOs sound clued-in when they gathered around the luau table during that big "experience sharing" conference at an island resort? How else would they know when to nod sagely while someone else relates their tale of SAP implementation? Or when to raise their eyebrows in appreciation of one of their peers' business savvy when they hear about how one of them deftly juggled a crisis during cutover from their legacy system to the new web-based one when they discovered that there had been no requirement for reconciling order counts at COB? I mean, something's got to get you through that awkward moment between when you first arrive and when you finish your third Hurricane...

Re:Article is self-contradictory (1)

vic-traill (1038742) | more than 7 years ago | (#19907181)

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.

Bing! Go to the head of the class - this is really rather well stated. The phrase 'buzzword-laden tripe' is a particular jewel, and I hope you won't mind if I use the ever-lasting shit out of it.

Re:Article is self-contradictory (0)

Anonymous Coward | more than 7 years ago | (#19907495)

I think delivering working software frequently is bullshit. It greatly multiplies your work. It's like I'm building a car but at various stages the consumer demands to come in a start driving it around. It's a lot more work to repeatedly get things release worthy than to just keep moving along on the project. Also giving frequent releases leads to scope slippage and creeping featurism.

Re:Article is self-contradictory (1)

mcrbids (148650) | more than 7 years ago | (#19909371)

I think delivering working software frequently is bullshit.
Already, you sound smarter than the average... eh...

It greatly multiplies your work.
Yeah, much easier to deliver software that, eh, doesn't work? I'll agree with that.

It's like I'm building a car but at various stages the consumer demands to come in a start driving it around.
Oh, I get what you mean, now. is the "frequently" part that multiplies your work, not the "working" part...

It's a lot more work to repeatedly get things release worthy than to just keep moving along on the project.
Write quality stuff to begin with, stuff that's properly layered, properly abstracted, with high-quality error reporting and a debugging framework built in, and you'll be amazed at what you can do!

Also giving frequent releases leads to scope slippage and creeping featurism.
Really? I find the exact opposite.

Let's say I'm asked to write software to do A, B, C, N, and Y. I start by writing software until it reaches a minimal level of functionality - bare bones, every non-critical feature omitted, and frequently not all that well tested. I whisk that in front of my clients, and they immediately start bitching about "it doesn't do Y and we need that very bad!".

I thank the client, and do Y. A week or two later, they get Y. Then I hear a whine about B. So I write it, and and a week or two later, kick out the software with B enabled. A few bug reports later, and everybody's happy.

Notice that features A, C, and Y turned out to be unnecessary! This happens ALL THE TIME. But what's even more interesting is that the client usually finds they need something very important that wasn't on the list to begin with. By keeping the development cycle short and keeping my attention on the customer, I find that I very quickly have something very compelling, and can consistently outperform my competitors in the marketplace. This is always a good thing!

I think that agile software development lends itself very nicely to the "Software as a Service" model rather than the "sell a widget" model. When you're selling software as a service, the release often mentality doesn't get in your way because the customer isn't paying for a bunch of releases, they're paying to always have the most current.

The last line of this classic explains it all... (5, Funny)

Anonymous Coward | more than 7 years ago | (#19906875)

'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!"

The problem is usually awful requirements (3, Insightful)

The Media Mechanic (1084283) | more than 7 years ago | (#19906889)

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."
( Not that I'm bitter or anything. )
http://blogs.warwick.ac.uk/images/steverumsby/2006 /01/30/dilbert20060121046729.jpg [warwick.ac.uk]

Re:The problem is usually awful requirements (1)

ruben.gutierrez (913239) | more than 7 years ago | (#19907179)

I suppose the development team is just as much at fault for not gathering the requirements effectively, if that's really the cause of failure. Requirements gathering is a constant problem, no doubt. But, I won't work on something unless it's clear what I'm supposed to be doing. And, if it's not, I have to at least attempt to gain the proper understanding.

Doubtful (0)

Anonymous Coward | more than 7 years ago | (#19909667)

In other words, software is only as good as the initial requirements and design.

And yet, I've seen countless startups come up with great and successful software without any requirements. Or when they had an initial design, end up with a product completely unlike it -- and far better.

That's not to say that bad mgmt can't kill a project -- it sure can -- but if mgmt came to a good team and said "make something like what we had before, but better", and then left them alone for a year, do you really think they wouldn't be able to deliver?

Mgmt doesn't do this, of course. They micromanage, or provide inadequate tools, or require unrealistic timetables. But *those* things kill projects, not lack of requirements.

Do you really think Steve Jobs wrote out a detailed design document for Mac OS 1.0 in 1981 and handed it to the programmers? Nah, they hacked on it until they figured out what it was supposed to do, and how.

Heuristic methods (3, Insightful)

mutterc (828335) | more than 7 years ago | (#19907075)

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.

Changing definition of success (1)

michaelmalak (91262) | more than 7 years ago | (#19907085)

The definition of success has changed over the past 15 years. In the past, requirements would change without a change in deadline. Now with real project management, such as PMI/PMP, becoming more popular, requirements changes are costed. It's obviously easier to meet the latter definition of success.

There have been some bona fide improvements in software development over the past 15 years: longer variable names, language-supported encapsulation, and inline documentation tags that allow for larger teams and for attrition; and code reviews, pair programming, and unit testing frameworks that make the work of mediocre programmers more repeatable.

Failing Projects come form endess TPS reports and (1)

Joe The Dragon (967727) | more than 7 years ago | (#19907175)

Failing Projects come form endless TPS reports and useless meetings As some time you spend more time of them then your real work and they are the only places the that the bosses get any info about the Projects as they are so dumb they waist IT time on showing them how do email 1-2 times a week and other easy things then the IT people don't have the time to fix things with the people who do the real work on the Projects.

Grain o' Salt (4, Insightful)

vinn (4370) | more than 7 years ago | (#19907193)

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.

Re:Grain o' Salt (1)

JonathanR (852748) | more than 7 years ago | (#19909397)

I think you're confusing project prioritizing with delivering projects.

Your first example about balancing the HR project with the operations manager's project seems more about resourcing and scheduling multiple projects than one or the other individually being a failure. The inability to meet HR's schedule expectation is a project management failure, since embarking on that project without knowing it can be finished on time and budget is a failure.

I work for a large multinational engineering contractor, and quite frankly, the company is hopeless at scheduling and resourcing projects, mainly because the projects themselves aren't scheduled properly and the resource requirements calculated. We have about three people scheduling work for about 300 engineers, which is insufficient. This approach causes all sorts of slippage, scope abandonment and short cutting in a (futile) attempt to deliver on time(ish). This doesn't mean that individual projects are unachievable, more that there are insufficient resources to achieve all of them simultaneously. Proper scheduling and resourcing calculations would reveal this, and proper timing and allocation would enable all projects to proceed with less crisis management.

On your second example, you might start some type of R&D feasiblility study to investigate rollout of a new networking infrastructure (n vs g or b), but in fact that investigation is a project in itself. The project outcome is a "next stage", "later" or "abort". Implementation of the new infrastructure is an entirely different project, and should be planned separately.

Your third example is also not a failure, but a sound recognition that you don't have the resources to embark on the project and/or the returns on a successful implementation are not sufficient to justify the capital.

So I wouldn't dismiss the article's comments and recommendations. I think they are pretty much all valid, and if managers at your level recognised that (as the senior management where I work don't) and did something about it, then a lot of people would be a lot happier. The best thing to do about it? Stop pretending that "high level" schedules are sufficient. Recognise that detailed schedules are required and are all about activity durations and dependencies rather than the "gimme the dates" crap that gets bandied about in weekly project review meetings.

Re:Grain o' Salt (1)

archen (447353) | more than 7 years ago | (#19909711)

I think that depends on how you interpret the article which is a bit ambiguous. On one hand it says if something delivers a product on time it is a success, and on the other it says if it produced something useful it is a success - which may not be the same thing. I'm also an I.T. manager (or whatever) and I can say that a project isn't necessarily a failure if you are smart enough to back out of it in safety before it becomes a total catastrophe. It also depends on your goals and the article is oriented to actually producing a product, for which not producing a product would be a failure. Most of my "projects" are really feasibility. IT is driven by new technology, and be definition you have little to no experience with it. So of course you need to test it. If your goal is to always at least learn something from the experience then no project is truly a failure, but that depends a lot on your organization and where you sit in the decision making hierarchy.

Re:Grain o' Salt (1)

JonathanR (852748) | more than 7 years ago | (#19909853)

...I can say that a project isn't necessarily a failure if you are smart enough to back out of it in safety before it becomes a total catastrophe.
It is still a failure if nothing concrete is delivered, i.e. a totally aborted project. Of course, well documented lessons learned, particularly for investigating use of newer technologies, is something concrete. If the learnings aren't well documented, then this also is a failure, as far as a company is concerned, as the people who had the experience can move on, taking their knowledge with them.

From a company viewpoint, if you are "backing out" of a project, you still have expended some resources, so you'd want to see something for that, if you are to label it as any type of success.

SAT Effect (2, Insightful)

Reason58 (775044) | more than 7 years ago | (#19907209)

In 1994, the researchers found that 31 percent of the IT projects were flat failures. [...] As of 2006, the absolute failure rate is down to 19 percent.

I have serious doubts that IT projects have made any significant improvements in management efficiency in the last decade or so. More likely the people estimating timelines, budgets and features have learned from their mistakes and simply set the bar much lower than they did in the early 90s.

It's the "SAT Effect" (tm). Why actually improve performance when you can simply tweak the metrics by which you measure?

This is not about moving goalposts (1)

rsborg (111459) | more than 7 years ago | (#19907815)

have serious doubts that IT projects have made any significant improvements in management efficiency in the last decade or so. More likely the people estimating timelines, budgets and features have learned from their mistakes and simply set the bar much lower than they did in the early 90s. It's the "SAT Effect" (tm). Why actually improve performance when you can simply tweak the metrics by which you measure?
Pardon, but as someone who's managed projects, it's a bit more than "tweaking metrics" or "moving goalposts". If you have an otherwise successful project, which is doomed to failure through unrealistic timeline and resource estimation, it's not only going to be "not successful", but as the manager of the effort you have to deal with resource burn-out, constant discussions with executive leadership to explain why you're behind, frustration, and general discontent in your project team. Not only do you not get time to complete your project, you spend MORE time bitching to management and dealing with the consequences of working on a doomed project.

Re:SAT Effect (3, Insightful)

nine-times (778537) | more than 7 years ago | (#19907925)

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.

Were any of them REALLY successful? (1)

Quietust (205670) | more than 7 years ago | (#19907247)

One almost has to wonder if the current 35% "success rate" is for truly successful projects, as opposed to ones where the only criteria for success was completing it. An article [worsethanfailure.com] from WorseThanFailure (previously TheDailyWTF), originally intended to explain why the site's name had changed, does a nice job of explaining just why "success rates" can be misleading.

Re:Were any of them REALLY successful? (1)

Xiaran (836924) | more than 7 years ago | (#19909205)

From personal experience I also found this dubious. I have work on projects that have been "declared" successful... sometimes despite the fact that I was still working on getting it fixed :) I was once working on a project that had to interconnect with a CRM project which was going badly. I was much surprised one friday to find a front page mention of the company email newsletter of how the CRM component had gone live. It was surprising because we 1. hadnt complete our testing and 2. they had no production servers yet up and running(and would not have for another four months).

digging a bit deeper (1)

edxwelch (600979) | more than 7 years ago | (#19907253)

If you'd dig a little deeper, I'd say you'd find the real root of the problem is that certain people working on the project aren't any good at their jobs, particularly management.. unfortunately any attempt at "fixing" the project will envolve the input from the same people that made the initial bad desicions .. so what is the solution? Obviously, not hiring people that aren't any good at their jobs.... but what if the person who is in charge of hiring people isn't any good at his job?

If you aren't part of the solution...... (4, Insightful)

Proudrooster (580120) | more than 7 years ago | (#19907275)

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.

Re:If you aren't part of the solution...... (1)

grcumb (781340) | more than 7 years ago | (#19907611)

Seriously, though the classic problem with IT projects are two-fold: 1) Unclear Requ2irements and, 2) Scope Creep.

Based on that sentence, may I suggest that you also consider: 3) Poor QA?

Re:If you aren't part of the solution...... (1)

Proudrooster (580120) | more than 7 years ago | (#19907787)

I believe this submitter is talking about catastrophic project failure, as in "the project failed miserably". QA in my experience is not usually the cause of projects failing, unless you consider the classic Lorane 5 Rocket disaster. [umn.edu] or the iPhone Launch and AT&T melting down on activations.

I am assuming this project has good DBAs and good programmers. Most shops have these, but these poor folks find themselves drowning in nebulous requirements and SCOPE CREEP.

Personally, I operate on the "It compiles, therefore I should slam it into production and go home, because I am that good."

Re:If you aren't part of the solution...... (1)

jimlintott (317783) | more than 7 years ago | (#19907613)

Mmmmmm.

A person with a functioning brain. The real world must frustrate you to no end.

Re:If you aren't part of the solution...... (1)

Black-Man (198831) | more than 7 years ago | (#19908185)

In my experience... following up after disasters... developers can be part of the blame. I don't know how many times where I've seen a person who thinks they are all that and a bag of chips just doing something because its "cool" or its the latest tech "fad". Yeah... it pads their resume and most managers are clueless on the details anyways, so they get away with it. They'll even come in after the fact, fix their crap and become "hero's". Definite win-win situation.

Re:If you aren't part of the solution...... (1)

jafac (1449) | more than 7 years ago | (#19908359)

You need to send your IT guys to S&R for a MONTH, not a week. Otherwise, you will miss that last day of the month, when 90% of the activity occurs.

Re:If you aren't part of the solution...... (1)

julesh (229690) | more than 6 years ago | (#19911867)

Seriously, though the classic problem with IT projects are two-fold: 1) Unclear Requ2irements and, 2) Scope Creep.

The two are one and the same, of course, because they both mean that the program you're writing might not be the one that's actually needed.

IMHO, You have to assign someone from IT to LEARN THE BUSINESS before trying to create solutions.

This is an interesting approach, and it certainly has merit. Another option, one espoused by the agile development community, is to have someone who already knows the business assigned to IT for the duration of the project. It might not be as good as your suggestion, but it may be more realistic, particularly for shorter projects.

Written by a project manager (1)

fox1324 (1039892) | more than 7 years ago | (#19907355)

How could I tell this article was written by an IT project manager? Plenty of vague buzzwords and friendly-sounding phrases, zero mention of technical skills/information, and most importantly - no coherent definition of what an "IT project" is. Many IT projects "fail" because many IT project managers don't have the slightest clue what they're managing.

Any changes in methodology or sample? (3, Funny)

John Hasler (414242) | more than 7 years ago | (#19907553)

> "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?

Re:Any changes in methodology or sample? (0)

Anonymous Coward | more than 7 years ago | (#19908045)

FYI, the Veterans Administration has a reputation as among the worst offenders when it comes to being primitive, slow, etc. Oddly, they also have *the best* patient data tracking system known. Did a case study on it in grad school (DePaul in Chicago, IL) and had the project lead speak to our class. He was a 20+ year MD (Neurologist) who 'liked' IT (his words - he writes code for a hobby and understands hardware, but we had to glean that from his talk about the project, not 'cause he said so') who was told about the project, offered the authority to make decisions (about features, deadlines, etc.) and given the resources to get it done (based on his estimates) and was then asked if he would be interested in heading it up. He was and did, and it works. It is also Open-Source, which the PM went to pains to explain to us (my school is an M$-only shop 'officially'). His take on why it worked: 1. Passionate advocate (him) 2. Sufficient authority (him) 3. Sufficient resources (based on well-documented estimates provided by him).

So, get a briliiant, accomplished PM, remove all barriers and give them what they want and how can you fail?

Incidentally, we tried to get someone from the FBI to talk about the poster child for bad project management (their 'Caseware' project, whatever it was called) but oddly, none of the (multiple) project leads would come talk to us about what went wrong.

Identify it: does it use xml? (1)

malraid (592373) | more than 7 years ago | (#19907683)

Fix it: pick a new xml parser, and start again from scratch.

simple process (1)

jrsumm (466914) | more than 7 years ago | (#19907931)

All they have to do is identify the problem and then fix it. What's the issue?

The metric I tend to use most often (1)

dkleinsc (563838) | more than 7 years ago | (#19908037)

The formula is simple: (clear plans to produce features) / (features promised to customer or end user).

In successful projects, that comes out to something like 80% or higher, while in unsuccessful projects you see at best 30%. The way this ratio is kept high is that in the initial planning stages you keep a technology guy in the room who can say no to the sales and end users (or sometimes "yes, but it will take you another 4 months and $300,000")

Not just IT (1)

athloi (1075845) | more than 7 years ago | (#19908105)

Projects with unclear goals, and unclear measurements for success, tend toward failure. Unfortunately, committees tend to design exclusively these, because being vague is how you keep your job. In case a project fails, describe it vaguely, so you can blame someone else and move on. This motif is repeated through human society, even politics. Who's to say the Iraq war wasn't one of those 31% of scope-creep, vague-goal projects?

Strategic vs Tactical understanding (1)

Freaky (20585) | more than 7 years ago | (#19908179)

I have been designing and managing IT project for 12 years. The keys to successful deployment are simple:

1. Understand the business need.
2. Understand the limits & capabilities of your team and software/hardware.
3. Identify a real budget.
4. Get full scope documentation and don't let it change. (all add on requirements are Phase II+)
5. Make sure the person leading the project is not also doing end user support.
6. Hire my company to actually do the work.
7. Profit!

Given that it is almost impossible to get process documentation out of the internal client most IT projects fail before they even start.

I am happy to say we hit over 98% successful completion on IT projects. Strategic comes before tactical, but you must have both.

How to spot the places where late is normal (4, Insightful)

Aceticon (140883) | more than 7 years ago | (#19908193)

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.

Mod parent up (1)

steveoc (2661) | more than 7 years ago | (#19908729)

Really enjoyed reading that one.

Ive worked a number of projects (mostly defence related) that cover all the points above in spades, and they were all a joy to be part of.

And Ive worked on large projects in large organisations that do none of the above .. at all. Yes, they were all disasters.

Smaller organisations sometimes get away with it, because they have to - they dont have the meat in the budget or resources to do things 'properly'. Most of these 'survive' somehow, but not forever.

I have found one at the moment that is quite unique - tiny organisation with a tiny staff, making an absolute killing in the fuel industry. The engineering is done properly, but the software development is totally cowboy style, and 1 man to 1 project.

The only parts that are done 'right' are the pre-project analysis and the requirements gathering - which we try and get close to (an ancient) DoD 2167a standard on. Other than that, its all cowboy style. Zero consistency between developers, and each working in a skillset totally alien to the others. A simple peer review of code is therefore pointless, so there is no margin for mistakes - at all. It seems to work because the $ margins are there, and each developer is a disciplined coder and tester up to a point (of their own code only, so you can imagine what up to a point means). Despite this recipie for burnout, its also a remarkably low pressure environment, with lots of fun social activity as well. This place has to be some weird sort of exception.

One other point I have just realised in reflection - although all deadlines are driven entirely by sales, the small handful of coders here really do have final say in just about all decision making processes related to THEIR code. Even to the point of altering requirements and re-writing customer contracts to suit. There is a 2-way respect/trust thing between the managers and the staff, and the customers as well.

We also drink together outside of work - staff, management, investors and customers all party together after hours when appropriate.

Its not unusual for a customer to drop in on their way through to a another city, talk turkey with the actual developers for a while, and then head out together after work and get smashed.

Weird but good.

Re:How to spot the places where late is normal (1)

Shados (741919) | more than 7 years ago | (#19909547)

All of those aside like 2 are describing my current work environment. The last one on your list (the project manager not having enough power) is an incredibly huge one, that way, way too many people miss. My current project manager is a former software architect. He's SEEING all the problems, and he KNOWS how to fix them, but doesn't have the power to enforce it (neither do I unfortunately). So he's just watching the train wreck, trying to do what he can...its sad really.

The requirements process is also a killer. Too many teams know about use cases (both high level and technical), but not about how to gather a good set of requirements. _BOTH_ are required, but companies go too often with one, but not the other. Current place has use cases, but no requirements. Previous job had full sets of requirements, but no use cases. Both end in failures (requirements as you mentionned can be ditched in certain environments like Agile if done right, but these were not agile shops). Part of it comes from too many businesses and development teams thinking that software goes -> preliminary analysis -> UML -> code -> test -> deployment. Thats skipping quite the important step(s).

As a side note, have you noticed that as a contractor, working for so many different places in such short time (compared to most other developers or IT people), you tend to learn (for the first few years) by seeing what NOT to do, more so than by seeing what -works-? Almost a process of elimination.

three rules from successful software projects (1)

Gena5m (1004304) | more than 7 years ago | (#19908203)

1) Fail early, fail often. 2) Early optimization is root of all evil. 3) Good horizontal communication. The problem is that it is in the human nature of bad managers to will project towards success. And, to continue on point touched by the first article, some cultures (to some degree Indian) makes developers hide failures "to please manager". Which compromizes communication. Given that it is especially challenging to follow these 'agile' rules on big projects. I just witnessed how brilliant, smart, flexible engineer and capable communicator was fired by his strong-willed boss who likes to succeed through personal overtime and lacks ability to manage complexity. Which is one of the main main tasks of modern software manager. On the base of it successful agile management approach is based on flexibility in ideas and communication. And on a big sign on the door: 'Strong willed work maniacs are not welcome!'

Re:three rules from successful software projects (1)

Shados (741919) | more than 7 years ago | (#19909483)

Rule 1 is so especially true. If you admit that you're about to fail, you can't completly fail, ever, because you'll (almost) always be able to fix things before its too late... Project that fails are almost always caused because no one was willing to admit the project was screwed until no one could go back.

I'm in a situation where the preliminary analysis was wrong on several, severe cases, so the project scope is ending to be on an order of magnitude greater than what was originally anticipated. We're being asked to cut corners everywhere to make it happen anyway, and finding "simple" solutions to all problems. Catch is, those "simple" solutions do NOT get the job done, so we end up with non-functional implementations. If people had admitted that they had screwed up as soon as it became obvious, we could have re-scoped the project, and succeeded with a slight spill on the budget. But now, it looks like its going to be a 1 year project that will take two, and the team's moral couldn't be any lower.

Annoying (4, Insightful)

steveoc (2661) | more than 7 years ago | (#19908373)

I find this article very annoying.

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 .. and conclude that things are improving, and then attribute the improvements to things like .. This awesome new, expensive, proprietary project management software.

Umm .. 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.

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 .. 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.

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 .. 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.

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.

Re:Annoying (I disagree) (1)

GoldTeamRules (639624) | more than 7 years ago | (#19908709)

I don't think that was the point of the article. While I agree that for software development things like Agile, XP, and better languages and tools have allowed for greater project success, I do think tools can be useful.

You don't use a bug/issue tracking system? How do you prioritize what you should be working on? Does the company you work for have several things going on at the same time? Do you do specific work for individual customers, and if so, how is this communicated?

I don't think "shiny/proprietary software" is the sole cause for greater project success. But, the article is dead on in explaining how tools like this can help.

From your post I can only assume that: 1) You have only ever worked for bad technical managers, 2) The company you work for is small and doesn't have enough information/customers to see any benefit to having a system help you track this, or 3) You are a typical embittered software developer with a god complex who thinks the only real contribution made to your company comes from your developement team.

Re:Annoying (I disagree) (1)

steveoc (2661) | more than 6 years ago | (#19910877)

I don't think that was the point of the article

Well, I do - I think the whole point of the article was to make 'project management tools' look good, and to provide 'editorial content' that should sell more ads for their little magazine.

Lets see who they exclusively quote in the article :
- Scott Johnson, CEO of AtTask, an Orem, Utah, maker of project management tools.
- Jim Johnson from the Standish group, who are offering to sell the reader a copy of the report on which the article is based.
- Raj Kapuor, executive vice president of the Center for Project Management, a software project management consultancy and education firm in San Ramon, Calif

And thats it .. the entire article is simply a platform for these 3 individuals to voice their opinions and tout the beneifts of their product. There is nothing more to the article, no analysis, no debate, no investigative journalism. Its just an advertorial. I am surprised that you cannot see that.

By all means though, feel free to follow up on the article, and have a look at the people being quoted.

I particularly liked reading through 'The Center for Project Management' website (which I did before writing my original comment above), and I must admit that their premier product did prompt me crack a smile. If I may quote straight from their website, ie. their uniquely original "Culture Model Approach", which is a "proven and tested Project Process Architecture (PPA(TM)). CPM's principles-based, four-phase, 24-step methodology" .. anyway, that made me smile even if it did impress the heck out of you. (Oh - btw - I am assuming that you did your homework too, and researched who these people were, the ones who's opinions you strongly agree with).

You don't use a bug/issue tracking system? How do you prioritize what you should be working on? Does the company you work for have several things going on at the same time? Do you do specific work for individual customers, and if so, how is this communicated?

Geez, I dunno. We have this MilStd-498 thing, and then there is this big stack of documents about DDx interop stds for Aegis development, and I think 'the company' mentioned there might be some other projects happening .. but who really knows ?

We are yet to be enlightened by the Culture Model Approach, we desperately need to get some proven and tested Project Process Architecture (PPA(TM)). CPM's principles-based, four-phase, 24-step methodology happening around here SOON, or we are so obviously fucked !

I don't think "shiny/proprietary software" is the sole cause for greater project success. But, the article is dead on in explaining how tools like this can help.

I respect your opinion on that. I personally havent been exposed to the same proven and tested Project Process Architecture (PPA(TM)) that your company must be using, so I cant judge.

From your post I can only assume that: 1) You have only ever worked for bad technical managers, 2) The company you work for is small and doesn't have enough information/customers to see any benefit to having a system help you track this, or 3) You are a typical embittered software developer with a god complex who thinks the only real contribution made to your company comes from your developement team.

From YOUR post, I can only assume that :
1) You cant tell the difference between an advert and a article.
2) You dont know me at all.

Re:Annoying (I disagree) (1)

GoldTeamRules (639624) | more than 6 years ago | (#19911097)

I think someone at the CIO level understands that the basic premise of this discussion is that standardized tools and processes can help increase the likelihood of project success. How? By communicating information like cost overruns and projected schedules early enough in the project timeline so that corrective action can be made. Data like this can help managers understand when a project is failing before it becomes apparent to everyone already working on it (by that time it is usually far too late).

Any good software development process (Scrum, Agile, etc.) is based on similar principles. However, tools and process templates are often helpful in order to formalize these best practices regardless of the size of the company.

I don't think anyone is going to rush out to any of these vendors/consultants immediately after reading this article. I think *most* people get the idea that these "experts" are merely representative of an industry trend at large. Is it advertising? Perhaps this may raise some visibility to the providers mentioned in the article, but there is no talk of specifics and/or why these specific tools/teachings are superior to alternatives. I'm pretty sure CIO magazine gets no benefit by quoting from 3 people that work for companies that 99% of its readers have never heard of.

Obviously, I don't know you, but I would be very surprised to learn whether you were functioning in a management role based on your cynicism about these kinds of tools. This isn't about some bullshit tool that pointy-haired managers deploy to help him/her to manage a development team regardless of whether they have any technical skills. This is about scaling your business to effectively track where you are at on your work.

Good tools make good practices more efficient. I'm surprised that you're not using ANY tools for tracking work. This sounds like chaos.

I only responded to your post because I see this attitude all the time with developers. And, granted, there are a ton of crappy tools out there that simply CREATE MORE WORK rather than help eveyone get on the same page (think M$ Project, for example). But I've seen development teams work much more effectively together by using project management/issue tracking software than they did without.

You have written off the article because they quote from 1 vendor and 2 consultants. How would you have written it? Who would you use? A CIO that would "endorse" the solution he/she chose to bring in house? Regardless of the approach, as soon as you mention ANY specific tool or PM practice, it becomes an "advertisement".

Re:Annoying (2, Insightful)

Shados (741919) | more than 7 years ago | (#19909453)

Then again, software "coders" are almost never the ones that are responsible for the success or failure of the project -either-. Architects, analysts, team leaders, researchers, etc, are. Actually "building" the thing is completly trivial once these people succeed on their side of things.

Almost like building a house. Once the plans are drawn, the ressources allocated, etc, if the project is managed correctly, its almost impossible for the coders to screw something up.

Outsourcing/OffShoring (1)

desertfool (21262) | more than 7 years ago | (#19908627)

What if the project is to save $X by outsourcing/offshoring and it is going bad?

The PHB's can't admit they are wrong and it isn't going well? Who gets the bad performance review? Why those who aren't management and had nothing to do with the bad decision in the first place.

Project management is not a profession. It is a joke.

Even when it fails, offshoring still proceeds. (1)

sethstorm (512897) | more than 6 years ago | (#19910479)

I doubt in this anti-worker climate that abortive failure of offshoring is an option. It just means it's delayed, especially with Cohen & Grigsby in the picture.

Thank the business lobby, and Ford/Reagan for giving businesses their thunderbolts for this.

#irc.7rolltalk.com (-1, Redundant)

Anonymous Coward | more than 7 years ago | (#19909607)

of Ope8BSD. How Demise. You don't fly They lloked FreeBSD because

Blame the ..... (1)

PPH (736903) | more than 6 years ago | (#19910571)

... IT management for treating information systems like they are some sort of black magic. Back in the '50s, '60s, etc. The computing folks had everyone convinced that nobody could possibly understand their domain of knowledge. That should have changed once PCs gave the average technically competent person in other fields hands on experience. But the folklore and mystique surrounding IT continues. The other side of this problem is that computer science is just a tool. Its a tool for solving problems and, in many cases, these problems fall outside of the computing domain (engineering, accounting, medicine, etc.). But the IT folks seem to think that, once some requirements have been collected from the customer, they (the customer) should just get the hell out of the way until he finished product is delivered. Knowledge of the problem domain is given little weight compared to that of the neat software about to be delivered. And woe to the poor customer, particularly if they are within the same corporation as their IT 'supplier', if they try to get too involved. It it isn't uncommon for the IT department to go over their head and have them slapped down by corporate for 'interference'. Don't even think about building it yourself.


Blame the customer for putting up with IT's shit. After all, outside of software businesses, IT systems are NOT the core products of most companies. If a department says it needs a system to do 'X', thats what they should get. Fully buzzword-compliant IT systems may be a feather in the CIOs hat (or a gold star on their resume when they jump ship to which ever systems supplier they just burned their companies millions with), but that's not the business the company is in. Also, blame the customer for the existence of the CIO position in the first place. Management in a company should understand their own business processes to the point that they don't need another department to tell them how to do their jobs.


Blame corporate management for not keeping tabs on both the customer organization who is too lazy to take an active role in their own business process re-engineering and would rather just throw their requirements over the fence and see what comes back. Blame them for nurturing IT departments that encourage this sort of thinking. And blame the people in mahogany row for not biting the bullet and pluuing the plug on sunk costs. I think quite a few 'challenged" systems would probably fall into the failed catagory if anyone had the balls to confess to the board of directors that a few hundred million (I've actually seen billion dollar plus black holes) have just been shoveled down a rathole.
 

If you're not failing, you're not trying. (1)

YouHaveSnail (202852) | more than 6 years ago | (#19911297)

A high failure rate could indicate a willingness to take risks and try new things. The fact (at least according to TFA) that the rate of project failures is half the 1994 rate could mean that project management has improved across the industry, but I think it's much more likely that the cause is just a change in the nature of the projects. Project managers in a post-dot-bomb world may be less willing to take risks. At the same time, there now exist best practices for many business-oriented computing tasks where there were none in 1994.

If I were a CEO and my CIO told me that he'd gotten the software project success rate up to 100%, I'd be strongly inclined to fire the guy and replace him with somebody more willing to try things that might not always work out.

Sponsorship (1)

CaptainZapp (182233) | more than 6 years ago | (#19911525)

That's a point that I missed in the fa. In my experience that's one of the most dangerous risks for just about any project. They either have:

No project sponsor from the business side (usually in high places), or - even worse - there are multiple "sponsors" from multiple departments (usually using the project as a war by proxy entity for their departmental feuds).

In both situations I wouldn't come near the project with a gas mask and asbstos suit.

One word.... (1)

xhydra (1083949) | more than 6 years ago | (#19911771)

MANAGEMENT
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>