Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Software Businesses IT

$10B Annual Tab for Spreadsheet Errors? 305

theodp writes "According to PWC and KPMG, more than 90% of corporate spreadsheets have material errors in them. With each error costing between $10K and 100K per month, one expert estimates corporate America loses in excess of $10B annually through the misuse and abuse of spreadsheets." From the article: "The key point about spreadsheets is that you need to know which ones are critical to your business, which ones are merely important and which ones you do not have to bother too much about. Once you know that, you can start to apply appropriate policies depending on the criticality of the spreadsheet involved."
This discussion has been archived. No new comments can be posted.

$10B Annual Tab for Spreadsheet Errors?

Comments Filter:
  • Ummm (Score:5, Insightful)

    by Anonymous Coward on Sunday April 24, 2005 @07:29PM (#12332535)
    Documents have typos. Film at 11.
  • by Anonymous Coward on Sunday April 24, 2005 @07:30PM (#12332538)
    people make mistakes.... it costs money.... next please?
  • GIGO (Score:2, Insightful)

    by OverlordQ ( 264228 ) on Sunday April 24, 2005 @07:30PM (#12332541) Journal
    Garbage In, Garbage Out

    Just because this deals with spreadsheets makes it news? I think people have had this problem since people started making inventories.
  • by appleLaserWriter ( 91994 ) on Sunday April 24, 2005 @07:33PM (#12332558)
    Spreadsheets aren't costing money, any more than pencil and paper costs money. It is the bad math that costs money.

    I'd bet a LOT of money that fewer mistakes are made with spreadsheets than by people who think they can do perfect math in their head, or perfect long division or multiplication on paper.
  • by aendeuryu ( 844048 ) on Sunday April 24, 2005 @07:34PM (#12332563)
    One small problem with spreadsheets is that people sometimes use them instead of databases, I guess because the interface seems simpler than making a properly developed interface to a database from the getgo. Then you get locked into the solution, etc.

    This was definitely a problem at my old job. They wanted to create a payroll sheet to keep track of hours, and the easiest way to do it was via a spreadsheet. I was the most programming-savvy person there (heh, you can already smell their doom), at so, not having any database training, I created a really suped-up spreadsheet that handled it for them. It was GREAT, until we had a work situation in which some people worked past 12:00 at night. At that point, people's total shift hours came out negative. We got it fixed eventually, but it involved some really nasty calculation, and it was a problem that could have much more easily fixed if it'd been done by database from the start.
  • by ScentCone ( 795499 ) on Sunday April 24, 2005 @07:35PM (#12332570)
    abuse of spreadsheets

    Is it just me, or is that just a wee bit breathless, from an analytical point of view? I doubt that even "misuse" really even has the right connotation, here. More like, misuse of math.
  • by geophile ( 16995 ) <jao@NOspAM.geophile.com> on Sunday April 24, 2005 @07:35PM (#12332571) Homepage
    If I undercharge due to a spreadsheet error, then I'm out $N, but someone else is $N better off.

    If only there were some consulting company, someone who I could call to help me implement some best practicies, to help me avoid these tragic errors. Do PWC and KPMG know anyone who can help?
  • Re:Primary error (Score:4, Insightful)

    by kaiser423 ( 828989 ) on Sunday April 24, 2005 @07:39PM (#12332603)
    Well, that matters on how you're using the spreadsheet.

    Also, if you're doing it by hand, how would that stop that error from propogating on down. I remember when I used to do tons of basic math by hand, little errors would still propagate through. At least with a spreadsheet, you can program in some error-checking logic.

    With a spreadsheet it's a lot easier to get the same answer multiple times rather than doing it by hand each time.

    There's nothing inherently evil with electronic spreadsheets. We had been using paper ones forever before then, and they had the same (and in many cases, worse) problems.
  • by Metaphorically ( 841874 ) * on Sunday April 24, 2005 @07:43PM (#12332621) Homepage
    The scary thing is the suggestion that the IT department should take over spreadsheets. Many people use a spreadsheet for applications that would better be served by a database with the appropriate front end and back end, or a dedicated software application. This article mentions managers specifically, but lots of employees whip up a spreadsheet and throw in some macros then find that the spreadsheet grows to a point of some real usefulness.

    It's when the spreadsheet becomes useful that people realize it's not scalable (maybe they don't use that word, but I do) and can be tough to maintain.

    Not to single out IT departments in particular, but I think the reason that these spreadsheets start up and grow is specifically that it's often difficult to get someone in another department to understand your needs well enough to make the tool that you really need.

    Today managers can't fund a good solution because their budget doesn't allow for the necessary development. Tomorrow they won't be able to afford to get the support they need to get a spreadsheet done.

    I don't have a great solution outside of better training for people on how to make spreadsheets that serve their needs.
  • Loses 10 Billion? (Score:2, Insightful)

    by tyleroar ( 614054 ) on Sunday April 24, 2005 @07:44PM (#12332635) Homepage
    I don't get his point. Of course there are going to be some errors within the spreadsheets. Does this mean people are actually losing money because of it? The benefit that they provide far outweighs its disadvantage.
  • by G4from128k ( 686170 ) on Sunday April 24, 2005 @07:47PM (#12332657)
    Although spreadsheets can contain costly errors, so can programs written in any language. I would argue that spreadsheets are a very powerful IDE for a wide class of small problems and can more easily create software with lower rates of errors than other "language oriented" approaches to software development.

    The reason spreadsheets provide superior debugging versus language-based software is that they instantly display the intermediate results of the formula every time the inputs or formulae change. Change one number in the inputs and the programmer can instantly see the intermediate and final calculations and do a visual sanity check on the results. In contrast, language-based software creates several impediments such as a manual edit-compile-run cycle, manual/isolated debugging statements, and few easy ways to visually monitor all the values of all the intermediate variables.

    Don't get me wrong, spreadsheets have some severe limits. First, they can provide too much power to developers with too little experience/competence. If the developer is an idiot, they are more likely to be able to create a spreadsheet than a program, but just as likely to create (and not find) serious logical error. Programming languages, to some extent, create a barrier that blocks morons (not always). Second, spreadsheets don't scale to large/complex problems very easily. Some of this reflects the monopolist state of the spreadsheet market -- the lack of competition for Excel means that it has not substantively improved in the last decade. (e.g., why is Excel still limited to 256 columns?!?!?).
  • by johnnick ( 188363 ) on Sunday April 24, 2005 @07:50PM (#12332668)
    This one has been known for a while, but perhaps the FUD associated with a number like "10 BILLION DOLLARS" (said in appropriately Dr. Evil-ish fashion) could get some attention.

    Spreadsheet functionality enables people to bury calculations and they become legacy tools within departments. They are like some of the worst spaghetti code. Someone who may be a serious spreadsheet jock develops a neat tool and it gets implemented in his/her department. The jock leaves, but the tool stays and continues to be used, despite the fact that no one left really knows how it works. Even assuming that there are no errors in it, as circumstances change, the spreadsheet might not produce the "correct" answer, but everyone accepts the answer produced by the legacy spreadsheet because "that's the way we've always done it." And, should someone attempt to modify the spreadsheet, they could get bitten by buried or misunderstood calculations.

    Also, spreadsheets enable executives to embed assumptions and play "what ifs" with their forecasts, which is good. But then they use the scenarios they like best to get their pet projects approved using some rather suspect forecasts that "must be true because that's what Excel says the results are."

    Spreadsheets are valuable tools, but, like any tool, you can get bitten if you don't really understand what you're using.

    John
  • by SerialHistorian ( 565638 ) on Sunday April 24, 2005 @07:53PM (#12332682)
    How do spreadsheets cost companies money?
    Just about everything in many companies is tracked on spreadsheets. Expenses, costs, estimates, budgets, projects, etcetera so on so forth.

    Often times, employees will use spreadsheets when a database (even Access) should've bene used. As soon as the spreadsheet becomes 'mission-critical' and contains information that is used to run the business and cannot be lost, you'll start to see employees whose sole job is to feed, maintain, and munge that spreadsheet. When data's in a format like Excel that can be shakey, you can see data errors start to build up when one page is dependent on another page which is dependent on another page which is dependent on some figure buried back in cell DA256 on Page 5 of the workbook... which is dependent on some other figure ... which gets munged or erased due to a
    And the worst part is that it's usually impossible to trace these errors back because there's no way to take a step away from it or a debug tool.

    (How do I know this? I write custom software for small businesses that realize that they can't continue doing business the way they're doing it.)
  • by Klivian ( 850755 ) on Sunday April 24, 2005 @07:55PM (#12332696)
    >It is the bad math that costs money.
    Wrong, it's not bad math it's wrong use of math. It's more the case of using wrong models to solve problems.

    >fewer mistakes are made with spreadsheets
    That should read, more mistakes are made faster with spreadsheets. Take a simple example like a spreadsheet to calculate the cost of some project. Lots of places they use a template, filling in some values and the spreadsheet does the rest. Small mistakes in the template can become seriously expensive when all is accumulated.
  • Re:Primary error (Score:5, Insightful)

    by bcrowell ( 177657 ) on Sunday April 24, 2005 @08:11PM (#12332776) Homepage
    Many people say that the whole idea or spreadsheets is fundamentally flawed because a single error can propagate itself throughout the whole spreadsheet so a miscalculation early on tends to expand exponentially down to the rest.
    Well, that would be that case no matter how the calculation was done, wouldn't it? I think the issue is more that spreadsheets tend to be impossible to test or debug adequately. It's like spaghetti code without comments. Of course in a simple case, each column has a clear name, and the calculation flows nicely from left to right, and everybody understands what it's doing. But that's like saying that in a simple case, FORTAN programs flow from top to bottom, and everybody understands what they're doing.

    I know at least one not-pointy-haired boss (my mom) who has had major problems with spreadsheets created by employees that are flaky, poorly documented, or poorly understood.

    The good news is that spreadsheets let people who aren't programmers do all kinds of fancy calculations on a computer. The bad news is that spreadsheets let people who aren't programmers do all kinds of fancy calculations on a computer.

  • by Anonymous Coward on Sunday April 24, 2005 @08:15PM (#12332795)
    Rule1 - Never! Never! Never! put your busness on a speadsheet.

    Rule2 - refer to rule 1

    There is nothing wrong with speadsheets and they are very usefull for analysis but what happens is people try to use them for everything and eventually you have a spreadsheet that is used as a company database.

    Yes I am aware you can lock a spreadsheet but how long before someone (usually a manager) makes a "special" change and before long all sorts of "special" changes occur and things start to get rapidly out of synch.

    A simple analogy is how may people have ever seen simple Unix groups work really well, now take that one step further to ACL's and it starts to get interesting. This is particularly true when you have many people wanting to make changes. The poor Sys Admin can only duck and run for cover.
  • by MichaelSmith ( 789609 ) on Sunday April 24, 2005 @08:25PM (#12332847) Homepage Journal

    The big problem with spreadsheets is that they are increasingly being used to implement software, but that the architecture they provide (a matrix of expressions) makes it almost impossible to validate the code.

    If the CFO of $COMPANY produces a spreadsheet demonstrating that all is well with the company finances then it is difficult to prove him wrong.

    This may be what went wrong with companies like Worldcom. They could have had one spreadsheet for insiders and another for auditors.

  • by yota ( 165006 ) on Sunday April 24, 2005 @08:35PM (#12332891)

    The big problem with spreadsheets is that they are increasingly being used to implement software, but that the architecture they provide (a matrix of expressions) makes it almost impossible to validate the code.

    ... which is something which companies like Pwc and KPMG started, with their quick and dirty approach to consulting, in order to save time and margin! It's the same with the PPT slides, which now have took the place of all reports but with way less informative content.

    Looks like they could have found a new line of business: give professional advice how to solve the problems generated by their professional advice, whoops... this is the old consulting business model!

    Andrea

  • by boots@work ( 17305 ) on Sunday April 24, 2005 @08:39PM (#12332905)
    I think book-keeping errors really do have a cost. If you unintentionally undercharge then you've inserted a market inefficiency. Suppose because you undercharged, you have a cashflow problem, which then causes a rippling disruption through your suppliers and employees. Suppose you go broke because of spreadsheet errors, and then all your customers can't buy your stuff anymore.

    Take your point about PwC and KPMG though.
  • by illusion_2K ( 187951 ) <slashdot@nosPAm.dissolve.ca> on Sunday April 24, 2005 @08:58PM (#12332987) Homepage

    'Spreadsheet sprawl' is the problem and OLAP [google.com] (online analytical processing [wikipedia.org]) is the answer.

    Of course the whole 'best tool' addage applies, but the problem with that is that most people don't realize what sort of tools there are out there for centralizing information (ala data warehousing [wikipedia.org] - wikipedia or google directory version [google.com]).

    A bonus to these tools is that of the three that I deal with; SAS, Cognos and Business Objects/Crystal Reports, all have some sort of plugin for Excel whereby it can be linked to a repository of information. The main problem is that these tools do require more $$$ than just getting a copy of Microsoft Office and the sticker-shock probably turns off many a PHB (to say nothing of those who have no idea in the first place).

  • by IntlHarvester ( 11985 ) on Sunday April 24, 2005 @09:16PM (#12333048) Journal
    > Not to single out IT departments

    I will single out IT Depts -- On many occassions, I've seen IT actually fight to prevent users from using programming tools (even if it's just VB or Access). If the only programming tool on one's programmable computer is the Excel macro language, people have little other choice but to use it. Usually IT's reasoning is some "enterprise J2EE initiative" or "next years ERP implemenation" or some other phony politics.

    (And even if a poor luser gets his hands on VB, good luck getting any sort of rights on a RDBMS system.)

    I think this all stems from the nerd prejudice that only they know the secrets of the machine. In most organizations I've been in, there's usually some business analysts or finance people that are capable of putting together solutions to their problems.
  • Not surprised (Score:5, Insightful)

    by slamb ( 119285 ) * on Sunday April 24, 2005 @09:23PM (#12333077) Homepage
    Most programmers have no little use for spreadsheets, so we don't know how bad they are. We've got a lot of principles that we apply to our own work, but we don't see that the business people are struggling with the same problems without the proper tools.

    I made a couple spreadsheets recently, and here's what I found:

    Fragile references

    They're still referencing virtually everything by [A-Z]\d+. This is beyond GOTO considered harmful - when Dijkstra made that claim, we at least could do "goto blah" instead of "GOTO 2050".

    Excel has a couple "solutions", neither of which are good:

    • You can assign names to cells, but not in a way like "the total of the yearly column of the expenses table". Even if it's in the List Manager, there's still a [A-Z]\d+ cell reference between.
    • It has relative and absolute references. Relative ones will basically update correctly when you move the source. Both kinds will basically update correctly when you move the target. They've made some effort to make range references expand and contract, too. But it's a heuristic; it's guessing information it doesn't really have.

    Massive code duplication

    In my spreadsheet today, I ended up with whole columns of formulas like this:

    =VLOOKUP((A4-FedStdDeduction),FedTaxRates,2,TRUE) +((A4-FedStdDeduction)-VLOOKUP((A4-FedStdDeduction ),FedTaxRates,1,TRUE)) * VLOOKUP((A4-FedStdDeduction),FedTaxRates,3,TRUE)

    I would have much rather made a function FedIncomeTax(AdjustedGrossIncome) that applied that same bracket logic. Once. And called it the N times necessary. You can define VBA functions, but I didn't see a way to reference cells from them. (Probably because it doesn't have a reliable way to do the dependency/error tracking seamlessly. I can think of how I'd accomplish that in Python...but Python is a very flexible language.)

    Unreadable code

    There's no way to put longer bits of properly-indented, commented code in there. Certainly related to the above; you're trying to cram way too much stuff into a cell (or group of cells) that's massively repeated, so no one even thinks of doing this.

    Poor layout

    The result looks poor in a couple ways:

    • There's no automatic greybarring (alternating light/dark backgrounds for rows). So you can get lost when reading a big table.
    • An entire worksheet column has the same width. If you have two lists on the same page, inevitably one of them will end up with an awkwardly-sized column.

    Poor charting abilities

    It didn't have much support for charts with confidence intervals. (Don't tell me there's no use for these in finance! They may write everything out to the nearest cent, but that doesn't mean they don't made wild-ass estimates when talking about the future.) If you want to do something like a box-and-whiskers graph, you have to do elaborate tricks [decisionsciences.org]. Even basic error bars have weird defaults; to get a meaningful confidence interval, you have to do custom stuff with ranges. The friendlier check boxes end up with the same-sized error bar for every point, which is worthless.

    Overall

    Just using Excel for my small needs was frustrating, and it's not because I don't know how to use it. (I can read Help files.) I can easily see how people would screw up badly with them and not notice.

    It'd be so much better if there were a more free-form document (no overal grid) you could throw 1-dimensional lists and 2-dimensional tables into. With support for formatting, referencing, and summarizing them well. (There shouldn't be [A-Z]\d+ references at all; the concept shouldn't exist.) Including the PivotTable stuff, of course. (Excel's one good point, though it could be better.)

    It also should have support for referencing external data easily - a RDBMS or CSV/

  • by Anonymous Coward on Sunday April 24, 2005 @09:26PM (#12333085)
    Ken Olsen, founder of Digital Equipment Corporation, made this rant about 15 years ago.
  • Re:Primary error (Score:2, Insightful)

    by LnxAddct ( 679316 ) <sgk25@drexel.edu> on Sunday April 24, 2005 @09:32PM (#12333112)
    But the nice thing with spreadsheets is that a correction to a flaw also instantly propagates through everything and you can more or less instantly fix any errors that there were rather then going through thousands of hand written sheets checking row by row and changing things by hand. There is always a chance for error in anything, the important part is how quickly you can correct those issues and in the end how much you can limit the total impact of such flaws.
    Regards,
    Steve
  • by Pfhreakaz0id ( 82141 ) on Sunday April 24, 2005 @10:58PM (#12333479)
    um, that's what the parent was talking about. Excel can do that. I've done it. A quick search on Microsoft office site turns it up (http://office.microsoft.com/training/training.asp x?AssetID=RC011831161033)

    Since we didn't have money for a full OLAP solution (even crystal reports was really out of our budget -- hell, even taking time to write the reports oursleves was out of our time budget), our solution was to build SQL views that were simplified and set up ODBC source on managers machines and then offer a small class (a couple hours) on how to use it.

    It gave the managers an interface they new (excel) and we knew they had right data. And if we changed stuff in the database, we could just redefine those views (with the same columun names), and there sheets would go right on working.

    You wouldn't belive the stuff a bean counter who has been working in excel for years can churn out in minutes. Charts, graphs, interactive "what if" scenarios by driving formulas off the values in certain input cells.

    Hell, I bash Microsoft Office all the time, but Excel rocks, even though I don't use it much.
  • Re:Other Losses? (Score:4, Insightful)

    by serutan ( 259622 ) <snoopdoug@geekaz ... minus physicist> on Sunday April 24, 2005 @11:43PM (#12333680) Homepage
    One thing the article also doesn't consider at all is what the error level was before spreadsheets were computerized. Spreadsheets have beeen around a lot longer than computers. A manual arithmetic mistake early on would propagate all the way to the bottom just like in Excel, but fixing it took a lot more work than changing one number.
  • by kbielefe ( 606566 ) <karl.bielefeldt@gma[ ]com ['il.' in gap]> on Sunday April 24, 2005 @11:52PM (#12333724)
    In my opinion the real problem is people are unable to see when their spreadsheet has grown to such a point that a professional database programmer is needed, because it was manageable as a spreadsheet in its early iterations.

    More than once I have had a relative ask me for advice about a spreadsheet that has become unmanageable. They lay down a set of requirements that obviously call for a custom database app written by a programmer. I tell them to hire someone to write it. A contractor or even an intern will do in most cases. They say they can't afford it, but also tell me they are wasting 10 hours a week just managing their current spreadsheet. They want a professional solution, but don't have enough respect for the work the professional does to hire one.

    Doc, I know you said I need brain surgery, but I can't afford it. When the tumor was small the headaches went away when I took an aspirin. Can't you just recommend a better kind of aspirin I can take?

  • by cgenman ( 325138 ) on Monday April 25, 2005 @12:07AM (#12333793) Homepage
    It's worse than that. The statistician takes a common problem, makes a few guesses, comes up with an exorbetant figure, and throws it out the window to use a bigger guess by a factor of 10

    So how much money is the Fortune 500 wasting annually? It is a simple sum: $165,000 times 9 times 500. That amounts to just shy of three quarters of a billion dollars. And is that anywhere near realistic? No. It is probably safe to say that corporate America, for example, loses in excess of $10bn annually through the misuse and abuse of spreadsheets. That's a big number

    A very big number. I wonder how such a large number was pulled out of such a small opening.

  • by enjo13 ( 444114 ) on Monday April 25, 2005 @12:29AM (#12333880) Homepage
    Just boggles the mind.

    "So how much money is the Fortune 500 wasting annually? It is a simple sum: $165,000 times 9 times 500. That amounts to just shy of three quarters of a billion dollars. And is that anywhere near realistic? No. It is probably safe to say that corporate America, for example, loses in excess of $10bn annually through the misuse and abuse of spreadsheets. That's a big number: it suggests a problem worth managing."

    Translated: If I take the actual numbers I have, it's a $750mil problem. By some magical feat, however, we can just assume that it's a $10bn problem because it makes my article seem MUCH more important.

    How can you possibly just increase the number THIRTEEN TIMES just to suit your needs. Show some integrity.. seriously.
  • by langoulant ( 657025 ) on Monday April 25, 2005 @12:31AM (#12333885)

    A programmer would be chastised for: cutting and pasting code; for not using revision control; and for obscured or hidden behaviour. Yet spreadsheet users commoly have all 3 problems.

    The problem is that spreadsheets have become increasingly complex without a corresponding adjustment to formal specification. Imagine if you were using a programming language that doesn't have formal type declarations.

    The are tools that assist businesses using visual modelling (much like scientists use) that can help detect and prevent errors in spreadsheets. Have a look at...

    XempleX [xemplex.com] or their product sheet Xemplex Product Overview [xemplex.com].

    p.s. I'm not affiliated with this company.

  • by mjfgates ( 150958 ) on Monday April 25, 2005 @12:37AM (#12333919)
    You've got to be young, because if you were old enough to remember VisiCalc, you would never have thought this.

    Most spreadsheets are made by the people on the ground-- secretaries, low-level managers, clerks. That's most of the problem right there; these folks tend to poke around randomly at a problem until they get something that "looks okay," and then forget how they got to a solution and just use it. God forbid that anything should change.
  • by Tony ( 765 ) on Monday April 25, 2005 @12:40AM (#12333935) Journal
    The ease of spreadsheet creation is the problem, not the solution. Yes, it allows non-computer-literate managers to create an analysis of a particular problem... but that analysis is often flawed, and it is nearly impossible (for any non-trivial spreadsheet) to figure out where the problem really lies.

    I have met several people who claimed to be "computer experts" based solely on their Lotus 1-2-3 / Quattro Pro / Excel expertise. It's all well-and-good to create a spreadsheet; but just like computer programming, you need some sort of development and quality control methodology. Too often (like, in say 99.999% of the cases) there is a single user creating a single spreadsheet that eventually controls some aspect of the way a business is run. There is no quality review; there is merely a, "yeah, that number looks right" phase.

    I've seen it too many times. It's endemic in business. I'm not surprised with the results of the study ("Spreadsheets considered bad"), though I'd rank the monetary valuation right up with the report I read 2 years ago, "Slow modems cost US businesses $4B yearly!").
  • by E Galois ( 857353 ) on Monday April 25, 2005 @12:46AM (#12333956)
    Anyone employing Excel for any statistical calculations should get a nice chill from reading any of B.D McCullough's papers on Microsoft's egregious (and mostly uncorrected or corrected badly) errors in this area.

    Click here [lfp.uba.ar] for a link to one of his recent critiques entitled:

    On the accuracy of statistical procedures in Microsoft Excel 2003

    Here is a nice quote from the above paper:

    "...persons who wish to use Excel for statistical purposes should exercise extreme caution...Persons desiring to conduct statistical analyses of data are advised not to use Excel 2003."

    "Excel is like a bikini. What it reveals is suggestive, but what it conceals is vital." -- apologies to Aaron Levenstein
  • by 2grhms ( 653219 ) on Monday April 25, 2005 @01:59AM (#12334167) Homepage
    This is not bad journalism. It is a serious article about a serious problem. Take people who have never written a program and have never heard of program-design-101, give them a huge collection of poorly documented functions and tell them construct a large complex program to calculate a number. Just how much would you trust that number? It is not hard to imagine what the resulting spreadsheet looks like. Now suppose that number is, say, the value of a mine, or road, or company. If your number is too low, you miss a great opportunity; if your number is too high, you buy the asset and subsequently lose a lot of money. In either case, the loss is serious money- hundreds of millions or more.

    I have spent the last two and a half years auditing spreadsheets for (1) complex financial transactions and (2) models for large public infrastructure projects. I work with a dozen other rocket scientists and actuarial types who specialise in this. My experience is consistent with "some professor from Hawaii", namely Ray Panko [hawaii.edu] who is the world expert in the field. Almost every worksheet of every model I have audited, has been riddled with potential and actual errors- and these spreadsheets are written by professionals and have been already reviewed internally. Auditors like KPMG and PWC are interested in whether an error is "material", i.e. big enough to effect the client's ultimate decision on whether to proceed at a given price. The sample size of 54 is large enough to give overwhelming evidence of the large number of errors, and of the proportion of such errors which are "material".

    All software has bugs when you write it. Reviewing your code, peer review, formal testing, code reviews help you reduce that. Even with this, how much released software is genuinely free of errors? I think perhaps TeX is. With spreadsheets, it is hard to write clearly and simply, it is hard to review, it is hard to test and you have no comments. There are going to be mistakes, and lots of them. If you are not seeing them, it is only because you are not looking. To make a spreadsheet (or any software) without errors you need to approach the problem like NASA. This, of course, requires a budget like NASA or a horde of open source zealots, and so PHBs and accountants need to decide when the cost of detection balances the risk of error.

    john@xq.se
  • Re:Ummm (Score:3, Insightful)

    by Baki ( 72515 ) on Monday April 25, 2005 @02:02AM (#12334177)
    The difference between a spreadsheet and an ordinary document is that a speadsheet is a kind of programming environment. End-users who think they can do the same job as professional software developers often build monstrous spreadsheets full of formulars, macro's and some VB for excel.

    I work at a large bank, making software to support the investment strategists. Often we find such situations where some strategist has built his own "program" using spreadsheets and sometimes some access "database". And in 99% of such cases these, of course, contain severe errors and thus produce garbage. I can imagine very well that this costs an enormous amount of money yearly.

    For years it has been a heated debate when we make some software program, if it should have an "export to excel" function or not. The end-users want it, in order to keep some control and be able to suck the data out of our system and then start playing around with their own "programs". The project management often want to prevent this (depending on the current political balance and power) because it is known that such playing around massively costs time, leads to irrational business processes and mostly causes erronous numbers and calculations to be used as basis for strategic decisions.
  • Code reviews! (Score:3, Insightful)

    by Calroth ( 310516 ) on Monday April 25, 2005 @02:28AM (#12334240)
    It seems to me that everyone else can pick up a few basic software engineering practices to tighten up the quality of their spreadsheets. Things like:

    Code reviews - give your spreadsheet to a buddy to check over. Have him or her review all the calculations. If you haven't explained them well enough, add comments.

    Change control - if you update your spreadsheet, keep old versions around and make a note of what you change. Find all numbers that total up different in this new version and explain why.

    Etc. etc. etc. I'm not saying that we should treat everyone else like programmers, or spreadsheets like programs. But a few simple practices like that and your PHB gets to claim that he personally saved the company $10B (and fixed the Internet).
  • Re:Ummm (Score:3, Insightful)

    by darkonc ( 47285 ) <stephen_samuel AT bcgreen DOT com> on Monday April 25, 2005 @02:35AM (#12334270) Homepage Journal
    So in this case, you can't eliminate all accounting mistakes and typos, but if some PHB needed to read this to question his spreadsheets, he's useless.

    I'd put it another way: Loss compared to what? If a spreadsheet saves a company $100K/month, but an error in the spreadsheet costs $10K/month, then the spreadsheet is still doing the company $90K net on the profit side of the ledger.

    Yes, it'd always be nice to kill that $10K bug, but until you do, you can still write it off as a cost of doing business.

    That having been said, if you'd like to pay me $70/hour to find your $10K error, I think it would be a good deal in both directions.

  • by j_w_d ( 114171 ) on Monday April 25, 2005 @02:52AM (#12334312)
    The article isn't about spreadsheets vs. pencil and paper; it's about improperly constructed spreadsheets and abysmally poor management of them. The plan may be perfectly good, but structural errors (such as a row inserted by somebody who "knows" it needs to be included, but doesn't know that the simple "fix" alters a critical cell address for a formula, and thus doesn't fix the formula) can have an indeterminately large effect throughout a model, since everything dependent upon that value will be in error. So, perhaps pencil and paper is more error prone, but a spreadsheet is more efficient at propagating it.

  • by Fulcrum of Evil ( 560260 ) on Monday April 25, 2005 @03:34AM (#12334394)

    Ohh but if they sell in bulk they reduce profits because people shop less and are locked in.

    Knowing them, they'd charge more per unit and count on the customer not to check, Sad thing is, they'd mostly get away with it.

  • Re:Ummm (Score:3, Insightful)

    by Angostura ( 703910 ) on Monday April 25, 2005 @06:50AM (#12334959)
    I'm sorry but this really annoys me, and I'm ever so glad that I'm not a user working a department that you serve.

    I love the implicit sneer in your scare quotes around "program" and "database".

    It's not surprising that investment strategists want to play around with their own models and investigate data on their own. It's part of what they are paid to-do.

    It seems to me that one way forward here would be to provide them with the Excel export that they want, but before it is enabled, the strategist has to agree to go on a compulsory 1 day course designed to explain the possible pitfalls of spreadsheet use and the compliance issues inherent in having unchecked spreadsheets lying about.

    Get them to sign a code of conduct which is part of their contract of employment following the course.

    Then give them their bloody Excel data and let them explore it.

If you think the system is working, ask someone who's waiting for a prompt.

Working...