Skip to content

Posts from the ‘Knowledge Management’ Category

25
Aug

Effective Knowledge Management for Federated Support Teams

Is it even possible?

                There are a number of complexities that come from running a large IT organization within any company.  Not the least of these is the complex architecture that can exist to support software, applications, hardware, and other IT-specific technologies.  Each technology can create a silo of support which is specialized and used to support a niche part of this complex web, but this is entirely seamless to the customers in the organization; that is, the consumers of IT who rely on it for their day to day work activities.  When an end-user calls the “helpdesk” and, heaven-forbid, pushes the wrong menu option how does one group of specialists connect the customer with the correct group of specialists?  Organizations attempt to create large structures of knowledge (knowledge bases) which can be used to aid in the switch-boarding of callers to the correct base support group or onto the correct “2nd level support” group.  Over time the knowledge bases which are used deteriorate due to improper maintenance and force the knowledge back into the heads of individual support personnel which is what the organization was trying to avoid in the first place.  What follows are my meanderings on the best practices that should be followed to keep the knowledge base alive and effective.

                For 8 months, I supported a large portfolio of applications, and as I progressed from month 3 to 4 to 5 and so on, the workload continued to mount.  Beyond the regular duties of taking, logging, researching, transferring, and following up on service calls, there were a number of business processes which needed tuning in order to make the job more effective; to add to the pile of work which had already mounted, there were departmental projects that needed supporting also.  This is the typical life and workload of a support analyst. 

                About mid-way through month 5, there was a significant change in the support and knowledge infrastructure.  When call time resolution increases to upwards of 10 minutes on average because of changes in the support system and knowledge infrastructure, something needs to give.  Granted the system wasn’t perfect prior to organizational improvements, but at least the knowledge base was up to date.  The task to update the knowledge support system, test for quality, and ensure that it would work as part of new support processes, was an insurmountable task.  The changes in phone numbers and service departments, compounded with the existing department DIY data quality approach made the issue larger than it needed to be.  If there were enforced governance standards surrounding the knowledge base, they were not communicated widely; and when I asked about standard change processes, even seasoned employees were confused about what the formal processes were because of a flurry of changes partnered with the light communication about the subject.

                The standards around an IT organization’s knowledge base need to be rigorous and agile, and those accountable for the knowledge base need to have eyes and ears into every corner of the organization that is logged and supported in the knowledgebase.  Furthermore, there should be policy and process established and formally defined to communicate the processes through which knowledgebase changes should take place.  I do understand that there are safe-guards and data owners who are there to ensure that their knowledge is not lost or incorrect; however, if they are not part of (or informed explicitly) about large changes happening over the support organization they cannot do their job.  This all sounds good and like common sense; however, even large organizations that believe they have this in place, in theory, can have a program running which looks healthy based on metrics and reports.  When in reality at the ground level, the processes are falling apart because of bulky and ineffective governance processes.  Quality of support information will deteriorate over time, and the entire process for a single application support area could be one or two bad employees away from deteriorating into a state of irrelevance with information that is simply irrelevant and unusable.

                In a large organization this type of governance is extremely difficult and can be extremely tumultuous from a political stand-point.  Either one centralized Knowledge Manager or a team of federated Knowledge Managers should be dedicated to policing and enforcing the updating, maintaining and deleting of items from the knowledge base.  Dual roles and side roles are ok for those who are practitioners of the actual data in the knowledge base, but at least one dedicated role per IT organization should exist to ensure that knowledge is correct.

                So, how can one measure the correctness of the data in the database?  There are a number of metrics that I see, and I’m sure there are standardized metrics that exists, but I’ll start at the ground (support) level.  Identifying metrics could be ones such as: number of times calls are transferred by issue or asset; customer complaints or dissatisfaction levels, especially with regard to specialized applications where more detail is needed in the knowledge base for adequate handling; support complaints regarding find-ability of specific issues within the knowledge base; low levels of knowledgebase use; increased amount of documentation support teams store on local drives or shared drives.

                Beyond the reactive route of chasing metrics, there are structures of leadership and policy which IT leaders can put into place.  As alluded to earlier, there need to be in place formal lines of accountability.  This means starting at the top with a governance model supported by the appropriate people.  For instance, an IT Service Manager, an Engineering Manager, a Business Administration Manager, a Human Resources Manager, a Financial Manager, and other appropriate stakeholders would fit in well to this type of governance.  Let’s examine this for a minute.

                The biggest argument at this point is: Why drag in the managers of Engineering, Finanace, HR?  Isn’t this an IT-driven initiative?  My argument is this: these are the ones who manage the consumers of the IT service provided, so they are the ones who will have direct feedback from these “consumers” of IT services.  Why guess at the issues, or wait for them to bubble up and escalate to a point where irreparable damage is done to IT’s relationship with a particular organizational function?   

                At the top of an organization, this governance group can set out accountabilities for knowledge base changes, and they should be in positions high enough in the organization to be able to pinpoint large knowledgebase-impacting changes (such as new service software roll-outs).  Once accountabilities have been assigned, working groups or advisory groups can be formed or leveraged.  This group of workers and advisors, however, cannot be idle observers.  They should produce analysis from their area of expertise, complaints from IT support customers/clients, and other objective feedback that can be used to help produce acceptable measurement to describe the state of the knowledgebase as a whole.

                Outside consulting can also help.  Having an outsider analyze the knowledge available to a certain support area, or focusing 40-80 direct hours of clean up and renewal can be extremely useful and help to increase productivity and customer experience immediately.  Often support teams do not have the 40 continuous hours to focus on this type of work, and the (literal and informational) exhaustion from support routines can cloud the entries that are placed into a knowledge base.  Furthermore, there may be opportunities to flesh out the support language that is used on various applications and within different functional areas; in other words, mediation may be necessary between IT and different functional areas to either improve relations, or establish a baseline for support.

                In conclusion, a number of measures must be researched and considered proactively within an organization as those in charge of the application support processes look to sustain their contributed organizational equity.  While some costs are implied with placing enhanced governance around knowledge base infrastructure, the flip-side of the equation is the hacking and grinding of frontline knowledge workers attempting to solve end user issues with broken, inaccurate or out of date information, and the end-users, typically those who make or save the organization its revenue, are gnashing their teeth and seething over their inability to do their jobs or even get a clear answer as to why their application is not working and when it might again work.  The latter should (continue to) be the major driver behind pushing out efficient, measured, and enforceable governance of knowledge base systems in all (but more significantly large) organizations.