business case study - knowledge Management strategy

HEC037-PDF-ENG.PDF

Home >Business & Finance homework help >Operations Management homework help >business case study - knowledge Management strategy

© HEC Montréal 2012 All rights reserved for all countries. Any translation or alteration in any form whatsoever is prohibited. The International Journal of Case Studies in Management is published on-line (www.hec.ca/revuedecas/en), ISSN 1911-2599. This case is intended to be used as the framework for an educational discussion and does not imply any judgement on the administrative situation presented. Deposited under number 9 65 2012 003 with the HEC Montréal Case Centre, 3000, chemin de la Côte-Sainte-Catherine, Montréal (Québec) Canada H3T 2A7.

Volume 10 Issue 3

September 2012

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA Case prepared by Professors Alina DULIPOVICI1 and Ann-Frances CAMERON2 The meeting with the executive management team was over. Rita Carson took a deep breath as she entered her office. As the leading director of the IT Department at Technology Project Authority3 (TPA), a state-level government agency in the United States, she oversees the adoption of the new knowledge management system based on Microsoft Project Server combined with SharePoint Server (hereafter SharePointProject). From the moment two days ago when she first saw the report on the SharePointProject usage statistics, Rita knew this meeting would not be easy. The management team’s criticism still echoed in her head:

The State Governor asked TPA to promote collaboration and knowledge sharing across governmental agencies […] What kind of example have we set for the other agencies if our own divisions do not really use the system we implemented a year ago for knowledge sharing? […] What message are we sending to the other agencies about collaboration and knowledge sharing if we’re not even able to do it ourselves?

In fact, in 2000, the State Governor had established IT-based cross-agency collaboration as a statewide goal for bringing agencies together to share information and resources. The traditional “siloed” data of each agency represented a significant barrier to providing more efficient services to citizens and employees. Deploying an integrated IT infrastructure among all 120 state agencies would allow cross-agency collaborations that would save money and increase the quality of services offered. Authorized government personnel would have real-time access to data regardless of its origin (which becomes irrelevant as long as the data is reliable and secure). For example, the management of child welfare cases would substantially benefit from the sharing of information among the Department of Human Resources, the courts, the Department of Juvenile Justice, the schools and the Medicaid program in the Department of Community Health. Also, criminal justice activities would benefit from the sharing of information among state law enforcement agencies, the courts, the Department of Corrections, and the Board of Pardons and Paroles.

1 Alina Dulipovici is an Assistant Professor in the Department of Information Technologies at HEC Montréal. 2 Ann-Frances Cameron is an Associate Professor in the Department of Information Technologies at HEC Montréal. 3 A pseudonym is used at the request of the organization. In addition, some facts have been altered for confidentiality or

pedagogical reasons.

HEC037

This document is authorized for use only by Jessica Valverde ([email protected]). Copying or posting is an infringement of copyright. Please contact [email protected] or 800-988-0886 for additional copies.

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

Given its role to assist state agencies to better plan, manage, purchase and use technology in general, TPA was mandated by the State Governor in 2001 to promote this vision of a collaborative IT environment across agencies, help state agencies identify relevant opportunities for collaboration based on their needs and the applicable legislation, and support the execution of such projects. To boost its credibility when promoting a collaborative IT environment to the other state agencies, TPA decided to first use its own departments to demonstrate that collaboration between government entities was possible through improved knowledge management. TPA’s own divisions functioned in silos and the sharing of information and knowledge was minimal. Seven years later, TPA could still not provide positive evidence of IT-based collaboration and sharing. The latest knowledge management system, SharePointProject, was barely used. Rita sat down at her desk and looked at the report again, thinking to herself:

How is it possible that only 12% of project managers and their teams used the SharePointProject system in the last three months? They were all ecstatic about this system at the beginning of the implementation project!

She didn’t understand what had happened or what had changed since its implementation. The report also indicated that close to 98% of TPA employees understood the importance of, and wanted to actively participate in, knowledge sharing. “If people are willing to share but don’t use SharePointProject, then what’s the problem?” she wondered. TPA’s executive management team was obviously disappointed with these results. At this point, they felt confused and asked Rita to guide them in the next steps. How should Rita approach this problem to ultimately find a solution that better supports TPA’s business processes and needs in terms of knowledge management?

