Slashdot Mirror
Is Your Development Project a Sinking Ship?
gManZboy writes "Everyone knows that some software development projects succeed and other fail -- the question has always been 'why'? I'm sure we all have our favorite (likely anecdotal) explanations. Well, these guys decided to actually go out there and do a formal survey, and they've got some real data on why projects actually fail (as reported by development project managers -- care to guess where 'changing requirements' ranks?). They've developed a diagnostic formula people can use to gauge the likeliness that the project they're working on right now is (or isn't) going to fail."
I used to blame "constant client requirement changes" for failed projects as suggested by my project manager.
s before signing off the budget.
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/discussion
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.
Rock that crushes, Paper & Scissors that don't matter.
So, if I know it is going to fail, do I still have to try?
DAMN YOU OCTODOG! DAMN YOU TO HELL!
Changing requirements is far less bad than a frozen spec based on overanalysis by MBAs who never spoke to customers.
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...
Fair management expectations
+ Well allocated budget
- Patch fixing firedrills
- unnecessary marketing spinoffs
+ free donuts
= success
People who sit around for months or years trying to design the perfect system. It doesn't exist. Compromise gets projects done.
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.
... did they fail or succeed?
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.
Mirror
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.
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.
but have you considered the following argument: shut up.
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.
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.
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.
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?
If a first you don't succeed, your a programmer...
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.
Article
Figure 1
Figure 2
Figure 3
So, I hope that helps as it gets slower.
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.
"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
Rich And Stupid is not so bad as Working For Rich And Stupid.
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.
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.
Mumia Abu-Jamal is *laughably guilty*. Check the evidence.
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
No, what I want to know is where "linking your project to a slash dot article" ranks.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Release managers can track requirement changes and their impact (effort, schedule) on the project. These changes can be reported separately from the primary schedule, so that everyone can see the impact of scope changes.
Change is not bad. Adapting to environmental changes (competition, customer education by early prototypes, vendor roadmaps) can make the difference between a one-shot failed project and a multi-generation successful product.
Big Visible Charts is a time-tested technique for non-political status reporting that helps everyone (from senior management to QA) take responsibility for the global impact of local changes. Grab a few unused monitors and create a wall-mounted status display with 1-minute project status updates, you'll be amazed at the results.
Yarrr!
is at least as important as managing down.
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.
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.
In group behavior: 'because they're evil/morons/sheep/crazy' is not 'insightful' it's 'oversimplified'
is to develop a sinking ship, isn't that another name for a submarine?
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
... since 1994, the Standish Group has been publishing the results and reasons of IT projects. Go here for the original report.
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.
Neurowiz
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.
It sank, and got redefined. It's now a sinking submarine.
"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.
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).
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.
Hey, I'm just your average shit and piss factory.
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)
Bel, the mostly sane.. "Of course I can't see anything! I'm standing on the shoulders of idiots." -- Me
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.
#include <sig.h>
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
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".
If you guys designed it as:
// customizations for customer1
// ... and other with similar needs!
if (featureX_enabled(customername)) {
} 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.
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?
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
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.
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?
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.
The hard truth moderation that gets no play here at Slashdot.
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?
We are one consciousness experiencing itself subjectively. Back to you with the weather, Bob!
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 comics, marketing departments can mess things up hardcore sometimes.
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.
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.
I'll suggest everybody who has not yet done so should RTF precedents for such a study...it is as ancient as it is true: Brooks "Mythical Man Month" describes the reasons projects blow up pretty well. For all the technology heaped on software development in the 30 years since the book came out, very little has changed: Software projects are complicated beasts attempted by mere humans. Steve McConnel's books will be more familiar to /. readers and his approach to project management tries to head off the "changed requirements" fiascos with a feedback and correction mechanism of frequent critical project reviews...I wonder if that actually has worked for anyone:-(
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
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.
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. :-)
The problem of poor requirements management being the leading cause of software project failure is very well known.
So well known that in addition to constantly pounding it into our heads during my Software Project Management course, the very last thing the instructor said on the last day of class was "if you take nothing else home from this course, what is the most common reason a development project fails?"
Class responds in chorus: "failure to manage requirements!"
It is hard, but as a concientious programmer, if you are not the project manager repeat after me:
THE FAILURE OF THIS PROJECT IS NOT MY RESPONSIBILITY
There. You and your self-worth can sleep now, whether it works out or not. Took me five years to work that one out.
http://pcblues.com - Digits and Wood
Is Your Development Project a Sinking Ship? YES
Researchers found that more than 80% of projects were due to the developers slacking off reading sites such as Slashdot.org. The other 20% were busy posting to the developer-friendly, productivity-munching nerd news site.
Tech, life, family, faith: Give me a visit
Could this account for the success of the open source model vs. big, flashy proprietary projects?
Think of each contributor as a subcontractor who has the authority to actually do something. Lots of well-trained eyes look at every support beam and make sure the nuts and bolts are all there.
And no one has to spend aeons in contract negotiations in order to fix an obvious flaw... Just stroll down to the hardware store for a device driver, or machine a custom widget yourself.
We start with unrealistic schedule (READ: what have management been smoking?) leads to short cuts (READ: code it first, worry later) compound it with requirement changes (READ: customer doesn't know what it wants) then wrap the whole thing up with zillions and zillions of bugs that are difficult to fix (READ: short cuts that had to be paid sooner or later...)
In the end what management estimate would take six months (which engineering insist can't be done in less than a year) took a year and a half, and is entirely unmaintainable.
A cow-orker uses the bulldozer metaphore to describe our project(s); every short cut we take is like dirt collecting in front of the bulldozer. At some point we either need a bigger bulldozer or we start from scratch...
This is caused by computer programmers knowing too much computer science and too little about the end-users' needs. This is why companies like MS succeed. If techies spent more time reading about the world at large, the technical community would be a better place as a whole.
Money sitting horded in some estate really doesn't help the economy as much as money spent. Consider my startup. I'd much rather have $5 million in revenue than $5 million more investment or loans.
I think you were tring to be sarcastic; but I think you have a very good point about how that economy works.
Interesting article. I can't disagree with its findings, though I'd argue they're of limited usefulness as the problems it notes can happen under a variety of situations.
The most unexpected result here, and the most insightful to me, is "Similarity to Previous Projects." This is a factor that I think deserves more attention - you can have a great staff, great management, and all the resources, but stick them in unfamiliar territory and your chance of failure goes up.
I don't think people pay enough attention to this factor, and thus it sneaks up on them easier than the obvious ones.
I have witnessed very talented people completely screw up an simple application because they had no previous experience with a project of that particular kind and neither did the management structure. Thus they all did their best, worked hard - and still produced a massively flawed product.
In these cases, I asked myself "How could they mess up like this when the solution was obvious." Now I realize that the solutions were obvious to me as I was more familiar with the kind of software they were trying to design.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
The lack of focus made testing difficult because it wasn't particularly clear what the testing metrics should be. A library system I know of was so overwhelmingly bloated trying to meet a variety of interoperability specs that when the testers saw some 2 megabytes of data cross the lan to handle a single checkout/checkin transaction, they didn't realize they had a problem.
Another salient feature of successful projects I've worked on is technical competence. The managers of the successful projects tended to be ex-coders and had a feel for what made sense vs what didn't. The bloated projects were run by people from all manner of backgrounds and hence, didn't have the cut-to-the-quick feel when something was going awry. One time, I was working on an air defense project for a country in the middle east and the project manager started getting antsy when he saw all his developers waiting on the compiler. We were using the machine we were going to deliver the product on and it was having a tough time just compiling code for some 12 developers. He sat down and wrote a bare-bones air defense system that did nothing more than establish a client server relationship and had the client simulate the required number of radar contacts per second while the server did nothing more than ack said contacts. The machine couldn't handle a load as simple as that which led to some back and forth with the hardware company until they upgraded the hardware to handle the problem. Had he not had the tech background, he wouldn't have realized that there was a problem until it was too late.
The number of projects failing now will probably rise because Moore's Law isn't there anymore to bail over-speced projects out. The code written today won't run any better on tomorrow's machines primarily because it doesn't look like tomorrow's machines are going to be much faster. Knocking that crutch out from underneath projects will tumble more than a few projects.
There are 300 hours allotted for the project.
32 of those hours will be spent by upper management deciding if they want the contract.
24 of those hours will be spent by the PM filling out the required cost analysis and estimate.
32 of those hours will be spent by upper management holding business meetings with the potential client to determine if the estimate is agreeable.
24 of those hours will be spent by the PM revising the estimate at the request of upper management.
8 hours spent obtaining client approval.
32 hours spent writing a project plan and summary.
32 hours spent chasing down every upper managers and QA auditors whose signatures are required on the project plan and summary.
32 more hours spent rewriting the project plan and summary to fulfill the requests of the upper managers and QA auditors.
32 hours spent researching the existing technology to support the proposed project plan and summary.
160 hours following the test plan.
Are we over budget?
32 hours negotiating with the client for more funding.
40 more hours finalizing the work.
80 hours writing up the required reports demanded by upper management, QA, and the client.
fast as fast can be. you'll never catch me.
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.
Yes, but you should be working harder on updating your resume than on the project.
//Information does not want to be free; it wants to breed.
Scores of people have investigated this in the past. A good reference is Steve McConnell's "Software Project Survivial Guide". He has a company, Construx, with some excellent tools for scoring a software project.
Is your development project a sinking ship?
( actually, I don't have a hard deadline on my current project, so eventually, I do expect it to succeed, but I am a couple of months behind my goal, from posting on slashdot too often, so maybe I've already failed... )
Which reminds me, they left off number 6: team members reading slashdot instead of working...
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.
Or spoke too much to customers??
I have had similar experiences where the sales team had promised suns and moons, and we had to slog it out to meet deadlines. And yeah, all of them were MBAs. Bastards.
How timely that this comes up. I have been reading into Software management and there are lots of books on the subject that go back to the 70's. The ones I am reading at the moment are "Agile Software Development" (by Cockburn) and "Fact's and Fallacies of Software Engineering" (by Glass). I was unable to follow the link to read what the guys had found but I have a guess it's pretty much a rehash what these other books are saying in more depth. There are a lot more books like the above out there, just search Amazon.
The books are interesting in that they show a hell of a lot of detail and history around problems of development projects. Companies like IBM have been studying the problems since the 50's. That fact that these guys have looked into it and produced yet another report shows that both programmers and managers are not looking into the volumes of books and case studies all ready out there.
I don't know whether that's +1 Insightful or just plain nuts. I've got mod points today, but there's no "Say What?!" option...
SMQ 90AE4B2BC4F6BEAF7340F0B40BA2DEF7340F6BC2D0392
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.
A Human Right
i actually was "assigned" to supervise a death march project at my last employer. my "new" manager(6th one in one year) knew the project was going to be canned(didn't confirm the inevitable to me, even when confronted), and most of the people would be absorbed into other projects or simply layed off. why was it a doomed project? politics.
someone else in our organization (at another geographical location), happened to be better aligned with the top management group, and used this to their advantage to eliminate competing projects, or in some cases eliminate the internal competition and take the projects over as their own.
of course at the time i had no idea what i was getting into(or who my "competition" was). no matter what our team did to produce a superior product, our project was cancelled for reasons beyond our control. i ended up stressing out and nearly damaged my health and my relationship...
then i read a book call Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects. i soon realized that we were set up as an ugly style project, doomed(in fact designed) to fail.
it's good to understand why projects fail, i have not yet RTFA, but i'm sure it will compliment some of the discussions/concepts in the death march book. good read.
three can keep a secret, if two are dead - benjamin franklin
CEO from CompanyA approaches CEO from CompanyB to discuss a merger. Both motivated by a common goal (make more $$ for the shareholders), they agree to the merger. Now it comes time to make their systems integrate.
.NET framework as their entprise architecture, and they use the latest version of Windows.
Upon investigation, it turns out that CompanyA uses a transaction based accounting system that updates a just-in-time inventory management system. Moreoever, CompanyA has selected CORBA as their enterprise architecture, and have specifically gone with ORB vendors A1, A2, and A3.
It also so happens that CompanyB uses a batch based accounting system that is updated every night (and twice on Saturday for some reason). They use a guy name Earl to manage their inventory of goods. CompanyB settled upon the
Do you see the problem?
Management makes decisions based upon meta-information about the business. Perspectus, and filings with the SEC are what CompanyA looks at when deciding if they should buy/merge with CompanyB. Rarely do companies look at internal systems for potential compatibility. They throw out an essentially random number that's supposed to represent "the cost of the merger" (this is what is supposed to be spent on integrating the two wild beasts), and for some reason everyone accepts that number.
In all due honesty, that's about as insane as trying to conjoin two independent grown adults.
I've seen this happen time and time again, up and down the management chain. At the lower levels, management thinks that SystemA can talk to SystemB because SystemA produces XML and SystemB accepts SOAP, not realizing that SOAP is a document retrieval / RPC mechanism and not a generic self-describing data language.
At the upper levels management thinks that CompanyA should purchase CompanyB because they're both in the tire manufacturing business, not realizing that the machinery used to produce truck tires (CompanyA's product) WILL NOT WORK to produce automobile tires (CompanyB's product).
It's the same thing over and over again. Management is often too disconnect from the innerworkings of an organization, and doesn't understand the key interaction mechanisms making them ineffective at evaluating whether a merger/buyout will be successful.
So is it any wonder why software projects fail?
Software is extremely specific (generalizations rarely work), requiring very careful attention to detail. Management, fundamentally, is at odds with this requirement. Unfortunately people believe that to be an effective manager, you must keep your "head above the fray" to "keep the team on task".
The truly effective program managers are those that continue programming after being promoted, and fully understand the system that they manage.
Do it for da shorties
What if project scores high on this - the way it is managed, but then no one needs/buys it, is that still considered a success? There were quite a few such in dotcom period...
...remember good 'ol times when IP used to mean Internet Protocol....
One result of ad-hoc software design and implementation has been government regulation of software in the financial, security and pharmaceutical sectors.
One result of government regulation has been the emergence of requirements management tools like Borland's CaliberRM and Telelogic's DOORS.
These tools trace every functional requirement back to a business requirement. They also track the risk (schedule, safety, robustness, performance) of every functional requirement to the rest of the system.
Vague specification, like vague design is an indicator of not understanding the problem. The first step towards understanding the problem is categorization of ignorance, such as unexpected consequences already experienced by the project.
Good requirements management tools incorporate practices that have been proven to flush out vague specifications. Good traceability educates upstream participants so they can produce better specs in the future. Better specs yield better products, including better spec management tools
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
I have mod points and I am not afraid to use them
http://www.poppendieck.com/construction.htm
you are unlikely to have the tracking data needed to justify your proposal (e.g. stopping/slowing changes).
You need to collect tracking data (task estimated effort and actual effort, linked to change requests) before there is a visible impact on the schedule.
Think of it as defensive data collection.
As one way to understand the difference, what's the equivalent of the halting problem, in construction? In fact, I would argue that anyone who claims that software development is like building construction is part of the problem, since you need an extraordinarily weak grasp of computing theory to believe that this is the case.
Most physical construction solves the same basic problem, and all that varies are various trivial physical properties like dimension, materials, etc. Computer systems solve a much wider variety of problems, including many entirely new ones. It's certainly not true that "every system we can dream of has been built". In fact, where we do see the same problems being solved over and over, we also see a much higher success rate - things like mainstream accounting systems are a good example. In that case, a body of domain-specific knowledge builds up over time, and implementing systems in that area becomes easier as a result. It would be more accurate to compare the construction industry to the industry which develops horizontal-market accounting packages. (Vertical market packages tend to introduce new twists that can put you right back into unexplored territory.)
This may sound obvious but software projects get in trouble when they aren't released. The usual reason for not releasing is management's unwillingness to ship software that doesn't work. What fools!
Experience shows that the marketplace will tolerate horrible performance if the user interface is comprehensive, kool and has all the expected switches, bells and whistles that may actually work someday.
So all projects should start with the GUI and worry about the algorithms later. Get those version 1.0's (user interfaces hooked up to simulations if necessary) out the door and in your customers' hands. Throw in a free year of "bug" fixes and start working on 2.0.
Hey, it worked for Bill Gates.
It's sad you work in an environment where developers do not understand the very simple concept of 'decoupling'. I am not going to sit here and expound upon the virtues of this practice because Andrew Hunt and Dave Thomas have already done this in The Pragmatic Programmer: From Journeyman to Master. If you haven't yet read this book, do so immediately. If your development staff hasn't read this book, make them. If they refuse or fail to understand it, fire them. I am convinced that 90% of our software development woes would be solved if project managers, tech-leads, and juniors alike all read and understood the concepts contained therein.
Join Tor today!
Here is a pretty good paper by Mary Shaw explaining why software is not yet an engineering discipline (IEEE). http://www.sce.carleton.ca/faculty/ajila/4106-5006 /Prospect%20Eng%20Soft.pdf/
nobody should eat sausage, or use software, if they know how it's done...
Heard this one from a former manager of mine, when I was trying to get a little more time to clean up some code...
Did the customer see an early prototype or previous incarnation of the system before signing the initial contract?
If the first prototype seen by the customer occurs after negotiation of scope, the scenario you outline is almost unavoidable (unless the product/market is well defined by existing products, in which case a custom solution probably wouldn't be on the table).
Does anyone else think they got this almost exactly backwards? Requirements volatility would be my number one issue, followed by dissimilarity to previous projects. Also, there doesn't seem to be a mention of bad resource allocation and scheduling.
It's good to use your head, but not as a battering ram.
Recall that these results are based on MIS managers' assessments, and the bias toward managerially controllable risk drivers might be a function of this stakeholder pool.
Further research is needed to determine whether other stakeholders, such as project managers or system users, share MIS directors' views, incorporate other risk drivers such as organizational politics that were not captured here.
So many of the project failures I've been on is the result of managers ignoring the risks raised by the development team.
It's funny isn't it, a full-blown software project employs managers, architects, designers, software engineers, quality engineers, configuration managers, usability engineers, technical writers, etc. but never a "requirements engineer." Worse, there are no requirements professionals, no specialized requirements engineering degrees in colleges and universities, no specialized usenet groups, nothing. Yet, requirements are one of the most critical part of the project...
The problem with so many software projects is that requirements are left to be written by people not trained in doing so. Many projects will just ask the client to write the requirements, or the project manager. But requirements are like usability (but not the same, and that's why many state that projects should start with usability tests, because they confuse those with the very similar requirements): they're critical to implementing something useful. You want to have someone with experience talk to the client and the users, and figure out what they want. Clients and users won't tell you that directly, because they're not trained in figuring it out, a trained professional must talk to them, watch them work, ask them what gives them headaches and what makes them happy, and turn these findings into requirements.
One day, the software industry will finally start giving a lot of importance to requirements and usability engineers. That day, the industry will be as successful as, well, Apple.
How about frozen specs, deadlines, and pricing set by marketing without consulting the techs to determine if the project is even doable?
Al: No, Peg. Your fat makes you look fat.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
"Is Your Development Project a Sinking Ship?"
Why yes, we make submarines. Hoo-hah!
But you do realize that all you're doing is moving around the location of "if" (should really be a switch) statements?
That's really not going to help you a hell of a lot unless you fully understand how to use objects. Even that though, is rarely the cause of failed projects.
Of the six reasons adduced for project failure, these cannot be accurately applied post facto:
. pdf/
0 1/10/1844255&tid=156&tid=9/.
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
This proof has been discussed at slashdot here: http://developers.slashdot.org/article.pl?sid=02/
I call this the 'doghouse' theory -- building software should be simple, like building a doghouse, if we could just get our act together.
No, but to imply that it is more complex than putting up a bridge or skyscraper also misses the point.
Wow, for people who like books like Tufte's The Visual Display of Quantitative Information, these guys produced a really good graphic as part of their article:
It takes a little bit of study to understand everything that it's saying, but it's an amazingly compact representation! It shows five values at once:That's an extremely elegant graph that conveys all of the most important points of the paper, and would still manage to fit legibly on a small card.
Mmmm, mmmm! Nothing satisfies like elegant design!
Ahrrrrrr! Batten down the code base, ya scurvy dogs!
I wonder how sound the methodology of this study is. The data consist of the opinions of MIS managers. Now I don't mean to claim that MIS managers don't know anything about the success and failure of projects in their organization, but they do have a certain perspective and certain interests and so may have a biased view of things. I'd feel a lot more confident of the conclusions if the study were based on a set of case studies in which they had interviewed not only MIS managers but other people involved, including the actual programmers. I wouldn't be surprised, for example, to learn that programmers think that changing requirements are more of a problem than MIS managers do.
A company I worked for had a perfectly good kettle. Sadly, between the 60 or so of us, an electric kettle would not kast long. We didn't really care. Every couple of months a company dogsbody would be dispatched to the nearby electrical shop to buy a replacement.
Then the disaster happened. They replaced it with a horrible slow oversized industrial kettle. This took forever to boil and was impossible to fill. Naturally the comapny soon went bankrupt. When I was looking for another job, I had a choice of two offers. One of them was with a company that had an identical kettle. So I chose the other. I seem to have chosen correctly. The company I rejected only had another 5 months left to live.
Is it al down to the kettle? No, of course not. Sometimes it's all about the fridge. But it's usually the kettle.
As evidence that the corollory is also true, a friend of mine works in an office that was previously used by a manufacturer for testing kettles. When the previous tenants moved out, they left several dozen prototypes behind. The company is going from strength to strength.
It's all about white goods.
The assessment leads to an "overall project risk score". And a higher "overall project risk score" actually implies a lower project risk.
Were any users involved in the design of the risk assessment tool?
It would be interesting to see such an analysis done with an open source-centric viewpoint: why open source/free software projects fail.
It would be necessary to structure the survey carefully to avoid the obvious results that don't contain useful information. For instance, Sourceforge is littered with old projects that never got past alpha or pre-alpha because no one was interested except for the project initiator (who never created enough of a start to encourage significant involvement from others), and the project initiator eventually lost interest him/herself. That may be the way in which most open source projects fail -- but that knowledge is of little use to someone running a project and looking for tips on management. There are of course books about aspects of this topic; but it would be nice if someone were to do a similar survey of open source projects that did get their legs underneath them, that did produce something that enticed involvement and an interested user community, only to eventually fail.
A fat person is anorexic because when they look in a mirror they really do see a fat person.
http://pcblues.com - Digits and Wood
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...
Don't look back the lemmings are gaining on you
Thanks mirrordot!
Tiwana and Keil were asking MIS directors what *they* thought, not project managers or developers, leading me to believe that this is more based on client perception than someone with experience working on said projects.
That said, they ranked changing requirements last when talking about risk of failure, and actually said that inappropriate methodology was the top reason of project failure.
Now, while a lack of any sort of methodology is a disaster waiting to happen, I have a difficult time believing that a bad fit for a project creates more risk than project complexity and shifting requirements combined, as they suggest.
*sigh*
Do you really believe that a client is going to place shifting requirements as a risk? After all, they're the ones asking for the changes!
If, on the other hand, you were just making up the rules as you went along because you wanted to be "flexible", then when you're looking over the smouldering wreckage of your project, you haven't got the faintest idea exactly what you did at any step along the way, much less what you might have done wrong, so all you're left with is the finger pointing, the arbitrary assignment of blame, and the promotion of the incompetant.
(Of course, when the problem with the process turns out that it was designed by moron managers who have no understanding of engineering, your chances of having management correctly diagnose the problem plummet, documented process or no...)
On a more serious note how many companies actually plan backwards? In other words this is the budget make the plan fit or else!!!!! These projects are doomed to fail!
It's written by Steve C McConnell (who also wrote Rapid Development and Writing Solid Code) and well worth it for anybody doing project management.
Rapid Prototyping.
Throw in "All Prototypes are Finished Applications" and you have the beginning of a beautiful product.
the longest website title I've ever seen.
Intel's Merced, ah um, Itanic, ah um, Itanium.
7 years on now and I still want to vent.
What a horribly mismanaged POS.
The blame was simply that in Santa Clara during the Internet boom every ranking lieutenant was more concerned about padding their resume for their next job than actually working on the damn chip.
I should have known when early in my involvement in the project we had a Validation Plan review with the Validation Czar, and he informed us that what we had just done didn't conform to the Validation Plan Handbook Version 2.
"Well, Gahsan (sp?) all we have is the VPH version 1, which we conformed to. When will the VPH version 2 be published?"
To which he replied, "Oh, it won't be published. We don't have time for that."
Arguments ensued. We lost.
That was pretty typical of the whole damn project.
The only time I felt there was truly a Captain at the helm of the ship was when Jim Miller was there. In about 3-6 months he was pushed out of the project (and eventually out of the company ~9 months later). Then we got back to the in fighting and finger pointing that promised nothing but success for that project. But, everyone's resume got a little padding.
I don't know how many times I completely designed, implemented, and tested my part of the chip, only have it totally re-micro-architectured. (I had been promoted off of validation into logic design by then.) This problem was project wide and frequent.
It was so bad, that since my part had only a few iterations, I started designing the interface to my part for other parts of the chip. "I know you didn't have time to write this. I know you said you'd get to it in 6 months. I wrote it. I hope you don't mind. Here it is. It is autonomous to the logical working for your functional unit block, but layout needs it physically in your section of the chip. I tested it. It has a simple 5 signal IO. And, it can be synthesized. No need for hand circuit design. Thanks. I appreciate this."
The best part was, since I had finished my section on time and working I got blasted in one of my later annual reviews for not working hard enough. "Maybe the reason the other guys worked so hard was because they are hopelessly behind and didn't do it right the first time. Maybe they couldn't do it right because you in management have changed what they are supposed to do multiple times on them. So, my reward for being ahead of everyone else is a bad review?" Of course, I was ready to quit by then.
Eventually engineers started to leave the project like rats on a sinking ship. But they put a stop to that. All internal transfers were frozen. So, the only way off the project became a resignation letter. Which since most of the work was in Santa Clara, wasn't a problem.
Intel should have shut the whole Santa Clara Processor Division down and moved everything to Oregon or Israel. You complain as much as you want about Willamette and P4, but at least they worked and sold. Merced was a still birth that should have been aborted.
Chris Peters (former Microsoft VP) wrote an interesting documented called "Is Your Project Out of Control". It seems to have appeared on the net in various formats.
OK so the higher the risk number, the lower the risk of the project. got it. i think.
All sigs should be as funny as possible, but no funnier.
Focus on launch from the start. Launch all the time, incrementally. Here's a few other nice pieces of advice. Read it, and then, well forgetaboutit... just do it.
Universal Elixir and Other Computing Projects Which Failed
6 86 236092
1 30 917397
3 21 117425
9 32 633609
by Robert L. Glass
(Copyright 1977)
http://www.amazon.com/exec/obidos/tg/detail/-/0
ComputingFailure.com: War Stories from the Electronic Revolution
by Robert L. Glass
(2001)
http://www.amazon.com/exec/obidos/tg/detail/-/0
Facts and Fallacies of Software Engineering
by Robert L. Glass
(2002)
http://www.amazon.com/exec/obidos/tg/detail/-/0
Waltzing With Bears: Managing Risk on Software Projects
by Tom Demarco, Timothy Lister
http://www.amazon.com/exec/obidos/tg/detail/-/0
. . . but my B.S. meter exploded. This is the kind of shit that business programs spew out.
It wouldn't have been so bad, just a qualitative redeclaration of the obvious, but then they had THE formula for risk assessment. Also, keep in mind, this study was based on interviews with IT executives, not staff or customers. I'm sure that this simply consisted of a series of bubble-sheets with a few questions on it.
I guess, this is better than nothing, but, as noted in earlier posts, common-sense is still twice as good.
Forget whatever crap they're telling you. It's all lies. ALL LIES.. If you believe it, you're setting yourself up for a hard, fatal landing on your first job. You'll start off all bright eyed and bushy tailed, believing all the stuff they lied to you about, and then one day the whole house will come crashing down around you and kill you. Or seriously maim you. Either way, you'll be toast.
The real deal is this; should you find yourself on a brand new project, a blank sheet in front of your project manager, they will start off with the best intentions. They will not repeat the mistakes of those other projects. Oh no. This project will use the latest techniques. Proper project plans. Waterfall development processes. Nail down the requirements before a single line of code is written; no! Before the first UML diagrams are drawn! The project will be on time, on budget and the best thing ever.
Oh yes, it'll start good. Then the first wrinkles show; the requirements gathering is taking too long and the customer is being vague or contradictory. Someone in sales promised a feature you wern't planing until the next version to the CEO of the customer and now it has to be in this version or they'll cancel the contract. The UML is taking to long and the external dependencies are getting too large; you have to cut back on the hardware, which means you'll need to re-evaluate the middleware and the database. Once you're one month behind schedule the project manager will produce a new gantt chart. Testing time will be cut in half, but now you're back on schedule. Once you start coding, you start to run into bugs in the middleware or tickle obscure edge cases in the database, and the vendor is taking forever to respond to the ticket, so you slip by a couple more weeks. Eventually you push a version out to testing, who discover that one of your developers made one to many assumptions about the target environment and the first version only runs properly on the development system, so it takes another week to fix that and send the second version to testing, while you get on with adding those new features the idiots in sales promised, and now you've got hundreds of problem reports queued from system test! With only two weeks to delivery your UML digrams, requirements, gantt charts and waterfall process can go fuck itself; this baby has to be out now and it must work!
It gets to the customer three months late. Then you find out that those vague requirements the customer didn't clarify...well they don't like your interpretation.
They don't teach you this in college because it would scare the fresh meat so much you'd all take up sociology instead.
Maybe they *should* be taught all the above. Then we wont have so many people who are in it strictly for the bucks. :-)
emt 377 emt 4
> 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.
Insert simplistic political, ideological, or personal proselytization here.
The reaon nearly all projects, that fail, fail, whether it is software, bridges, business transformation, or simply moving house, is inadequate risk management. Risk management is the one fundemental process that any sane PM must be able to use.
As a PM I spend around 30-40% of my time managing risk. I've never had a project fail yet
No but, yeah but, no but...
To find out how long a project will take to complete, take the amount of time you estimate the project would take in an optimal environment, multiply by two and convert to the next higher unit of measurement.
Thus, you can determine that a job you think will take a week will take 2 months.
>> we keep playing the buzzword bingo with our new systems, e.g. "Extreme programming"
Although i advocated Extreme Programming higher in the thread, i support this statement. The thing is - it's not words; it's not something you're supposed to play bingo with or talk about - you're supposed to do something.
The prime success factor of any project is always Getting Things Done.
What I find interesting is how many risk factors are addressable by good modern programming practices. Customer feedback is at the heart of the extreme programming model. Identification and encapsulation of customer requirements is also a major point in XML design practices.
Project complexity is well addressed by refactoring. If refactoring is stressed as a programming activity, the code base improves as time passes, rather than degrades. Good refactoring also heals program structure after yet another round of feature shifting. It also aids starting the project, as developers are free to start with a fairly good structure and rely on refactoring by knowledgeable developers to optimize the program structure as the project moves forward.
Formal project management processes are a dime a dozen, but good UML documentation, updated with each refactor, will go a long way to providing the structure to support any project management process.
Really, between UML design, XP style customer feedback and consistent refactoring, most of these risks are assessed. All of these feed nicely into methodology choice, leaving language and platform choices as the only factors undressed.
Well, that and the true cause of most project failures: incompetence. One factor keenly missing from the list is poor performance of personnel. In my eight years as a professional developer, every one of my failed projects can be traced to idiotic decisions made by people who should not have been given the responsibility for the decisions that were made.
Hm,
... and In contrast, a structured methodology emphasizes structure over iteration and might be more useful for managing larger projects
....
... only lack of any method, and finally there are some methods which are better suited than others or simply more performant/productive.
All headlines of the article make sense. Most of the ext written to that headlines not. Bad!
Use of an inappropriate methodology.
Most projects don't use any. Having no clue about methodology, like obviously the authors of the survey have none, thats biggest problem in software engineering.
To be successfull it does not matter wether you use RUP, Catalysis, XP or SCRUM. They only perform different and have different costs. Adapting a "methodology" well, we call it "tuning the software process" (as all modern projects are based on OO languages and OO methodologies with a few exceptions in functional programming and less mainstream projects like kernals etc.) comes long after establishing a basic process at all. (Versioning, requirements tracking, issue tracking, iteration planning)
So imho, project managers need to get a clue that there are even things which are engineering or sciense in software.
Really obvious is their lack of understanding at this two citations: For example, a methodology such as rapid prototyping relies on iteration to
Thats plain wrong! ALL our day software development methods focus in iterations or increments.
Lack of customer involvement.
I second that. However it fits my previous topic. The guys making the survey have no clue. All methodologies above require to have a strong involvement of the customer. So they rank the same poin on position 1 and 2
Lack of formal project management practices.
What is that? Depending on methodology (or I prefer still "software pricess") you plan in a different way. Milestones basically are oout. Making a milestone based plan contradicts the other points they bring up later. If requirements are changing, the featue X planned for milestone Y DEFINITELY will not be available at milestone Y as more important NEW features will have shown up. Or X became so important that it was finished much earlyer, sacrifysing some other feature.
Realy good success you make with XP and/or SCRUM. Al plans are mood if you have to manouver with high speed in hostile area where everytign shoots back at you.
Dissimilarity to previous projects.
I second that as well. However the text is weak again.
Project complexity
THAT should be rank 1! Because its the mother of all failure. Why? Thinking "we do not need a software development process" comes straight from the point of view that everything is under control because "its easy", so project owners don't see the complexity and thus not the risks.
Requirements volatility
True, but "methodologies" like XP and SCRUM craft the software development process around the fact that requirements do change. So this again makes the very first point of the survey mood in my eys. There is no WRONG method
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Usually a plan and design shows how to get to the first basic requirements while having a model that can support most directions the person is willing to go. It is the fundamental/abstract model that has to be carefully established, not the details of every part of the implementation.
Burning $15 million says nothing about why the plan failed or if it failed.
Unfortunately, better technology often has little to do with business success, but I find it not a compelling argument for the crap we see many companies put out that does not meet basic reasonable requirements.
If success is defined by your bottom line, go join Microsoft who can put anyone out of business and steal their designs without expending any effort or advancing the industry or market.
By your criteria, Internet Explorer in any version more-widely-deployed than non-IE browsers is the better browser. I disagree. I do not consider Microsoft a success, because they do little or nothing to advance the art, and destroy it in many ways. Or we should all give up programming and become IP sharks and unethical bullies. I have no use for their work, and they are extremely antisocial, however profitable they are.
The main reasons why software projects fail are:
... silly.
... he costs that much? Wow, they make more money than we do, how can I spoil his success (and by that spoil the projects success) and how can I gain benefit from rescuing the project later? :D If I tell him that SOAP is much better than CORBA he wont have people to do it :D So I can sell him two more consultants and get a bonus from my company :D and we make more money :D
a) complete lack of funding
Underestimation of complexity. Featureitis. Unable to prioritize. As soon as the underfunded project is in trouble more money is wasted by "just accepting" that it will take longer but the core bad habits of wrong priorities and adding features remains. So the cycle repeats until it fails or is finished over time and over budget.
b) underestimation of complexity
Alllreay pointed out above. Big software projects in trouble in germany, Toll Collect and Arbeitsamt (Bureau of Work/Employment) are typical examples where the project owner wanted a finsihed product in about a year. Both projects involve dozends if not hundrets of developers. Imagine, a software project of 100 man years is expected to be conducted in a year
c) Greed, jealousy, envy, distrust
Wow, there is a project? It runs better than mine? What can I do to slow them a bit? So I look better with my project in relation?
Wow that consultant from that other company
Hm, the customer has no clue
I would go so far that untrue consultants (or simply incompetent consultants who do not dare to admit that they are at the wrong place) are the most evil and one of the core reasons for project failures.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
5 x 3.0 = 15.2 ??? Huh?
6 x 1.9 = 11.6 ??? What?
7 x 1.1 = 7.4 ?????
9 x 0.8 = 7.3 ?
At least they got 1 x 1.7 and 3 x 1.5 right. Sheesh, no wonder projects fail if that's the sort of mathematical skills people have.
I've watched one particular development project for several years. I won't mention the company's name, but it rhymes with Mockheed Lartin.
I don't think they've ever had a problem with changing requirements, because the requirements were written completely without the input of the end users - they specified what THEY thought the end users should want, and then proceeded to build it and let political inertia force it on the users, despite it not being what they wanted or needed.
Your tax dollars at work...
I suspect that the risk factors would be inverted if the front-line implementors were surveyed instead of managers.
Note that those items that managers feel the most comfort changing are considered the highest risk. It's a lot easier to change the methodology than to hang tough on requirements or to say no to features that might increase complexity.
I was hired in the early 80's to spend time at a number of big UK defence contractors to identify why the software projects were all failing or being "completed" 3 or 4 years late.
... plug in humans who didn't matter because they were easily replaceable. There was little attempt to involve them in the project by asking there views on on the design or the development process. This resulted so often in the project management missing out on experience (both how to do things and how not to do them) that could have smoothed the development, as well as establishing an us-and-them division that reduced the chances of the developers responding positively to problems.
I can agree with most of the points, especially about inappropriate technologies and methodologies, but it seems that one of the most important factors has been missed completely : the human factor.
Regardless of the other factors, on the worst projects the developers were treated just as "resources"
After my work the big companies introduced formal project management methodologies and better development technologies, but this did little to change the outcomes.. The previously bad projects now had all the documentation and signed-off specs to show that everything was ok, yet still produced non-working software. The previously well run projects were now taking less time but tended not to produce all the needed documents,
The "resource" view of development so often results in applying the wrong developers to the different parts of the project. Some developers enjoy particular bits of the development and some are just good at certain things. On the converse good developers can have weaknesses in certain parts of the process but can perform brilliantly when paired with someone who is good in those areas. To find these things out requires talking with the developers as if they are people rather that resource units in MS Project. Developers can usually spot things going wrong with a project long before it shows up on the project monitoring tools, but find it frustrating that they cannot influence the management to avoid the impending problems. Too often they found that all their managers wanted were their timesheet figures, a situation made much worse if contract programmers were being used..
Paul
www.opencouncil.org
Open
One small item I;d like to add in the mix of comments is that in my opinion project management is mainly relevant to the grey mass of University sanctioned semi-competents. Genius has a way of coming up with the goods regardless. Unfortunatly there isn;t that much genius to go around, and most projects never get a glimpse of genius. Also, no self-respecting genius wants to do updates which means the even software that was touched by genius will at some point be FUBARred by a semi-competent on upgrade-duty.
- It took western civilisation 2000 years to ensure popular literacy, and now we work with icon driven GUI's. Go figure.
It's probably worth pointing out that these results would be totally unpublishable in most fields.
They approached 590 (or more) MIS directors, and got 61 responses. In the world of surveys, a response rate of 10% means your results are not generalizable. Actually, a response rate of 70% may mean that; 10% means they're garbage.
The outcome also isn't actual project "failure" or "success" -- it's what the MIS directors (or whoever actually ended up providing the information) thought were important risk factors. They do admit this, but it's not immediately obvious; and there's a big difference.
The methodology also looks dodgy, even though it's hard to make out what they actually did. They seem to have asked 60 people to each assess the risk for 12 projects, then lumped all of those back together for a "sample" of 720 (which it isn't). Then they used structural equation modeling (which was pointless -- ordinary OLS regression looks perfectly appropriate, and, in fact, amounts to the same thing) to predict the risk assessments given. And used the regression coefficients as weightings in a "tool" people might use to assess risk.
If the six risks picked a priori really are the most important ones; if the twelve projects provided are somehow fairly and equally representative of software projects in the real world; if the sixty directors (or whoever) are somehow representative of all directors; if the judgements of directors are objective, empirically based, and totally accurate; then there might possibly be some use to the tool.
As it is -- oy.
I've worked on many software projects over the last few years. Here were points of failure:
1. No source code control. Particularly a problem if there is one key engineer holding things up.
2. Your in a start up company. The sales and marketing departments in your company make a deal with a large customer. The customer changes the requirements on a weekly basis. The changes result in practically a new product being created. Later, you find out that the important customer is not paying a single dime for the project. They a jerking your chain. In fact, they might be mining info out of your company.
3. The project manager does not know jack. A paper pusher but knows the lingo. e.g.. "flow", "process", "milestone","power point".
4. Too many consultants or third parties involved. They don't want the project to end because it means no more $$$.
5. Mergers in service companies. Typically there is hacked code on a back end nobody has ever seen. The managers want to create one system. You get a hodge podge of incompatibility.
6. Lack of documentation and specs. Nobody even knows what to build or how to update/merge the systems.
OK, thats my 2 cents.
Posted by michael on Tuesday Januar 04, @04:45PM (but we are stupid enough to not type timezone)
from the down-down-down-and-the-flames-went-higher dept.
gManZboy writes "Everyone knows that some news site 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 stupid survey, and they've got some made up data on why web sites actually fail (as reported by article posting managers -- care to guess where 'changing story quality' ranks?). They've come up with a diagnostic formula posters can use to gauge the uselessness that the article has any value so we know if it is (or isn't) going to suck enough to be posted on slashdot."
Insightful Sarbanes-Oxley comment
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:
I am not ranking them in importance, will leave that to others!
Mike
---
BDOS ERR ON A:>
I maintain a groupware application for a school. One of the things to coordinate is scheduling for classes.
There's two systems: One that's currently active, and a new (vastly improved) one under development. The currently active system was initially developed by somebody not particularly familiar with relational databases, and so is very, very cumbersome to work with.
People need *something* today. We can't commit our resources to something new without providing something today for people to use. But, the current one is so kludgy and terribly designed that it takes massive amounts of time just to keep that bug-infested, terrible thing alive.
So, 80% of the available time goes to maintaining something that really should be deleted, only because the new stuff isn't done yet.
AUGH!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
In my time as a programmer I heard a lot of people complaining about requirements changes. My inclination was to say it's not the client's job to make good requirements. If the client was in a place to make non-vague requirements he probably wouldn't need your help programming them.
A good project manager will listen to the client's end user vision of the product before the project starts, and (this is the key part) during the development make the client aware of consequences of their delays or changes.
All's true that is mistrusted
Mod this reply up even if poster can't spell project. That last paragraph is right on!
The biggest one for me is:
7. Project is fucking impossible
Terrorists can attack freedom, but only Congress can destroy it.
Interesting that project managers say the factors that they are paid to manage are the ones that are most important and higher risk (and thus justify the most funding, of course).
I also think that the chosen dimensions are not orthogonal. The methodology chosen is influenced by experience with similar projects... If your architects have done something similar before, then a structured approach will be extremely effective, if they haven't, then an iterative approach as they work out how to do it.
All in all, a pointless study that will do more harm than good.
How many builders/bricklayers/electricians/cabinet makers do you know that will "moddify" the original plan or do extra work for free? NONE!
Even if you ask a builder to use bigger door handles or woodgrain, or more kitchen space, they will charge you per hour for EVERYTHING, and EVERY item. Why cant clients just get a damn clue and respect the software people.
Liberty freedom are no1, not dicks in suits.
From a requirements management point of view, the challenge is asking questions that result in testable assertions. A project is work that is bounded by a start and end date, where the end is defined by a set of testable completion assertions (functional, performance, quality).
We need not completely understand the market, but we need to understand the immediate customer to a point where a robust Q&A session with either developer or customer yields no "surprises". Robust Q&A implies sanity checks against other (markets | customers | projects | technology) of comparable complexity.
Everyone must manage up at least as much as down. That goes for the developer, release manager and even yes, the customer. Customers have customers too. We can only reduce risk and characterize uncertainty within the limits of our domain expertise. At the same time, we both educate and learn from those immediately up and downstream.
When these learning boundaries start to number in the dozens, and the system boundaries start to number in the hundreds, a good requirements management tool can perform instant impact assessment for any proposed change or discovered defect. Such a tool is the difference between saying "That's a bad idea" and "That will endanger component X, functionality Y, development path Z and customer schedule T".
News flash: software is nothing like building construction.
Helping with organizational effectiveness is our job.
BULLSHIT. Most large software development *is* much more complicated than putting up a skyscrapper.
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.
I find it funny that they didn't consider 'fundamentally a worhtless idea' one of the top reasons that projects fail.
...), the customer won't want it, and won't buy it.
Seriosuly, how many of you have worked on a project (probably you were assigned by someone who wanted to get rid of you), where you thought from the beginning of the project 'this is a terrible product?'
Even if the product ships (which is unlikely, because your coworkers probably also think the product is terrible, thus morale plummets, thus productivity plummets, thus
I currently have no clever signature witicism to add here.
Weren't we on a project together onetime.
I don't know about that, but I firmly believe that anyone who uses the word "methodology" when he really means "method" should be summarily fed to rabid minks.
Great men are almost always bad men--Lord Acton's Corollary
Anyone know what's going on at Sony's internals that this game is being so neglected? I've been playing EQOA a while now and they never update, some important quests have been broken for over a year, new content is usually god-awful quests that are taken down a week later. This article really got me thinking about this in a serious light.
A good example of how NOT to develop and maintain an MMORPG.
Related quote from a truly classic film.
Tommy: Does this suit make me look fat?
Richard: No, no. Your face does.
Oh, Chris Farley, how we miss thee.
It's interesting that everyone seems to be focussing on requirements creep (granted it's _really_ fucking annoying), whereas TFA explicitly states that the biggest risk factor is a poor choice of methodology (eg, force-fitting every project to extreme programming, or OO, or whatever the currently fashionable methodology might be). This relates quite well to what's in Robert Glass's "Facts and Fallacies of Software Engineering" (recently reviewed on Slashdot, but I'm too lazy to look up the reference). I'm not completely convinced myself, but I believe that selecting the methodology before _any_ other work starts can cause problems.
What a long, strange trip it's been.
Why do so many development projects fail?
Because the programmers spend all day reading Slashdot! Get back to work!
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.
I guess when the NWS spent 10 years planning a new weather data system and 2 years coding, it must have been super well managed!
(The 10 years were from 1985-1995. I think you can figure out the rest.)
I've been on a few sinking ships, and it is very easy to know when the ship is sinking.
The rats are the first to flee from a sinking ship. So if you see the rats getting out make escape plans.
...lack of courage...client wants to change the requirements, have the balls to charge him more and tell him the deadline's going to move. There are very few management failures that can't be nailed down to good old fashion lacking of the steel ones.
I think good programmers may be kind of rare (though I'm not sure they are as rare as we think).
However I don't think rare people are often fickle. I do think rare people are often mistreated, and mis/underused (I hope you get the gist of my combo word there) and thus leave a company in annoyance. A good person treated well will tend to stay at a company as long as the work is interesting - after all, why should they look elsewhere if they are happy? Usually events that make you leave a company like moving and so forth, are brought about by a company themselves.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Over the past five years I have successfully completed six projects for my employer that most people would consider major projects. Three of them had multi-million-dollar budgets and all of them had multi-million-dollar goals (i.e., saving the company ten million, opening up a new market that should account for 20 million, etc.)
I've been a "professional" developer for over 10 years, and a developer in general for over 20. From a technical standpoint I am generally acknowledged by my peers as one of the best around.
Want to know how those projects got done, on time, on budget, and fulfilled their requirements (and even exceeded them in some places)?
I can tell you this... there was never any formal methodology involved (although subconsciously we did follow many best-practices without even realizing it). None of these projects required any death-marches (one got a little tight at the end, but nothing crazy), and all were stunning successes in the end.
Simply put, they handed me the reigns and got out of my way, mostly anyway. I wasn't bugged daily by PM's looking for statuses. I wasn't constantly bothered by users looking for access to development work. I wasn't always called by management to discuss were the project was.
I was involved in the business analysis for all of them, although I was not primarily a business analyst, we had a "real" one of those, I just participated to keep the requirements gathering phase somewhat realistic in terms of the technology that might implement the solutions (of course at that phase you aren't focused on technology, your barely thinking about it actually, but it helps to have someone involved that knows what may or may not be possible and let the business analyst focus more on the business side of things).
Then, I did 90%-95% of the architecting of the systems. There were others involve, but the vast majority of the final decisions were mine.
Then, I did 90%-95% of the actual coding. In fact, three of the six projects I did ALL the coding on, the others I distributed some portions of work to other developers.
I then did my unit testing and handed off small pieces of the system TO ACTUAL USERS, at whatever increments I could (i.e., put something real in front of the user ASAP, even if they aren't going to actually use it in a real way immediately, you just want to keep them engaged and invested in the work). All of these projects were iterative, although I found that there wasn't a large amount of scope/feature-creep, nor was there a lot of reworking of things I got wrong. Sure, there was some of that, but it was perfectly manageable because the design phase (what I call requirements gathering plus architecting) was done pretty well.
And it is very important to point out that at virtually NO POINT IN TIME did I work more than my usual 40 hour week. Maybe a couple of 40-45 hour weeks here or there, but generally 40 hours on the button (some weeks even less frankly).
Some of the coding I farmed out to others, I even let them do some of the design work on small units of work, but it is fair to say that I am single-handedly responsible for 90% or so of all of these systems, from start to finish.
Now, I'm not saying any of this to toot my own horn. I'm just trying to make a point, which is this...
If you have talented, capable people working for you, and you let them "do their thing" and trust in them, success tends to happen. People tend not to work to their full potential when they feel people are constantly looking over their shoulder (even when they are, it should be in a non-invasive way).
Naturally, you have to find the right people, and you have to get that level of trust, which isn't usually automatic upon hiring someone, but it's a worth-wild exercise to partake. This isn't easy, but my experience is that it is worth the time, and will lead to better results than going nuts implementing some majestic methodology, forcing particular tools on people, or otherwise bein
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
You don't understand constructin and you don't understand software either as far as I can tell. You can't just stack a room on top of another room just like you can't test a single software transaction and then say the same methodology will work if that is multipled by some n For example a building was constructed, a Library, at a major Massachusetts university. The engineer who designed it didn't consider that the weight of the books was a significant aspect. So concrete started falling off. With software if you scale it things can break in a way that you will not understand later. Look at what happened with that airline during Christmas. And so I conclude is that one of the bigest problems in software is that people don't understand that scaling things doesn't work. IE: and example from C code: int myarray[100]; Well, we can add an zero to that and have: int myarray[1000]; What about just one more zero? soon we have : int myarray[100000000]; And that just probably, I am going to guess, is going to cause a resource allocation problem. You will blow up the heap. You won't be able to load your code. And then the manager asks and the amatuer software guy says: "I only added one zero" But he multiplied it by 10. And then the product doesn't work. It was just a zero.
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.
Codified thought?
I am not sure what you mean.
I picture software as data and methods. And in some cases the data is the method/process.
When you start to think of software as memory fields and a processor that works on the memory fields based upon what is in another part of memory then you start to have a better handle on how to engineer software.
Abstractions such a memory managers are a good for learning. But when you want to engineer things, you have to think of the data that is in memory, both the data that is the code that executes as a method and the data that is the data used by the methods.
You start to think about the stack and the heap and what a line of code does to the memory space. You start to think of how the process starts, how it proceeds, how it branches.
There is not thought in the software itself, but just bits and a processor or two. It takes thought to make software, but I don't believe that software is codified thought. Not even a little.
What would you then call firmware? What about hardware when a chip is burned to do things in a specific way (an ASIC)?
Oh, and a virus is an exploit of the fact that methods are really just data. You put the programm counter to an address that is supposed to be data, but it is really a method. that is what a stack overflow trys to do.
Software is more like stacked dominoes. It takes thought to stack the dominoes but the dominoes are not themsleves codified thought.
I agree there is no magic. But are you sure that there isn't just a little bit of newts feet? ; )
Some software is engineered traditionally like a bridge or a sewer.
You are build bit fields that will be read by a processor.
It is just like setting up dominoes that you then push one and the thing does what it does.
it is like putting a train on a track and then letting it run.
If you don't see it that way, then you abstract the software to a point where, yes, you can't engineer it.
Then you are a coder and a theorist and you can get things to work but only if you use tools that are created by a real engineer.
Engineering is engineering. You apply it to anything. You either are or are not an engineer. If you are not an engineer then if you do mechanics you are a tinkerer. If you do software then you are a script kiddie. Software has the same objectivity from an engineering stand point as any other technical field. The problem is that so many who say that there are software engineers are just script-kiddies with no degree or any understanding of engineering or even how memory and microprocessors work together.
And these people get rich any way. And when their stuff don't work, it doesn't matter because they have already cashed in their stock options and bought their beach front.
If they designed a bad bridge and people died from their incompetance, then they could be held criminally liable. We don't hold software up to any standard at all in most cases. If our OS stops working because of a poorly designed browser the company assumes no liability at all. They tell us it is our own fault because we didn't install anti-virus software.
Fortunately their are still parts of the software world where real engineering is required. Fortunately for the toy operating systems, like the predominate desktop OS, the worst that really happens when the stuff don't boot anymore is that the owner has to reinstall or, better, install a different OS that doesn't have the same problems.
But for software that runs real machines, heart monitors, robotics in factories, automobile control systems, there are real engineers doing real engineering and applying it to software. And this application is just as objective as a bridge or a sewer. How about the software that controls the flow of a sewer? Or the software that raises or lowers a drawbridge? It it doesn't work bad things happen. So, of course, real engineering applies to that software. But for the software that lets you watch DVD's, who cares? If you can't watch the DVD then you go and get a different player. No one is hurt.
Jealousy, that's what it is. Women have those goofy magazine quizzes, so us geeks "gotta" go out and come up with something to quiz ourselves against. "Is your project doomed to failure?", "How to drive your project manager wild.", "The 25 code tricks that get your regression testers revving.", "Lose 25 lines of code a week in three easy steps." and my personal favorite, "Are you good at passing the buck? Take our quiz to find out!".
Yeah, I got karma...
*Condense fact from the vapor of nuance*
77 Surefire Ways to Kill a Software Project ;)
The project has been going for a year, but QA is being added three months before the release date, which will *not* be missed since not missing release dates is pretty much the only thing that upper management is judged on for bonuses. No, I'm not kidding.
We've got one upper managment guy for all of IT and his prior experience was...an actuary. Doesn't want the QA, programmers and Business Analysts to *ever* communicate or have meetings since "it's not cost effective, just a waste of time. They each know their job". Classic waterfall, except there is *no process* formally put in place. None. I yearn for the old days of sneakernet when at least you knew where the *correct* code to be tested was physically located! Specs? Oh, yeah, there are plenty, many differently-named ones out in many folders on many servers; pick the one that uses the prettiest font and follow that until someone makes a new one to match the latest new requirements. Just be careful when you do a filename search because different people call the project by different names; not even the working name has been standardized.
There is no middle management. There is a project manager, (well we actually use our Business Analysts as Project Managers), but she said in our first (of three total for the project) meeting "I'm more of a conduit for communication, so I am going to stay hands-off". Wanna know who is actually running the entire project for us? Yup, the hired guns that are doing the programming.
Oh, did I mention that two months before implementation into production we have yet to receive a stable prototype? Have I forgotton to mention that as a company, we have no version control and no issue/bug tracking? Oh, and we don't get merit raises, just a match to the lower 1/4 of the salary for the position for the region.
Soooooo, do you still think you have it that bad?
It is easy to become a programmer. Pick up VB for dummies and off you go. Managers for some reason think that all programmers are the same and does not put a high enough value on experience
That I will be alotted an absolutely reasonable and appropriate amount of time to actually to complete a project. I have a dream that my ptototypes will not be scattered around the country in various states of "production". I have a dream that I will someday be able to look at a project in CVS and proclaim - that is the damn freaking good code - I am proud that my name is on this application ( and mean it ).
...
I have learned to live with disapointment this long - back to the next fire
He'd have a few experiences to share!
This technique is generically known i current project-manager-speak as Project Dashboards, referencing the instrument panel of a car. The idea is essentially what anon stated, to summarise and present progress, budget and quality level in as near to real-time as possible. For us, this generally meant at best daily rather than on a 'minute by minute' basis.
See my journal, I write things there
in the pharma world, FDA-regulation and GxP has led to a number of methodologies for formally validating IT projects - the stuff I work on is detailed down to Little Rubber Feet level - including firmware revision numbers...!
Horrible to work in if you're used to improvising projects, but essential if you're going to have 1005 reproducability and a bulletproof project.
Users come up with a formal User Requirement Spec which they sign off, IT comes up with a Functional Requirement Spec and a Technical Requirement Spec, and then formally maps using a traceability matrix everything the customer's asked for against those documents - so nothing can be left out, and the users can't say they've not got precisely what they've asked for...
All my software projects fail for one very obvious reason: I'm lazy. I spend the first year of a 2-week software project doing other things like reading Slashdot. Of course the project is bound to fail because I'm not going to start it until a year after it was supposed to be done. I'm self-employed and have very little other experience, so I can't say about team projects.
Once you have captured requirements, you present them back to the user with some difficulty estimates. This is where the 'Win98' thing you quote should get killed. You also make sure that the customer is aware that you are always thinking around the next releases too (even if there is no budget yet), so they feel comfortable with postphoning funtionality.
When changes appear (you can't dodge all of them), you make sure that the customer is aware of changes to delivery schedule and budget. Perhaps they don't really need that in 1.0?
See my journal, I write things there
Ackshly, this is a present tense - the present perfect. If you had wanted to use the past, you should have written "I was a part of a project" which would have been more appropriate.
The present perfect places the event(s) described in a stretch of time between now (because it is the present perfect) and an earlier time, whereas the simple past refers to a single event some time in the past. In this case, to get the full power of the present perfect you need to refer to more than one past project, which is beyond the scope of the simple past tense.
We have wonderful, elegant tenses and tense structures in English (although we are conspicuously lacking a future tense) so let's learn how to use them to explicitly express things other languages can only imply!
!GrammarNazi
Appreciate the history lesson. Are any of the early requirements management tools still around, in any incarnation?
Agree on the value of tracking estimates and actuals. I've not had the experience of working on a project that was mature enough to track both. But even a mental comparison of estimates with personal observation was invaluable in understanding developer strengths/weaknesses.
Do you think there is a place in the market for an open-source requirements management system? E.g. if someone started such a tool, would any home-grown tool owners contribute expertise or code?
Have you seen a good tool that is more affordable than CaliberRM/DOORS? The market seems to have an absent low end (excluding MS Office). Microsoft plans some process management for their developer tools, e.g. "Visual Studio Team System" is mentioned in a comprehensive description (with photos) of their internal build+test environment for ASP.NET.
You've just described trickle down economics.
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman
Here are some examples of the kinds of changes I have seen, all under the flag of SOX:
* No developers allowed to touch data in production systems. Furthermore, no developer allowed acounts on production boxes. You are of course allowed to use a GUI or instruct someone else to make the change...
* All code must be run through QA test plan 100% before drop to production.
Yes it's true that the purpose of SOX is to improve fiscal responsibility of comapanies. But the wording is very loose, and open to interpretation - this interprition is helpfully provided by consulting firms that decide the extent of the process changes you must implment in order for their auitors to sign of on complianes.
Because upper management is scared witless of any lawsuit against them personally, they go for the most extreme of changes without question.
I think in the long term it will be a huge incentivew for a comapny to NOT go public because of all the extra overhead you must endure to comply.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I have seen many great, fairly egoless programmers. In fact the people you describe I would say could NEVER be a great programmer exactly for the traits you describe - they could not work well in a team.
A great programmer is one that can come up with elegant designs but then can shift into an equally elegant production and support of same system. It might be good to move them around after a while but all really good programmers I have seen relish the thought of supporting a real system in production, as it is another chance to learn how a system should be changed to best meet the needs of the people using it. Real programmers are not ones that live only in the deisgn or build phase, they can and do span all worlds.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
From a customer standpoint you don't consider Microsoft a success.
From a business standpoint, would you rather be a stakeholder in Microsoft or Netscape? I think your viewpoint is jaded by your opinion of their products.
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman
...is the fact that it is a survey. I think that this type of analysis would have shed more accurate insight if outside 3rd parties had analyzed the development projects rather than having people involved with the project(with their own biases, attachments, perspectives etc...) complete a questionnaire. 1) Outside parties would have fewer biases about why a project fails. 2) The usability adage "trust what people do, rather than what they say they do" applies here. 3) There is a possibility that the people that were surveyed were major contributors to the failure, and hence should we trust their judgment?
From a technological standpoint, IE is quite bad. But from a business perspective, it could be Hello World, and it would be successful, as the years of Microsoft dominance with very bad products shows.
Or is Chinese communism an unqualified success because it serves so many people.
If you have never used anything but IE before, I can imagine you somehow feeling that IE served users' needs.
A short list that is more than a year old is found here.
Anyone with a lot of knowledge of both products or the products of other browser makers could come up with many more significant differences. It is horrible to have a Windows user telling of all his problems pleading you to come help and then you are forced to stumble through the web with IE for him because he is too short-sighted to use anything else. That is why he is on Windows with all the problems in the first place, because he was incapable of good analysis.
If IE had never existed, the World Wide Web experience of the user would be just as universal and far richer. If Netscape or others had never existed, it would be far poorer. That is the bottom line, however you want to define the success or failure of technology that has nothing to do with solid technology. What did Microsoft contribute... Active X? There is a real winner. Broken/incompetent standards support to make pages only work in IE if written by IE users? Security holes galore, generally not present in the other browsers? A monoculture (even if the technology had been good, this is a bad thing). Declaring IE a technological success is a statement about you. At Microsoft, the only real success is something that can be abused to dominate, and a rusty, infected blade seems to be of more use to them in surgury to threaten the patient than a good one, so define success in their terms if you like.
Cent 1: Poor methedology by coders. Yes, when code monkyeys :) don't comment there code, use good variable/method names, and are generally lazy they increase the overall complexity of the project making it more likely to fails
Cent 2: Poor communication. Communication between all of the players (project managment monkeys, business mangement monkeys, code monkeys, QA monkeys, and customer monkeys) is critcal to success of any project. A breakdown in communication between any of these groups is always costly and sometimes fatal. This aspect of project management is why the old "we will just add some more programmers to the project" generally just makes things worse.