My project is currently debating the usefulness of Excel in eGovernment projects for Emerging Markets.  It’s not much of a debate; everyone agrees that Excel is not an appropriate platform for a sovereign (or even a semi-autonomous) region to use to manage anything.

Yet, its siren call remains.  Excel seduces because there is limited connectivity.  Its omnipresence – and the sunk cost of the license fee – beckons.  Developers and users are comforted by its familiarity.  Implementors tell donors that it’s just a fling, a temporary solution.  The affair begins, but next thing they know, they are crashing against the rocks.

I advocate for prototypes to gather data, set up business processes, and define functional requirements, so I am not blind to Excel’s appeal.  (To kill the metaphor, imagine me blindfolded and thrashed to the mast of Ulysses’ ship as it drifts to an enchanted Microsoft island.)  But even for prototypes, I think that costs of implementing an Excel-based solution far outweigh the benefits.  In the final reckoning, there is one good argument for Excel, two arguments against Excel, and four bogus arguments that are just myths.

Before I go through each of these arguments, I want to establish a few assumptions.  First, we’re assuming that an experienced VBA developer creates the Excel solution.  The solution catches errors, is flexible, and runs quickly.  This is not always the case, but I want to give the benefit of the doubt.  Second, there is zero connectivity.  Once again, this is not always the case (most places have some limited, occasional bandwidth through V-Sats), but I didn’t want to split hairs.  Third, the implementing partner has access to developers who have skills beyond VBA.  I suspect that Excel is often adopted out of ignorance of other solutions, but I want to assume that everyone has the resources to do what is right and not just what is expedient.

So here are the arguments.  Let’s start with the good news.

The Argument for Excel

I want to be fair and look at both sides of the coin, but after a lot of thought I can only think of one argument that supports using Excel as an eGovernment platform and even that argument comes with caveats.

Excel is Easy. I am a fan of VBA, the programming language that enables custom Excel solutions.  I have developed solutions with it (and continue to develop with it) for over 10 years.   A good developer can develop a beta-application in hours, test it over days, and deploy it over weeks.  VBA in Excel is easy to modify and while it is optimized for calculations, you can create acceptable user forms and interfaces.    In a short amount of time, Excel workbook can become a prototype and test a solution to support business processes.

If, however, the (experienced) developer has struggled to fix an error prone solution for months, it probably means that Excel is not the right tool to solve the problem.   Excel isn’t the right software for many problems (writing reports, drawing pictures, sending emails).  Excel is useful for financial models, some types of data entry, and data manipulation.  It should not be used for everything.

The Argument against Excel

Sometimes I fear that these arguments are so obvious that people don’t even mention them.    Nevertheless, they are important reasons not to use Excel.  Let’s get through them quickly.

Excel is not Scalable. Deploying an Excel solution is like putting a male and female bunny in a cage.  Little Excel solutions will be hopping around very soon.   The best argument against Excel is that it creates an operating environment where information lives on desktops and is inaccessible to the entire organization.  It empowers a single user, but does not provide enhanced capabilities to the entire organization.

Excel is not Secure. While it is possible to protect worksheets and prevent a user from ruining a developer’s precious code, it is much more difficult to implement even the most basic security requirements.  There is no (easy, automated) way to enable segregation of duties, where one use enters information and other user approves the data.  There is no (easy, automated) way to track who has viewed or modified the worksheet.  There is no (easy, automated) way to check to see if the person making updates has the authority to make those changes.   Using Excel in a context where people have incentives to be dishonest (such as payroll or financial management) is asking for trouble.

The False Arguments

These are the most interesting – and infuriating – arguments for Excel.  People make claims that Excel solves intractable problems when often Excel makes these problems worse.

Excel is a Low-Bandwidth Solution. This used to be one of the most compelling arguments for Excel, but new web standards have allowed web-browsers to emerge as strong competitor.   Modern web-browsers, which can run JavaScript and have offline data storage, offer a compelling alternative to Excel.  These solutions can run when there isn’t a network connection and can output data in formats such as XML that can easily be transferred.    An added benefit is that when connectivity becomes available, the same interface can synchronize with central data-stores and be used in an online environment.  This solution is much more elegant (albeit harder to develop) than relying on a desktop-based application like Excel.

Excel is Available on Every Computer. According to Forrester Research, 80% of enterprise companies use Microsoft Office for worker collaboration and productivity.  We’ll ignore the 20% that don’t use Office and assume Excel truly is omnipresent.   In theory, since Excel is already installed on the user’s computer, the VBA solution should work without any modifications.  In practice, however, Excel’s security settings prevent VBA code from running by default.  While this prevents malicious code from hacking into a computer, it also make deploying a solution fairly complicated.  In addition, changes between Excel 2003, 2008 and (soon) 2010 complicate testing and deployment.  It’s available, but it isn’t consistent and it still requires manual installation.

Excel is Familiar. Even if people know how to use Excel, they will not know how to use the Excel solution that addresses the eGovernment problem.   Training will be required.  Worse, Excel’s worksheet, row, column, and cell structure constrains developers and offers limited options for creating intuitive interfaces.  For example, there is no easy way to validate an entire record (as opposed to a single cell) before the solution stores the record.  Likewise, creating interfaces that support workflow and approvals is very difficult in Excel.  Ultimately, this results in unintuitive solutions that need more training.

Excel is a Temporary Solution. It’s common to hear people claim that they are building an Excel based solution as an interim fix before they can deploy the solution that will last for all eternity.  Unfortunately, that claim is rarely supported by clear plans – and timelines – to actually design and deploy the sustainable enterprise tool that will replace Excel.  Temporary solutions sans a clear plan for depreciation are permanent solutions.


If you’re debating whether to use Excel to produce an eGovernment solution, ask yourself the following questions:

  • Do I want the solution to support multiple users?
  • Is the information sensitive?  Can modifying the information hide corruption?
  • Do I want this solution to last for more than six months?

If the answer to any of those questions is yes, don’t use Excel as a development platform.  Excel is a great tool for many things, but it isn’t a great tool for everything.   When someone suggests using it for an eGovernment project, be wary of the false arguments.