Technology Project Authority (TPA)

Technology Project Authority (TPA) is a state-level government agency in the United States established in 2000 by the State Governor to create a more efficient and responsive government through the innovative use of technology. Employing close to 530 people, TPA’s responsibilities are:

 To oversee governmental IT projects costing more than $1 million;

 To establish policies and standards for technology and IT security used by the state agencies;

 To coordinate governmental IT purchases consistent with established policies and standards;

 To facilitate statewide strategic planning with regards to the state’s information systems and telecommunication networks.

Appendix 1 shows an excerpt of TPA’s organizational structure: a 12-member board of directors, an executive director and three divisions (Finance, Project Planning and Operations). TPA’s internal IT Department is under the direct supervision of the Finance Division. The IT Department is responsible for all of the IT projects within TPA (i.e., internal IT projects) such as

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

the implementation of SharePointProject. The Project Planning Division is responsible for initiating and planning IT projects with other state agencies (i.e., external IT projects). Once these external projects get to the execution phase, they are transferred to the Operations Division. Note that while project management and operations divisions are often considered opposite entities, managing projects is the core business at TPA, and thus it represents their operations. Within the Operations Division, the Projects Management group is responsible for the project management aspects of a project and the Solutions Development group is responsible for the technological development and deployment. For example, integrating child welfare information and case management activities among the Department of Human Resources, the courts, the Department of Juvenile Justice, the schools and the Medicaid program in the Department of Community Health represents an external IT project. Initially, it is the responsibility of a project manager from the Project Planning Division and then, once it is ready for execution, it is transferred to a project manager from the Projects Management group, within the Operations Division. TPA regularly reviews its IT strategic plan and fine-tunes it in accordance with technological progress and the statewide goals established by the State Governor. Since the first IT strategic plan was released in 2001, the use of IT to facilitate agency collaboration has been identified as a long-term goal. The specific objectives of this strategic goal have evolved over the years from general guidelines (for example, share information across agencies) to more concrete action steps (for example, integrate the shared front end from a specific agency into the existing state portal). Moreover, in the latest IT strategic plan (released in 2007), the use of IT to facilitate agency collaboration is no longer an isolated goal but an important step in making TPA’s IT architecture and IT infrastructure more efficient and effective (see Appendix 2). Although the general goal of “agency collaboration” could be achieved through a variety of strategies, TPA’s executives chose from the beginning to improve the organization’s knowledge management activities. Improving knowledge management within and across TPA’s divisions would allow TPA not only to lead by example in terms of how cross-boundary collaboration could take place among the other state agencies, but also to improve its work practices and to sustain its expertise in IT project management and technology development. As TPA had a strong culture focused on the cost, scheduling, scope and quality of delivered projects, and as the IT projects (external and internal) undertaken at TPA had many similarities, the use of appropriate tools to share information and knowledge about projects would allow the project teams to avoid reinventing the wheel.

Knowledge Management at TPA

Working toward the general goal of improving collaboration within and across TPA’s divisions had been extremely challenging. TPA’s executive managers had to continuously adjust the organization’s knowledge management approach (see Figure 1).

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

Figure 1: Main Phases in the Evolution of the Knowledge Management Approach at TPA

Phase 1: The seeds of a formal knowledge management approach

