Slashdot Mirror
Why New Systems Fail
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.
Why New Systems Fail: Theory and Practice Collide
author
Phil Simon
pages
251
publisher
AuthorHouse, 2009
rating
8/10
reviewer
Bruce F. Webster
ISBN
9781-4389-4424-1
summary
Risks and pitfalls of enterprise COTS projects
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.
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.
the users dont understand what I write!
most new systems fail because the user doesn't read what he is doing, and then they blame it on the system
"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"
"Going to war without the French is like going deer hunting without your accordion." ~General Norman Schwarzkopf
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?
If you can read this... 01110101 01110010 00100000 01100001 00100000 01100111 01100101 01100101 01101011
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.
Sent from your iPad.
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.
If I had an Ass, I'd call it Fanny Bottom, then I could slap my Ass; Fanny Bottom, on the Arse.
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...
"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?
Clients are over expecting.
Salespersons are over promising.
Developers are over outsourcing.
"I am the king of the Romans, and am superior to rules of grammar!"
-Sigismund, Holy Roman Emperor (1368-1437)
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.
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.
Why, without your clothes, you're naked, Miss Dudley!
Tim who? Sure, he's probably done stuff but as long as he doesn't have a Wikipedia entry he's just a nobody.
Counting down the seconds before I get a "there, fixed that for you."
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
...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.
:P
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.
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.
The Kai's Semi-Updated Website Thingy
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".
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 (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.
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
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.
If you didn't come to party don't bother knocking on my door. Prince '1999'
90% of Everything is Crap.
If you disagree with me on social issues, then it's pretty clear that you are a narrow-minded bigot.
All projects can be described by:
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. 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.
The search for project requirements 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 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, but the trek is the essence of the exercise.
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
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".
The best thing about a boolean is even if you are wrong, you are only off by a bit.
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.
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.
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.
If you know how systems succeed, why would you sell books for a few royalty bucks a copy when you could sell successes for $$$$$?
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?
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.
putting the 'B' in LGBTQ+
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.
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.
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.
Do not taunt Happy Fun Ball
978-1438944241 Tim S.
which isn't software focused, but contains principles *absolutely* useful for software as well as other types of engineering is Inviting Disaster. It's an easy, highly entertaining read, with the bonus that you (ought to) learn something as well. I highly recommend it.
Software projects only fail because people agree and/or commit to features or schedules that are not thought out ahead of time. Anytime such a committal is made, either that part of the project will fail, or some part that connects to that part will be forced to fail as a result of the developers being forced not to design the software properly. Software projects are supposed to be really expensive (just look at the early days for examples), but to cut costs, sales and non-technical people agree to nonsensical schedules and features. The clients won't sign onto a project unless it is cheap, so the managers/sales folks that agree to the MOST nonsensical stuff are initially seen as winners. Developers are then given the responsibility for delivering on a deal that they didn't design or agree with. Since every development outfit does this, none of the clients out there have any idea how complicated and expensive it would be to actually do things the right way.
stuff |
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?
You do realize you've just described most reengineering efforts, right?
Another interesting read .. Software Project Failures Sabina Seifert ...