What’s an “85% system” and what are its downsides?
I recently discussed a very frustrating client project with the Senior Consultant on the project. He shared an insight he had a couple days prior – our mutual frustrations stem from the fact that this client instructed us to develop an application that
handled only 85% of the possible situations the users might encounter. When the application was up and running, the client thought it was our fault when the application we had developed didn't handle the 15% we intentionally – after giving appropriate warnings to the client – didn’t address. As I said – frustrating.
As I thought further about this consultant’s observation, I realized a similar 85% comment could be made about a system implementation done by another client.
What is a “System”?
At Todd Herman Associates (THA), we view a System as being comprised of three parts, taken together:
- Process – The steps required to make a task, or a sequence of tasks, 100% complete.
- Technology – The application(s) aiding the Process.
- People – The persons who complete the tasks required by the Process, as aided by the Technology.
I recently changed my definition of Process from what I've used in the past – because I realized the tasks needed to be performed to 100% completion to satisfy both the people performing the tasks and the people relying upon the results produced by the system.
When any of these three parts – and, most commonly, the Technology (Application) part – are taken to only 85% completion, the result is an 85% System.
What's Wrong With an 85% Application?
When a process can be executed by one person – or perhaps by two persons working closely together – a simple macro-enabled Microsoft Excel spreadsheet or a simple Microsoft Access database that performs 85% of the overall process can suffice. The reason? Those carrying out the work know where Excel runs out of steam, or where results in Access need to be exported for final analysis and presentation in, say, Excel. They accept those limitations – they know it is an 85% application because they probably developed it.
An 85% application is fine, as long as there is no staff turnover, the volume of transactions remains low, and the complexity of the work does not change. If any of these factors change, different – and likely more – people will need to use this 85% application, and that's when the limitations become frustrating to everyone.
In such a case, either an off-the-shelf or a custom-developed application is needed to satisfy users and overcome the limitations of the original 85% application. There are two ways either type of new application can turn into an 85% application:
- All (100%) of the necessary capabilities of an off-the-shelf application are not implemented.
- All (100%) of the situations users may encounter are not coded into a custom-developed application.
Let's consider each scenario.
An Off-the-Shelf Application with Only 85% Implementation
We're working with a client where an industry-specific ERP (Enterprise Resource Planning) system was largely implemented by the Accounting staff, with little or no help from either the ERP developer or an outside consultant. By and large, the ERP system was configured correctly. The 85% comes in because the client did not have someone with knowledge of how to use the system's available tools to customize data entry screens, or with the technical chops to develop the reports the users really wanted. These two things have frustrated users for years, to the point where executives overseeing the lines of business using this ERP system wanted to select and implement a completely new ERP system. Fortunately, playing by the system's rules to customize data entry screens and using the right tools and techniques to develop useful reports is much easier than a “rip and replace” solution. Based on our review, this particular ERP system seems solid, so we're set to begin helping them address the issues with data entry screens and available reports and move it much closer to a 100% system.
A Custom-Developed Application Handling Only 85% of Routine Situations
Another client has always been “We've got to fix this one thing so users can get back to work...” That approach works with an application that largely handles all the routine situations users encounter. What happens, though, is every time one thing is fixed, 15% of the routine situations still cannot be handled.
The problem is compounded whenever new features are requested and developed because the client only shared with us how to handle 85% of the situations the new features would need to handle. Since the initial code could handle only 85% of the tasks and the new code could handle only 85% of a different set of tasks, the joint impact of the original code and the new features was to handle about 72% (85% * 85%) of the routine tasks. Add on two more sets of new features, each developed to client specifications to handle only 85% of the cases, and you get to reliably handling only 52% (85% * 85% * 85% * 85%) of the routine tasks.
The Moral of the Story
Whenever an application is implemented or developed to only 85% completion, a company has an 85% system. Getting beyond an 85% system requires more time and costs more money. While budget is always a consideration, I sense a good number of companies have not quantified the ongoing financial impact of their peoples’ inefficiencies and frustrations coming from an 85% system. Until they take these impacts into account and are willing to invest their time and finances, neither we – nor anyone else – can help them.
Sincerely,
Todd L. Herman
