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

Project Management Authority

[fembots]

I used to blame "constant client requirement changes" for failed projects as suggested by my project manager.

Later I realized, as suggested by the senior management, that a good project manager should not let that happen had he properly designed and managed the project.

Recently I started to think that maybe all failed projects are due to the delays inevitably imposed by the senior management who requires many policies/protocols/documents/approvals/discussions before signing off the budget.

These delays introduce deadline pressure to project manager, and allow too much time for client to ponder about other features, and most importantly, give breathing space for competitors to come up with similar products BEFORE we do.

Re:Project Management Authority

[jeillah]

Most products specs I've seen lately are what I call CYA specs. They ask for things that are comprehensive enough to keep the blame away from the analyst even if the requirement is for things that are difficult to implement and probably never used by the end user. A prime example of this is requirements for searching and reporting. The spec will call for the ability to search or report on any field or groups of fields, as determined by the user, with multiple search criteria for any field with the data sorted on any field. And it has to be simple enough for a non-technical user to use (no fair making them enter SQL). Chances are it will only make sense for the user to view data in a few ways so why not define these ways and put that in the spec? Nope, cause they might miss something and they'd be shamed for life. Better to just put "I want everything I can think of and might think of in the future" in the spec and complain that the project is behind schedule and is too big and runs too damn slow when (if) it is finally delivered.

In case you can't tell, I'm in the process of reviewing just such a spec from our legal department right now. Specs written by lawyers are pretty but wordy without really saying what exactly they want...

Re:Project Management Authority

[Mr_Huber]

The difficulty here is making absolutely sure the client and the mangement know the difference between a working prototype with canned data and a fully functional application capable of handling real world situations. All to often, I've seen really good prototypes either turn into the actual product, or be the source of unrealistic estimates of project status. (After all, if the demo works, how hard can the rest be?)

I remember reading an article by Joel Spolsky where he advised to deliberately make the UI for demos less than polished. Make it look like something that was knocked together. Make it too pretty and the client will think you're almost done. After all, to the client, the UI is the app. If that looks done, the guts of the thing must be near done as well.

I blame perfection

[Anonymous Crowhead]

People who sit around for months or years trying to design the perfect system. It doesn't exist. Compromise gets projects done.

Projects fails because no one ever learns

[Ckwop]

It's as simple as that unfortuantely - we *never* learn from our mistakes. Over the last thirty years every system we can dream of has been built from nuclear power plant control system to stock market analysis systems.

Yet we keep playing the buzzword bingo with our new systems, e.g. "Extreme programming", we still keep promise a schedule we can't keep to, we still allow the customer to shift requirement much later in the project than should be allowed, management still don't have enough dialog with the programmers on the ground floor, the list goes on..

Wake up! We're not special.. the construction industry has been doing huge projects of equal complexity for centuries. Get past your intellectual snobbery and start working together..

Simon.

Skill sets for Project Management

[ag4vr]

One key element that appears to be missing is the qualifications of the manager or management team. Project management is a different skill set from design or development.

It's not to say that a good designer or developer cannot be a good project manager; it's just a different job, like asking a plumber to rewire your house.

Re:A classic one for me

[SoTuA]

When your project manager hands you a project started by a rookie and tells you, "It's 95% done. All you have to do is the final touches."

Aaaah, that one is subject to the 95% rule:

The first 95% of the project takes 95% of the time, and the remaining 5% takes the other 95% of the time"

(loosely quoted from some fortune)

After I RTFAed...

[Eneff]

Thanks mirrordot!

Tiwana and Keil were asking MIS directors what *they* thought, not project managers or developers, leading me to believe that this is more based on client perception than someone with experience working on said projects.

That said, they ranked changing requirements last when talking about risk of failure, and actually said that inappropriate methodology was the top reason of project failure.

Now, while a lack of any sort of methodology is a disaster waiting to happen, I have a difficult time believing that a bad fit for a project creates more risk than project complexity and shifting requirements combined, as they suggest.

*sigh*

Do you really believe that a client is going to place shifting requirements as a risk? After all, they're the ones asking for the changes!