95% of IT Projects Not Delivered On Time 654
An anonymous reader wrote " The Globe and Mail reports that 'A new report conducted by market research firm Info-Tech Research Group says 95 per cent of information technology groups are not delivering some number of projects on time or to the full satisfaction of the business executive.' The article goes on to discuss the reasons for this pervasive (perceived?) problem. The article mentions Info-Tech's reasons: unrealistic time frames, staff shortages, and poorly defined project scope. However, the article's author lays the blame with vendors."
Phew!!! (Score:5, Interesting)
Thanks /. a copy of this story now sits on my boss' desk.
Comment removed (Score:5, Interesting)
Not Suprising (Score:2, Interesting)
It is not necessary to impliment the full-blow SEI CMM to produce good software on-time. If developers would take the time to first make reasonable estimates of how long it will take to finish a project and then track how much time they actually put into it, we might start to see some improvement.
On the management side, when managers start to realize that software is not developed instantly and that problem solving takes time we might be able to reduce the number of features that are packed into a piece of software without extending the schedule.
Correction: 95% of Schedules are Wrong (Score:5, Interesting)
Have there been any advances in scheduling technology? Like profiling developers over the types of software they write, etc.. ?
VERY true (Score:5, Interesting)
I work with OCR/ICR technologies. NO SALESPERSON should EVER be allowed to sell this without taking a month long training course about what it actually does.
I can't count the number of times customers were expecting 100% accuracy because thats what the salesman sold them.
In my experience (Score:5, Interesting)
1) requirements are agreed on, seem reasonable enough, but then detailed specifications are drawn up and client keeps pushing to add more things to specs until you have a 120 page document that will take 2 years to deliver. If, however, you tell the client it will now take 2 years vs. the 5 months you said when you were looking at a 2 page requirements document, they will cancel the project, and if they weren't paying for the requirements phase, forget about collecting any money for them (why you should always get paid for all phases of project planning). Since you can't do this, the client will eventually get upset, even though it's their own fault.
2) Project is delivered very early in prototype form, only to have the client say they want 50 more features that they forgot to describe in the requirements process, but they refuse to pay more, and refuse to acknowledge that the time frame must be pushed out to accomodate their new requests.
Yes, I've managed client relationships before and large (multimillion dollar) implementation and customization projects. I have reasonably good people skills, and still found these problems generally insurmountable when my client's company had a completely nontechnical person in the role of project sponsor and manager on their side.
The best predictor of success of a project in my experience are the lines of reporting and control in the client's company, and the existence of some technical knowledge in a position of responsibility and authority. If their CIO or President or whoever is the ultimate decision maker has a senior arhitect or tech VP that knows their shit AND functions as a trusted aid in the decision making process, these issues can usually be bypassed. If there is no senior source of technical knowledge, you can kiss the entire project's ass goodbye. Try to get as much money as possible from the client while it's going on, but forget about the project being "successful" in how its received by management.
Re:In other news (Score:3, Interesting)
There is a good saying: Fast, Cheap, and Good. Pick two. You can't expect to deliver great software on time with a lack of appropriate resources.
Optimism (Score:5, Interesting)
Even with the benefit of fixing our estimates as we liked, the entire class did very poorly. The morals of the story were
a) people are over optimistic in the accuracy of thier predictions
b) even, in our case, when we could have given zero-to-infinity ranges, we tied ourselves to restrictively narrow frames.
I thought it was fascinating, it's one of the few classes I remember vividly.
Bad Summary, Bad Article, Interesting Topic (Score:2, Interesting)
Second, the article shows some flaws as well. Because 5% reported that they are always on time and budget, the researchers concluded that 95% were not. That's bad science, letting the observed lead to conclusions about the unobserved.
Finally, the larger the project, the harder it is to define an end point. Tweaking a screen to change a color is certainly doable, but may take weeks to get to in the project list. Implementing a major project that requires lots of unknown elements, such as a system conversion, cannot be considered a plan, but an estimate. And when it comes to estimates, it's very hard to get *anyone* to be less than optimistic.
For an interesting read on project planning and estimating, check out Elihu Goldratt's book, Critical Chain, which shows the application of his Theory of Constraints to project management.
Why projects fail (Score:2, Interesting)
I work in a place that just recently started implementing Project Management. The biggest problem I see is that if you don't have buy-in by upper management you'll be fighting a battle of critical change requests on a constant basis.
We just had one project take place that was mandated but never went through PM at all. Not even a requirements document was produced. It was a nightmare that touched 75% of the I.T. staff.
Had PM actually been followed the process would have started back in November of 2004 and then the blame would have been off the plate of I.T. But for fear of stepping on toes I.T. management decided not to follow its own procedures.
Re:This is why (Score:4, Interesting)
Customer: Joe Bloggs says his company can do it for (stupidamounts) in (notime)
Us: OK, we've got no problem being competitive. Can we just check that their system is being designed to the following standards ?
Customer: They didn't mention it, but I'm sure it must be included.
Us: I see, and is our support agreement in line with what they are offering?
Customer: * Thumbs their document * - Don't see anything about support. But they're cheaper - You must be trying to have us over!
Us:
Let me guess... (Score:1, Interesting)
Re:Methodologies and the lack of it (Score:2, Interesting)
I'd argue that having constant client interaction (XP) actually hinders progress because you give them opportunity to constantly refine (read 'change') the requirements. Hey no problem with me but someone has to associate a cost with this, nothing is free.
The whole XP methodology is fine for reliably delivering systems that the user actually wants but it does nothing to do so in a timely fashion, which is the point of the article.
Housing developers aren't expected to change the foundation and add entire sections to a house after the project has started, without delay. Yet we are expected to perform this magic because the client and management don't equate the bits n bytes in our projects the same as natural resources in any other industry.
Want to know the worst thing a developer can do? Work on some side project to mock something up to impress the boss, demo it and wow them beyond belief. Problem is, you only took a weekend to hack that demo together but the boss doesn't understand that there is no framework in place to extend it, no authentication, no connection to an actual backend/db, no error handling, no logging, no nothing, just a fancy bun with condiments but no hamburger patty inside.
Yep. (Score:5, Interesting)
In my experience, a much higher percentage of European projects are delivered on time than US ones. The simple reason is that in Europe, engineers are more respected and are usually tightly involved with the requirements gathering/planning phase.
Unfortunately in the US it usual practice to keep engineers away from clients and only involve them when everything is already agreed on paper. This means that the engineer gets a garbled requirement to work from, and the technical decisions have already been made/commited to by someone without any technical skills (i.e. sales or management).
The net result is that the engineer is expected to implement someone elses bad design that usually misses important aspects or doesn't address the actual problem, in a hopelessly optimistic timeline. Furthermore god help the engineer if the customer isn't kept happy.
Re:But what about non-IT projects? (Score:3, Interesting)
For a good look at this, see Tom DeMarco's "Controlling Software Projects". One of Tom's points is that one reason we are so bad at estimation is that we so rarely do it. What we often oall estimation is often actually more like negotiation: "How long will it take you to do X?" "Three months" "No, that's too long" "How about 2 months?" "OK, thanks for the estimate". Instead of actually trying to predict how long it will take, you're negotiating what the schedule will be.
Re:Nah (Score:5, Interesting)
When an engineer designs and builds a new bridge it is entirely possible that no bridge like it has ever been designed or built before. Sure, there are some base cases that just get churned out, but there are also big, new, creative designs that occur for bridges. How is that bridge engineers usually manage to not have their bridges falling down all the time? Well, for starters the designer doesn't run with a "build and test" mentality. There are formal methods for bridge design, and if you assume the properties of various basic components, there are methods to prove the stability and properties of the bridge. Did you know that there are formal methods for software design, and if you assume the properties of basic components (like hardware, OS , etc.) there are methods to prove the stability and properties of the software?
Yes, formal software methods are hard and time consuming compared to just building and testing. Formal bridge design is hard and time consuming compared to just building and testing.
For some reason we accept that software should be just thrown together rather than properly designed and proved. Yes, there are plenty of projects for which the level of formality I'm talking about simply isn't required - that's fine. My point is that there are plenty of projects for which the level of formality I'm talking about would be a damn good idea - yet it is never even contemplated let alone used. At worst you should be considering some level of formality for just those components of your system that are most critical.
Jedidiah.
Re:Nah (Score:1, Interesting)
However (and it's a big however), it still doesn't mean that your solution is correct! Did you get the requirements right? Is your system what the users expected? Is the interface layout easy to use? Is it fast enough to be useful? Does it add value to the customers toolset? These are all questions that formal software techniques don't address. And the only way to address them is to "build, ask, and test."
You can't generalize normal software development into engineering. Some of it (for instance, the stuff that keeps the space shuttle from crashing back to earth) COULD benefit from those techniques. However, this certainly doesn't fall into the "normal IT" category.
Re:Nah (Score:4, Interesting)
With software, the construction costs are negligable and the costs of a full-size model failing are also trivial. The correct engineering discipline in this case is to do the testing on the actual software.
In order to use a proper engineering discipline for software, you need to document what the code is supposed to do, all of the assumptions about the state of the system, and so forth. Then you need to test whether the actual code does what it is supposed to and maintains the constraints on the data. But you only do a little of this with theory and formal methods; most of it needs to be done by actually trying the code in various circumstances. Traditional engineering is done with a lot of testing of parts, testing of models you hope are similar, some simulation, some intuition, a bit of theory, and a big final inspection.
Now, it is true that a lot of the engineering practices are missing in the software world. But the things people actually do in the software world are a part of engineering; just not a complete method. And there is an unfortunate tendancy towards producing extra work which is not actually useful in the name of adding superficial similarity to different parts of the traditional engineering process. It is a bit like asking a civil engineer to produce a drawing of a new bridge not to scale without any information about the materials or the site.