Forgot your password?
typodupeerror
Programming IT Technology

Is Your Development Project a Sinking Ship? 494

Posted by michael
from the down-down-down-and-the-flames-went-higher dept.
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."
This discussion has been archived. No new comments can be posted.

Is Your Development Project a Sinking Ship?

Comments Filter:
  • by fembots (753724) on Tuesday January 04, 2005 @04:31PM (#11257219) Homepage
    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.
  • by Anonymous Coward on Tuesday January 04, 2005 @04:33PM (#11257246)
    Changing requirements is far less bad than a frozen spec based on overanalysis by MBAs who never spoke to customers.
  • I blame perfection (Score:5, Insightful)

    by Anonymous Crowhead (577505) on Tuesday January 04, 2005 @04:34PM (#11257269)
    People who sit around for months or years trying to design the perfect system. It doesn't exist. Compromise gets projects done.
  • by testednegative (843833) on Tuesday January 04, 2005 @04:36PM (#11257293)
    ... did they fail or succeed?
  • by Ckwop (707653) * <Simon.Johnson@gmail.com> on Tuesday January 04, 2005 @04:37PM (#11257304) Homepage
    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.
  • by severoon (536737) on Tuesday January 04, 2005 @04:37PM (#11257307) Journal

    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.

  • by jacobcaz (91509) on Tuesday January 04, 2005 @04:38PM (#11257318) Homepage
    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.

  • by xbrownx (459399) on Tuesday January 04, 2005 @04:38PM (#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.
  • by ag4vr (705570) on Tuesday January 04, 2005 @04:39PM (#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:So... (Score:3, Insightful)

    by kin_korn_karn (466864) on Tuesday January 04, 2005 @04:44PM (#11257395) Homepage
    Ah yes, the Heisenberg method of project management...
  • by Interfacer (560564) on Tuesday January 04, 2005 @04:44PM (#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 ;)).
  • by rainmayun (842754) on Tuesday January 04, 2005 @04:44PM (#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!
  • by Anonymous Coward on Tuesday January 04, 2005 @04:46PM (#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.
  • by Anonymous Coward on Tuesday January 04, 2005 @04:46PM (#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.
  • by Anonymous Coward on Tuesday January 04, 2005 @04:50PM (#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.
  • by expro (597113) on Tuesday January 04, 2005 @04:53PM (#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.

  • Smart People (Score:2, Insightful)

    by persaud (304710) on Tuesday January 04, 2005 @04:55PM (#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).
  • by irritating environme (529534) on Tuesday January 04, 2005 @04:56PM (#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.
  • I utterly agree (Score:3, Insightful)

    by SuperKendall (25149) * on Tuesday January 04, 2005 @04:57PM (#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.
  • by SoTuA (683507) on Tuesday January 04, 2005 @05:03PM (#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)

  • by Linker3000 (626634) on Tuesday January 04, 2005 @05:12PM (#11257725) Journal
    I used to blame "constant client requirement changes" for failed projects as suggested by my project manager.

    My experience shows this to be quite valid sometimes regardless of how much project control you attempt - a classic scenario goes like this:

    1) The customer is invited to a 'proof of concept' or 'milestone' demo of the proposed system

    2) The customer requests new features or amendments to original spec

    3) The new features are subjected to a cost/benefit analysis by both parties

    4) Customer wants the changes and so the contract clause relating to 'additional or amended requirements' kicks in and a new pricing structure is drawn up.

    5) Customer complains that they are being 'forced into a corner' with the new charges - they want everything completed but aren't willing to pay the extra but feel that if they don't agree you'll walk away from the project

    6) Developers have to decide whether to make the amendments within existing budget, even though it's additional workload, or insist that the customer covers some or (hopefully) all of the charges.

    7) Customer complains and says they won't pay - OR they agree, but you just know that at the end of the contract you'll get a serious amount of grief trying to extract the full and fair cost of the work from the customer.

    8) Customer pulls plug and takes your proposal elsewhere for someone else to work on, or you decide to cut your losses and jump ship anyway.
  • by Anonymous Coward on Tuesday January 04, 2005 @05:13PM (#11257736)
    In your example, the problem is not the sales guy. It's the PM not understanding the customer needs.

    All too often the PM is some MBA who couldn't keep his job during the .com downturn, and now makes "specs" out of a vacuum, or worse, textbooks from experts; without understanding the customers needs.

    At least when the sales guy sold a feature, you know that it's important to the customer.

  • by kpharmer (452893) * on Tuesday January 04, 2005 @05:15PM (#11257754)
    Most project management methods push waterfall development - with its huge reliance on time-consuming and error-prone upfront analysis & requirements gathering.

    Of course, they hate requirements changes. And of course, their initial requirements are usually wrong - and fail to meet the need.

    The answer isn't to stop changes - but to use methods that aren't so vulnerable to impact of change - like patterns, agile methods, passionate & highly skilled staff, etc, etc.

  • by Anonymous Coward on Tuesday January 04, 2005 @05:15PM (#11257760)
    Please share that evidence.

    I've seen companies burn $15 million in "stealth mode" waiting to perfect their product, while competors with "inferior crap" take the whole market.

  • by grassy_knoll (412409) on Tuesday January 04, 2005 @05:16PM (#11257766) Homepage
    Our most famous crash and burn ( to date ) was an attempt to migrate a number of different applications to an Oracle Applications suite.

    We expected a web based desktop client wouldn't require configuration; a jinitiator component required numerous desktop visits.

    We expected streamlined operation; In fact the replacement product required more end user data entry and provided less critical information ( i.e. fewer metrics the end users have come to expect).

    Management drank the marketroids cool aid. They should have asked the end users to evaluate the software before commiting to a purchase, rather than shoehorning the end users into accepting what was the cheapest.
  • by VeriTea (795384) on Tuesday January 04, 2005 @05:16PM (#11257769) Journal
    I would repeat after you, but what would I gain by repeating something that isn't true?

    Ok, there is a lot of truth there, but to dismiss the analogy out of hand is to miss some very important lessons. My dad manages large-scale construction projects so I know a little bit about the industry.

    Some lessons that may relate
    1. The team that designs a project is always different from the team that constructs the project. They are seldom even from the same company. The client gets to arbitrate between the two when conflicts come up.

    2. Many projects are extensively estimated after design, but before construction by the constructor (who has much more experience and motivation to accurately assess project costs then the designing company).

    3. Design firms, and construction firms often specialize in very specific types of buildings (i.e. one company may construct only clean-room facilities, another company designs only bridges, etc.). When companies take on specialized projects that they have no institutional experience with, they often fail spectacularly.

    4. The designing company divides the project design documents into known specialties. Metalwork, brickwork, glasswork, electrical work, etc. There are hundreds of catagories, and the design documents break out the project into those standard catagories. When the construction company builds the project, they hire subcontractors to perform work in each specialty. The company that does the glasswork has lots of experience with glasswork. The company doing roofing has lots of experience with roofing, etc.

    5. Changing the design in mid-construction (which always happens) cost big bucks. No exceptions.

    There are more, but I'm bored with this post so I'll stop now.

  • by MerlynEmrys67 (583469) on Tuesday January 04, 2005 @05:21PM (#11257833)
    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.

    So I worked on a project that spent 8 months getting through "project approval" on an 18 month scedule. Of course by the time it was approved, they still wanted it to be delivered in 18 months (from the start date) so we now had 10 months on an 18 month schedule.

    Long story short - we delivered in 13 months, and were blamed for being late... Nothing like marketting and management not taking any blame for taking 8 months to approve the beginning of the project

  • by jeillah (147690) on Tuesday January 04, 2005 @05:23PM (#11257863)
    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...
  • by BobPaul (710574) * on Tuesday January 04, 2005 @05:27PM (#11257913) Journal
    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.

    What planet are you from? If you tell the customer it can't be done for this that and the other reason, you're more likely to get canned as they move on to another consulting firm that can get the job done.

    Even in this day and age, most people see software as a magical phenomenon that can do anything provided the magician is powerful enough. Telling them "no" means you're but a lowly apprentice.
  • by Anonymous Coward on Tuesday January 04, 2005 @05:31PM (#11257946)
    I wonder if that actually has worked for anyone:-(

    The risk based spiral I read about in Rapid Development many years ago has done the job for me (I rarely deliver late). Any changing requirements come in a later version and after an early version is available the customer has a lot more focus on what they actually want (because its an impossible task for them to know before development begins).

    Risk based spiral also catches gotcha operational problems early on and forces me to be more formal with the release/unittests. It also keeps the customer onside since they see the project evolving. Any changes are fine and are all part of the process. Although this is only for small projects and YMMV as ever.
  • by persaud (304710) on Tuesday January 04, 2005 @05:33PM (#11257962)
    Fork the spec for query building into two sections.

    One where real requirements analysis yields the top ten most valuable and requested queries + report templates. This can be handed off to a designer who creates an efficient and highly usable interface.

    The second spec is for a generic ad-hoc query and reporting mechanism. Since the need is so very generic and so very unpredictable, prudent analysis concludes that a buy solution would be more practical than a build solution. Therefore, buy a generic reporting solution like Crystal Reports to meet the generic needs of the generic spec.

    Finally, create separate cost, development and user feedback tracking for the two reporting subsystems. Review at 3-month intervals.

    The winner will be clear sooner rather than later.
  • by mpcooke3 (306161) on Tuesday January 04, 2005 @05:44PM (#11258071) Homepage
    Yet we keep playing the buzzword bingo with our new systems, e.g. "Extreme programming"

    Hang on! The whole point of XP is about the fact that customers change their mind and developers never get it completely perfect in the first draft. XP promises a schedule based on the last one or three week iteration so it inherently remains accurate over time.

    I've been doing XP properly for about 5 years and it's one of the reasons the company i work for has survived. Massive code changes have been neccessary as we've pretty much changed the product into an entirely different one that is now profitable with the aid of an agile process and tools + those 1500 unit tests.

    Please don't blame XP just because it doesn't fix mega-death-march projects overnight or because it's a buzzword used by people who have never even written a unit test let alone pair programmed.
  • by Systems Curmudgeon (573857) on Tuesday January 04, 2005 @05:45PM (#11258079)
    Of the six reasons adduced for project failure, these cannot be accurately applied post facto:

    Use of an inappropriate methodology: Had they used a different methodology, they might have simply stumbled on different "gotcha's".

    Lack of formal project management practices: This reason means they know a number of issues got out of control. They do not know how much more those issues would have been controlled, nor how much additional control might have slowed progress.

    In addition, the "Requirements volatility" category begs a big question: requirements DO change over time; how is this category different from "Lack of formal project management practices" that would have planned for requirements changes?

    It is interesting that "Project complexity" falls low on this list, because it is the most clearly proven reason why project plans fail. See this website for a fairly formal proof that project complexity cannot be estimated in advance: http://www.idiom.com/~zilla/Work/Softestim/kcsest. pdf/ [idiom.com]
    This proof has been discussed at slashdot here: http://developers.slashdot.org/article.pl?sid=02/0 1/10/1844255&tid=156&tid=9/ [slashdot.org].
  • by archilocus (715776) on Tuesday January 04, 2005 @05:55PM (#11258170) Homepage

    I'm working for a large Telco doing roughly 80-120 IT projects every calendar year worth about $200M. Most of them get through in one way or another, but some fail spetacularly and all of them have ridiculous overheads, delays and frustrations.

    Best example of a crash-and-burn is a transaction engine designed to process a simple text file from another company. Should have been 6 months/$500K, project actually folded at 2 years / $3M and now we're going round for a second bite at the cherry (but with a new project name!!!).

    Why do they fail ? Lot's of reasons.

    Sometimes the user's requirements are unclear. Sometimes we're using the wrong spanner for the job. Sometimes the team loses the plot and we get a jumbo jet when we wanted a paper air plane. And we're always under pressure on time, but that's business - if we don't get there first someone else will.

    What's the root cause?

    Complexity. We let our systems get too complex and now a two line code change can cost >$500K because the down stream effects will hit ten other systems that generate $1M/day of revenue.

    The moral - KISS. Use the simplest solution for the job. Don't let the sales guy run away with it, don't let your geek-ego run away with it, don't let the user's get over excited and your project might just come in on time on budget. As someone else said... it isn't rocket science... or shouldn't be...

  • After I RTFAed... (Score:5, Insightful)

    by Eneff (96967) on Tuesday January 04, 2005 @05:57PM (#11258191)
    Thanks mirrordot! [mirrordot.com]

    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!
  • by FriedTurkey (761642) * on Tuesday January 04, 2005 @06:10PM (#11258328)
    Therefore, buy a generic reporting solution like Crystal Reports to meet the generic needs of the generic spec.

    Using a integrated/seperate application is often not an option. Crystal Reports will often cost more time creating custom reports than just building a tool yourself. I always lie to clients and say "I don't know how to do Crystal Reports" despite doing many more than I would like to remember. Crystal Reports often require a lot of time to do outside a simple report especially when you get into nested reports and such.
  • by Anonymous Coward on Tuesday January 04, 2005 @06:12PM (#11258359)
    A reading from the Book of PMBOK. Praise be unto PMI to whom all praise is due.

    "The project manager is ultimately responsible for the success or failure of the project."

    Simply put, a project manager is responsible for managing everything from budget to quality to scope changes to communication to record keeping and personnel. If the project fails it is because the project manager did not step up to the duty of changing whatever needed to be changed in order to get the project done. And, yes, I'm a full time professional project manager and have been for the last 15 years. Project management isn't for everyone. It's not easy, it's not an extension of being a coder or network engineer (though I was both in former lives), it's an entirely different discipline.
  • by Mr_Huber (160160) on Tuesday January 04, 2005 @06:13PM (#11258366) Homepage
    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.
  • Correct (Score:3, Insightful)

    by sg3000 (87992) * <sg_public@NoSpam.mac.com> on Tuesday January 04, 2005 @06:21PM (#11258433)
    > management tries to replace good ol' fashioned thinking with
    > process

    That's because that's what they teach in business schools. Businesses are about repeatability and consistency. It's good if you can make a cup of coffee. It's great if you can sell a cup of coffee for more than it cost you to make it. If you can make a good cup of coffee and sell it profitably one million times, you have a healthy, sustainable business. Obviously, the third action requires a process.

    That's why sometimes people make a distinction between management and leadership. Management is about incremental cost reductions and process improvement. Leadership is about changing directions and determining new courses of strategy.

    The problem is managers often confuse themselves for leaders and leaders confuse themselves for managers. That's why many start-ups fail: the person who started it had great leadership skills (coming up with a new idea for a product), but poor management skills (taking that product and building a sustainable business out of it).

    Management is always looking for a process. The problem is creative people can feel stifled by the process and poor performers can hide behind it. A good idea is to have a mixture of people (managers and leaders) in different roles so you have elements of strategy combined with repeatability. Obviously to do that you have to have effective teamwork and people that can get along with each other. I think the relative scarcity of all those elements (managers, leaders, teamwork) is the reason why failure is so common.
  • by Anonymous Coward on Tuesday January 04, 2005 @06:21PM (#11258442)
    Go read! Better than that, get a university degree. The more liberal the better. Honestly, it is worth it.

    Yeah a good old liberal education. That's the ticket!

    Then there'll be no need for stringent project requirements. Your design committe can concentrate on making sure the user interface is esthetically pleasing, non-offensive, accessible to the visually challenged, the mentally challenged and all other differently-abled beings regardless of their gender and sexual preferences, culturally neutral, politically correct in all ways, environmentally friendly and completely sanctioned by the UN and Amnesty International and Greenpeace.
  • by LWATCDR (28044) on Tuesday January 04, 2005 @06:37PM (#11258581) Homepage Journal
    Of course they are not all standardized but MOST are. And the ones that are on time and on budget and complex are.
    Even if you do build it yourself unless you are a complete moron or a glution for punishment you will standard sized windows, doors, electric outlets plumbing fixtures... and so on.
    And it may not be possilbe to build what ever you want. In many contries they are very very strick about building codes. In many places in the US you have all sorts of rules.
  • by SunFan (845761) on Tuesday January 04, 2005 @07:07PM (#11258838)
    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.

    Thanks for trivializing a large part of our economy. Think about all the details in contruction, down to interior design, financing, legal compliance; do you still think it is less complex than software? The main difference between construction and software is that people don't have much of a problem mortgaging a house, but no one I know would want to take out a mortgage for software! Yet, a software system can cost more than an entire office building! People just have not come to terms with the true cost of what they want. People who would gladly pass up granite counter tops and stainless steel refrigerators still demand all the latest codecs on their new Best Buy wonder machine.

  • by Eneff (96967) on Tuesday January 04, 2005 @07:19PM (#11258964)
    I think all developers expect some measure of volitility. I think the bigger problem behind requirements volitility is "the customer isn't sure what they want, and can't express what they do want to the developer."

    Now, the researchers seem to account for that in "lack of customer involvement." However, where is "We just assumed it would do that!" placed? It touches complexity, requirements volitility, and customer involvement.

    It also depends on how you define failure. Does an extra six months added to the project count as failure because it wasn't on time due to changing requirements? Or is a project that shifted focus mid-project a success even though the timescale changed?
  • Mmm. (Score:3, Insightful)

    by mwillems (266506) on Tuesday January 04, 2005 @07:30PM (#11259070) Homepage
    Well, maybe as an engineer as well as a senior manager and a CTO, I can add my two cents' worth.

    First, a survey based on data "as reported by development project managers" is suspect to a high degree. Obviously their view will differ from that of the senior manager and from the actual developer. SO I will put little stock in that survey.

    But the question is valid: why does it always fail?

    Personally, I see a mixture of the following:

    • Management lack of technical knowledge, or "How can you ask someone to manage a development project when that person is the sort of person who does not even know how Excel works?" This leads, of course, to wildly unrealistic expectations: which is the prime cause of failure. The emperor has no clothes and spending 100k on Siebel will not make your company suddenly efficient!
    • Developer lack of discipline - a real biggie. "We do not need to write specs, that does not apply to us: we need to design it as we go", how often have I heard that, as well as "Hey, even MS is always late so we're not doing badly only being 6 months late". There's also Blaming Others: "if you had not asked us to also fill in time sheets/come to a company meeting/etc we'd have been on time".
    • Developer lack of business understanding. The world is complex and guess what, it ain't ideal. Success in business is about being somewhat less inefficient than the competitor. It's not about being left alone for six months in a clean environment without intrusion.
    • Lack of specs (which leads to mission creep immediately), or overanalysed specs: both of these kill a a project quickly.
    • Lack of process around implementation and testing. Sorry - you do need progress reports, test sequences, checklists, code reviews, etc.


    I am not ranking them in importance, will leave that to others!

    Mike

  • Re:Traceability (Score:3, Insightful)

    by frank_adrian314159 (469671) on Tuesday January 04, 2005 @07:37PM (#11259141) Homepage
    Vague specification, like vague design is an indicator of not understanding the problem.

    It may also be that the market is not completely understood and, as such, neither is the solution. If you can say you completely understand any market, you are a better man than I. Or maybe you have the luxury of ignoring your market.

    Bottom line, I believe that there is a certain amount of understanding beyond which trying to understand the problem further is wasted effort. This point is reached far before the amount of uncertainty or "lack of understanding" reaches zero. It happens even sooner in rapidly shifting knowledge domains or markets. Unfortunately, that's also where the most profitable use of software lies.

  • by Anonymous Coward on Tuesday January 04, 2005 @08:23PM (#11259508)
    Projects work best when done by a small team with a strong vision. Even if the small team is a team-within-a-team. You can add project managers, junior coders, analysts, other support people, etc. But when the project gets moving, no matter how many people on the team it seems like it's always the same three or four guys who are doing the lifting. And they become very good at humoring the project managers.
  • Scary! I'd say we must work at the same place, but this pretty describes large software development efforts everywhere.

    Particularly the "framework" bit - this sort of thing is a particular pet hate of mine. Why do people do this kind of thing continually when it almost never works? Why not just solve the direct problem instead? I have seen it over and over again. People seem to miss the obvious point that solving the class of problem is always going to be an order of magnitude (at least) more difficult that solving an instance of the problem - and you need an appropriately large budget to do it. The final nail in the coffin for the "let's build a framework while we're at it" lunacy is that the "framework" often ends up providing a solution to something that didn't even need doing in the first place - it's just something someone thought might be useful early on. I can't count the number of times we've ripped the bloated, buggy, badly designed, unusable "framework" out of a system and it's then become reliable, simpler, smaller, more efficient, and more extensible and flexible (those two points are often the reasoning for the "framework" in the first place, so it's ironic how that works out).

    Sigh. "Frameworks" - it's my anti-pattern of the year. Or maybe decade, or even career. That's not to say it can't be done, it can of course, but only with lots of time, money, careful thought, planning and exactly the right people - certainly not as an off-hand skunkworks inside some other project with no clear purpose or direct problem to solve.

  • by tallbill (819601) on Wednesday January 05, 2005 @01:12AM (#11261180)
    You link in a ten year old article and this is supposed to be relevant? Software Engineering suffers because software can be made to seem to work and managers see it and say: ship it. They can't get away with this in construction or in electionics. But software is not as mature a discipline. But engineering for quality is a very important thing to do. And engineering is not something that software schools tend to teach. Why? Because anyone with a brain in their head went out and got rich. And they didn't care about doing things as engineers because they got seduced by the money and the stock options. The best software engineers, as far as I can tell, are the ones who were trained in another engineering discipline and then moved over to software. And then there was a whole generation of software accedemics who got seduced by the money and tried to patent their way into an easy retirement. They acted like experts and know it alls and stood in the way of real engineers trying to do real work. But engineering when applied to software has very strong results. It might not make people rich and so managers aren't interested. In software often when things are not engineered the software doesn't work. No big deal. In Civil, Electrical, and Mechanical engineering if things don't work correctly often times it means that people die, the building falls on them, they get electricuted. Fortunately there are what are known as real-time software engineers. And these are the people who do real software engineering. They aren't just trying to push through standards that they have patented clandestenly so that they can get royalties. The greed of the first generation of software engineers is why software engineering suffered. These people got rich, cashed in, and then got out of the business.
  • by mpcooke3 (306161) on Wednesday January 05, 2005 @05:32AM (#11262046) Homepage
    I don't know any real XPers that say "no other process can work". Many XPers are rightly concerned that some people claim to adopting XP without doing all the practices and then slag it off when it doesn't work.

    In fact most of the XPers I know are also interested in other Agile processes.

You are in a maze of little twisting passages, all different.

Working...