Don't Waste Your Time Chasing Perfect

Not everything worth doing is worth doing to the nth degree. Just like you can overthink and over-engineer your technology, you can foolishly try to achieve levels of immediacy, proximity and precision that frankly no one really needs or cares about — except maybe a few of your geeky engineers. Pursuing perfection is a perfectly good way to burn through lots of cash, waste a lot of time and energy, and frustrate your own people in the process.

In the real world, good enough is often good enough. Trying to be better than that, or perfect, is more about your own neuroses or bragging rights than an attempt to address the actual needs, requirements and desires of your people, users or customers. The Six Sigma standard needs to take a step or two back because; while it's a great goal and a significant standard to shoot for in some businesses and contexts, it's a foolish fantasy and a false formula in the majority of cases.

Constant observation and measurement, ongoing review and iteration, and continuous improvement are essential to your long-term success. But getting too far ahead of your skis, spending more than you can afford shooting for levels of unnecessary precision, setting standards that make no sense and add no value to your offerings, or trying to address too broad a set of needs and customers are formulas for expensive failures. Worse yet, these ever-elusive objectives distract you, diverting attention and resources that need to be focused on far more critical needs.

Constant observation and measurement, ongoing review and iteration, and continuous improvement are essential to your long-term success. But getting too far ahead of your skis, spending more than you can afford shooting for levels of unnecessary precision, setting standards that make no sense and add no value to your offerings, or trying to address too broad a set of needs and customers are formulas for expensive failures.

It's way too easy in our metric-driven digital world to fall in love with stats and factoids and to pursue the numbers while losing sight of the end game. I remember long arguments with clients in one of my first businesses, where we tracked customer satisfaction by making millions of phone calls each year to consumers at home to determine how satisfied they had been with a recent experience. It might have been a service visit, a sales encounter, a meal or a hotel stay.

The clients (and their internal bean counters) were always worried about the numbers - how many interviews had we done, how many were fully completed, how many customers were happy or unhappy. And, believe me, I know those were important considerations. But what they never understood was that the most important measurement-- the real goal of the effort--was to successfully connect with and, if necessary, "fix" the customer. It was critical to show them that the reason for the call was because we cared about them and their satisfaction-- not that we needed to be sure that our CSI or NPS scores were up to snuff. And, even more importantly, that we would try to resolve any problems or issues they had. If we were interrupting something important, if they just didn't have time to talk, if they didn't care to participate, the critical action was not to push them or browbeat them into participating so we "completed" the interview. The proper thing was to politely apologize for bothering them at a bad time and hang up. Getting it right (not pissing the customers off) was more important than getting one more incremental interview done.

We see similar problems when IT departments exceed their brief and try to achieve levels of company-wide information access without balancing the potential risks to the business against the actual (not imagined or assumed) users' needs. Trying to create and maintain ubiquitous data solutions can create unnecessary exposures from a cyber security perspective without adding any incremental operational benefits. The truth is that all of the people almost never need access to all of your data, and especially not all of the time. This is the constant tension between "real time" and "right time" access that too few companies take the time to understand and manage.

The truth is that all of the people almost never need access to all of your data, and especially not all of the time. This is the constant tension between "real time" and "right time" access that too few companies take the time to understand and manage.

One of my favorite examples of how businesses are exposed to peril is the practice of giving employees working remotely real-time access to inventory, shipping and billing records on the company's main computer systems. Email and collaborative work groups are obvious instances that demand real time access and therefore present serious continuing risks--especially because overall employee compliance and security diligence generally still sucks. Yet there are other important, but less well-understood, areas where catastrophic business invasions, data and financial manipulations, and ransom lockups and accompanying demands are just as likely to arise.

The more frequent exposures and most serious breaches in these areas come through the most mundane of access points. Even worse, the entire business tends to assume that there are no exposures of consequence inherent in the activities around such basic processes. The facts are clearly otherwise and we hear every day about outside penetrations in which company and customer data is stolen, company funds and materials are misdirected and diverted, and millions of dollars of false receipts and invoices are created and fraudulently paid. All right under the noses of the company's financial and audit teams.

But there are some fairly simple solutions and almost every business can figure out a method within their SOPs to take a step or two back from the newest frontier and focus on protecting their basic business instead. And here's a flash: you as the boss need to worry about this because your IT guys are all about the latest and greatest and fastest and they will quickly lead you off in the wrong direction if you don't aggressively rein them in.

They know that it only takes one security hiccup to bring the house down on their heads and they know that such a breach is fairly inevitable and that, at best, they can only play for a tie anyway against the bad guys. So, they spend their time focused on the things they can control (and "improve") like access, speed and response times even if the net effect is to increase the company's exposure to external threats.

But you can do better than that and greatly improve your company's odds of avoiding a data disaster. And you can do it quickly and without spending a lot of time or money. There are a bunch of approaches like air gaps and sneaker net systems, but I'm just going to focus on the one I've used successfully in the past which I call the DMZ approach.

To build your own DMZ, you start by asking, who outside your four walls needs access to your internal data and servers, why they need it, and how immediately they need it-- both in terms of access and in terms of the timeliness of the data they are trying to get. What you will find is that a lot of people need little or no immediate access (if they ever need it at all) and that a lot more people can live very happily with levels of access and immediacy that get the job done for them without exposing or jeopardizing any of the company's critical servers and systems. Once you scope and scale the problem, building a straightforward solution is simple.

In our case(s), we knew that we had hundreds of sales and support people in the field and they needed to make regular inquiries. BUT they rarely needed the information they were seeking to be real-time data. It was totally acceptable for more than 95% of the inquiries for specified data to be delivered same day-- not last second. And so, we built the DMZ, which was just a disconnected data repository into which we dumped, and regularly refreshed, relatively current data up to 8 times in a 24-hour business day. Everyone in the field could access that data any time, but those inquiries were never connected or attached in any way to our in-house servers. They had sufficient and timely information to respond to their needs and their customers, and we had a one-way, bullet-proof system that never let the outside world directly access our systems. Everyone in the place slept better and no one was really any the wiser or missing anything they really needed to do their jobs. You should ask the same questions of your own systems before you have your own breach.

Bottom line: even if we could give everyone on the team perfect information in real time and at all times, we couldn't afford it and it wasn't worth the attendant risks. Good enough to get the job done is good enough.

To view the original article at Inc.com, click here.