Beta
×

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

Thank you!

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

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

Why New Systems Fail

samzenpus posted more than 5 years ago | from the read-all-about-it dept.

Businesses 140

bfwebster writes "Over the last forty years, a small set of classic works on risks and pitfalls in software engineering and IT project management have been published and remained in print. The authors are well known, or should be: Gerry Weinberg, Fred Brooks, Ed Yourdon, Capers Jones, Stephen Flowers, Robert Glass, Tom DeMarco, Tim Lister, Steve McConnell, Steve Maguire, and so on. These books all focus largely on projects where actual software development is going on. A new book by Phil Simon, Why New Systems Fail, is likewise a risks-and-pitfalls book, but Simon covers largely uncharted territory for the genre: selection and implementation of enterprise-level, customizable, off-the-shelf (COTS) software packages, such as accounting systems, human resource systems, and enterprise resource planning (ERP) software. As such, Simon's book is not only useful, it is important." Read on for the rest of Bruce's thoughts on this book.Phil Simon has written a long-needed and long-overdue book. Most risks-and-pitfalls book in the IT category focus primarily on projects where actual software engineering is the principal activity. However, many of the large, expensive and often spectacular IT project failures over the past 20 years have little to do with software design and development. Instead, they involve a given organization selecting and implementing — or trying to implement — a commercial off-the-shelf (COTS) software package to replace existing legacy systems, either homegrown or also commercial. The reasons for such a move can be many: standardizing IT and data management across the enterprise, seeking new functionality, retiring systems that are no longer supported or supportable, and so on. By so doing, the firm (usually rightly) thinks to avoid the risks and expense of from-scratch custom software development. However, the firm (usually wrongly) thinks that such a project comprises nothing more than installing the software, training some users, converting some data, and turning a switch. A quick search on the terms "ERP" and "lawsuit" shows just how mistaken that idea can be.

Simon's book is far more informative and instructive than a Google search and should be required reading for all CIOs, IT project managers, and involved business managers prior to starting any such enterprise COTS project. He covers the complete lifecycle of such projects, starting with the typical expectations by upper management ("Fantasy World") and following it through system selection, implementation, and production, along with a final section on how to maximize the chances of success. Along the way, he uses several real-word case studies (with names changed), as well as a few hypothetical ones, to demonstrate just how such efforts go wrong.

What Simon writes is spot on. For roughly 15 years now, my primary professional focus has been on why IT projects fail. I do that both as a consultant (brought in to review troubled projects to get them back on track) and as a consulting or testifying expert (brought in to review troubled or failed projects now in litigation). I have reviewed hundreds of thousands of pages of project documentation and communication; I have likewise traced or reconstructed project histories for many major IT projects, including enterprise COTS projects. It's clear that Simon knows exactly what he's talking about and knows where all the bodies are buried.

The book itself is very readable. Simon's tone is conversational and a bit humorous; he occasionally dives into technicalities that would be lost on upper management, but always comes back to basic principles. The real-world and hypothetical case studies will have those of us who have been on such projects nodding our heads even as we occasionally wince or shudder. His coverage is exhaustive (and at times a bit exhausting), but his goal appears to be to give those managing and overseeing such projects the information they need to navigate the shoals. He goes into detail about COTS pitfalls such as project estimation, vendor selection, use of consultants, group responsibility, integration with legacy systems, data conversion, and report generation.

The first section of the book covers how and why firms decide to initiate a major COTS project. Besides the "Fantasy World" section that compares management expectations to what really happens, the book also covers why firms hold onto legacy systems, why they buy new (replacement) systems, and how they can (or should) make the decision among building a custom system, buying a COTS system, and "renting" enterprise software via a web-based software-as-a-service (SaaS) vendors such as Workday and Salesforce.

The second section covers COTS system selection. The book divides current ERP and COTS vendors into four different tiers based on company size and use (e.g., SAP, Oracle and BaaN are all Tier 1) and warns of the, ah, enthusiasm of vendor salespersons. (Old-but-still-timely joke: What's the difference between a used car salesman and a software salesman? The used car salesman knows how to use his own product and knows when he's lying.) The book then raises up front an issue often left (by customers) until much later: how will business processes change as a result of the COTS system we're acquiring? It then talks about selecting, if necessary, a consulting firm to help with the installation and project management.

The third section covers the actual COTS implementation process, including the overall strategy, roles and responsibilities, providing the necessary environments, data migration, testing, reports, and documentation. This section is a bit exhausting at times, but it is critical for exactly that reason: far too many firms launch into a major COTS acquisition without fully realizing just what it will take to get the system into production.

The fourth section briefly deals with life after implementation. In theory, one of the reasons a firm buys a COTS system is to avoid doing its own maintenance and support; the reality is that the firm often doesn't like paying those large annual maintenance fees and instead goes off on its own path, which is seldom a good idea.

The fifth and final section talks about how to maximize the chance of success in a large COTS implementation. This section builds upon the rest of the book, which has provided suggestions along the way. In particularly, it talks about how to deal with a troubled project mid-course in order to get it back on track.

Throughout the book, Simon puts a significant focus on human factors in project success and failure. He identifies issues such as internal politics, kingdom-building, reluctance to learn new systems, internal project sabotage, end-user resistance, and staff allocation. Simon divides firm personnel assigned to work on the COTS project into four groups — willing and able (WAA); willing but not able (WBNA); not willing but able (NWBA); and neither willing nor able (NWNA) — and talks about how each groups helps or hurts. Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All. Again, those of us who have been on major IT projects, particularly those involving COTS implementations, will recognize both sets of categorization and the risks they entail.

While Simon is himself a consultant, he is also quite frank about the role consultancies can play in COTS project failures. In particularly, he notes the tendency of consulting firms to underestimate project duration and cost in order to win business, as well as the frequent unwillingness to point out risks and pitfalls to the client, particularly if they represent something the client wants to do.

My few complaints with Why New Systems Fail are mostly production-related. Simon self-published the book; as such, the book's internal layout and graphic design leaves something to be desired. Likewise, his organization and prose could use a bit of editing in spots; he has a propensity for throwing in terms and abbreviations without clarification, and the technical level can vary within a given chapter. Almost all of his footnote references come from Wikipedia; his bibliography is small (just four books) and cites only Brooks from the cadre of authors listed above. None of this makes the book's content any less important or useful, but some of the very people who should be reading this book might well skip or skim it for those reasons. My understanding is that Simon is working on finding a publisher for the book, which will likely solve all those problems.

In the meantime, if you or someone you love is about to embark on an enterprise-level COTS project, get this book; I've added it to my own short-list of recommended readings in software engineering.

You can purchase Why New Systems Fail: Theory and Practice Collide from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

140 comments

Sorry! There are no comments related to the filter you selected.

This story... (1)

