Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is Your Development Project a Sinking Ship?

michael posted more than 9 years ago | from the down-down-down-and-the-flames-went-higher dept.

Programming 494

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

cancel ×

494 comments

Project Management Authority (5, Insightful)

fembots (753724) | more than 9 years ago | (#11257219)

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 (4, Interesting)

Anonymous Coward | more than 9 years ago | (#11257289)

Flexibility to meet changing requirements is a good thing.

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.

Re:Project Management Authority (2, Insightful)

xbrownx (459399) | more than 9 years ago | (#11257324)

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.

This cannot be emphasized enough. The project manager needs to not only manage the people within your company and what work they're doing on the project, but also the customer and the customer's expectations.

Re:Project Management Authority (1)

Fnkmaster (89084) | more than 9 years ago | (#11257428)

That's great in theory, but if your sales and marketing people aren't willing to cooperate, it can be hard for the project manager who is sometimes dictated to what he can or cannot tell the customer ("we already sold them feature X without asking you, so no, you don't get to tell them that feature X adds two months to the deadline").

Correct, but there is more (4, Insightful)

Interfacer (560564) | more than 9 years ago | (#11257398)

Not only do client requirements change, but management is also responsible for fubaring things.

i have been part of a project (past tense) where:
- management delivered a much too low cost estimate in order to get win the bid.
- management then expected the project manager and team to meet the deadlines that were doomed in advance.
- the software design lead designed a behemoth of a framework full of performance and design issues.
- management did not understand that if you have unexplained system behavior, you cannot say when you will have solved the problem.
- hardware design was not reviewed, just like software design. this lead to huge problems just before and during acceptance.
-near the end of the project, more and more people were reassigned to a new project that has the ability to make the department manager look good to the head office. he wants to move up. In effect, succes of the former project became a more and more distant possibility until failure was assured.

and there are probably some other things that i either forgot or purposly left out (trying to repress memories maybe ;)).

Change Transparency a.k.a. Big Visible Charts (3, Informative)

persaud (304710) | more than 9 years ago | (#11257424)

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 [xprogramming.com] 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:Project Management Authority (1)

bwalling (195998) | more than 9 years ago | (#11257442)

Too much "planning and documenting" and not enough prototyping. Whip something up and have the client/user work with it. Make changes based on that. Don't plan the living shit out of it before you even have something to work with.

Re:Project Management Authority (0)

Anonymous Coward | more than 9 years ago | (#11257618)

Whip something up and have the client/user work with it

Jesus Christ, you must work for my ex-boss. All I ever heard that bitch say was "Put it out there and see what you can do with it", or "just give them something to look at it for now", or the classic "whip something up right fast". WTF does that mean? Just WTFF does that mean? How the hell do you "whip" something up when there is less than zero project requirements gathering going on? I'm so glad I don't have to work for that fucking bitch anymore.

Over design (2, Informative)

grahamsz (150076) | more than 9 years ago | (#11257626)

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.

Hammer Revolution! (-1, Offtopic)

hammer revolution (836067) | more than 9 years ago | (#11257220)

--;

The hammer revolution has begun

--;

So... (5, Funny)

Blue-Footed Boobie (799209) | more than 9 years ago | (#11257227)

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

So, if I know it is going to fail, do I still have to try?

Re:So... (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#11257286)

no, if you want to go collect your fucking unemployment check right now, knock yourself out...

Re:So... (5, Funny)

2A (841921) | more than 9 years ago | (#11257370)

but what will really bake your noodle later, is would the project still have failed, if I hadn't told you it would?

Re:So... (2, Insightful)

kin_korn_karn (466864) | more than 9 years ago | (#11257395)

Ah yes, the Heisenberg method of project management...

Re:So... (1)

Blue-Footed Boobie (799209) | more than 9 years ago | (#11257401)

Someone mod that funny...

Re:So... (5, Funny)

Neil Blender (555885) | more than 9 years ago | (#11257429)

but what will really bake your noodle later, is would the project still have failed, if I hadn't told you it would?

Dude, Oracle jokes are so next week.

ta daa (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11257240)

fp!

Re:ta daa (-1)

Anonymous Coward | more than 9 years ago | (#11257283)

you suck

IE Team (-1, Flamebait)

CypherXero (798440) | more than 9 years ago | (#11257241)

I think the Internet Explorer team should read this study...

"changing requiresments" less bad than no change (4, Insightful)

Anonymous Coward | more than 9 years ago | (#11257246)

Changing requirements is far less bad than a frozen spec based on overanalysis by MBAs who never spoke to customers.

Re:"changing requiresments" less bad than no chang (0)

Anonymous Coward | more than 9 years ago | (#11257367)


Of the $2.5 trillion spent on IT during 1997\u20132001, nearly $1 trillion was wagered on underperforming projects [3]. A large number of underperforming projects ultimately fail, costing U.S. companies more than $75 billion each year [8]. While some events cannot be predicted or controlled, many of the risks that repeatedly plague software projects can be assessed and managed.

That's taking the view of the shareholders. The money spent isn't "gone", it's been paid to employees and contractors who then spend it on food, lodging, xbox modchips, etc.

Actually I think it'd be interesting to see them use their formulas on the budgets given to the Pentagon every year.

Re:"changing requiresments" less bad than no chang (1)

tchuladdiass (174342) | more than 9 years ago | (#11257659)

Based on your logic, if you put a bunch of money in an S&L account that isn't FDIC insurred, and the president of the S&L decides to squander your life savings on booze, parties and yachts, then your money hasn't really dissapeared... it has gone to the liquore and yacht manufactures who in turn pay their employees who buy consumer goods & services, some of which comes from the company you work for and ultimately ends up in your paycheck. :-)

Yeah but... (3, Interesting)

Anonymous Coward | more than 9 years ago | (#11257262)

Are they really getting at why projects fail, or are they just getting a good record of what people on failing projects like to bitch about?

Changing requirements blah blah blah not my fault blah blah blah...

The formula (5, Funny)

superpulpsicle (533373) | more than 9 years ago | (#11257266)

Fair management expectations
+ Well allocated budget
- Patch fixing firedrills
- unnecessary marketing spinoffs
+ free donuts
= success

Re:The formula (0)

Anonymous Coward | more than 9 years ago | (#11257452)

You work for CA?

I blame perfection (5, Insightful)

Anonymous Crowhead (577505) | more than 9 years ago | (#11257269)

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

Re:I blame perfection (0)

Anonymous Coward | more than 9 years ago | (#11257402)

It's the Microsoft model at work!

Re:I blame perfection (3, Interesting)

LazyNerd (794850) | more than 9 years ago | (#11257468)

I've seen a quote attributed to General George Patton that says:

"A good plan, violently executed today, is better than a perfect plan tomorrow."

Do you have evidence of this? (3, Insightful)

expro (597113) | more than 9 years ago | (#11257504)

I have lots of evidence of failed projects due to failure to plan.

It can take months or years of thought and discussion to reasonably avoid extreme catastrophies.

While it is silly to try to plan every detail and anyone who claims to do so is lying, a simple elegant, successful general approach is seldom the first one to pop into the head. It takes a lot of thought. Of course, for those incapable of such forethought, why not fail earlier rather than later.

My Development Project (0, Offtopic)

Artie_Effim (700781) | more than 9 years ago | (#11257272)

I was developing a robot that automagically first posted slashdot.org for me, to save me tons of time at work and whatnot, but sadly it didn't work too well.

Diction (-1, Troll)

pete-classic (75983) | more than 9 years ago | (#11257288)

Everyone knows that some software development projects succeed and other [sic] fail -- the question has always been 'why'?


I don't know the answer.

But I do know that if the answer is "diction," you're doomed to fail.

-Peter

the real question is, using their formula... (3, Insightful)

testednegative (843833) | more than 9 years ago | (#11257293)

... did they fail or succeed?

Aggressive scheduling (3, Interesting)

kevin_conaway (585204) | more than 9 years ago | (#11257301)

Our project is currently suffering from aggressive scheduling. We are put on too tight of a timeframe to allow even the most minor setbacks. Changing requirements seems to be the nature of the game, and when we dont allot enough time to accomodate these changes, we get into trouble.

Re:Aggressive scheduling (1, Insightful)

Anonymous Coward | more than 9 years ago | (#11257426)

I'm in QA, been doing this for 9 years. This parent's post is right on. Aggressive scheduling KILLS projects. It's what causes tension.

Remove cloud cover (2, Interesting)

persaud (304710) | more than 9 years ago | (#11257581)

Non-minor setbacks are often the result of aggressive scheduling, but cannot always be attributed directly to the specific change or person who initiated the change.

Look at a schedule as just one component of a (good or bad or in absentia) process. Look at a process as just one component of the product. Then non-vetted schedule changes (aggression without responsibility) become product defects.

What do you do with defects? You track them. You test for them. You fix them. Data (evidence) is needed for tracking, testing and fixing schedule defects. Collect the data in advance so you can fix the schedule in retrospect.

Otherwise, every day will be Groundhog Day.

here's a mirror. (0, Troll)

JaffaKREE (766802) | more than 9 years ago | (#11257302)

Mirror [heatheringtons.com.au]

Re:here's a mirror. (2, Insightful)

rainmayun (842754) | more than 9 years ago | (#11257407)

You jackass! I actually clicked on that....

Anyway, since I can't read the story, I'll just blather on about conditions here where I work... the #1 cause of failed software projects is poor client management. We all know that the client doesn't know jack about making software... if they did, they wouldn't need to hire us. Yet when the client contradicts themself, the opportune moment to flash that consulting brilliance and prove why we cost so much is immediate. It would be so easy to say "what you've just asked for is impossible because it conflicts with this other thing you asked for". Yet from a marketing perspective, that's bad for business. Why? Because our company's goal is to maximize profit, not to maximize software quality. Believe it or not, we often get contract modifications to fix those very problems we could have circumvented because the developers foresaw them coming. Essentially, we get paid to build the same system twice. How's that for consulting brilliance!

Re:here's a mirror. (1)

dgatwood (11270) | more than 9 years ago | (#11257635)

Believe it or not, we often get contract modifications to fix those very problems we could have circumvented because the developers foresaw them coming. Essentially, we get paid to build the same system twice. How's that for consulting brilliance!

On the flip side, if you show that you are brilliant up front and point out the problems early, they will tell everyone else what an incredible job you did, unlike those lazy, incompetent morons who they hired the last time who had to redo the whole project. Now instead of one customer over the course of a year, you have one customer for six months and then six months each for eight of their partners who were shocked that a company would actually sing the praises of a contracting company....

Or, the corollary: in the end, forcing others to pay for fixes for things that you should have caught to begin with is the surest way that your company will be replaced by an open source project that took an intern six weeks to create using MySQL and PHP.

Re:here's a mirror. (0)

Anonymous Coward | more than 9 years ago | (#11257484)

Arrgh!! You got me! (I must be a vampire, because I didn't see myself)

Re:here's a mirror. (1)

JaffaKREE (766802) | more than 9 years ago | (#11257492)

It's not really a troll so much as it is a joke, but I guess there's no -1, Joke.

Re:here's a mirror. (1)

BobPaul (710574) | more than 9 years ago | (#11257494)

That's the funniest thing I've ever seen!!

Anyway, here's an actual mirror [bombaycompany.com]

And here's a MirrorDot Link [mirrordot.com] in case that goes down.

Projects fails because no one ever learns (5, Insightful)

Ckwop (707653) | more than 9 years ago | (#11257304)

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.

Re:Projects fails because no one ever learns (2, Insightful)

Anonymous Coward | more than 9 years ago | (#11257425)

The construction industry has also suffered from slipped schedules and cost overruns for centuries. (Bay bridge, anyone?) The big difference is that with construction it's a little bit more obvious to clients that they just have to keep waiting until it's done.

Re:Projects fails because no one ever learns (3, Interesting)

LWATCDR (28044) | more than 9 years ago | (#11257485)

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

Umm no they have not. Construction is one of the slowest to change industries on the planet. Take a hotel It is really just room after room. You design one room and then multiply that out to make a floor. Then you stack the floors and you have a building.
The key is standardized everything. Look at your average home. It is still built out of sticks or concrete blocks. Very little has changed in a very long time. The latest thing is metal studs but it took decades for them to become commonplace in homes. Very little changes and very little in really innovative.
And if you think that building projects are always on time and on budget.... Ha Ha Ha Ha Ha Ha
Not on your life.

Re: 'doghouse' theory of software (1)

Punctuated_Equilibri (738253) | more than 9 years ago | (#11257493)

I call this the 'doghouse' theory -- building software should be simple, like building a doghouse, if we could just get our act together.

The big difference is that construction projects are tangible, you can walk up to the doghouse and see with your own eyes how it was built. When a change is suggested it's obvious to everyone what the impact is.

Software is abstract. There may be some screens and output, but the internals can only be understood conceptually (and only relatively few people can do this).

That's why software is much more difficult to execute, even though from a project manager's point of view the plan may look similar.

Re:Projects fails because no one ever learns (2)

swimmar132 (302744) | more than 9 years ago | (#11257517)

Repeat after me: Software is nothing like Construction.

Construction Analogy Fundamentally Incorrect (3, Insightful)

irritating environme (529534) | more than 9 years ago | (#11257544)

In 90% of the subprojects of construction, a manager can walk by in a few seconds gauge: - progress - quality of work - time to completion - implications to dependent subprojects Can't do that with software.

Visualization Problem (1)

persaud (304710) | more than 9 years ago | (#11257630)

If you have an automated QA process and a decent release management system that generate tracking data, you can create "dashboard" status displays on wall-mounted monitors that show everything you listed. Although this may seem draconian, it actually brings management into the schedule as an early risk management participant, rather than an outside observer who offers little input into daily tactics.

Ratio of Intelligence to Project Complexity (4, Insightful)

severoon (536737) | more than 9 years ago | (#11257307)

I've done a lot of thinking about this...I've come to the conclusion that too often, management tries to replace good ol' fashioned thinking with process. It doesn't work. People tend to get focused in on what they're doing to the exclusion of all else, and that means the smart people are cubbyholed and only have half the story and can't see where other parts of the project are failing, and dumb people have free reign over their little part.

If the ratio of intelligence to complexity is too low, then the project will fail no matter what process is in place or who is managing it. That's all there is to it. There's a lot of cool stuff out there to be done in development...sadly, most of the good ideas will never make it because the people working on them don't use common sense and best practices...they're just not smart enough to see what's important and what isn't.

This isn't one of those self-important diatribes from a holier-than-thou developer, either...true I'm a developer, but I admit when I'm too dumb to handle the particulars of a project; usually, that means the project is too complex for most people, but they press on anyway. Those projects always go down in flames eventually.

You have to know what the strenghs and weaknesses of your team and its members are, and exploit those to the fullest. Maybe, then, you can barely accomplish a project if the goal of that project is simple enough.

Smart People (2, Insightful)

persaud (304710) | more than 9 years ago | (#11257530)

can be used as an excuse to avoid process, which is a distinct animal from bureaucracy.

Good process is independent of the intelligence of the humans implementing the process.

Good process amplifies the effectiveness of all participants.

Good process generates tracking data that can be used in negotiations between development (reality) and management (theory).

I utterly agree (2, Insightful)

SuperKendall (25149) | more than 9 years ago | (#11257553)

I have seen this time and time again, people trying to use Process as a mechanism to put everyone on the same level. It sure works - the people who are normally 10x as effective as others are hamstrung and unable to be effective at what they do.

This is the real tragedy of Sarbanes-Oxley. It is being used as a trump card for every process flunky that comes down the pike to implement their favorite process to the fullest. This is going to have a real and very unfortunate effect on companies that become too infected with process to move.

Sigh. (1)

Benanov (583592) | more than 9 years ago | (#11257317)

Requirements Volatility was #5 on their list. Around where I work it's #1.

Another day of this client making some _unnecessary_ and nit-picky change and I'll start adding an extra week to my estimates of when it'll be done.

Re:Sigh. (2, Interesting)

Neurowiz (18899) | more than 9 years ago | (#11257437)

You should be doing that anyway.

An estimate is done based on assumptions and scope. If your client changes the scope, that should cash in your pocket the moment they say "Yes" to the proposed change and resultant cost.

Part of my job is process improvement. One of the first things I find useful to teach development teams is how to say "No" or "It'll cost this much and take this long. Do you still want it?"

Re:Sigh. (1)

javaxman (705658) | more than 9 years ago | (#11257620)

Requirements Volatility was #5 on their list. Around where I work it's #1.

Another day of this client making some _unnecessary_ and nit-picky change and I'll start adding an extra week to my estimates of when it'll be done.

So wait a minute: Lack of customer involvement is #2 on their list of problems, but Requirements Volatility is last... but getting the customer more involved in your case means making the Requirements Volatility worse...

What their ranking really says to me is that successful projects include the customer who knows what they want and thus sets the requirements early. In my own experience, the customer usually has only a vauge idea what they want, and a really good idea of what they don't want. What you need to be able to do is put off the _truly_ unnecessary changes to a _scheduled_ version 2, either doing a planned multi-pass prototype/design phase, or locking down agreed-to requirements sets and designs ( including UI and other specifics ) as the very first step.

Beware, though- what you as a programmer might see as a nit-picky change might really be a workflow-enhancing feature that prevents the customer from hating your app... people would much rather their tools do what they want, rather than having to learn to use them.

If your client is making time-consuming changes late in the project... well, the very fact that they can do that, or that small changes are time-consuming, should raise a major red flag. You're doomed- either the change being made isn't really minor, or you've blown #1 and picked a development methodology which doesn't allow for smallish changes to be quick changes.

Blame the P.M. - usually (4, Insightful)

jacobcaz (91509) | more than 9 years ago | (#11257318)

Every project, whether it's a development project, implementation or business process engineering, that has failed for us has been because of poor project management. Period.

We've had people who didn't know how to accurately scope business requirements, get buy in from other departments and generally "play nice" enough to keep everything running smoothly. Your P.M. needs to be able to be a hard ass, but also to be a buddy.

It boils down to excellent management skills and excellent people skills and without both you're setting a project up for disaster. A good P.M. needs to know when to tell senior management it's asking for the impossible too, and a good P.M. needs to know he has kung-fu so he can get away will telling senior management their idea won't be implemented.

Managing Up (1)

persaud (304710) | more than 9 years ago | (#11257472)

is at least as important as managing down.

Re:Managing Up (1)

Angry Toad (314562) | more than 9 years ago | (#11257598)

Couldn't agree more completely. A good PM works people at all levels to ensure things come together.

Of course that's assuming he/she is given sufficiently free reign to focus on project success over other priorities.

Re:Blame the P.M. - usually (2, Interesting)

Fnkmaster (89084) | more than 9 years ago | (#11257511)

The problem is when sales start suffering and things aren't going well on that end of the business, senior management will tell the project manager to stuff it or get fired, and that they have no choice and the customer absolutely can't be told that feature X has too high a time cost to make it into the next release.

If your project manager is completely constrained, then it's not his fault that he can't push back on poorly defined business requirements or ridiculously unreasonable timelines.

The solution is your sales team needs to buy-in to the idea of properly qualifying customers and setting expectations reasonably, or not setting expectations at all until project management has been brought into the sales process. The "lie, cheat, do anything to close the deal" technique often fucks small companies over leaving these disastrous projects in its wake. And yes, bad project management, poorly defined requirements or changing requirements and other factors can certainly ruin a project too.

Re:Blame the P.M. - usually (1)

John_Sauter (595980) | more than 9 years ago | (#11257551)

Every project, whether it's a development project, implementation or business process engineering, that has failed for us has been because of poor project management. Period.
Blaming the project manager is a cop-out. It's like saying a plane crashed because of "pilot error." Yes, probably the pilot made an error, but he certainly didn't intend to crash the plane (terrorists excepted). To understand the problem well enough to fix it, you need to go deeper. What is there about the system that caused the project manager to make poor decisions?
John Sauter (J_Sauter@Empire.Net)

Re:Blame the P.M. - usually (1)

jacobcaz (91509) | more than 9 years ago | (#11257602)

  • What is there about the system that caused the project manager to make poor decisions?
Well, in several cases it was upper management not having a methodology for selecting a qualified project manager; thus putting the wrong person in charge of the project where it promptly fell on its face.

Everything got much better when that person unexpectedly quit and walked out. A bit of panic and frenzy and then things smoothed out quite nicely.

So if you don't have both a top-down and bottom-up methodology for projects the blame can be pinned largly on the underqualified P.M. and on the management structure that put him there in the first place.

Cosmo Quiz (5, Funny)

brw215 (601732) | more than 9 years ago | (#11257321)

Is this simply the nerd version of the ages-old cosmo quiz? I fail to see how "The one-minute risk assessment" is any more comprehensive or meaningful than the "Does he think you are fat"-type quizes that make their way through women's magazines.

Re:Cosmo Quiz (0)

Anonymous Coward | more than 9 years ago | (#11257462)

I fail to see how "The one-minute risk assessment" is any more comprehensive or meaningful than the "Does he think you are fat"-type quizes

The difference is that you don't know if your project will fail or not. We already know you're fat, we just don't want to admit it.

Buzzword Alert (1)

leonscape (692944) | more than 9 years ago | (#11257333)

I can't believe how many buzzwords they managed to fit in there. You don't have problems their Risk Drivers, don't we already have enough Jargon?

Skill sets for Project Management (5, Insightful)

ag4vr (705570) | more than 9 years ago | (#11257340)

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:Skill sets for Project Management (0)

Anonymous Coward | more than 9 years ago | (#11257614)

I've seen more projects fail because the Project Manager is a fresh-out-of-MBA-school kid who spends more time with his textbooks rather than understanding both the technical and/or customer issues.

I'd rather have a salesguy or an engineer be a PM than your typical "professional" project manager; because at least they'd understand half the issues. The career-PM won't understand either one.

I used to not think so (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11257346)

I used to not think so, but then I started to get the hint when I saw Leonardo DiCaprio hanging around on deck all the time.

Coral Link (cached with pictures) (0)

Anonymous Coward | more than 9 years ago | (#11257349)

Article [nyud.net]

Figure 1 [nyud.net]

Figure 2 [nyud.net]

Figure 3 [nyud.net]

So, I hope that helps as it gets slower.

A classic one for me (0)

Anonymous Coward | more than 9 years ago | (#11257353)

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

That's a guarantee that the entire app needs a complete rewrite. Now, that's what I do from the get-go. I'm fortunate that I am in a situation where I have that kinf od leeway.

Re:A classic one for me (2, Interesting)

Neil Blender (555885) | more than 9 years ago | (#11257396)

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

That usually means the UI isn't done. Unfortunately, the UI consists of 905% of the remaining work.

Re:A classic one for me (1)

MrBandersnatch (544818) | more than 9 years ago | (#11257661)

Thats similar to my most recent project.

2 VB6 "programmers" and 9 months work and they handed off the project to my current employer, "90% complete".... ...problem being that the 10% that wasnt completed was the design, documentation and testing!

I tell you, I wept!!

Re:A classic one for me (1)

stratjakt (596332) | more than 9 years ago | (#11257476)

The funny thing is, that pretty much sums up most OSS projects. The final 5% is always missing or up to the user.

In fact, most of these rules apply to any given OSS project.

MOD PARENT "+5 TROLL DAT" (0)

Anonymous Coward | more than 9 years ago | (#11257613)

The hard truth moderation that gets no play here at Slashdot.

Re:A classic one for me (5, Insightful)

SoTuA (683507) | more than 9 years ago | (#11257622)

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)

Learn from the pros and never fail again! (0, Flamebait)

Dystopian Rebel (714995) | more than 9 years ago | (#11257364)

"There is no project failure that Marketing can't redefine as a success."
-- excerpt from The So-Secret-We'll-Have-To-Kill-You Microsoft Handbook

Overruled by beancounters (1)

tjlsmith (583149) | more than 9 years ago | (#11257392)

was the cause of the project I just involuntarily left (it was canceled) to flounder, and will be the cause of the one they are on now.

I blame the If statements (3, Interesting)

TheFairElf (669537) | more than 9 years ago | (#11257403)

The client I'm currently working for has a core product that is modified as per each customer's requirements. The modification process works exactly like this:
if (customerName == "cust1"){

// customizations for customer 1
}else if (customerName == "cust2"){...
}
.. and so on. There's a new customer? Easy, add another if statement. The entire code base is a hodgepodge of conditional statements. Needless to say, the program has tons of bugs and the performance sucks. Its a wonder to me that the customers put up with it and even continue to pay for it.

Re:I blame the If statements (1)

NoInfo (247461) | more than 9 years ago | (#11257520)

Well, Duh! Everyone knows you have to use switch statements in that kind of project.

Re:I blame the If statements (0)

Anonymous Coward | more than 9 years ago | (#11257522)

Introduce them to version control [tigris.org] .

Re:I blame the If statements (1)

yohan1701 (779792) | more than 9 years ago | (#11257548)

Hey I think I used to work there.

Poor implementation (0)

Anonymous Coward | more than 9 years ago | (#11257576)

If you guys designed it as:

if (featureX_enabled(customername)) {
// customizations for customer1
// ... and other with similar needs!
} else if (featureY_enabled(customername)) {
}

You'd be doing both yoursleves and future customers a favor.
If one customer has a need, it's likely others you'll see in the future have similar needs.

Re:I blame the If statements (2, Informative)

Greslin (842361) | more than 9 years ago | (#11257660)

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. :)

Care to guess where 'changing requirements' ranks (2, Funny)

Kenja (541830) | more than 9 years ago | (#11257410)

No, what I want to know is where "linking your project to a slash dot article" ranks.

Is Your Development Project a Sinking Ship? (1)

i 3 joo! (846337) | more than 9 years ago | (#11257446)

Yarrr!

It always comes down to people (4, Insightful)

Anonymous Coward | more than 9 years ago | (#11257475)

It ALWAYS comes down to people. This article looks to be a discussion relevant more to a commercial environment than an open source one, but I guess the same fundamental principle is true - without the right people you will not succeed. This means competent and motivated technical people, clueful and skilled management, and customers willing to be reasonable and pay for what they are getting. Take away any one of these elements, and there is no technique in the world which will result in something everybody can define as a success.

These guys break down the problems into useful categories, which will be helpful for good teams who want to know how to be more efficient. But for my money a group of serious, decidated people who honestly want to get the job done and do it well will usually get there, barring external factors beyond their control messing it up. It might take a while, cost $$, etc. but they'll make it, because they WANT to.

Many (I would even say most) successful open source projects succeed because they have one or several individuals willing to put the work in to make something happen. The tools they use or the way they work are less important than determination to get it done and do it well. Those without that wither on the vine.

In theory, commercial companies and development teams should be motivated by the $$ they are paid, but that doesn't always translate into doing the job well. There are PHBs, lazy workers, unreasonable customers, and all the other joys of life out there. There is no magical "business formula" which can transmute this combination into a good product.

Don't get me wrong, project management and efficiency techniques are a very good thing, but only when you've got the people to make good use of them.

If your project. . . (2, Funny)

smooth wombat (796938) | more than 9 years ago | (#11257496)

is to develop a sinking ship, isn't that another name for a submarine?

This has already been done (5, Interesting)

Neurowiz (18899) | more than 9 years ago | (#11257502)

... since 1994, the Standish Group has been publishing the results and reasons of IT projects. Go here for the original report. [standishgroup.com]

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.

Re:This has already been done (1)

slowhand (191637) | more than 9 years ago | (#11257582)

... since 1994, the Standish Group has been publishing the results and reasons of IT projects...

You beat me to it. Now, 10 years later its coming to light.... with a reference to the Standish Group CHAOS REPORT. More study is a good thing. Lots of replies above seem to reflect a lot of "who cares, just get it done", combined with lots of "I know what it is, its xyz..." Folks, read the CHAOS REPORT report if you havent.

Is it a sinking ship? Nah... (0)

Anonymous Coward | more than 9 years ago | (#11257513)

It sank, and got redefined. It's now a sinking submarine.

The Golden Rule of PM (1)

ip_freely_2000 (577249) | more than 9 years ago | (#11257526)

"90% of the effort to finish the last 10% of the project."

Personally, I've been most successful when the project worked 'good enough' when 90% of it was done.

I completely agree with others above me on this thread who have said "Never look for perfection". Getting the system to something that 'just works' should always be the goal.

It's not magical (5, Interesting)

beldraen (94534) | more than 9 years ago | (#11257549)

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)

Lack of widgets (0, Offtopic)

BestNicksRTaken (582194) | more than 9 years ago | (#11257550)

My main personal project is at a standstill for now until I can figure out how to make my own wxWidgets widgets and wxPython wrapper.

I basically need a way of putting a checkbox into the last column of a wxListCtrl, kinda like a ColumnSorterMixin in the wxDemo, but I need a checkbox widget, not just a bitmap.

If anyone knows how to do this, it would mean I could do a lot more development (maybe even finish) my cross-platform Livejournal client.

Where I used to work, the decision was to go with Qt for all C++ GUI work, mainly because of lack of widgets in GTK+ and wxWindows as it then was known, plus it's easy to make your own custom widgets in QtDesigner.

My Perl ethereal clone is coming along nicely, I would convert it to Python, but don't have time to research libpcap support.

Quilty Software (2)

RManning (544016) | more than 9 years ago | (#11257558)

In my experience, the quality of the software that's implimented is the biggest cause of success or failure. If we build from scratch (or using open source), we can almost always pull a failing system out of the fire by throwing a few more quality development and analysis hours at it. If we buy good quality software to impliment, it works about the same. If we buy terrible software and try to impliment it, no amount of time or money can save us.

A number of times we've had a software buying decision from a PHB for some crappy system just to see the project fail. I've never seen (in my 10 years as a developer) a project fail that had good, open development behind it.

No doubt that changing requirements can make a project suffer (and keep us developers in super-overtime-mode). However, if you keep the users in check (project mgr to the rescue) and have a good in-charge developer to manage the technical side, I don't think you can get in too much trouble.

I question (1)

joeflies (529536) | more than 9 years ago | (#11257575)

what the metric for success is. In some parts of the article, it sounds like the metric for success is executing on the project plan. If the plan was a bad design, but the engineers delivered 100% on project deliverables, then the project is measured as a failure - through no fault of the engineering team or the project management team. This is a bad design that was properly engineered and project managed, but eventually didn't satisfy the requirement. You can be a full six sigma and build properly constructed junk.

In other parts of the document, it sounds like measure of success is being able to change the goal and then having the engineers adapt to the changing goals. The article calls that "innovation" but often that's pulling a rabbit out of the hat. That's bad project management with flexible design and hit/miss engineering, with time being a mitigating factor.

What I'm driving at is that I don't know if it's so easy to categorize risk nor attribute success to a one-minute drill or "embedded knowledge drivers" and "execution coordination drivers".

How long (1)

Timesprout (579035) | more than 9 years ago | (#11257577)

Before someone can finally admit they were part of a team of fuckwits who promised way more than they could actually deliver and so kicked off the cycle of overexpectation?

Please check my math (2, Interesting)

Spackler (223562) | more than 9 years ago | (#11257587)

Ok, I did RTFA (for once).

Quote1: nearly $1 trillion was wagered on underperforming projects

Quote2: A large number of underperforming projects ultimately fail

Quote3: costing U.S. companies more than $75 billion each year

How does 7% failure become a "large number" of projects failing?
I would expect 7% to fail just from bad ideas alone.

A little gloom and doom?

Interesting survey results... (2, Interesting)

glh (14273) | more than 9 years ago | (#11257604)

I find it interesting that "methodology" was the biggest risk driver for a project.

I think the true crux of the problem with software development lies in understanding requirements. A methodology will most definitely HELP find the requirements, but I don't think it's directly the biggest risk driver.

In my experience the biggest problem is getting the users engaged in the requirements gathering. This is the most critical piece- no matter what methdology you use (and they will come and go) you still need to make sure that you understand the requirements. In most business environments, software development tends to a discovery process. In some cases the users can visualize a system and what it should look like, in others they cannot and it just may take a lot longer time. In that case, expectations should be properly managed by the stakeholders. PM's come in to play and should explain what is likely to happen- requirements will change, development or design may take more time, etc. Investigate other options for requirements gathering and understand not all of it may be able to be done on paper.

I've found that most business applications work best when I have users who have had some level of experience with Information Systems, who are committed to walking through what the system should do, and have support from management to do so through the entire development cycle. Technology and development tools are usually the issue, especially if you have competent developers.

laziness and negligent behavior (3, Funny)

dj42 (765300) | more than 9 years ago | (#11257616)

In my experience, it is usually drugs, alcohol, too much sleep, unconcerned management, or a combination thereof that causes projects to fail. Have you ever tried to project-manage after 8 double vodkas, a short nap, and a full rack of ribs?

In my personal experience... (1)

papasui (567265) | more than 9 years ago | (#11257619)

It's because of poor project managers who don't fully understand the project and the marketing departments that want to change the scope of the project every 15 minutes. Much to the point that a project that had 4 months of work completed and the original project was within a few hours of being 100% completed that it ended up being outsource and later scrapped completely. Read some Dilbert [unitedmedia.com] comics, marketing departments can mess things up hardcore sometimes.

I'll RTFA in my next comment but first... (3, Informative)

museumpeace (735109) | more than 9 years ago | (#11257638)

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" [yourdon.com] 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 [amazon.com] 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:-(

project managers? (0)

Anonymous Coward | more than 9 years ago | (#11257658)

as reported by development project managers

in my experience, project managers are why projects fail.

Too much pushing paper and trying to use stupid metrics that they don't understand. The biggest concern seems to be to assign as much time as possible to non-project timecodes so that it looks like the project is going well when it isn't.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...