In 2001, after the decision to lead by example and improve its knowledge management activities, TPA established a list of collaboration opportunities (see Appendix 3) to reduce inefficiencies within and across its divisions, such as unnecessary spending for multiple IT platforms and information systems and inefficient use of IT components. To capitalize on these opportunities, a set of tools (some new tools and some that had been put in place to serve a purpose other than knowledge management) was used to facilitate the subsequent knowledge management activities: email, instant messaging, discussion forums, templates for the standard project deliverables, shared drives for transferring files, etc. The initiative had mixed results: some acknowledged the potential savings, but others noted the loss of ownership of the data to be shared. In the end, very few employees from the three divisions changed their work practices to include knowledge management activities. Three years later, in 2004, the situation had not changed much: very few people used IT to create, store and share information and knowledge about their projects either within their division or across the three divisions. The executive management team decided to formalize the knowledge management initiative. Bob Archer – a well-known executive project manager from the Project Planning Division – was given the new title of Knowledge Manager. His responsibilities as the knowledge manager were to promote and assist the three divisions in their efforts to collaborate. The executive management team also chose the shared drive, among the various technologies used to store and disseminate information and knowledge within and across projects (see Appendix 4), as the main electronic repository. The project teams were unhappy about the choice of the shared drives as the main electronic repository, as there were many problems. In particular, the shared drives could not deal with version control and redundancy. For example, project managers felt that looking for documents on these shared drives was like looking for a needle in a haystack. It was a real challenge: Where do you look for documents on the shared drive? In which folder? How do you know if it is the most recent version? Is there anything else about this issue that has been discovered since? Additionally, there was 900GB of data on almost everything and everybody and there was no index or standard organizing structure. As a result, the shared drives were used in conjunction

Phase 1 2001: Decision to improve knowledge management 2004: Decision to adopt a formal approach to knowledge management

Phase 2 2005 – 2006: SharePoint

Phase 3 2006 – 2008: Project/SharePoint

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

with the other tools. Some even preferred not to use them at all and only share the issues and solutions from their projects during team meetings and one-on-one meetings. Bob Archer quickly understood that it was time for a new phase of TPA’s approach to knowledge management. He made a recommendation to the executive management team to acquire a more effective electronic repository that would integrate knowledge from various sources, replacing the shared drives and other tools. Phase 2: SharePoint

In 2005, the executive management team mandated Rita Carson (the leading director of the IT Department at TPA) to implement Microsoft SharePoint Services (hereafter SharePoint) in the IT Department, the Project Planning Division and the Operations Division. SharePoint is a browser- based collaboration and document-management platform whose objective is to support knowledge management activities. An important characteristic of SharePoint is that it is highly customizable. At TPA, SharePoint was configured to provide key functionalities that the shared drives did not have, such as: document versions, check-in and check-out of documents, alerts when changes were made, task monitoring, forums and instant messaging. Given all these benefits, the executive management team expected SharePoint to become the main tool for knowledge management activities and to replace all the other tools. Following a phased strategy, SharePoint was first introduced in the IT Department. Because of this group’s IT background and skills, it was thought there would be fewer problems. Then, the plan was to implement SharePoint in the Project Planning Division, followed by the Operations Division. As the various project teams got access to SharePoint, they were required to use the SharePoint site created for their project to store and share all project-related information and knowledge: project deliverables, contact information, meeting minutes, lessons-learned databases, diagrams (e.g., organizational charts, project charts, graphical representations of the system, etc.), memos, white papers, roadmaps and any other project-related information. In order for these SharePoint sites to have a coherent “look and feel,” the IT Department set up a default structure, which was designed to be intuitive, simple and broad enough to apply to both the internal and external projects at TPA. However, several project teams complained about this structure, which was too general and was interpreted differently by the various users. Instead of a coherent “look and feel,” the differences between the SharePoint sites were significant. Another significant problem was access to the SharePoint sites. Project teams from the Project Planning Division interacted significantly with project teams from the Operations Division. For security reasons, however, the IT Department configured SharePoint in such a way that access to a particular project’s site was restricted only to members of that project, and gaining access to the SharePoint sites of other projects was a tedious and time-consuming process. A workaround solution was quickly found: documents were put on both the SharePoint site and the shared drives. This solution complied with the formal requirement of having all the documentation on SharePoint and – through the shared drives – the documents were also accessible to all TPA employees. Over time, many different versions of a document existed and the documents on SharePoint were not always the most current version. The executive team was still using these documents to audit the project deliverables (project plan, status reports, etc.); basically they were only checking the existence of the deliverables on the SharePoint site and not their content or

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

