posted 23 Feb 2011 in Volume 14 Issue 5
At the helm
Keith Power asks who should oversee knowledge and content management?
“I have always viewed the whole concept of a chief knowledge officer as being totally bizarre.”
John Smyrk, principal, Sigma Management Science
In the 1990s the role of chief knowledge officer (CKO) began to emerge. One motivator for this was to differentiate the role from chief information officer or head of IT as a way of emphasising that KM is not principally about IT. At KPMG, for example, Ian McBride became the first incumbent in the newly created CKO role in Australia in 1998. At that time he reported to the chief operating officer and also had a dotted line relationship to KPMG’s global CKO in Boston.
Although McBride and his team worked closely with the IT function, his was not an IT role. McBride, like most of KPMG’s other CKOs at that time, came from a non-IT background and there was a clear delineation as to who was responsible for what. McBride was responsible for furthering KM in Australia in general and the KWorld implementation in particular. Interestingly, as a former chief financial officer (CFO) himself, he thought it was dangerous for CFOs to be in charge of information and knowledge and that finance people should stick to finance.
Defining the role of the CKO
The CKO title was (and the author finds still is) usually restricted to large and often global, professional services firms for whom knowledge and intellectual capital are their principal assets. It is often a reflection of how seriously the organisation takes KM, that it has someone in a senior, dedicated role to oversee these assets and maximise its investment in them. Other titles also abound for essentially similar roles. However, despite the prefix of ‘chief’, Robert Hillard, information management Australian leader at Deloitte, has never seen either a CKO or a chief data officer report directly to the CEO and finds they are usually a couple of layers lower in the organisation.
Hillard agrees that these roles recognise important assets. The one danger with them, he says, is that by creating them people think they have automatically solved a problem. Nor does he think a CKO role is ever essential. Rather, having a CKO can be a good way to create a focal point for maintaining the information assets of the organisation and ensuring that people are motivated to be enhancing and maintaining those assets instead of simply exploiting them. Incumbents also need a broad range of skills for the role.
“They really need to have a good handle on information and on the economics of information,” he says. They need to understand the industry sector they are in and they need a good knowledge of the organisation itself to be able to navigate it and work through any barriers.”
IQ Group’s vice president of operations, Dan Elam, believes the CKO role differs greatly between industry sectors and means different things to different people but thinks the role is appropriate for a lot of organisations. A large multinational consulting company, for example, might have 10,000 projects running at any one time. When the next project arises around a particular technology or vertical industry it will want a way in which it can see what the company has worked on before and what pertinent information it has available, he says.
According to Elam, that is very different from a global financial services organisation, which will want to look at the products it has in the market, analyse the relationship it has with its customers and determine what new products it should offer or of which ones it should divest itself. On the other hand, it can mean big savings for a pharmaceutical company to be able to leverage previous research or better manage its information in order to reduce the cost of drug approval or just the cost of possible litigation associated with the drug.
Elam says that in many cases the CKO role does not exist until an organisation already has a number of initiatives underway and some large IT investments. It needs someone with a broader perspective of the business than IT who can take a more holistic view especially in a global organisation which may have to comply with different laws in different countries, for example. So like Hillard, Elam thinks incumbents require a lot of vertical expertise.
“If you’re in manufacturing that’s very different from the financial services role,” he reiterates. “I wouldn’t want the knowledge officer for the drug company to come from the oil and gas industry and not have any understanding of clinical trials or something like that.”
However, Elam does think CKOs need to be IT savvy.
“All of the information revolves around technology these days. They don’t have to be super technical but they need to have a strong appreciation for what is possible with the technology. If you don’t know what’s possible then you won’t have a clue about what you can actually achieve and that requires technology. We’re finding the CKOs are more often than not reporting to the CIOs. So they become a de facto part of the IT organisation,” he says.
John Smyrk, a long time IT management consultant and principal of Sigma Management Science in Australia, first came across the term CKO in about 1990, at the height of the artificial intelligence boom. However, it did not make much sense to him then and nothing he has seen since suggests that anything has changed significantly.
“The first issue concerns the definition of knowledge,” he says. “In the 1980s, a number of useful conceptual models were proposed that drew promising distinctions between data, information and knowledge. Under that approach knowledge is characterised as a form of expertise (which associates it closely with natural or artificial intelligence). This line of reasoning then begs the question: should an organisation have a chief expertise officer? I very much doubt it unless of course we are talking about the normal role of the human resources function.
“Fundamental issues begin to emerge the moment an attempt is made to either define the term chief knowledge officer or develop terms of reference for a CKO. In all the cases I saw (admittedly some years ago) the role of CKO quickly collapsed into little more than a tarted-up variant of a CIO. And that raises a related issue. In the face of any reasonable definition of information, CIOs are rarely chief information officers – they tend to be more like chief IT officers with some responsibility for certain critical subsets of an organisation’s processes, information and data,” Smyrk says.
The knowledge custodian
Whatever the title, smaller organisations may feel they neither need nor can afford a dedicated knowledge custodian, at least in a full time capacity. Gartner’s Debra Logan, though, advocates making knowledge and information management someone’s job.1
“Knowledge workers understand the documents they create and use. What they do not necessarily understand – or need to understand – are systems designed for content management or how the enterprise portal is implemented. IT professionals on the other hand understand information systems but not necessarily how to translate the requirements of the users into a useful system of classification (a point many IT professionals and their managers might contest). The structure and meaning of the content should be imposed by the users not constrained by the limitations of any one system.
“The information architect or information manager mediates between these two groups. In many ways information architect is a similar position to the knowledge engineer, and both terms are used by enterprises to describe the role,” she says.
Anne Jaques leads the global consulting KM team at Deloitte. According to Jaques, Deloitte is an organisation made up of many ‘member firms’ one of which she is a director. Jaques reports to the CEO of global consulting in Deloitte, who is responsible for seeking synergies between the member firms. KM, she says, is considered part of the glue that enables Deloitte to act globally to support its clients.
Jaques does not use the CKO title herself but her role entails:
The development and execution of a KM strategy that supports the business strategy of Deloitte’s consulting practice globally;
Relationship management with senior leaders of Deloitte key member firms, to understand local and global priorities and to provide KM services that meet those needs;
The overall management of several teams globally based comprising 36 full-time equivalent positions (FTEs) onshore in North America and the UK plus 100 FTEs offshore in India. The teams range from portal management, people, communities, content, research and business support; and
Representing global consulting KM on global councils that direct KM across all business units such as tax, audit and risk services.
According to Jaques, the ability to find experts within Deloitte, together with the need to rapidly respond to market opportunities is critical and this is to which she ascribes the importance of her role and team in the organisation. In a role such as hers Jaques believes it is important to be technologically savvy but not a ‘techie’ as well as ‘a low maintenance, self motivated individual’. Along with negotiation skills she says one needs to understand the organisation: its culture, the pain points of the practitioners and what motivates the leaders; and be able to communicate with leaders in their terms and see and communicate the big picture.
Jaques has no formal or direct relationship with IT but says the KM infrastructure in Deloitte is heavily reliant on the IT organisation. She also sits on a KM Governance Committee that governs IT projects specifically related to KM.
Jaques originally qualified as a librarian and spent some time in the UK public library service establishing a fee-based business information service for local businesses. She joined Deloitte to run a research centre focused on external content and subsequently relocated to the US to work in KM.
A lawyer by training, with patent litigation her specialty, Jane Hogan has been with Gilbert + Tobin Lawyers since 2003 assuming her present position as head of knowledge in 2006. The role entails her running an internal team of professional support lawyers. She also sits on the firm’s IT steering committee and risk committee, among others.
Along with the head of IT and the head of human resources Hogan reports to the managing partner of Gilbert + Tobin and works closely with IT in what she describes as an excellent relationship.
“My focus is on the legal side rather than on the broader information brief,” she says. “I am interested in the information design, how systems fit together and how they are used whereas my colleagues in IT tend to work on the technical side. And when we run projects together I generally lead and project manage them.”
Joseph Lopez has been knowledge manager at Delta Electricity since late 2002. The role, he says, involves looking after information management assets within the organisation and getting people to recognise the value of the information and the way they relate to it. Lopez holds a postgraduate diploma in KM and while his is not an IT role he interacts closely with and now reports into Delta’s IT function.
When restarting or salvaging a failed KM initiative Gartner’s Jeffrey Mann adds that management will often assign a new person to relaunch the initiative. This person will often have an IT or project management role but could also come from a line of business function related to knowledge use within the organisation or a senior member of management.2
‘Content Management Plus Organization Equals Knowledge Management’, Gartner, 2009.
‘What to Do When Knowledge Management Goes Wrong’, Gartner, 2006.
‘Organize Knowledge Management From the Top Down, While Executing From the Bottom Up’, Gartner, 2007.
This article is an extract of the Ark report Delivering Successful KM Projects: A Best-Practice Guide, written by Keith Power. For more information on how to obtain a copy of the report, contact Robyn Mace at email@example.com or on +44 (0)20 7566 8229
Keith Power is an award-winning Sydney-based journalist. Formerly editor of Informatics magazine, he has written extensively on KM and related topics. Keith can be contacted at firstname.lastname@example.org
Top down and/or bottom up
Deloitte’s Robert Hillard cites the case of one of his clients wanting to implement a KM programme from the bottom up and found it got very good buy in from the bicycle club but almost no content was of actual value. It does not matter whether CEOs are actively filing all their documents in the system or actively involved in the social media aspects of the programme, he says. What does matter is that the CEO is valuing the information assets of the organisation from the top down as this is seen as increasing the value of the organisation.
Others do advocate a bottom up approach. Gartner’s Jeffrey Mann, though, says that organisations need both bottom up and top down approaches to organise KM and high level collaboration projects effectively3. Mann recommends that managers of KM projects should concentrate most of their efforts on bottom up development because these activities deliver most of the benefits, while planning for some measure of top down management to make the KM activities visible, give them credibility and to tie them in with the overall KM initiative.
“Top down initiatives alone rarely deliver much practical benefit. High-level commitments must be converted into specific efforts that support practical, pragmatic business issues. These results can only be delivered by line-of-business (LOB) groups and individuals, that is, from the bottom up. Since this is where the value comes from effort should increase from the bottom up. Visibility within the organisation should flow from the top down starting with senior executive validation. Initial efforts should concentrate mostly on achieving demonstrable value from specific projects and applications. Once established, more attention to programmes and projects will improve efficiency and institutionalise KM and collaboration practices within the organisation.
“We receive many inquiries from Gartner clients who have been given the task of coordinating their organisation’s KM and overall collaboration efforts but don’t know where to start. They want to pull together an enterprise strategy but also need to provide tangible benefits to the business. The issue of where to focus is crucial to many of these customers. Should they concentrate on an enterprise wide effort to define how the organisation uses knowledge and coordinate all activities across the company (that is, a top down approach)? Or should they encourage many different individual efforts which support specific business areas, often ones which are initiated by these business areas (that is, a bottom up approach)?
“As is often the case with these kinds of apparent dichotomies the real answer is a bit of both. Orchestrating top down coordination plus bottom up execution is the best approach to take to ensure success. Planners need to strike the right balance between dictating collaboration efforts from above and allowing collaboration projects to arise naturally from individual users,” his report states.
Benefits and pitfalls
According to Mann, top down initiatives often appeal to high-level executives and to IT leaders because they offer visibility, coordination, funding and support for higher level projects later on. Top down support validates the entire initiative confirming that the organisation takes KM seriously and is committed to doing it better. However, concentrating on this approach alone could lead to many high level activities without achieving pragmatic business results. KM planners should get to value creating projects and applications as quickly as possible. LOB units can directly own or direct the application and project stages while initiatives and programmes are typically coordinated by a central IT or KM organisation.
“A bottom up approach is usually popular with users because they are invested in the project and enjoy coming up with creative solutions to everyday business problems. They also often save time and money. One benefit of the bottom up approach is that it provides a natural feedback loop regarding the projects and applications that are implemented. Users can provide direct commentary regarding what is working, what needs to be improved and what does not need changing. But if there are too many bottom up projects the overall collaboration initiative will be uncoordinated. If the organisation uses a bottom up approach alone it may end up with duplicated effort across LOBs, wasting money and time; and introducing redundant or incompatible technology.
“However, planners should remain cautious when consolidating even redundant applications. Users are more likely to use the applications they have acquired or built themselves. If users enthusiastically adopt an application and use it productively managers should weigh the risk of wasted money and potential incapability with established systems against the benefit the unit may gain from using the system. Forcing users to drop an established and popular system also incurs costs both political and financial. It makes no sense to force them to move to an approved platform if doing so means they won’t use the application anymore. Small cost savings from eliminating redundant licence spending is often an insufficient justification for killing a bottom up application that is successfully delivering value to users,” Mann says.