Slashdot Mirror
Is Your Development Project a Sinking Ship?
gManZboy writes "Everyone knows that some software development projects succeed and other fail -- the question has always been 'why'? I'm sure we all have our favorite (likely anecdotal) explanations. Well, these guys decided to actually go out there and do a formal survey, and they've got some real data on why projects actually fail (as reported by development project managers -- care to guess where 'changing requirements' ranks?). They've developed a diagnostic formula people can use to gauge the likeliness that the project they're working on right now is (or isn't) going to fail."
All too often, some sales guy will toss in a requirement like "must run on Win98"; and thousands of man hours will be wasted trying to meet something that wasn't even important to the customer.
If the original spec calls for "turn lead into gold", it's a very good thing if the requirements can evolve as technical issues are identified.
... since 1994, the Standish Group has been publishing the results and reasons of IT projects. Go here for the original report.
We've gone from about 25% of projects being "successful" (on time, on budget, meeting stated needs) to about 31%. So translated, that means 2/3ds of the time you get into your car or get on an elevator, it'll work as you want.
Consistently, the top reasons for projects failing, for the past 10 years?
1. Unclear, poor requirements
2. Lack of user involvement
3. Lack of buy-in and support by upper management
I have to agree with other comments made, this isn't rocket science. We just need some time and maturity as an industry. Civil and mechanical engineering have had thousands of years to work out their kinks. The software engineering science has had to deal with technology and implementation far outpacing our understanding of the basics and principles involved.
But we're getting better.
Honestly, if the world at large knew how brittle, fragile and reliant on heroism most of the critical financial and industrial software was, there would be a huge outcry. It's one of the shameful aspects of our industry.
Neurowiz
Having many years of successful software project management under my belt, I can tell you it boils down to two concepts: professional training and discipline.
There are a million and one books and surveys and they all say the same thing. First, there is a formal process for the development of anything (not just software). This starts with the formal documentation process and meetings to discover functional and non-functional issues. Second, there is a very strong sense by everyone to want to adjust it a little more. From senior managers who allow scope creap to managers who want steps to be cut to make up time to programmers constantly who rewrite the code because they think they can squeeze 5% more time out of a loop that runs for less than a second in a process.
Most people do not realize that in a successful formal process that the actual time in a software project that is used to build the software should amount to only about 30% of the project's development time. The other 70% is time spent on documentation, meetings, and testing to ensure that the 30% of time used on software delevopement is actually what the company is needing. And, it is discipline that keeps people on the project process in the face of the fear of not getting the project done right. The process has to be allowed to work, both to reach a project end point and to have unobstructed process from which to learn.
The part I get a kick out of is that just because people write software or run a company that they somehow think they just ought to know why projects work. If complex systems were just so easy, why would we need formal training? After all, anyone can build a bridge successfully without training, right? I am not being hard on people, though. I had this exact same though years ago and what I figured out is that the vast majority of the software industry is so poorly trained that it doesn't even realize that it poorly trained.
Successful software development books have been around for more than 30 years. Go read! Better than that, get a university degree. The more liberal the better. Honestly, it is worth it. Here is a good place to start: Systems Analysis and Design by Kendall and Kendall (ISBN 0-13-041571-5)
Bel, the mostly sane.. "Of course I can't see anything! I'm standing on the shoulders of idiots." -- Me
i actually was "assigned" to supervise a death march project at my last employer. my "new" manager(6th one in one year) knew the project was going to be canned(didn't confirm the inevitable to me, even when confronted), and most of the people would be absorbed into other projects or simply layed off. why was it a doomed project? politics.
someone else in our organization (at another geographical location), happened to be better aligned with the top management group, and used this to their advantage to eliminate competing projects, or in some cases eliminate the internal competition and take the projects over as their own.
of course at the time i had no idea what i was getting into(or who my "competition" was). no matter what our team did to produce a superior product, our project was cancelled for reasons beyond our control. i ended up stressing out and nearly damaged my health and my relationship...
then i read a book call Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects. i soon realized that we were set up as an ugly style project, doomed(in fact designed) to fail.
it's good to understand why projects fail, i have not yet RTFA, but i'm sure it will compliment some of the discussions/concepts in the death march book. good read.
three can keep a secret, if two are dead - benjamin franklin
One result of ad-hoc software design and implementation has been government regulation of software in the financial, security and pharmaceutical sectors.
One result of government regulation has been the emergence of requirements management tools like Borland's CaliberRM and Telelogic's DOORS.
These tools trace every functional requirement back to a business requirement. They also track the risk (schedule, safety, robustness, performance) of every functional requirement to the rest of the system.
Vague specification, like vague design is an indicator of not understanding the problem. The first step towards understanding the problem is categorization of ignorance, such as unexpected consequences already experienced by the project.
Good requirements management tools incorporate practices that have been proven to flush out vague specifications. Good traceability educates upstream participants so they can produce better specs in the future. Better specs yield better products, including better spec management tools
Here is a pretty good paper by Mary Shaw explaining why software is not yet an engineering discipline (IEEE). http://www.sce.carleton.ca/faculty/ajila/4106-5006 /Prospect%20Eng%20Soft.pdf/