whether the content was up to date. Hence, the SharePoint site was used primarily as a high-level audit tool, rather than as a sharing tool. This “double-entry” practice generated a lot of frustration and confusion. When looking for documents, the expression “It’s on the site” soon became a catch-all phrase for documents on the SharePoint site, documents on the shared drives, or documents that had not even been posted (since most people not on the project team could not access the project’s SharePoint site to verify a document’s existence). SharePoint was therefore perceived as a “covert” knowledge repository because not everyone could access or verify the knowledge. Despite the potential benefits of using SharePoint, the project teams eventually went back to their pre-SharePoint habits. The shared drive and email became the most commonly used tools for storing and sharing knowledge, in conjunction with all the other tools that SharePoint was expected to replace (see Appendix 4). Furthermore, some project teams chose not to use SharePoint. For example, some considered that their projects were too close to completion to make the transition from the shared drive to SharePoint worthwhile. In the case of the Solutions Development group, the leading director decided that the group used the shared drive efficiently and effectively, and he thus considered the effort to switch to SharePoint worthless. All these problems made Bob Archer realize that SharePoint was still not the right knowledge management system for TPA’s needs. The lack of clear standards reinforcing the use and adoption of SharePoint contributed to the general perception that SharePoint was just one of the many tools to support knowledge management endeavours. He recommended that the executive team reassess their needs before deciding on a specific technology. Phase 3: SharePointProject

Following Bob Archer’s recommendations, TPA’s executive management created a committee to find a knowledge management system that would be more appropriate for TPA’s needs. Rita Carson was part of this committee, along with Bob Archer (Knowledge Manager), Andrew Collins (Director of the Project Planning Division), and Harry Linton (Director of the Operations Division). Together they represented every group involved in project management at TPA as well as the future users. Rita remembered clearly how the committee identified a list of “must-have” functionalities and assessed several tools. Their final choice was Microsoft Project Server combined with SharePoint Server: SharePointProject. SharePointProject is a multi-user networking system, significantly different from SharePoint. SharePointProject provides a lot of details about the projects (similarly to Microsoft Project) and also it automatically integrates data and information from other sources, such as lessons learned from previous projects (using knowledge repositories similar to those found in SharePoint). SharePointProject was not perfect for TPA’s needs but some of its functionalities seemed very useful. The executive management team was happy with the committee’s decision and quickly sent two or three memos to remind everyone of the benefits of sharing knowledge and to explain the organizational benefits of using SharePointProject. Once the project got underway, the implementation team from the IT Department examined TPA’s business processes as well as the work practices embedded in SharePointProject. The goal

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

was to determine the best parameters for the configuration of SharePointProject. When a gap was identified, the team documented the necessary changes to the existing business processes. All the relevant processes were thus revised and documented. The configuration followed closely what the business analysts documented, except for a few minor situations when ad hoc decisions had to be made quickly to avoid long delays. The implementation of SharePointProject followed a phased strategy, targeting first the IT Department, then the Project Planning Division, and, finally, the Operations Division. Once SharePointProject was available in a division, all the project managers and project teams needed to attend six training sessions on how to use the tool. After that, they were responsible for managing their projects in SharePointProject. The executive management team expected SharePointProject to gradually replace the other tools used for knowledge management tasks, including the shared drives and SharePoint. Although all three divisions recognized the potential benefits of SharePointProject for their daily project management tasks, the adoption process did not go smoothly. Using SharePointProject implied a significant change, from using a mix of tools to using a single, integrated tool to manage projects and share project-related knowledge. SharePointProject could provide an integrated view of a project, but it required collaboration from practically every TPA employee. For this reason, people were excited about SharePointProject, but also skeptical about whether or not everyone else would really use it. The implementation, and consequently the adoption, of SharePointProject suffered several delays. There were some technical problems due to aging servers that needed to be replaced. Furthermore, many project managers were too busy with their daily responsibilities and could not attend the training sessions. Additional training sessions had to be offered for those individuals. Nevertheless, by the end of 2007, Rita was happy to report that the new platform had been implemented throughout the three divisions. This didn’t mean, however, that everybody was using it. Switching from SharePoint and the shared drives to SharePointProject implied migrating or converting all of the existing project data. As the divisions felt swamped and understaffed, their leaders did not see the adoption of SharePointProject as a short-term priority. As a result, the few people who did use the system began calling it “a fancy note-keeping program.”

