Platt Perspective on Business and Technology

Finding virtue in simplicity when complexity becomes problematical, and vice versa 8

Posted in social networking and business by Timothy Platt on January 15, 2018

This is my eighth installment to a brief series on simplicity and complexity in business communications, and in carrying out and evaluating the results of business processes, tasks and projects (see Social Networking and Business 2), postings 257 and loosely following for Parts 1-7.)

I focused in Part 7 on Information Technology help desks, and on rarer help desk long tail problems and disruptively new and novel challenges that arise in the midst of the more standard and routine issues recurringly faced there. I focused there, in general terms, on the issues of identifying and understanding these special case problems for what they are. And I focused there on bringing the right people into the conversations that are needed for resolving them, and with mutual understanding among all involved in that, in the face of specialty-speak jargon and in the face of information access partitioning as arise in all functional areas and in all professional specialties. That usually means, to cite a specific requirement for achieving this: bringing the right combinations of people together and from both sides of the Help Desk, and into direct communications with each other, disintermediating these communications by eliminating unnecessary gatekeepers and middlemen from these processes, who would primarily just add to any information sharing friction that might arise.

Then I stated at the end of Part 7 that I would continue its discussion by delving in at least some more detail into the issues and challenges of more effectively resolving these and other rare (at least at first) event challenges. And in anticipation of that discussion to come, I added that this will mean my reconsidering the issues and opportunities of intranets and of how social networking and interactivity can facilitate better communications and problem resolution. And I begin address all of this with the fundamentals and build from there:

• Every help desk that I have ever heard of, let alone worked with, has always faced an array of problems to resolve that fit a Pareto principle pattern, and a strong form of that with on the order of 90% or more of all help requests fitting into a top ten or top dozen or so list of recurring problems and the remaining percentage of requests arriving as exceptions.
• Primary help desk support focuses on that recurring 90% fraction, and with standardized responses developed for both identifying and resolving all of them.
• Anything else arriving as a problem requiring help desk assistance is either one of a seemingly open ended array of individually much rarer long tail challenges that are at least in principle already at least known of,
• Or they are new and probably disruptively new types of problems that no one there, by definition, start out prepared to fully identify for their details, or resolve. These problems, I add can arise in older and more familiar technologies that are at least in principle already pretty well known, and as easily as they can from new technology that the business is just becoming familiar with. All it takes, for the former of these two possibilities to apply, is the introduction of a new way to use a technology already in place, that brings people to test out and use aspects of it that the business and its employees have never had to face before. Even genuine zero-day vulnerabilities can emerge into visibility that way and certainly for complex software applications and larger software systems.
• Resolving a problem that arrives at a help desk begins with understanding what it is, and with correctly identifying it. That is easy and straightforward for the roughly 90% of them that are both known and expected, and that are thoroughly prepared for.
• The more novel: the less known and expected, the more of a challenge it can be to distinguish between symptoms that an employee faces that arise from some underlying problem, and the actual underlying problem itself that would have to be addressed. And the more novel such a problem is, the less likely it is that the first help desk staffer who faces it will either be able to resolve this on their own, or that they will automatically know precisely who they should escalate this help request to for resolution.
• So they will probably take a first try at it themselves, and certainly if a help request problem has features (in its symptoms) that look somewhat familiar to them. And then they will escalate it to one of a fixed list of more experienced help desk trouble shooters who in effect specialize there, in dealing with escalated help requests (insofar as they do help desk work as part of their jobs.)
• Then they will try resolving matters there, working or at least attempting to work with the people who first called such a problem in, in order to gather the details on what happened.
• If they cannot resolve it either, they will reach out to whatever specialists they think would be needed to solve this still-open problem where that might mean reaching out in-house to fellow IT professionals who do not usually do any help desk support work,
• Or their reaching out to software developers or manufacturers involved that provided this here-problematical software,
• Or as a last resort this might mean their reaching out to specialist outside consultants – and certainly if this is a problem that has come to have wide-ranging and financially significant impact. This last contingency is not at all common but it always has to be there as at least a possibility.
• I have simplified a more complex escalation process here, where larger and more complex businesses, with larger and more complex IT departments add in review and evaluation layers too, in order to help keep their efforts and resources effectively utilized. And even initial contact help desk personnel can for example try reaching out to software providers themselves too. But even this outline should be enough to indicate the complexity and layering that a new and emerging problem, certainly, might face as it travels through this type of system from when it is first reported to when it is resolved.
• And every possible step along the way in this, and every gatekeeper step that would pass a problem along or stop that process and for whatever reason, carries opportunity for miscommunication, delayed communication, and business systems friction and with all of this both adding to the direct costs created by these problems, and adding to the delays faced in effectively resolving them – which means increased costs too.

Smaller organizations have simpler and less complexly structured help desk support systems. But that does not mean they automatically face less risk of the communications and friction-creating problems that I just wrote of there. It simply means they are going to be more likely to have to reach outside of their organization for help to resolve novel and difficult problems, or else find alternative tools to use to bypass a problem and with all of the delays and costs that can bring. Fortunately, I write of rare events here with 90% and probably at least 99% of all of the help desk requests faced, more readily resolvable in-house and through simple help desk escalation processes. Risk management here, means at least considering those rarer and more irksome possibilities too.

Now let’s consider how a business can more effectively tap into its in-house expertise and particularly where that would mean reaching out beyond its usual at least part-time help desk escalation specialists, and with a goal of bringing the percentage of these problems that can be resolved in house to as close to 100% as possible. And that is where an interactive intranet can become invaluable. I am going to address that in some detail in my next series installment. And then after discussing that, I am going to pick up on and discuss customer service and support desks, as cited in passing as a source of working examples in Part 7, in order to more fully discuss this series’ complete set of issues. I add in anticipation of that, that I will explicitly consider how the issues of this series play out when services such as Information Technology help desks, and Sales and Marketing supportive customer services are maintained and run in-house and when they are outsourced.

Meanwhile, you can find this and related material at Social Networking and Business and its Page 2 continuation. And also see my series: Communicating More Effectively as a Job and Career Skill Set, for its more generally applicable discussion of focused message best practices per se. I offer that with a specific case in point jobs and careers focus, but the approaches raised and discussed there are more generally applicable. You can find that series at Guide to Effective Job Search and Career Development – 3, as its postings 342-358.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: