GovKM.com – A Divergence of Managements

Especially clear in the largest organizations, the roles among varying levels and types of Information Technology (IT) support tend to aggregate into two high-level divisions: Technical Support and Functional Support, with Technical Support primarily supporting hardware and updates to software, and Functional Support primarily supporting the human customer with solutions to software related problems and questions. It needs to be understood from this point forward that these are two distinct career fields, as dependent and independent as acquisition is to finance. The gifts, abilities, and training required for one exist in a completely separate specialty than those required for the other.

To make it a little clearer: The interest and skills required to install, configure, maintain, and lifecycle computer and network hardware and software are tasks that are primarily focused on the the discrete, finite tasks of installation and maintenance of hardware and software; the interests and skills of those who learn the detailed capabilities of software and who enjoy imparting that knowledge to customers is as different and opposing to the former as Engineering is to Liberal Arts.

Currently, both of these verticals are managed by the Technical Support side of Information Technology – IT also typically heads CIO departments.

It is asserted here that Knowledge and Information will one day play the predominant role in IT decision making. To come will be the predominant notion that the maintenance of the data structure and the importance of its constant availability in multiple formats, regardless of the hardware, network, or infrastructure used to access it, will drive with sensitivity for the information the decisions involving technology. For this reason, technology moves downstream from information.

For far too long, the Technical Support side of “IT” has minimized the value of the Functional Support side. For example, software updates are performed in accordance with the schedule solely determined by the Technical Support division (certainly because the Knowledge and Information Manager, who will likely come from the Technical Support division to lead the Functional Support division, has not stepped forward yet to take charge of the Knowledge and Information domain). No rerepresentation from the Knowledge and Information sector is present to voice the impact to organizational knowledge when Technical Support decides it’s time, for example, for a software migration to occur. Flexibility and adaptability are imposed upon the user and the knowledge – not the technology, as it should be.

What is Functional Support?

Functional Support is software performance and instruction provided to the customer.

So, it’s a Help Desk?

No…it’s a lot more. It’s the Exchange administrator who answers requests to create new shared mailboxes or distribution lists; it’s web administrators who update various web properties; it’s the systems analysts mapping organizational business processes for automation; it’s anyone who has rights to create new folders on shared drives or sites, lists, and libraries on various content management systems; it’s also the Help Desk that answers questions regarding, often proprietary software, and that resets passwords. And, it’s a 1000 other things involved in performing software tasks or assisting customers in performing them. Need PhotoShop support…expect to routed to someone who works among others providing knowledge support to customers – from within the undefined Functional Support office – the Knowledge and Information (or whatever it’s to be called) office. Graphics design is not technical work. It’s knowledge work. It involves business knowledge that is not required or pursued in the Technical Support curriculum. Need training or training development? Clearly, this is knowledge work and the tools used to create modern training are complex and sophisticated. The educator, trained in training development and presentation, could not care less about the technical reasons hardware functions. They simply need it to work so they can produce their products. Whom do they call if they need help? It depends. If the application is broken and does not function properly – call Technical Support. If the challenge is understanding how the application functions, how to create a desired outcome – call the Functional Support team. If there’s only a Help Desk, call it and ask for solutions which they are unable to provide, like this software application support. Keep doing it! In time, their logs will show an inability to answer customer needs and they will have to respond. It’s a slow road, but it’s how the ball the gets rolling.

Functional Support is the bulk of what is currently called IT support and, if not inclusive of everything that needs to break away from CIO/IT offices and become its own division, then it’s likely the largest part of it.

How did Technical Support and Functional Support get rolled together?

They didn’t actually get consciously rolled together. Functional Support rose as a consequence of technology. From the moment desktop computing technology was deposited at customer workstations, customers asked questions from how to turn it on to how to send email to how to use the provided software applications to how to write programs. The first instinct for customers was to turn to the techs who installed the hardware to ask the questions about the software – and immediately the forced marriage between Technical Support and Functional Support was consummated. Showing the user how to turn on the computer was originally the extent of the IT workers’ role with customers. Suddenly, in their support role, they rushed to also become software experts to answer customer needs.

Hardware techs didn’t like it. They’ve never liked it. The line of work they chose kept them focused on a very silent class of customers – computer and network hardware and the software used for their maintenance. Also identified, though, were techs who did not particularly enjoy working on hardware, but became experts at the finer workings of both proprietary and ubiquitous software applications, and who additionally enjoyed working with customers. (Hardware techs tend to have a certain disdain for humans.) As the need for Help Desks arose, naturally those who understood applications and enjoyed helping customers were regrouped into cells where Functional Support took root.

Software assistance was not the original primary function of Help Desks, however. Initially, Help Desks were established to capture service tickets for hardware support. Quickly, however, customers began asking for software application support and Help Desks responded by attempting to provide software SMEs. This quickly failed as the span of organizational software, both licensed and custom, increased and responsibility for in-depth knowledge of the applications was pushed back to the individual user.

Abandoning management support of the software and abandoning management responsibility for data format and storage, in ways such as allowing virtually all users permission to create folders inside folders inside folders on shared drives, allowed for the Wild West environment in which information chaos currently looms.

It’s time for a divorce…or at least a renegotiation of the terms! 

The groundswell of disorganized, unauditable, unsearchable, unmeasurable business information, completely in chaos in the majority of government organizations, gives testament not only to the mandate that the information must someday become structured, but also to the notion that how the information has been and is currently managed needs to change.

The groundswell of disorganized, unauditable, unsearchable, unmeasurable business information, completely in chaos in the majority of government organizations, gives testament not only to the mandate that the information must someday become structured, but also to the notion that how the information has been and is currently managed needs to change.

An earlier post attempted to define the value of an organizational information set as the importance it carries in answering questions in the larger information parent. The value of information belonging to subordinate organizations is based on how well it answers questions for its parent – your organization. Optimizing systems to adhere to ontologies consistent across enterprises and inter-agencies is the first and, arguably, the most important step in beginning to organize government information.

Who has the call to standardize the federal taxonomy/ontology? 

Who knows? The Federal CIO position (vacant as of this posting, 5/10/17) suffers from the same malady as CIO directorates in federal agencies taking guidance from it: Its focus is on Technology, not Function. The Federal CIO office is far to concerned at the moment with reducing the federal IT budget by mandating the move of federal agencies to shared cloud services (as the DoD CIO has done with the Joint Service Provider for all DoD agencies operating on the NIPRNET), than it is with answering questions about ontologies or best practices concerning the management of knowledge and information. If the right mouths ask the question, however, the answer would currently fall at the feet of the Federal CIO, since CIOs are perceived as possessing both the Technical expertise on all phases of equipment configuration AND expertise in the development of taxonomies, folksonomies, and ontologies, operation of software, training of employees, development of training, process re-engineering, information security, information architecture, workflow development, data structures, analytics, metrics development, and the list goes on. A Complete Fallacy! These are not the performance objectives of the the misnamed CIO or the Technical Support team…these belong to the Functional Support team – the Knowledge & Information Management team and its lead, the rightly named Chief Information Officer (CIO).

So where do we go from here?

Particularly since the advent of cloud services, government IT offices (CIOs) have struggled with identity. Some organizations have attempted to adapt to the change: Headquarters of the Veterans Administration (VA) renamed its CIO office to OI&T – the Office of Information and Technology. The Defense Security Cooperation Agency (DSCA) created two divisions within its CIO office and titled them IM&T (Information Management & Technology). Formalizing office divisions to separate Information and Technology manifests the realization that the two are distinct enough to be considered separate entities.

What to do once they’re separated still hasn’t been figured out!

DSCA divided its operations based on internal manpower breakdowns. Those the CIO employed fell into two basic groups – Technical workers and Knowledge workers. Regardless of the reasons for its split, it made the right move. Unfortunately, when asked what the vision is for the IM portion of the name IM&T, no answer is provided.

Nonetheless, it seems the world is moving in the direction of divergence between Information and Technology.

Leave a Reply

Your email address will not be published. Required fields are marked *