Slashdot Mirror
95% of IT Projects Not Delivered On Time
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."
Thanks /. a copy of this story now sits on my boss' desk.
Introducing Microsoft Vacuum 1.0 The first Microsoft product that doesn't suck.
Isn't it ironic that Slashdot is linking to an article speculating on why IT projects are completed late, that will then be speculated upon by hundreds of Slashdot users, during typical business hours?
I'd be morelikely to conclude that this means the schedules are simply wrong. it's so difficult to plan a correct schedule, and asking developers how long they think XYZ will take doesn't really work well.
Have there been any advances in scheduling technology? Like profiling developers over the types of software they write, etc.. ?
"Not knowing when the dawn will come, I open every door." - Emily Dickinson
"Could it be that marketing is always overselling the product?"
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.
This is almost always because the scope of a project changes between when it's initially described and when it's delivered. A majority of projects I've been involved with fall into one of two categories:
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.
We had some very good project management classes in college. During one, the lecturer asked us to give answers to a pop-quiz, but we could give the answer as a range, for example, for "How long is the Danube" you could guess "1000-1500km" with no limits.
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.
I'm a software developer now resident in the USA for about 5 yrs. Preivious to that I've been a developer and consultant working all over europe.
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.
I think that's exactly the problem with software expectations. They always assume that building software is like building a house, or a bridge, or a toaster. In other words, they always assume that building software is done by experienced people who've built nearly identical software systems before.
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.
Craft Beer Programming T-shirts