This is part one of a two-part post examining the use case for moving your business from spreadsheets to custom software. This blog helps you identify whether you're at an operational inflection point, and Part 2 will offer considerations to help you manage this transition without sacrificing the qualities that make your business successful.
The business case for using spreadsheets to support organizational operations is a compelling one. The creators of Lotus 1-2-3 understood this in the 1980’s. Then, Microsoft made spreadsheets more powerful and accessible with Excel in the 1990’s—and growing numbers of businesses have been using spreadsheets ever since.
As personal computers have grown ubiquitous, and with the advent of cloud services like Google Drive, spreadsheets continue to be used more and more. And, understandably so. Spreadsheets are powerful, flexible, widely available, and have little to no upfront cost to obtain and use. At the same time, though, advances in the web have made custom software development relatively quick and accessible to a wider range of businesses and organizations. Many businesses don’t recognize when to switch from relying on spreadsheets to investing in this precious asset.
A client once came to us for support for their Google spreadsheet. It turns out that the person who developed the logic for the spreadsheet left the company abruptly, and the owner did not know where to turn. In the wake of the departed employee, the spreadsheet would break regularly. When this happened, it was easy for an employee to lose an entire day due to the need to process orders manually. This cycle repeated for months before they contacted a software firm—and when we engaged with the client, the situation had grown pretty dire.
This story points to the emergence of an inflection point in the lifecycle of a business, whereby the stresses of operating on a spreadsheet become apparent. I have observed similar scenarios on multiple occasions, and hope to help organizations recognize when these inflection points are occuring.
Let’s take a brief moment to explore what I mean when I say inflection point. Andy Grove, Intel Corporation’s third, and perhaps most renowned CEO, popularized the concept of the strategic inflection point in his book Only the Paranoid Survive (page 32). In the book he says:
“An inflection point occurs when the old strategic picture dissolves and gives way to the new, allowing the business to ascend to new heights...a strategic inflection point is when the balance of forces shifts from the old structure, from the old ways of doing business and the old ways of competing, to the new.”
Given that he’s discussing business strategy, his discussion about the strategic inflection point is about factors that are occurring outside of the business—changing attitudes of customers, new competitors, and a growing disconnect between what you think your business is doing in the market versus what it is actually doing. However, this same principle can be applied internally. Let us turn our focus inward and place the above into an operational context. For the sake of this discussion, we’ll call it an operational inflection point.
An operational inflection point occurs when a business’s operations reach a point where a business needs to adjust its way of operating or risk losing customers, employees, data, money, and more. Using spreadsheets is often a good initial solution while a business is getting started. But, as the business is scaling up, it can be easy to overlook their technical limitations. Once reliance on spreadsheets has been identified as a problem, there is hope.
The process of moving to custom software can seem daunting—especially for those who have never embarked on or managed such a project before. Here are some things that can aid in helping you make a smooth transition from operating your business on spreadsheets to utilizing custom software.
Set a clear vision for the new system
It may sound cliche, but your software project will need a clearly articulated vision. A classic mistake when businesses are going from spreadsheets to custom software is to just duplicate what the spreadsheet was doing. Businesses that are operating on spreadsheets rely on a lot of manual procedures. Many—dare I say, most—of those manual procedures can be automated, saving your business both time and money, and freeing up people to work on other priorities within the organization.
To craft a clear vision for the custom software project, ask and document the following:
What is absolutely essential in order for your new application to be usable?
This is often referred to as the Minimum Viable Product (MVP) and is the first critical milestone for any new custom software project. The goal for embarking on a new project should be to reach this milestone as soon as possible without sacrificing the quality of its implementation. This can be one of the trickiest things to decide on, because it requires breaking down all of the things that people in your business have been doing routinely and subconsciously. Also, there often tends to be the assumption that everything that has been happening in the spreadsheet needs to happen the exact same way in the new application. This is not always true.
Businesses that operate on spreadsheets are accustomed to a great deal of manual processes. For example, data is often entered into them manually by one or a small group of trusted employees; and once data is input, that person is responsible for triggering the next part of the workflow. The degree to which manual processes are happening might be hard to recognize. As you move to custom software, the developer will be able to help you gain operational efficiencies—sometimes very easily. You’ll need to determine which of these are necessary at the first release and which you’ll be able to improve over time.
Codify your workflows
The better you are able to articulate your business’s workflows, the better chance you have at being able to transition from a system of using spreadsheets to using a custom application. It’s likely that your workflows are pretty well codified depending on your spreadsheet setup. If this is the case, it’s important to articulate that workflow to the developer.
As you’re thinking about your workflows, another important thing to think about is what data is important to maintain and preserve. Building in the proper workflows can also ensure that the appropriate data is being collected—and at the appropriate time.
There are some processes that are unique to your business and others that are common to all businesses. Your new custom software application should capture and encompass the parts of your operations that are distinct, while leveraging simple and cheaper third-party solutions for the processes that are not unique. For example, for most businesses, accounting is pretty standard. Unless your way of doing accounting is a core differentiator, you should be able to get by without needing a developer to create an accounting feature. For that, you could purchase a Software as a Service (SaaS) accounting membership and have the developer create a way to have your custom application talk to that system.
What projects are likely in the future?
Changes are hard to anticipate. But, maintaining and communicating a wish list or future projects before the current project begins helps the developer to make decisions that can pave the way for less time-intensive changes or additions later on. For example, if you know that you’re going to want a mobile app in the future but today all that’s needed is a web application, the developer can architect the application with this in mind.
Identifying that your business is at an operational inflection point is just the first step. When you begin exploring custom software solutions, you'll want to make sure you find a partner you can trust, and work through a deliberate process that ensures your app does what your business needs it to.
I'll explain this process and offer some tips to make the most of it in Part 2.