About a 1.5 million years ago in tech time, aka the ’90’s, I was in charge of global internal tech support for a company now called DaVita Healthcare. It was my third such stint as a tech support implementer in my 20’s. Each facility had its own Local Area Network (LAN) with PC’s and print servers, and lots of opportunity for things to go wrong. There was no internet-based networking, so to access each facility’s LAN we had to use a dial-up modem. Pushing updates to the computers in these facilities was difficult. It would have been absolute mayhem except for something my boss at the time taught me: The Price-Waterhouse Problem Resolution Protocycle (PWPRP).

Essentially it goes like this: 1) Refine the problem description until it is accurate; 2) Note detailed assessments that were used to refine the problem description, because that exposes your methodology to defining the problem and can tell you if you’re doing something wrong; 3) Detail all resolution attempts, keeping in mind that these will inform updates to both the Problem Description and the Assessment. 4) Not the disposition of the problem for future tracking (was it a training issue, a bug, etc…) and knowledge base entry; 5) Confirm with the user that the problem is solved to their satisfaction.

My degree is Management and Organizational Development, and I wrote my thesis on improving the efficiency of technical support by implementing help desk software I wrote that updated its records via modem dial-up and database reconciliation between my home office and the home offices of other tech support analysts I managed across the country.

But I soon realized that my entire way of approaching ANY problem, technical or otherwise, had been permanently changed with this kind model. I also became acutely aware that many technical support organizations do not employ the PWPRP. The dead giveaway is in the violation of Service Level Agreements (SLA’s) and the experience of being handed off from one support analyst to another. In these situations I have to repeat everything again to the new analyst, and they still might not get the problem description right.

Then there is the “we fixed it, ticket is closed” scenario. No ticket should ever be closed without the user verifying the resolution worked according to their expectations.

In my web design business, I am often a consultant tackling technical issues such as “how do we create a secure library of author documents where people can filter by author, category, and date of publication all at the same time?” This sort of request includes the unspoken assumption that an interface will be created to elegantly handle this need. Although this is not a tech support issue, it still benefits from the PWPRP. In this case, the Problem Description is already accurate and is in the form of a system requirement. The phases of Problem Description, Assessment, Resolution, and User Acceptance is a useful construct here. Consider that the Assessment will include context of why the Problem Description exists and denotes any dependencies such as licensing costs for anticipated modules, and other planning items. Resolution becomes the coding and design work required to fulfill the requirement. Acceptance is where the client confirms the requirement was implemented correctly. The PWPRP is flexible for different situations.

What I really learned in the end might seem obvious, but a lot of organizations don’t do it: have some sort of formalized methodology for addressing challenges that all staff understands and embraces. If some do it one way, and the rest do it another way, there will be problems that surface in the form of lost information and incorrect conclusions. In business, this translates quickly into burning money trying to solve problems in an inefficient manner.

Now for the bonus info: Having an agreed upon methodology also segues nicely into W. Edwards Deming’s Total Quality Management paradigm. In the case of technical support, this means making knowledge gathered from the experiences of tech support available to other stakeholders, such as upper management, so that all levels of the organization benefit from customer interactions. But most importantly, the customer ultimately benefits and the organization’s reputation improves.