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

Comments

Change Transparency a.k.a. Big Visible Charts

[persaud]

Release managers can track requirement changes and their impact (effort, schedule) on the project. These changes can be reported separately from the primary schedule, so that everyone can see the impact of scope changes.

Change is not bad. Adapting to environmental changes (competition, customer education by early prototypes, vendor roadmaps) can make the difference between a one-shot failed project and a multi-generation successful product.

Big Visible Charts is a time-tested technique for non-political status reporting that helps everyone (from senior management to QA) take responsibility for the global impact of local changes. Grab a few unused monitors and create a wall-mounted status display with 1-minute project status updates, you'll be amazed at the results.

Re:Change Transparency a.k.a. Big Visible Charts

[Anonymous Coward]

I recently did something similar but web-based. The wall-mounted display wouldn't work in our case since the project is too big and managers have often seperate offices. However everyone has continuesly web access open.

A SIMPLE status portal page in which you can see REALTIME successful and failed code builds, status of regression systems, resources and 1-click (tm) away usefull info towards the RELATED log files, code changes, problem reports, documentation,...;

While we have a huge corporate network with lots of fancy stuff, this project page came within a week the homepage of most people working on the project.

Why ? Managers, coders and testers get and realtime (max 3 min. delay) current progress, status and available resource info. NON-POLITICAL is important for motivation. Compare status reporting (GREEN lights: everyone should feel good, things are going smooth, RED lights: there's a problem, we need help) with pageranking ( following people are responsible for x-number of bugs, bugreports ...) and ask yourself what reaction both systems provoke. The first system provokes more often a "I might help" reaction while the second provokes more a defence reaction, as in "hey, this actually not really my fault"

If it's the fastest way to get the latest info both as a global overview as links to realtime logfiles of what went ok or wrong, that's what people will use.

How? No graphics, just keywords and a few colors show global status info with ALL details 1 click away. Don't post 3 line sentences to say something went wrong or ok. The key is simple, dynamic, and realtime usefull info. The content should be 99.999% automaticaly generated and updated. If most content has to rely on a webmaster it's mostly useless. Webmasters tend to take holidays or get too often other things to do with equal or higher priorities . In that case the page looses most of its interest since the 'realtime' factor disappears.

I'll RTFA in my next comment but first...

[museumpeace]

I'll suggest everybody who has not yet done so should RTF precedents for such a study...it is as ancient as it is true: Brooks "Mythical Man Month" describes the reasons projects blow up pretty well. For all the technology heaped on software development in the 30 years since the book came out, very little has changed: Software projects are complicated beasts attempted by mere humans. Steve McConnel's books will be more familiar to /. readers and his approach to project management tries to head off the "changed requirements" fiascos with a feedback and correction mechanism of frequent critical project reviews...I wonder if that actually has worked for anyone:-(

Re:"Software Engineering" is not yet "Engineering"

[fyrie]

Fixed Link http://www.sce.carleton.ca/faculty/ajila/4106-5006 /Prospect%20Eng%20Soft.pdf