jornak (1377831) | more than 5 years ago | (#28706565)

... is literally full of fail.

New Systems Fail Because... (1)

SolarStorm (991940) | more than 5 years ago | (#28706575)

the users dont understand what I write!

users? (0)

Anonymous Coward | more than 5 years ago | (#28706577)

most new systems fail because the user doesn't read what he is doing, and then they blame it on the system

Too Many Words in Sentence (0, Offtopic)

Haffner (1349071) | more than 5 years ago | (#28706585)

"Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All" should read as "Similarly, he identified the four types of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All"

Re:Too Many Words in Sentence (0)

Anonymous Coward | more than 5 years ago | (#28706907)

That's actually the same number of words in both versions.

Re:Too Many Words in Sentence (0)

Anonymous Coward | more than 5 years ago | (#28707077)

Congratulations, you can count. I hope your achievement was worth it.

Re:Too Many Words in Sentence (0)

Anonymous Coward | more than 5 years ago | (#28707869)

Anon doesn't achieve anything. /smirk

Re:Too Many Words in Sentence (1)

FishWithAHammer (957772) | more than 5 years ago | (#28707301)

Except that there very much is a fifth. A good project manager enables his people to get their jobs done more effectively, and shields them from administrative bullshit.

Just because your PMs have sucked doesn't mean the rest of us haven't worked for great ones.

Software Projects vs. Traditional Projects (4, Interesting)

religious freak (1005821) | more than 5 years ago | (#28706607)

I was discussing with a friend how software projects are probably the most difficult to run and predict, especially with very large projects. He disagreed and said that all large projects are difficult - when you're building a bridge a multitude of things can and do go wrong.

That's obviously true, but how many bridges never get finished compared to the number of software projects that never get finished? It seems project management is very difficult for IT related stuff. So am I just being IT centric in thinking our projects are more difficult than most?

Re:Software Projects vs. Traditional Projects (1)

characterZer0 (138196) | more than 5 years ago | (#28706779)

Simple. If you build a bridge, and it falls over, you have just wasted a lot of money in materials and labor that you have to reinvest. Plus you have to dispose again of the broken bridge. It is worth it to have a reasonable schedule and proper design.

If your software fails, you just fix the bug and recompile. It simply makes economic sense to rush it out the door.

Re:Software Projects vs. Traditional Projects (3, Insightful)

Splab (574204) | more than 5 years ago | (#28706927)

Not quite, you could do the same with a bridge, if parts of it collapse you can rebuild it.

The reason why software is so buggy is no one is being hold responsible. Software is the only product out there where catastrophic failures are accepted and people happily sit around waiting for new stuff.

If a bridge fails, some contractor is going to lose a lot of money, if someone is killed in the process they will be out of money (most likely). If software fails people just get a new update.

Re:Software Projects vs. Traditional Projects (2, Interesting)

Splab (574204) | more than 5 years ago | (#28707317)

And just to add to my own post (give us a friggin edit slashdot!), EU is currently working on adding the same form of guarantee for software that hardware manufacturers has to supply, this means, any bug found within 6 months of purchase has to be fixed within a reasonable time (rule of thumb, 4 weeks), if not the customer has option of full refund.

This will probably mean:
1. Software is going to be a heck of a lot simpler, most stuff I've worked on where things didn't go according to plan is the scope of the project.
2. We are going to see a lot of specialized shops out there, when you build a building you will usually have a contractor with a lot of sub contractors for doing the actual construction - the same will hold for software.

I think this is a very good thing, this will require software to adhere to a common API (for the specific type of work you are doing), just like any other handyman work.

Now some specialists out there are going to claim BS, but think about it, construction was a maze until people settled on some key standards, the same will happen in our line of work, we are currently seeing the end of the wild west for computers.

Re:Software Projects vs. Traditional Projects (1)

dougisfunny (1200171) | more than 5 years ago | (#28708505)

I wonder if they'll do the same thing for laws. If its bad, it has to be fixed or repealed.

As for what it would mean, I doubt you'll see simple software, or subcontracting.

But you will likely see larger legal departments, they have to account for things.

Huge EULAs that state the software is guaranteed if you click X, Y, Z, in that order any other use is not permitted and may cause damage. Similar to the safety signs on curling irons "For External Use Only" which don't make it any safer.

Re:Software Projects vs. Traditional Projects (3, Insightful)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#28708551)

Probably a pretty good way for big vendors to squelch small and/or FOSS competitors. I'd be very nervous about the possibility that this mandate will end up requiring very little actual quality, documented and legally vetted in incredible breadth and depth, which would perfectly serve the interests of incumbents...

Re:Software Projects vs. Traditional Projects (1)

dougisfunny (1200171) | more than 5 years ago | (#28708771)

Microsoft Windows 8
EULA:
Not for use as a personal flotation device.
Do not ingest.
Do not use.

Re:Software Projects vs. Traditional Projects (1)

mikael_j (106439) | more than 5 years ago | (#28707379)

Except there are plenty of software projects where the original project is a huge mess due to poor planning, impossible deadlines and all the regular management issues that it ends up taking less time rebuilding the whole thing than it would to "just fix the bug and recompile", I've been involved in a couple of them myself.

What's disturbing is how a lot of people in management don't seem to realise what a waste of money this is, if the developers say it's gonna take three months to build it's probably not a good idea to say "ok, you've got two months" and then when the developers say "this new version will take at least two months" you probably shouldn't tell them they've got one month...

/Mikael

Re:Software Projects vs. Traditional Projects (1)

dave562 (969951) | more than 5 years ago | (#28707815)

Not only should not short change the developers, you should probably give them even more time. If they say they need four months, give them six. That leaves some leeway for the often frequent delays that most rookie project managers and developers fail to account for. If you come in ahead of schedule then you look good. When I was a consultant, we would always overbid our hours. Given the choice between coming in under budget, or having to go to the client with delays and ask for more money, the choice was obvious. It's a difficult strategy to use when starting out and you're hungry for work. But once you have a few successful jobs under your belt, the word of mouth buzz is good. You become, "The guy who did it in 25% less time than he said it would take."

Re:Software Projects vs. Traditional Projects (3, Insightful)

Rastl (955935) | more than 5 years ago | (#28708161)

People are taken out of the equation when it comes to bridges. You don't have to teach people how to use *your* bridge since the use of a bridge is the same regardless of which bridge they use.

People are the main reason why I see projects fail. Incomplete/incorrect requirements, artificial deadlines, glory seekers, scope creep, poor training, process change, resistance to process change, etc. These are all variables that don't have to be considered when building a physical structure.

And unfortunately they're also variables that aren't given enough consideration in the project from start to finish.

I'm currently waiting for my company to replace the system at the heart of our IT support functions. The one we've built around our business processes for the last 9 years. The one they honestly believe can be replaced by a Big System in about 2 months. And they wonder why I drink.

The really sad thing is that the system they're dead set on replacing isn't broken, is still in active use out in the wild, is off the books, and has no real reason for being replaced except for a manager who wants to put his name on the replacement project and his manager who is convinced that since the system isn't one of The Big Three we shouldn't be using it any more.

Re:Software Projects vs. Traditional Projects (5, Insightful)

MightyYar (622222) | more than 5 years ago | (#28706825)

how many bridges never get finished compared to the number of software projects that never get finished?

All bridges are essentially "open source". Plenty of bridges have failed, but the failures are right out there in the open, ready to be studied by anyone who wants to build another bridge.

In contrast, when a company's software project fails, the only people who learn from it are the ones involved with the project.

Re:Software Projects vs. Traditional Projects (1)

hemp (36945) | more than 5 years ago | (#28707045)

In contrast, when a company's software project fails, the only people who learn from it are the ones involved with the project.

And a lot of times, the ones involved don't learn from it either, but merely continue on their merry way selling their consulting services to the next client.

Re:Software Projects vs. Traditional Projects (1)

dkleinsc (563838) | more than 5 years ago | (#28707205)

In contrast, when a company's software project fails, the only people who learn from it are some of the ones involved with the project.

You make an incorrect assumption, namely that all those involved in the project will learn anything. Least of all the guy who decided to start the (possibly completely doomed) project with insufficient time available for things to go wrong, who has managed to successfully blame the failures completely on his most junior subordinate.

Re:Software Projects vs. Traditional Projects (1)

davek (18465) | more than 5 years ago | (#28707407)

All bridges are essentially "open source". Plenty of bridges have failed, but the failures are right out there in the open, ready to be studied by anyone who wants to build another bridge.

I'm afraid I can't understand your analogy. Perhaps if it were in terms of a car design failure...

Re:Software Projects vs. Traditional Projects (1)

MightyYar (622222) | more than 5 years ago | (#28707483)

I'm afraid I can't understand your analogy. Perhaps if it were in terms of a car design failure...

There's a good one, but that would lead to a discussion of presidential politics :)

Re:Software Projects vs. Traditional Projects (1)

genner (694963) | more than 5 years ago | (#28710565)

I'm afraid I can't understand your analogy. Perhaps if it were in terms of a car design failure...

There's a good one, but that would lead to a discussion of presidential politics :)

Change! Hope!

Re:Software Projects vs. Traditional Projects (1)

guruevi (827432) | more than 5 years ago | (#28708327)

There are plenty of projects out there that get killed everyday. Even bridge projects get killed everyday. It's just that you don't notice because it hasn't gone to the compile stage (the building of the bridge) - most bridges get stuck in the political, feasibleness or 'is this really necessary' stage. By then a bridge building project has already consumed thousands if not millions in contractors, engineers, lobbyists and hookers and then in the backlash vendors will sue because somebody already promised they would buy stuff or have stuff made for the bridge but then they cancelled the project.

Sometimes bridges get 'compiled' or built while having a PHB (*ahem*Palin*ahem*Ted Stevens*ahem*) in charge and that's when you'll notice (the famous bridges to nowhere or unnecessary duplicate bridges) - see also: http://en.wikipedia.org/wiki/Gravina_Island_Bridge [wikipedia.org] and http://en.wikipedia.org/wiki/Bridge_to_Nowhere [wikipedia.org]

It's tax payers money, it's just a line item on the state or federal budget and compared to other items on the list (defense costs, political advertisements and toilet bowls) it's really nothing to mention.

Re:Software Projects vs. Traditional Projects (0)

Anonymous Coward | more than 5 years ago | (#28708779)

Even the ones in management?

Re:Software Projects vs. Traditional Projects (2, Insightful)

Dr_Barnowl (709838) | more than 5 years ago | (#28706931)

Indeed. With a bridge, the requirements are simple and obvious - you want a structure that permits transit from one side of some geographical divide to the other. All the detail is just detail, the end requirement is invariable.

With a software project, the requirements are often poorly understood or even unknown - a nebulous sense that things could be better if only we had better software. Often the software itself will reveal the real requirements.

Re:Software Projects vs. Traditional Projects (1)

idontgno (624372) | more than 5 years ago | (#28707759)

All the detail is just detail, the end requirement is invariable.

While the functional requirements for bridges tend to be invariant, the "ility" requirements often go [msn.com] wrong [wikipedia.org] . And those performance requirements are the places where software projects often go wrong, too.

Re:Software Projects vs. Traditional Projects (1)

PainKilleR-CE (597083) | more than 5 years ago | (#28706957)

"Software Engineers" are one of the few types of engineers that are not liable for the failure of the systems they create. They're also one of the few engineers that usually see construction start before the designs are complete.

Additionally, software prototypes don't live in the same realm as other prototypes. You can show a proof of concept in software, and then something happens when you scale it up that you weren't expecting, or someone just screws up writing their piece of the code and it takes two years to track down a mis-placed keystroke. If it's a third-party product (as with this book's subject matter), it's even worse, because you call support and everyone's trying to determine how they can shift the blame to someone else and clear their support tickets rather than actually help someone out.

Re:Software Projects vs. Traditional Projects (0)

Anonymous Coward | more than 5 years ago | (#28707167)

Usually people calling themselves software engineers are not Engineers at all.
In Canada to legally use the term Engineer you must be registered with a provincal Engineering Society and you are indeed liable.

We still have the problem on non Engineers taking a six month course and then claiming to be a "Software Engineer". This is like taking a first aid course and claiming to be a neurosurgeon.

That being said, as an Engineer in the IT field , I can say that in my experiece Engineers are great at running projects just don't let them write code that others may need to read and support later :(

Re:Software Projects vs. Traditional Projects (1)

iamhigh (1252742) | more than 5 years ago | (#28707295)

Oh, so you have to be registered huh? Well according to the always-correct wikipedia, engineering is "the discipline, art and profession of acquiring and applying technical, scientific and mathematical knowledge to design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective or inventions."

If you take requirements from users, manager and process owners, create a system that satifies the requirements and produces the desired output, then you are an Engineer. Not you, you're an idiot (and all the other... but I'm a real engineer!), but the plural form of you.

Re:Software Projects vs. Traditional Projects (0)

Anonymous Coward | more than 5 years ago | (#28707345)

Took the 6 month course eh ?

Re:Software Projects vs. Traditional Projects (1)

onkelonkel (560274) | more than 5 years ago | (#28708289)

Are you liable for the bugs in your system? By liable, I mean if it kills someone are you legally responsible? If it breaks at the wrong time or produces an incorrect result will you have to pay for the financial losses incurred by your users? These things are also included when you call yourself an engineer.

Re:Software Projects vs. Traditional Projects (1)

religious freak (1005821) | more than 5 years ago | (#28708387)

I agree. I don't think engineer should be the vaunted title - scientist should be.

* A scientist has likely has a PhD and does original research.
* Being an engineer requires a good, working knowledge for whatever you're doing, and a four year degree doesn't hurt.
* A technician is someone who can look at a documented problem and implement a documented solution (and probably took that 6 month course)

I'm better than a tech, but not as good as a scientist, so odds are, I'm an engineer. At least, that's the way I see it.

Software job titles (1)

rlseaman (1420667) | more than 5 years ago | (#28708873)

I don't think engineer should be the vaunted title - scientist should be.

"Engineer" and "scientist" are more like different roles, not different titles. A single individual might wear both hats at one time or another. Better job titles might be "computer systems architect" versus "computer systems researcher". That is - what is the motivation for practicing either engineering or science?

Having worked with a lot of both engineers and scientists, it is clear that there is no implicit hierarchy. I don't know about a "vaunted title", but depending on the enterprise either an engineer or a scientist might take pride of place. In academia, for instance, the science side usually rules. But with the bridge example, one certainly hopes that an engineer is in charge and hires scientists for various jobs such as researching materials or unique lighting requirements. Of course job titles associated with roles that more directly concern financial aspects of the project outvote everybody else :-)

I prefer "programmer" as a title over "software engineer", just as "teacher" is preferable to "educator". Fancy titles obscure fundamental purposes. On the other hand, "software systems engineer" is perhaps more accurate than "system programmer" because the word software describes the type of system. Also, "system programmer" tends to have overtones of IBM System 370 era groupspeak.

Engineering is design. Science is discovery. Both are (potentially) equally creative.

Re:Software job titles (1)

religious freak (1005821) | more than 5 years ago | (#28710675)

I don't disagree with any of your points (and your points are good ones). My point is that PHBs are looking for folks they like to call engineers - they pay these "engineers" more than they pay mere "consultants" or "analysts" and probably in some cases, even mere "programmers". In that case, I'll take engineer and not argue the point.

Hell, you could call me a grilled cheese sandwich if you paid me enough.

Re:Software Projects vs. Traditional Projects (1)

plopez (54068) | more than 5 years ago | (#28709791)

do you carry Oand E insurance? No? Then you're not an engineer.

Re:Software Projects vs. Traditional Projects (1)

religious freak (1005821) | more than 5 years ago | (#28710633)

Uh, that called E&O (Errors and Omissions) around these parts. And I do have that, though it has nothing to do with my software activities.

And you're not the boss of me. I'm an engineer - if you prefer to call yourself something else, good for you.

Re:Software Projects vs. Traditional Projects (1)

FishWithAHammer (957772) | more than 5 years ago | (#28707315)

This is exactly why I don't call myself a software engineer, nor would I.

Re:Software Projects vs. Traditional Projects (1)

Nursie (632944) | more than 5 years ago | (#28708201)

"Software Engineers" are one of the few types of engineers that are not liable for the failure of the systems they create."

How so? How are they liable?

Not every engineering projecgt outside of software involves protecting people's lives. Not evey software engineering project does not.

Seriously, you think the engineer (and yes he's an engineer) that designed a lightswitch that fails after a few uses is *personally* liable for replacing them?

And you think the company that sells network management software to the US government is not liable to be sued if it doesn't perform to contract?

So screw you all, I'm a Software Engineer. And a filthy hacker. Depending on what's appropriate at the time.

Re:Software Projects vs. Traditional Projects (1)

slodan (1134883) | more than 5 years ago | (#28707383)

In many ways, software engineering (as opposed to programming) is just leaving its infancy. I think we'll see the industry evolve to become more similar to other engineering disciplines within a decade or two. We have only recently gained the level of differentiation and specialization that other engineers have had for years.

I also think that the constant comparisons between software engineering and civil engineering (the "bridge" analogy) are misleading. Plenty of other engineering projects fail in other disciplines, and they do it as silently as software projects. I don't have any comparison data on failure rates, but I suspect that the rates are more closely related to project size than to engineering discipline.

Re:Software Projects vs. Traditional Projects (1)

Nursie (632944) | more than 5 years ago | (#28708145)

""Software Engineers" are one of the few types of engineers that are not liable for the failure of the systems they create."

Annnnnd... FAIL.

You think electronic engineers are personally liable for incorrect or buggy circuit design?

You think companies that sell software under contract are *not* liable when it doesn't perform?

What a load of shit.

Re:Software Projects vs. Traditional Projects (1)

dgreenbean (832074) | more than 5 years ago | (#28708225)

The difference between a "Programmer" and a "Software Engineer" is analogous to that between a "Mathematician" and an "Accountant." The former uses a creative process that cannot be broken into discrete parts. The entire process is design. The latter merely manipulates the work of the former in a formal, discrete process toward an end goal. This is not a value judgement on either; it is merely a definition. The problem is that, in business, there is either a lack of understanding or of acceptance of this definition. The roles then get blurred. People more inclined to the creative side are stifled with detail, while those with great attention to the details are thrown into design. Other terms can also confuse the issue: "Architect," "Developer," "Analyst," etc. all have implications that are often not natural to the industry. Next comes the systems/software divide. It seems that when people are promoted in the corporate world, their focus tends to shift from software to systems. This nearly guarantees that "Programmers" will turn into "Software Engineers," and often "System Administrators," as that is where the promotions are (note that most middle management essentially performs the role of a "System Administrator"). Unfortunately, this makes for a bad programming environment. The hybrid model that "Programmers" and "Software Engineers" are forced to live in creates this hybrid culture of creatively designing a system that takes on a new life during implementation, finally culminating in failure. Agile project models are better, but this still does not address the issue that creativity cannot be time- or resource-constrained. Management hates this because that is exactly what they are supposed to figure out how to resolve. I certainly don't have the answer, but I can at least recognize the problem for what it is. Until we change the industry to support separate "Programming" and "Software Engineering" positions, projects will continue to fail tremendously.

Re:Software Projects vs. Traditional Projects (4, Interesting)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#28707003)

Software certainly does have the disadvantage of being extremely complex(Both internally and, perhaps ultimately more serious, in its interfaces to other software and systems.) What gives it an extra edge of danger, I suspect, versus some other complex projects is the difficulty(particularly for those of limited technical understanding who happen to be involved) of intuitively grasping how the project is going.

You wouldn't want a non-engineer trying to micromanage bridge construction; but anybody can stick his head out the window and see how far across the water the bridge is today. The incipient cracks in the foundation might well be missed(as they often are), and the project can still easily go over time, or over budget; but it is hard(er) for fundamental delusions about progress to crop up.

A layman looking at a complex piece of software doesn't have nearly the same chances. A "nearly there" system with a few serious but non-systemic bugs looks like a broken unusable mess. A brittle demo being coaxed through by a guy who knows the system better than the back of his hand looks a lot like an intuitive interface. If your institutional structure or culture has any of the factors that encourage delusions, lying, yes-manning, or similar, the people who are supposed to have a grand vision of the project won't have the foggiest idea what is going on.

Re:Software Projects vs. Traditional Projects (1)

Mr Z (6791) | more than 5 years ago | (#28710203)

Speaking of bridges going badly, the Michigan Department of Transportation issued a great report about the Zilwaukee Bridge. [michiganhighways.org] (Site isn't M-DOT, but the it reproduces their report.) It had all sorts of problems during its storied construction, but it eventually was completed and stands tall and strong today. The report's conclusion summarizes:

Completion of the new high level bridge at Zilwaukee will bring to a conclusion some 20 years of planning, designing and construction of one of the biggest and most complex projects ever undertaken by MDOT. It represents a significant engineering accomplishment.

The project has encountered problems, some of them serious and most of them related to the 1982 accident. There have been no serious injuries and no lives lost, however, and the project, including the knowledge gained from the repair process, has provided much engineering experience of value to the entire highways industry.

The bridge, when completed, will be safe, durable and efficient, ready to serve the motoring public for many years to come. It will replace an obsolete, inadequate drawbridge that has caused numerous accidents and endless traffic delays over the years. And it will easily accommodate the more than 31,000 vehicles that travel along that section of I-75 freeway every day.

One of the other big differences between bridge building and software construction is that the scope of the bridge's purpose is well defined: I want to get cars from point A to point B over some obstruction. The unknowns are generally confined to how that end is achieved, rather than the actual end that's being worked for. The Zilwaukee Bridge had well defined success criteria that were in place from the get-go.

When developing a new software project (as I'm doing right now at work), I find that if I ask N people what the exact requirements are, I get N+1 descriptions. In the end, I'm left to find the overlap and do my best to fill the fringes. It's hard to measure success when different stakeholders have different goals in mind, and agreements on said goals are often superficial.

You won't see that on a bridge. "It's supposed to be eight lanes!" "Well, it's seven traffic lanes plus a really broad shoulder. That's a total of eight lanes wide, after all." "That's not what I wanted. Make it wider!"

Re:Software Projects vs. Traditional Projects (1)

Z34107 (925136) | more than 5 years ago | (#28707015)

My theory: If you build a bridge, and it falls over, you go to jail. Additionally, people die.

I guess the kinds of project managers described ("the know-it-all, the micromanager") that evidently exist in IT would all be felons in the bridge-building world. But dammit Jim, IANACE (I Am Not a Civil Engineer), nor a project manager, nor an IT manager.

Re:Software Projects vs. Traditional Projects (1)

JobyOne (1578377) | more than 5 years ago | (#28707093)

I think it has something to do with the fact that it's easier for bigshot investors/CEOs/bigwigs to wrap their head around physical problems brought up by engineers.

If a structural engineer says "this cabling isn't strong enough, we need this other type and it will cost X more," that's a pretty concrete statement. And nobody wants to argue with a structural engineer.

If a software engineer says "we should just buy X software package so I won't have to spend the next 2 weeks reinventing the wheel," a bad manager could pretty easily decide that they would rather pay their own people $2,000 to get a crappy knockoff of a tool they could have bought for $1,000. Then when that crappy reinvented wheel breaks they can just blame the coder who didn't even want to write it in the first place.

Also people at the top rarely understand software, and can't be bothered to even learn the basics. Saying "do it" and expecting it to magically get done does not make a good manager.

Re:Software Projects vs. Traditional Projects (1)

Chirs (87576) | more than 5 years ago | (#28707243)

While it's true that things can go wrong building a bridge, it's also true that the fundamental physics of bridge-building are fairly well understood. There are standard tables that are used to spec girder strength, fastener type, etc. I suspect that most bridges don't involve custom-making the metal alloys specifically for that bridge, or nonstandard concrete mixes.

With software, for many fields it just isn't standardized. I suspect that there are many more original problems being solved in software than in bridge building.

Add to that the fact that there really isn't any professional responsibility attached to software designers. (I won't dignify them with the term "engineers".) If a bridge fails, the engineer who signed off on it gets in a lot of trouble.

Re:Software Projects vs. Traditional Projects (1)

radtea (464814) | more than 5 years ago | (#28707563)

I was discussing with a friend how software projects are probably the most difficult to run and predict, especially with very large projects. He disagreed and said that all large projects are difficult...

Actually, all large projects are equally easy with regard to prediction. A larger project is even more amenable to a statistical estimation approach, because the workforce and circumstances are averaged over the larger size, creating a more homogeneous, stable mass.

For any organization that has built more than one of something, you have lots of hard data from previous schedules and estimates to base your new schedules and estimates on, if your project managers are even minimally competent. After all, it isn't exactly rocket science to keep a table of numbers ("how long we expected the project to take" and "how long it actually took.") This also requires adequate requirements documents, and that's a more difficult problem, but it's hardly surprising that "projects teams that don't know what they're building have a hard time estimating how long it will take to build it."

The first project an organization undertakes is a bit trickier, but again, even a modestly competent project manager will track schedule progress against real time, and after about three weeks will have a correction factor to the original schedule that will bring things pretty close to reality. This should be done anyway, on all projects, of course, because circumstances do vary from project to project, but on subsequent projects the correction factor should be closer to unity than not.

The thing that makes project scheduling and estimation "hard" is that most project managers are either incompetent, or so beaten up the first they tell the suits the truth that they spend the rest of their days lying to avoid further abuse. I've known people in both categories, and the first group are the ones who crow most loudly that project estimation is hard because it is so far beyond their modest competencies. The second group will pull it out as a backup excuse when things go badly wrong next time, and because suits are idiots they are willing to believe it, thus perpetuating the cycle whereby everyone gets off the hook for failing to do an incredibly simple job: keeping a table of numbers, and applying a simple numerical multiplier to their schedule after the first three weeks.

Someone below quoted Tolstoy about all unhappy families being unhappy in their own way. This is funny, but it's false in the case of project management. There are very few ways projects go bad, and one of the the most common is an excessive focus on the particularities, rather than a global view that sees the individual circumstances as a valid statistical ensemble that can be averaged over meaningfully.

There is nothing particularly difficult, intellectually, about project estimation. Virtually all the difficulty comes in the politics of the organization, and a deep grounding in solid empirical estimation practises will help you navigate those waters. McConnell's Rapid Development has some nice starter material on estimation that is well worth having a look at.

Re:Software Projects vs. Traditional Projects (2, Interesting)

getNewNickName (980625) | more than 5 years ago | (#28707571)

Software projects fail more easily than their physical counterparts due to the brittleness of software programs. It is unlikely a bridge falls apart if it's missing a single screw, but for software a single line of bad code could cause the application to crash. Currently software has a very small tolerance for errors, which makes it very difficult to successfully complete large projects.

Re:Software Projects vs. Traditional Projects (1)

DragonWriter (970822) | more than 5 years ago | (#28707769)

That's obviously true, but how many bridges never get finished compared to the number of software projects that never get finished?

You tend to have to make an expensive investment in resources (securing real estate, preparing the site, etc.) to even begin building a bridge, which is less true of software projects, therefore a bridge project that gets cancelled between when the project starts and when it is complete is a lot more likely to be cancelled before any construction is done than a software project that is cancelled is likely to be cancelled before any programming is done. So IT projects are more likely to be visibly abandoned after "construction" has begun than bridges, because there tend to be less front-loaded costs in IT.

Mod Parent Up (0)

Anonymous Coward | more than 5 years ago | (#28710141)

This is the most insightful comment in this thread.

I won't talk about bridges, because I'm a mechanical engineer who designs HVAC, Plumbing, and Fire Protection systems for buildings.
Once a building gets beyond the foundation phase, it is fairly rare for something not to be completed, because, for one thing, once a building gets started, it may be more expensive to demolish what has been built so far than to finish the project if you take into account that the project will be worth at least something when it is done. (Abandonment might not be a legal option) However, a project sometimes gets completed only after the original builder goes bankrupt and the project is sold cheap to someone else - this will not usually be apparent to the general public.

What is somewhat common, is projects failing during the design phase: budget gets out of control, the Owner changes their business plans, the builder can't come up with the money, or investors pull out because the project can't or won't meet the original goals, etc.

Maybe the problem with large software projects is that the coding is being done while the design is still being worked out. This is becoming more and ore common in the construction industry, and it adds a large amount of difficulty as well as haste that makes waste, and in my opinion makes it easier to have a building that (though built a little cheaper) has problems.

Re:Software Projects vs. Traditional Projects (0)

Anonymous Coward | more than 5 years ago | (#28709087)

Why do we always compare building/implementing software to building bridges and cars? Why not compare building/implementing software to starting and running a restaurant?

Re:Software Projects vs. Traditional Projects (0)

Anonymous Coward | more than 5 years ago | (#28709155)

Lately, I've begun to feel that a lot of the reason for project failure is the "All You Have To Do Is.." effect.

Users get a wild idea, someone shows them some artwork, they say "It's simple! All You have to do is...".

Unfortunately, the developers get the specs, look at it, forget how much time and effort gets wasted on obscure diversions because while the hard parts of the project often end up being simpler than imagined, some of the "simple" parts of the project turn out to be much harder than imagined. And because even before we were constantly being threatened with replacement by cheap offshore labor, few of us had the nerve to stand up and say "No, it's actually probably going to take three times that long".

Plus, of course, there's the classic ailments like Second System Effect, Feature Creep, etc.

Computers are stupid. They don't understand "All You Have To Do". In fact, that's one of the first lessons in programming is that a computer has to be told in excruciating detail exactly what to to.

A recent complication has been the extensive employment of developers who were raised in cultures where the good worker has traditionally been expected to be little more than a computer him/herself. Thus, the design team has to "program" the programmers so that they can provide those Great Big Savings by programming more cheaply than Western programmers, who require relatively little programming.

Of course, the final insult is that computers have lost their reputation for precision and reliability, because the customers frankly don't care that much about quality, as long as the work gets done fast and cheap. So even if the project doesn't fail outright, it's often pretty worthless.

Re:Software Projects vs. Traditional Projects (1)

Swampash (1131503) | more than 5 years ago | (#28711343)

Bridges are designed by engineers. Software is designed by people who CALL themselves engineers. There's a big difference.

Didn't need a book to know this (4, Informative)

Em Emalb (452530) | more than 5 years ago | (#28706615)

Not trying to be a jerk (hah, stupid buttface!) but the reason most new "systems" fail is for one of 4 reasons:

1) the decision maker(s) not understanding the actual requirements thereby causing a situation where they end up with a system that doesn't fit their needs

2) the third party or in-house developers not understanding the actual requirements thereby causing a situation where the system they've created either doesn't work or doesn't work as it should

3) the new system is too complicated/buggy/worthless and the end users of the system refuse to use it and/or complain constantly (I HATE CHANGE!)

4) all of the above.

There are more, but those are the big 3.

Re:Didn't need a book to know this (4, Insightful)

MightyMartian (840721) | more than 5 years ago | (#28706703)

I've had two projects fail ignominiously. One was my fault for not getting much more concrete requirements, and getting caught up in the "oh, and can you add this to it too?" The second was because I was basically lied to by a supplier who claimed their own product could do what it ultimately could not, and since it was a core feature of the system we were putting in place, the whole thing died, but not before consuming heap loads of money.

I learned a few things. The first is to get exact specifications. Let there be no wiggle room, no "well I thought it would do that" crapola. Extras can be added on once the core system is demonstrated to work, not before. Have a design philosophy and stick to it. As to lying suppliers, well, it's a lot easier to assess these things nowadays than when the one project failed in the mid-1990s. Still, I always keep in the back of mind "if software/library/whatever doesn't work, is there something that can".

Re:Didn't need a book to know this (4, Insightful)

dave562 (969951) | more than 5 years ago | (#28707013)

As to lying suppliers, well, it's a lot easier to assess these things nowadays than when the one project failed in the mid-1990s.

What is different now from the 1990s? I've been involved with one software project that failed because the vendor promised functionality that they couldn't deliver. The client spent a significant amount of money on the project. Once it came out that the software couldn't do what the vendor promised it could do, the client sued the vendor and recouped all of their money plus legal fees. The client was able to sue because the vendor put it in writing.

Getting things in writing from the vendor is of paramount importance. Doing a needs analysis with the client before shopping around for software vendors is key. With a needs analysis in hand, you can present that to the vendors and ask them point blank whether or not their software fits the needs. If they say it does, make them sign a contract to back up their claims. Then they either deliver what they promised or they get sued.

Re:Didn't need a book to know this (1)

Purpendicular (528740) | more than 5 years ago | (#28707697)

Unfortunately, there are no "exact specifications" in the real world. As the reviewer, I thoroughly recommend reading Weinberg (Quality Software Management), but also Tom Gilb, "Principles...". Funnily enough, Craig Larman points out that the guy accused of inventing the Waterfall model did no such thing. According to his son, he has been misquoted for 30+ years.

Re:Didn't need a book to know this (4, Interesting)

rgviza (1303161) | more than 5 years ago | (#28707921)

> I learned a few things. The first is to get exact specifications. Let there be no wiggle room, no "well I thought it would do that" crapola.

This is not realistic. You _can't_ get the requirements right up front because the users don't even know what they want until they have a system that doesn't have it. They think they told you what they want, but they didn't because they don't know themselves. A more realistic approach is to get the best requirements you can, and build enough time into the project to handle 1.5-2 years worth of scope creep because that's what's going to happen with any huge system.

If you try to hardline your users by forcing them into a corner with rigid up front requirements that they cannot possibly help you formulate, they'll simply go outside the company and work with someone who knows how to run a project better and you'll get laid off. (refer to Linus Torvald's rant about specs to see why specs and requirements done this way are useless, except as a starting point)

If you are prepared for scope creep, and frame the first release as an alpha, you will succeed. I've been doing this for 20 years and I've seen the approach you are talking about fail over and over even with PM's that have 30 years experience. They knew better but corporate policy forced them to operate this way. Inevitably the requirements were hopelessly incomplete and the users were pissed off when they had to sign off the project as complete because of what they agreed to, and in the end, the product did not meet their needs. The whole idea is to give the users the product they need. So even if you succeed in beating them on paper, and they are forced to sign off complete, you've failed.

Know what happens when you do this to your users? They hire contractors, who will be more flexible and give them what they want, and fire you. You are better off with a "Look this is a big system and it's going to take a while to get it right. Lets figure out what you think you need now, we'll build it, and use that as a starting point to flesh out your system."

XP for the win for corporate development, Waterfall = FAIL. Waterfall can only succeed if you are a software company building a boxed static product produced by someone that knows what they want.

At the end of the day a large corporate software project will take 10x longer than you think it will. I've never seen one that didn't. I've seen plenty that failed. Plan accordingly.

-Viz

Re:Didn't need a book to know this (2, Insightful)

Anonymous Coward | more than 5 years ago | (#28708299)

I think you need to take it one step up the abstraction chain. First, find out what the goals of the users are: what real-world problem are they trying to solve? Forget traditional "requirements" and such, which just leads to discussion about the "system" in the minds of the user and the "system" in the minds of IT. Which, by the way, are greatly different. Once you first figure out what they are trying to accomplish well above requirements, only THEN can you start to figure out the requirements to meet their goals.

The major problem is that everyone in IT projects forget to first figure out the users' goals, but rather go straight to requirements. Requirements depend on goals.

Re:Didn't need a book to know this (1)

michael_cain (66650) | more than 5 years ago | (#28709395)

I learned a few things. The first is to get exact specifications.
==========
This is not realistic. You _can't_ get the requirements right up front because the users don't even know what they want until they have a system that doesn't have it. They think they told you what they want, but they didn't because they don't know themselves.

I have to agree with the parent. I've had an opportunity to watch the post-mortems on several large, failed software procurements by my state's government. My opinion is that the fundamental reason all of them failed was inadequate (sometimes grossly so) specification. I also agree with you, that the customer generally can't (or won't) do it. I believe the way I put it to one director was "If you can't specify the interfaces, the protocols, and a reasonably complete conceptual model of the data, you're paying $78 million for the vendor to guess." Given the price tags on large state software systems these days, government is going to have to figure out how to avoid buying $78 million prototypes that aren't going to be even close to right.

Re:Didn't need a book to know this (1)

Bacon Bits (926911) | more than 5 years ago | (#28709495)

I think the problem there comes in that a huge proportion of corporate software is contracted. Your method, which I agree is the proper way to build a successful system, simply doesn't work when the programmers are required by a quote-to-order system to do as little work as possible and may be paid by the hour for labor, and managers are required to keep costs as low as possible.

Yes, this means software contracting generally designs your system for failure. You absolutely must have in-house capabilities for systems analysis and project management.

This, I'm sure you're aware, is why the cost of Windows just doesn't matter to business. Compared to the costs of everything else, the cost of the OS -- heck the cost of the OS and the cost of the hardware -- is a drop in the ocean.

Re:Didn't need a book to know this (1)

Coz (178857) | more than 5 years ago | (#28706953)

YOU may not need a book to know this. but there are intelligent-in-their-area bean-counters who get sold on these things at major companies every year. THEY need this book, and as responsible techies, it's our job to make sure they have it. Remember, if it's in a book, it's not just OUR opinion - it's Official :)

Re:Didn't need a book to know this (1)

Yetihehe (971185) | more than 5 years ago | (#28707275)

2.1) Bad communication of requirements with third party coders. Happening right now with one project I'm working on ( aka "Why didn't you implement X? It's logical that it must be that way!" )

PHBs is the simple answer (1)

Finallyjoined!!! (1158431) | more than 5 years ago | (#28706645)

Buying software designed to take the user 4 times longer to use, takes 4 times more key presses & takes a 4 times faster processor to do the same task as the "old" software, but it enables some sodding PHB to get a report in one click.

Alot of Software is Shit (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28706663)

Let's be real here for a moment...

People who make alot more than I do look at a list of features. They don't tend to ask peons like me if these features are implemented in a reasonable way.

I'm not given the opportunity to warn of an impending clusterfuck until it's to late. By then it's not just my problem, it's everybody's.

Of course by the time it gets that far it is to late to turn around.

By the way, I heard second hand of very senior people at a company being fired because of an SAP implementation gone awry.

Me - I cram good websites in to shitty content managements systems. Generally i could personally develop most of the features that are in these CMSes if instead of dicking around with them I was just writing code.

I have personally spend over 3 days implementing a drop down list...

Re:Alot of Software is Shit (1)

PhxBlue (562201) | more than 5 years ago | (#28707227)

Me - I cram good websites in to shitty content managements systems. Generally i could personally develop most of the features that are in these CMSes if instead of dicking around with them I was just writing code.

So you work with the Air Force Portal, then? *Rimshot!*

Incredible review (0)

Anonymous Coward | more than 5 years ago | (#28706793)

"Simon's book is far more informative and instructive than a Google search and should be required reading for all CIOs, IT project managers, and involved business managers prior to starting any such enterprise COTS project."

Who is Bruce Webster? He must a trainer of CIO's or something to presume to know what CIO's should or shouldn't read. No doubt he's an expert in risk management. I suppose he's developed seriously mission-critical systems in his time. But if that was the case, why didn't he write a book about it then?

Re:Incredible review (1)

rjstanford (69735) | more than 5 years ago | (#28708111)

Additionally, since when is being "more informative and instructive than a Google search" considered to be good enough to justify a book purchase?

New Systems fail because: (1)

vertinox (846076) | more than 5 years ago | (#28706873)

Clients are over expecting.
Salespersons are over promising.
Developers are over outsourcing.

firs7 po5t (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28706959)

Tolstoy's version (5, Insightful)

T.E.D. (34228) | more than 5 years ago | (#28706997)

People have written oodles of books on this subject, because there are oodles of different ways to screw up a project.

The best insight on this subject comes from Tolstoy, not Brooks. He was talking about families being functional, not software, but the principle is the same.

All happy families are alike; every unhappy family is unhappy in its own way.

A far better method of approaching this issue is to study projects that don't fail, not ones that do.

Re:Tolstoy's version (1)

ljw1004 (764174) | more than 5 years ago | (#28707219)

Why do you think the principle is the same?

My experience is that it's the opposite. Project failures always come from the same sources (bad expectations and bad specifications and bad process control).

But project success comes from many different reasons most of them unexpected -- and often it's enough for just a couple of these "success wildcards" to arise in order for the project to succeed. Sometimes a star programmer pulled it off, sometimes a star manager, sometimes the solution just fell out instantly, sometimes the team happened accidentally on the right architecture at the start by blind luck, sometimes there was the right synergy of people, sometimes the project got enough key parties excited about it, sometimes the right person left at the right moment to let someone else take over, sometimes re-architecting was right, sometimes it was wrong.

That said, my experience is too limited for me to draw conclusions. I'm curious what led you to your opposite conclusion, and about what other people have found.

Re:Tolstoy's version (1)

JesseMcDonald (536341) | more than 5 years ago | (#28708165)

The original quote was overly simplistic. The causes of success and failure are both diverse, in families as much as in software.

Re:Tolstoy's version (1)

dcollins (135727) | more than 5 years ago | (#28708753)

All happy families are alike; every unhappy family is unhappy in its own way.

That's interesting. I think just yesterday I said exactly the opposite.

Everyone I know who's furiously pusued the American married-with-2-kids nuclear family ideal is miserable. Everyone I know who has some alternative-y lifestyle (without marriage, kids, lucrative job, white picket fence, or some combination) seems a lot happier.

Re:Tolstoy's version (2, Insightful)

genner (694963) | more than 5 years ago | (#28710707)

All happy families are alike; every unhappy family is unhappy in its own way.

That's interesting. I think just yesterday I said exactly the opposite.

Everyone I know who's furiously pusued the American married-with-2-kids nuclear family ideal is miserable. Everyone I know who has some alternative-y lifestyle (without marriage, kids, lucrative job, white picket fence, or some combination) seems a lot happier.

In reality everyone is miserable.

Re:Tolstoy's version (0)

Anonymous Coward | more than 5 years ago | (#28708851)

Study both, or else you'll get the halo effect. That means everything that a bad project does is bad, inversely every project that works is doing everything okay.

To buy or to build (1)

snspdaarf (1314399) | more than 5 years ago | (#28707039)

I have seen several COTS projects break up in flight, once as a participant, three times as an observer, and a big part seems to be management not wanting to change their business process to match that of the COTS package. It seems simple to me. Either do things the way the purchased software wants them done, or write your own software to automate your existing processes. Unfortunately, the people that make those kind of decisions will not be the ones that read this book.

Tim Lister? Who's he? (1)

davidwr (791652) | more than 5 years ago | (#28707083)

Tim who [wikipedia.org] ? Sure, he's probably done stuff [wikipedia.org] but as long as he doesn't have a Wikipedia entry [wikipedia.org] he's just a nobody.

Counting down the seconds before I get a "there, fixed that for you [wikipedia.org] ."

Underpromise and over-deliver! That's my motto... (4, Interesting)

filesiteguy (695431) | more than 5 years ago | (#28707131)

...or at least one of them. I haven't read the book yet - but it is now listed as a to-do in my list of to-do items taking up space on my blackberry.

In any case, I'd be curious what the answer is. In my short software development experience - only since '93 have I been doing enterprise-level development - I see one factor being the overwhelming key to failure.

Communication.

When you have analysts and developers (who are notorious for not being communicative in the first place) trying to interface with executives and managers (who are trying to CYA) then you have a perfect storm brewing.

Add to it, the fact that COTS solutions rarely actually fit the needs of everyone, and you subscribe to failure. A classic example that I just saw this week is with the California State Child Welfare lien processing system, written by Accenture. I asked for a minor change in the file layout some months ago. Only this week did I hear that I'd need a change request and that they'd get back to me in a few months. :P

By contrast, I've written my own in-house custom software systems for the enterprise. (One system in production has well over 500 concurrent users on any of fifteen different modules.) When teh customer(s) request a change, then it can - depending on complexity - be implemented and tested in a matter of days. Of course, harping on the communication theme, I'm in constant communication with teh customer, the end-user (if different), my developers, and my analysts. (I'm a PHB in the middle.) I make sure that we under-promise and over-delivery whenever possible.

"New Systems" are never created. (1)

goffster (1104287) | more than 5 years ago | (#28707141)

A good system is one that evolves constantly from humble beginnings with smart
people making and guiding decisions at every step in its evolution.

You start with a good idea, implement it. Add more good ideas, discard the bad ones.

If your system is useful, and supersedes the older slow/bloated one, then it "becomes" the "new system".

Re:"New Systems" are never created. (1)

kigrwik (462930) | more than 5 years ago | (#28707923)

A good system is indeed one that can evolve and adapt to shifting requirements.

A good product/project manager is one that can say "NO" and prevent feature creep. But you need some backbone to say no to the boss/client.

requirements gathering failure (1)

Dan667 (564390) | more than 5 years ago | (#28707143)

In my experience, the main reason software projects fail is a failure to collect adequate requirements. The tendency to jump in a code something is extremely great, but that is the absolute worst thing to do. For projects I manage, it is about a 2/3 requirements gathering to 1/3 or less code writing. A lot of people hate gathering requirements, figuring out how people do their job / what people actually need, and following up with minor changes that are extremely important in the different in a system that a user will hate to use vs one a user wants to use. Also, managing expectations is very important.

65% of all IT projects fail (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28707149)

65% of all IT projects fail (whatever "fail" means). Most projects are entered into without upper management support and are under funded and under prioritized. The vast majority of projects started by a middle manager should never have begun at all. Those cause churn in their team until they reach a point that new networking or servers are needed. Then they are stuck with all the wasted time already spent. Another failed project.

Control the budget and resources to prevent false starts. That is the main way to increase the success ratio.

After that, you need user buy in for any new software system deployed. Users need to find all the good things it will allow, not all the things they will need to do differently or can't do. More than a token number of real users need to be brought in during planning to ensure the new system will actually be "better" however that is defined. Better could mean - not on a mainframe or not on UNIX or not a desktop thick application.

After working for 15+ years performing designs and installations of COTS systems across many, many servers, I'm positive most users won't change unless they have no other choice.

Do you really need a book the say that?

As for turning more projects into successes, you'll need to pay someone from outside your company to tell the PHB Exec-types the same thing you've been saying for years. Somehow, if someone charging $300/hr says it while wearing a suite, then it must be true.

The bigger the rollout, the harder the crash (4, Insightful)

petes_PoV (912422) | more than 5 years ago | (#28707255)

"But we don't have time for a pilot"

Also heard as "Why, don't you have confidence in your project"

Putting aside the sheer commonsense approach of not giving a porsche to a newly passed driver, most projects are run in a state of panic. Panic that the timetable is slipping (although this is almost always due to poor time-estimating, it seems to get presented as being due to slothful or untalented techies), Panic that it's costing too much - again due to poor cost estimation, rather than ovespending. Panic about bugs, Panic about training (ha!). Panic about compatibility with other systems. Panic about all the little patches, workarounds, working practices and hacks that have developed in the old system - that everyone knows about, but have never been documented.

All these, could have been identified and most of them fixed just by running a small scale prototype in parallel to the existing system. However by the time the project is halfway through, most of the directors are firmly engaged in either "buyers remorse" or utter denial. They become deaf to bad news and generally take full aim at the messenger, while leaving the culprits of all the problems unscathed. This is usually because all the biggest mistakes are made right at the start - in the design stages. However, these have been completed and signed off, so by definition cannot be at fault. The blame gets transferred down the line, to the people who have their hands-on right at the time the deadline is due. It's the original smoking gun: "The project ran over time / budget today - you were working on it when that happened, therefore you must be to blame". It's simplistic, always wrong and always starts off the finger pointing part of the process. You can't get away from it.

Although the biggest problem I see is "seagull" consultants. They fly in, make a lot of noise, crap over everything and fly off. The trouble usually only surfaces once they've disappeared.

classes of problems (3, Insightful)

rev_sanchez (691443) | more than 5 years ago | (#28707259)

Communication - Ill defined or changing specifications and poor documentation make development and testing very difficult.
Technical - Large systems tend to be very complicated and it's difficult and expensive to make them fault tolerant and build in the sort of redundancy, validation, and security that make critical systems reliable.
Leadership - Decision makers on the client and supplier side often don't know enough details about various parts of the project to really know what they want much less what they need.
Organizational - Setting deadlines before defining the scope of the project, belligerent coworkers and other HR issues, uncooperative clients, cutting testing time to meet deadlines, and other general issues within the organizations can lead to death march development and other undesirable situations.

We need an SOB with Power to say NO !! (0)

Anonymous Coward | more than 5 years ago | (#28709941)

You need one hard-nosed SOB with enough power to say "No!" again and again

No to new requirement
No to modifying requirements
No to fixing a minor bug that can be worked around or lived with
No to consultants design by PowerPoint solutions
No to features that are not core to the requirment
No to cutting 10% of the budget expecting 90% solution to work
No to cutting testing due to schedule crunch
No to belief that "We don't need to train users"
No to relying on vendors without testing hardware or software
No we are not going to change programmers in the middle of the project

Give me 1 GOOD person who really knows a CRAPPY system
& they will run rings around 10 so-so people using a GREAT system.

Sturgeon's Law (2, Funny)

n6kuy (172098) | more than 5 years ago | (#28707703)

90% of Everything is Crap.

Requirements, requirements, requirements... (1)

rlseaman (1420667) | more than 5 years ago | (#28707747)

All projects can be described by:

  1. define the problem
  2. entertain solutions
  3. iterate

Requirements are the interface between #1 and #2. Thus, one way or another all system failures are about requirements. Either the true project requirements were never discovered - or the customer was allowed to impose unnecessary and counterproductive pseudo-requirements - or the domain requirements weren't correctly elaborated into appropriate functional requirements - or the process for managing the requirements was top down and static when it should have been bottom up and iterative (or vice versa) - or a contractor was permitted to be non-responsive to the requirements (for any of a 1000 reasons) - or...

Which is to say that each project represents a single complex-but-inherently-self-consistent problem. There are an infinity of possible solutions. Each solution attempts to manage the complexity of the problem space, but cannot ever eliminate this complexity [wikipedia.org] . Further, all real world solutions are guaranteed to be inconsistent. We often refer to these inconsistencies as bugs, but more often they are failures of the conceptual model, that is they are requirement failures.

On the other hand, development teams often complain that requirements have changed - for instance that the customer is demanding new features. Rather, requirements never change, only our understanding of the scope of the problem changes. Discover the requirements and the Platonic ideal of a project will be laid out in front of you [onter.net] .

The search for project requirements [youtube.com] can be an adventure as rich as any our species embarks upon. Projects fail for the same reason that expeditions fail - a lack of imagination. A customer's description [wikipedia.org] always fails to capture the essence of a project; customers always fail to include a broad enough vision for how the new or modified system will fit into the organization. The first stage of any project is to clarify that vision. As with Indiana Jones, the trail is fraught with dangers [wikipedia.org] , but the trek is the essence of the exercise [wikipedia.org] .

It's one big poker game (1)

petes_PoV (912422) | more than 5 years ago | (#28707859)

Everyone knows when a project is doomed. However, no-one is willing to report it. The reason is that so many people have bonuses, contracts and reputations at stake that they will always hold out, right up to the last, in the hope that someone else will fold first. Once the first guy admits "there might be a slight problem", everyone else piles in on top of that. Typically blaming the fall-guy for all of their problems, shortcomings, missed deliveries and failures.

The higher up an organisation you go, the more the people in charge have to lose. Therefore the less likely they are to admit it's a disaster. This goes as far (and often a lot further) as continually pouring in money even when all the signs are screamingly obvious that nothing good will ever come out of it.

The Emperor's New Clothes was obviously written by a long-time predecessor of this book's author.

The problem with these kinds of books... (1)

devleopard (317515) | more than 5 years ago | (#28707901)

They're stuck in an old paradigm: plan it, build it, test it, deliver it, you're done. This may still be true for certain types of applications (think an accounting system), However, today's giant web applications written in ColdFusion, PHP, or the like are as much a system as the traditional ones. Moreover, many companies' web applications *are* their business. Therefore they have to make adjustments on the fly, or lose business. No different than other businesses - if you run a restaurant, and your competition is smokin with a new dish, you better get it on your menu. Fast. If your chefs say they can't do it, then you either get new ones or embrace the idea that you don't have the competency, at least in that area, to compete. Unfortunately this reality of online businesses tends to screw up Gantt charts and whatnot. In addition, these books assume giant teams - how many applications that drive entire companies are architected, built, and maintained by teams of less than 5? Heck, my bread and butter is building big apps, primarily in ColdFusion, where I generally am the sole developer, either building from the ground up or coming on after the application was built by a team and supposedly "finished".

A better book would be "How New Systems Succeed".. (3, Insightful)

russotto (537200) | more than 5 years ago | (#28708681)

Because why they fail is not all that interesting. A project specified mostly by people who don't know what the system is supposed to do, implemented by people who don't understand the business, replacing a legacy system containing within its labyrinthine bowels the combined knowledge of tens or hundreds of expert users past and present. What could possibly go wrong?

Add on top of that a COTS requirement, so it's a matter of making the requirements fit the software's limitations (while still fitting the business), and you have an almost guaranteed recipe for failure. Particularly when the users _won't_ adapt.

Re:A better book would be "How New Systems Succeed (1)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#28709217)

If you know how systems succeed, why would you sell books for a few royalty bucks a copy when you could sell successes for $$$$$?

Re:A better book would be "How New Systems Succeed (1)

PeanutButterBreath (1224570) | more than 5 years ago | (#28709335)

Because why they fail is not all that interesting

Be sure to tune in for tonight's episode of "When animals don't attack".

Please?

Misperception (0)

Anonymous Coward | more than 5 years ago | (#28708705)

However, the firm (usually wrongly) thinks that such a project comprises nothing more than installing the software, training some users, converting some data, and turning a switch.

No wonder they have problems! One doesn't "turn" a switch, one "flips" it! Problem solved.

Software is hard (2, Insightful)

plopez (54068) | more than 5 years ago | (#28709889)

You can't see it, touch it, smell it, taste it etc. Most of it is an intellectual abstraction many programmers, not to mention the general population, isn't very good at.

Doing software well requires being an expert in complex problem domains. The domains may require knowledge of complex financial, legal, engineering and manufacturing systems. It may require modeling human relationships. Or combinations of all of the above.

Where people get things wrong is they do not take the time to understand their problem domain. They look for magic bullets. They need to spend time with their end users and understand the work processes. A little business process modeling goes a long way.

ERP Systems Failure (1)

Guil Rarey (306566) | more than 5 years ago | (#28711133)

ERP Systems fail (and this is by no means an exhaustive list, just what I have seen myself) ...because the sales pitch is to the board of directors and the implementation is at the user level. ...because I (financial analyst that I am) have a job to do. Your system helps or it doesn't, but I've got to get my job done.

The common theme here is that ERP implementations lack humility and respect for the existing business and the people who actually run it. In pursuit of relatively nebulous "strategic" advantages, an inflexible, underdocumented, undersupported system is shoved down everyone's throat.

A few years down the road what happens? The planning guy (me) and the accounting guy had EACH separately reimplemented Access databases to provide the information we need to do our jobs, despite the fact that a module exists in the ERP system to do exactly what we need to do.

Except that, of course, it's been configured in such a way that it doesn't do any such thing, and we can't change it. Hell it took me 3 months (not full time) grovelling through help screens to even understand it. No, there's no budget for training. Or user support. And changing things? Get in line.

The Right ISBN (1)

TimSSG (1068536) | more than 5 years ago | (#28711415)

978-1438944241 Tim S.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?