I have now been using spreadsheets for a quarter of a century. When I started as an analyst trainee, my boss said I should spend some time learning about a new product, Lotus 1-2-3, so the department could figure out whether and how to use it.

A few months later, at the Lotus Development IPO road show, I happened to sit next to Mitch Kapor. I knew he was from the company, but I thought given his age he might be a district sales manager or something. Since I had used every function and command of the program, I proceeded to give him a full critique and suggested detailed improvements. Then the underwriters got up and introduced Kapor as the founder of the company. I was a bit embarrassed — the trainee that lectured the founder.

Today, spreadsheets are used to analyze and operate organizations of all types.Of course, with the introduction of Excel, Microsoft grabbed the business from Lotus, just as Lotus had grabbed it from VisiCalc. They are ubiquitous in the investment business; it is impossible to imagine how we did without them, or to underestimate how critical they are in the investment processes of most every firm.

Unfortunately, most shops do not have a thorough understanding of the columns and rows that underpin the decisions that they make. In most cases, the models and databases are created by the users themselves, many of whom lack the programming skills to make their spreadsheets “industrial strength.” Consequently, there are weaknesses in the analytical foundation that are not evident. Occasionally we read about failures stemming from a faulty spreadsheet. More often such problems do damage but don’t make headlines in the Wall Street Journal.

In the skill set section of every résumé that you receive, it says the candidate can do wonders with Excel, and no doubt many can, when the capabilities are defined narrowly as the ability to produce an analysis using functions to analyze a straightforward problem. Beyond that, very few users construct their spreadsheets in ways that provide the structure, safeguards, error checking, and navigation that allow others to understand whether a mission-critical application is properly composed, or to actually use it as intended in the absence of the creator. No one really teaches this stuff, and most users are too busy doing their real jobs to learn it on the fly.

How does your firm deal with the inherent weaknesses in the standard user-built approach? If you don’t have a plan, you probably have a problem.