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.

Over design

[grahamsz]

I've seen a lot of projects get truly overdesigned, because someone wants to make sure that they'll be easily extensible to changing requirements.

The resulting source is then needlessly complicated, and often when it comes to extending it, the original design gets in the way because it didn't pander to the particular change being made.

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:I blame the If statements

[Greslin]

I inherited a similar system back in the mid-90's when I did internal app development for a major aerospace/defense firm in Central Florida. The thing was a nightmare of nested IFs and CASEs, and every time one of my predecessors needed a new set of conditionals they'd just tack another in.

The thinking (or so I was told) was that in the early days of this app, it was written to be temporary, so just hack something together and make it fast. Unfortunately - and this seemed to be the rule with this company, and I hear still is - the temporary system stuck around because it worked today, and a new system would wait until tomorrow. Or next week. Or whenever.

So every new conditional was another hacked modification, another IF or CASE.

My task was to rewrite this monster and figure out a way to get it away from IF/CASE nesting, but keep every ounce of "flexibility" and functionality. Just a temporary system, they said; we'll replace it with a fully designed system after another year or two of consultation sessions.

After pulling my hair out for several days on that one, I thought about an article I once read on how the Infocom guys did their games. Rather than trying to code for every possible situation, they coded for a single *default* situation - "when in doubt, do this", etc. Then everything else was an exception rather than a rule, and could be easily abstracted. I did something similar with this system and sliced the code base down to about a third of the previous system, without losing any functionality. It actually gained some, since now new functions could be thrown into a database rather than needing to be hardcoded into nested branches.

It took a little longer to develop than what they anticipated. Not much longer, a few weeks, but a little longer. And my supervisor kept complaining that the design was too "involved" for a system that was only temporary.

That was 1997. The thing's still running today.

Moral of the story: In any given situation, the odds of replacement (whether code, or a job, or even a spouse) is essentially a path-of-least-resistance formula. If it's easier to maintain the status quo than it is to upset it, the status quo will almost always be maintained. The more management tells you that the code is temporary, the more you should assume it'll end up permanent.

Also, it never hurts to learn how other developers solved similar problems. :)

Re:Please check my math

[Xoro]

The $75 billion is per year.

The $1 trillion is over many years.

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

[fyrie]

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

Software Project Survival Guide

[Titusdot Groan]

The Software Project Survival Guide has an excellent self survey to gauge the current risk of your project failing. It's a lot more detailed than this "survey" and includes things like having a top ten risks list and management support.

It's written by Steve C McConnell (who also wrote Rapid Development and Writing Solid Code) and well worth it for anybody doing project management.

keep a strong launch focus

[clsc]

>> and most importantly, give breathing space for >> competitors to come up with similar products >> BEFORE we do.

Focus on launch from the start. Launch all the time, incrementally. Here's a few other nice pieces of advice. Read it, and then, well forgetaboutit... just do it.

Re:So...

[EvilTwinSkippy]

Do or do not. There is no try.