Where Are We Now, and What Should We Do?

Rita was puzzled by the usage statistics for SharePointProject and wanted to better understand the situation. She organized a meeting with the same committee that chose SharePointProject: Bob Archer (Knowledge Manager), Andrew Collins (Director of the Project Planning Division), and Harry Linton (Director of the Operations Division). Before the meeting, each director talked to his group and gathered some general opinions about SharePointProject. At the meeting, Rita delved directly into the main issue: Rita: What’s going on with SharePointProject? In 2006, we were so certain that

SharePointProject was the technology that we needed. I know there were a few technical bumps along the way, but they shouldn’t have been deal-breakers. The four

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

of us carefully chose the most appropriate system for our divisions. Why aren’t people using it? The executive management team is obviously displeased. Now it’s time to get to the bottom of this. I am the one responsible for the adoption of this system and therefore I need to understand what’s going on in the three divisions. Don’t we still need to share our expertise?

Andrew: Oh, we still need to know what others are doing because we may be able to help each

other. They may have something that we need and vice-versa. But right now, despite having SharePointProject in place, there’s no sharing. Basically, the environment is “This is your project. This is mine. I’m working on mine and I really don’t care what’s going on with yours.” If there is a specific need, yeah we may accommodate and inquire, and use SharePointProject, but otherwise we don’t share knowledge.

Harry: I agree with Andrew. I had spent four weeks trying to solve a problem with one of my

projects before I found out that a project team from the Project Planning Division already had a solution. Four weeks of wasted time! It’s unacceptable! But everybody just wants to see their own project implemented on budget and on schedule and working properly. So, documenting and sharing knowledge is a nice thing to do, but it’s just dessert and not part of the meal.

Andrew: I don’t think the low usage of SharePointProject is due to a misfit with our needs. I

think it’s a matter of expectations. Everybody in my division has had some experience with SharePoint and Microsoft Project in their previous jobs or with their previous employers. Everybody got really excited about the possibilities of SharePointProject at the beginning. Everybody imagined it differently and I think they find it hard to adjust to the new processes.

Rita: I have several new hires in my division who come from the private sector. They told

me that the way we communicate between teams is a bit different. They find it hard to get access to knowledge because there is too much redundancy and not enough resources. So, their expectations are completely different from the processes that we put in place.

Harry: I think there is another problem. Several senior project managers have never used a lot

of documents in the past. Conversations and meetings... I mean we have meetings every other week and it is a collaborative effort. It is a matter of talking and communicating, making sure that we’ve done the right thing and stayed on track. SharePointProject is a whole different story.

Bob: Everything is in people’s heads and that’s one of the problems. Only a small part of our

knowledge gets into documents or is incorporated in organizational processes. Documenting projects and sharing project documents via SharePointProject is not part of our formal responsibilities. Every time someone leaves TPA, we realize how dependent we were on that person. The knowledge is gone, but the project has to move forward.

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

Harry: I’m not sure though that we can generalize this problem. In the Operations Division, I have the two extremes. In the Solutions Development group, everything gets put into documents. It’s a young group of developers, business analysts and technical architects, and they have a different culture: document and reuse. In the Projects Management group, my project managers are mostly external contractors with 15 to 20 years of experience. As projects are being planned and executed, they don’t check on SharePointProject to see what others have done. They will go to their buddies – you know, the other project managers – and ask them to share whatever they have documented.

Rita: Clearly SharePointProject is not being used as it is supposed to be used. For example,

few people created their lessons-learned documents in SharePointProject. The technology cannot provide the overall view if the project teams do not provide the required ingredients. I know from my own projects that I discover things all the time that are not documented. That knowledge is still in people’s heads.

Bob: I see that problem every day. Our people have the desire to share, but sharing

knowledge is not an automatic behaviour. First of all, it’s more like “what’s in it for me?” This is one aspect of sharing that our organization does not address. Currently, I don’t have any return on value for having made my contributions other than just the feeling that I contributed. Sharing knowledge is not even formally acknowledged as one of my daily tasks. I have to find the time to do it. Second, what is valuable in my eyes? How do I know that is what I need to share? I consider myself a senior project manager, but sometimes I still hesitate about what to share and how much. I don’t want to expose myself for everyone to read what I did and have them think ‘What an idiot!’

Andrew: I believe in the benefits of documenting and sharing our expertise about projects. I try

to use SharePointProject as much as possible. I try to reuse existing knowledge, but it’s not always easy. People’s documents have themselves in mind; they don’t have me in mind. The documents are either too general or too specific, and I have no idea how I can reuse that information for my case. We can’t document for the organization at large, but we need to learn how to document so that the organization can absorb that knowledge and reuse it.

Rita: According to the internal report I have on the use of SharePointProject, many people

feel that this is not the right platform to share knowledge and make a difference. They complain that there are still too many knowledge sharing tools. I am honestly disappointed that SharePointProject has not yet replaced the other tools.

Andrew: I feel the same way. When we chose SharePointProject, we talked about how we would

enter the data once and then automatically have the various reports and deliverables in the required format. We would have a high-level view of the project for the executive team and a different view with more details about the methodology for the business owners. I know several project managers who still create these reports themselves instead of using SharePointProject.

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

At the end of the meeting, Rita went back to her office and wrote down the main points. She looked at her notes and reflected on a possible approach to better support TPA’s business processes and needs in terms of knowledge management. Suddenly, a smile illuminated her face. The meeting with Bob, Andrew and Harry had really helped her better understand the usage statistics. She now felt ready to prepare her detailed recommendation for the executive management team. 2012-08-23

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

Appendix 1 TPA Organizational Chart (excerpt)

Board of Directors

Executive Director & State CIO

Finance Division

Operations Division

(Harry Linton)

Project Planning Division

(Andrew Collins)

IT Department

(Rita Carson) Projects

Management Solutions

Development

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

Appendix 2 TPA – Information Technology Strategic Plan (excerpt from the 2007 plan)

1) Security: ensure the security of information and IT assets from intruders

The objectives for this strategic focus are: • Provide statewide systems, applications and infrastructure to enable secure

information collection, storage, retention and exchange. • Support the State in its ability to recover all IT services that are critical to business in

the event of a disaster or other significant event. • Build and deploy secure e-government initiatives.

2) Customer Service: improve internal and external customer service to ensure that every person interacting with the state government will have a faster, friendlier, and easier experience

The objectives for this strategic focus are: • Increase scope, quality, availability and usability of electronic services for all

customers. • Foster partnerships between state and local government agencies to provide seamless

services to constituents. • Effectively market available services and how to access them.

3) Service Delivery: provide products and services that are competitive in cost, quality, and sustainability

The objectives for this strategic focus are: • Improve the cost and quality of IT products and services while meeting agreed-upon

service levels. • Develop public-private relationships (enterprise wide preferably) to provide market-

competitive IT products and services. • Increase efficiency and cost savings through innovative uses of existing and new

technologies.

4) IT Governance: ensure that technology projects are aligned with business objectives and deliver a positive return on investments

The objectives for this strategic focus are: • Develop and implement portfolio management and oversight processes at the

enterprise and agency levels. • Formulate IT life cycle management guidelines (define, design, develop, deploy,

support). • Improve project management practices, tools and execution to ensure efficient,

effective and appropriate use of state, federal and local funds. • Improve efficiencies in enterprise-wide IT procurement processes and contracts.

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

5) Agency Collaboration: provide the necessary IT tools to coordinate services, empower state employees, and enhance services offered to citizens

The objectives for this strategic focus are: • Share data, knowledge, and services easily across boundaries (internal and external). • Promote IT solutions that support common business processes across the agencies. • Leverage enterprise architecture to take advantage of emerging trends and support IT

initiatives.

6) IT Workforce: attract, support, train, recognize and retain a highly skilled IT workforce

The objectives for this strategic focus are: • Improve attraction and retention of critical skills within the state’s IT workforce. • Improve IT workforce knowledge and skills through training and development

opportunities. • Increase workforce flexibility through mobility, teleworking and flex-work initiatives. • Improve the overall workforce knowledge, skills and productivity in the use of

technology.

7) Internal Business Processes: continuously improve internal processes and procedures to add value and meet customer needs

The objectives for this strategic focus are: • Simplify, update or repair internal processes and procedures to better meet customer

needs. • Improve internal processes and procedures regarding program/project management,

procurement, pricing and cost recovery, and integrated planning.

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

Appendix 3 List of Collaboration Opportunities

This list includes examples of collaboration opportunities to reduce inefficiencies within TPA.

COLLABORATION OPPORTUNITIES EXAMPLES

Shared infrastructures Wide area network, IBM mainframe

Shared application services Payment engine, content management system

Shared applications Licensing & permitting

Shared business process Document imaging, call centres

Enterprise contracts Contracts with Microsoft, Oracle, Digital Copier

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

Appendix 4 Most Common Knowledge Sharing Tools in Phase 1

TOOLS HOW THEY ARE USED FOR KNOWLEDGE SHARING

Shared drive  Shared folder that can be remotely accessed from another computer, usually via a local area network, as if it were a resource on the local machine;

 Used to store project deliverables, contact information, meeting minutes, lessons-learned databases, diagrams (e.g., organizational charts, project charts, graphical representations of the system, etc.), memos, white papers, and roadmaps.

Microsoft Project  A project management software program that assists project managers in developing plans, assigning resources to tasks, tracking project progress, managing budgets and analyzing workloads;

 Used by some project managers to store contextual information about clients or projects within the traditional charts and diagrams;

 Microsoft Project files were sometimes stored on individual manager’s computers and sometimes on the shared drive.

Email  Used for dissemination and storage of electronic messages describing contextual information about clients and projects.

Instant Messaging  Real-time text-based communication between two or more people;  Used by developers to share advice and help each other during the

actual development of the technical solution.

Intranet  TPA’s internal website has functionalities to allow file transfers and discussion forums among TPA’s employees.

Project templates (as text documents or spreadsheets)

 Examples of project templates are checklists, audit lists, dashboards, “best practices” lists, project standards list, etc.;

 Used to codify key knowledge about projects in order to facilitate communication and reporting across projects;

 Project templates were sometimes stored on individual managers’ computers and sometimes on the shared drive.

Phone  Used by several project managers and team members to share their expertise.

We Gave Them a Tool, but Hardly Anyone’s Using It! Untangling the Knowledge Management Dilemma at TPA

Appendix 5 Additional Background Information on Key Players

Rita Carson

- Role: Leading director of the IT Department at TPA - PMP certified project manager - Before working for TPA, she had 8 years of experience as a consultant in service design

and operations. She had successfully delivered a wide range of IT solutions.

Bob Archer - Role: Knowledge Manager at TPA - Executive project manager in the Project Planning Division - Before being named Knowledge Manager, Bob Archer had two main responsibilities.

First, he oversaw program and project management in the Project Planning Division, making sure that the project management methodology was applied efficiently. Second, he was responsible for identifying and planning training sessions not only for the Project Planning Division, but also for the other two divisions. Bob Archer was highly appreciated by his peers because he managed to increase the success rate (in terms of cost, time and scope) of external IT projects from 35% to 78%.

- He was a very good communicator, with a passion for sharing his expertise on project management. He understood the value of knowledge sharing, and the executive management team believed he was the best person to convince people to use a knowledge repository. His appointment as Knowledge Manager did not surprise anyone. This responsibility was in addition to the other two responsibilities he already had.

- He didn’t have much experience with KMS implementation projects, but for him KMS was not much different from any other complex IS. Thus, he was confident he was up to the task.

Andrew Collins - Role: Director of the Project Planning Division - PMP certified project manager - He had over 20 years of experience in effectively managing and delivering integrated

computer systems, performing strategic business planning, financial planning and business process re-engineering. He had worked for both public and private companies.

Harry Linton - Role: Director of the Operations Division - Project manager - An accomplished director with extensive experience in directing operations. Before

joining TPA in 2005, he worked as a consultant providing IT solutions to small and mid- size companies and as an IT consultant for a local government agency.