Difference between revisions of "Information technology"
(→Common pitfalls) |
|||
(20 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
==Purpose & benefits== | ==Purpose & benefits== | ||
− | The appropriately implemented technology can enable the KM program and activities of the organization. | + | The appropriately implemented information technology (IT) can enable the KM program and activities of the organization. Information technology can make or break a KM program: if it is done well KM can be very successful, if it is done poorly KM will fail, but IT is not the only part of a KM program, it is an enabler only. |
==Description== | ==Description== | ||
+ | IT refers to both hardware and software, it can be owned and operated by the organization or it can be cloud-based, whatever makes sense for the size and operations of the organization. | ||
==Variations== | ==Variations== | ||
+ | Information technology may be referred to as knowledge management technology, technology, or as any of the various types of supporting technologies (see a partial list in the [[#Related articles]] section. | ||
==Implementation guide== | ==Implementation guide== | ||
+ | ===Step 1: Collect=== | ||
+ | First analyse the organization’s existing Knowledge Management practices, starting with current information and knowledge processes or flows, business processes, and organizational culture. This analysis is crucial to understanding the current state of the People, Process, and Technology components that are part of the Knowledge Management activities. | ||
+ | |||
+ | Information collected through the use of interviews, questionnaires, and workshops is incorporated into a KM Strategic Plan document that becomes the basis for the next steps in the Knowledge Management initiative. | ||
+ | It is only in understanding the current state that a plan can be developed to more to the desired future state. | ||
+ | |||
+ | ===Step 2: Analyse=== | ||
+ | The goal of the Analyse step is to review/interpret the information gathered in the Collect step and to create a framework of processes, knowledge, and information flows. These are then associated with Knowledge Management methods and best practices as well as the technology or technologies that will support them. Throughout this phase, the organization must work to understand how its processes can be evolved to create stability and flexibility to advance the maturity of the Knowledge Management activities within the organization. | ||
+ | |||
+ | ===Step 3: Resolve=== | ||
+ | The analysis from Step 2 is summarized in a strategic plan document that forms the basis for future phases in the Knowledge Management initiative. Key to this is to rationalize existing and desired processes and information flows, identifying dependencies, and defining metrics and key success factors. The finalization of the plan typically includes a maximum of two iterations/review sessions with identified stakeholders; more than two iterations results in loss of momentum and loss of interest/buy-in by the stakeholders. Reviewing the strategic plan with the stakeholders and getting input helps with buy in and support, but also ensures that nothing was misunderstood or overlooked. The plan often includes the following sections: | ||
+ | • Baseline metrics and KPI’s (key performance indicators); | ||
+ | • Best Practices; | ||
+ | • Governance, e.g. policies and processes; | ||
+ | • KM Requirements analysis; | ||
+ | • Knowledge lifecycle process; | ||
+ | • Management of change plan, including communication, training, and awareness-raising activities; | ||
+ | • Plan for developing a high-level taxonomy and meta-data; | ||
+ | • Roles and responsibilities; | ||
+ | • Scalable, phased roadmap for KM within the organization; | ||
+ | • Strategic direction. | ||
+ | |||
+ | ===Step 4: Select software application=== | ||
+ | Once the strategic plan is created, the organization can take the requirements developed and specified in the Collect-Analyse-Resolve steps and start looking at specific technologies. The organization may want to consider creating their own application rather than buying an application off-the-shelf, especially if they have needs that are not met by the marketplace. However, in most cases, the benefits of buying off-the-shelf software far outweigh the benefits of a custom development initiative. This make versus buy decision will be further discussed in a later chapter. | ||
+ | |||
+ | When selecting an application, it is important to compare the same features and functions against each technology being considered. The easiest way to do this is to create a scoring methodology and record scores for each application. Adding up the totals will give each application a score. Once each application is scored, appointments with the desired vendors can be made to review their product or depending on the organizational rules, an RFP can be issued to the desired vendors. | ||
+ | |||
+ | In making a final decision, each of the finalists must be rated and ranked on the same criteria, therefore the initial scoring system may need to be modified based on the results of the functionality review, e.g. some functionality may be available out-of-the-box from one vendor, while another requires it to be a customization, price is not the only criteria. Other factors that may influence the decision-making process are guidelines put forth by the IT department and / or any existing vendor relationships. | ||
+ | |||
+ | ===Step 5: Design/develop/test=== | ||
+ | Design, develop, and test, are a fairly standard set of IT activities. Design is creating and documenting the customization and configuration information in the case where software has been purchased off-the-shelf. In the case where the organization has decided to create a customized application, the design phase is quite detailed as users will be involved in detailed design sessions so that the application development team has the information they need to design and develop the application. | ||
+ | |||
+ | A critical part of the design/develop/test step is determining the high-level taxonomy and meta-data as planned in the over-all KM Strategic Plan. Detail level taxonomy and meta-data are created as needed as part of the implementation and evolution of the KM initiative. The taxonomy and meta-data may need to be revised as the application and processes are tested, this is expected and will help ensure the acceptance of the KM technology and processes once they are implemented. | ||
+ | |||
+ | If the organization has chosen a customized application, there are many software design lifecycle (SDLC) methodologies that could be followed. SDLC methodologies will not be discussed further as they are beyond the scope of this article. | ||
+ | |||
+ | Once the customization and configuration details have been determined, the application can be configured to meet the organization's needs. This is the develop activity for an off-the-shelf software application. | ||
+ | Performing adequate testing is critical to the success of the implementation. There are many types and levels of testing that must be performed. Two of the key sets of tests are: functional testing, which ensures the application works the way users expect it to work; and stability testing ,which makes sure the application consistently performs at or above an acceptable level; this is often called load testing. | ||
+ | |||
+ | It is important to include users in the functional testing as the users are able to easily identify functions that do not work as they should. Catching these types of errors before the system goes live helps to ensure its success once it is operational. | ||
+ | |||
+ | The other important consideration with testing is that the final test environment should be the same as the production environment; this is often referred to as the user acceptance environment or staging environment. It should mirror of the production environment as this allows IT to monitor how the application behaves and predict as best as possible how it will perform in the production environment without it actually being in the production environment thus reducing the likelihood that the application will fail when it moves to production. | ||
+ | |||
+ | ===Step 6: Implementation=== | ||
+ | The implementation step involves organization staff as much as possible, so that the organization feels that it is part of the process and will be able to continue with KM on their own once the project is completed and the KM activities are completely implemented. This approach maximizes buy-in and acceptance among staff, helping to ensure the ultimate success of KM within the organization. | ||
+ | |||
+ | Implementation includes executing an initial Management of Change plan and evolving the plan for future phases of the KM initiative. The Management of Change plan will include training and communication activities to help inform and engage staff throughout the organization. Part of the Management of Change activities will be to assign roles and responsibilities as they were envisioned in the KM Strategic Plan. | ||
+ | |||
+ | Implementation activities also include a roll-out of KM processes, workflows, and governance as defined in the KM strategic plan and capture base-line metrics. Additionally, an evaluation of the need to select/develop further metrics is included in this step. | ||
+ | |||
+ | ===Step 7: Use=== | ||
+ | At this step of the KM programme, the organization is using the application in its everyday activities. Governance policies and programmes are being executed and monitored by the governance committee and future projects are being planned. Feedback and suggestions for improvements are being collected and implemented where possible and prioritized where they may require budget, longer-term planning, or additional resources not otherwise available as part of regular operational activity. | ||
+ | |||
+ | ===Step 8: Evolve=== | ||
+ | In the evolve step, the feedback and suggestions for improvement received during the Use step, are evaluated along with improvements based on new releases in the application from the vendor as well as changes made necessary by the maturation of the organization. As the organization matures in its use of the technology and KM processes , staff often become capable of using more complex functionality and features, and of generally performing more sophisticated tasks with the technology implemented to support their KM activities. This evolution is desired and necessary. | ||
+ | |||
+ | The other part of the evolve stage is the continued implementation of the strategic plan that was developed earlier as part of the road map process. As the strategic plan is implemented, it continues to evolve to meet the needs of the organization as they currently exist and as they are anticipated to change over a rolling 3 to 5 year time horizon. | ||
+ | |||
+ | A diagram of this process created by [http://missingpuzzlepiececonsulting.ca/about Stephanie Barnes] is below. | ||
[[File:IT_implementation_roadmap.png]] | [[File:IT_implementation_roadmap.png]] | ||
==Success factors== | ==Success factors== | ||
+ | ===Understand business objectives=== | ||
+ | The first thing to do is to understand the business objectives. This means understanding the issue that the business is trying to resolve. For example, is the business trying to increase sales, are they trying to improve marketing campaign results, are they trying to improve communication, is there a collaboration problem that needs to be corrected? Just what is the problem that is being addressed and how does it align with the overall organizational strategy? Understanding the objective(s) underpins not only the selection of the right kind of technology but the determination of success criteria and metrics for the initiative. | ||
+ | |||
+ | ===Understand user requirements=== | ||
+ | Another activity in aligning the business and IT is understanding the user requirements from a business perspective. This means asking the users what functionality they currently have in any existing tools that they may be using and asking them what additional functionality they want. This is not as easy as it may seem as the users may not understand the functionality that is available or know what they want. In this case, it is incumbent upon the person collecting the requirements to know the functionalities that are available and discuss them with the users. In some cases this may involve showing users’ technology options; however, this should be avoided if possible, as jumping to possible solutions too soon can spell disaster for the project through misaligned expectations. | ||
+ | |||
+ | Part of understanding user requirements is understanding how people do their work. When do they work, how do they work, who do they work with, what tools do they use, and what expectations do they have about the availability of technology and information. These are all important questions to ask in determining the technology requirements. The technology requirements do not just mean the software but also mean the hardware requirement, for example, what is its availability level, where geographically should it be located, what kinds of bandwidth and redundancy are required. | ||
+ | |||
+ | In understanding user requirements it is important to identify groups of users based on the types of activities they will be doing using the technology. For example, Community of Practice leaders is one type of user group or profile. They will expect to be able to create a community, add members, send messages, and do other administrative and facilitative activities for their Community using the technology platform. | ||
+ | |||
+ | ===Embed KM in processes=== | ||
+ | Once the strategic and process driven requirements are understood it is important to determine how Knowledge Management will be embedded in these processes. Do the processes need to change, does the software need to be configured to accommodate existing processes, what needs to happen in order to enable the business processes with Knowledge Management. | ||
+ | |||
+ | ===Training and communications=== | ||
+ | Part of this alignment with business processes includes the training and communication plan. It is important to train staff in the new technology. Whether that training takes place in a classroom or through CBT (computer-based training), or through some other means is up to the implementation team to determine. Training will be different for different organizations and for different groups within an organization. The communication plan needs to assess the needs of various stakeholder groups and determine the frequency of the messaging to each group, in order to maximize buy-in and support. | ||
+ | |||
+ | ===Metrics=== | ||
+ | Metrics are an important part of ensuring the technology is aligned with the business needs. Understanding what the business needs to measure helps to identify the data that needs to be collected as part of the technology. In fact, that the technology must be able to collect data and report on it in order to meet business needs and objectives is itself a requirement. | ||
+ | |||
+ | ===Senior management support=== | ||
+ | Another component of business-IT alignment is ensuring that there is passionate and on-going senior management support. It is only through buy-in at senior levels and a relationship between business and IT management that the Knowledge Management initiative will be able to get the resources it needs to be successful. When other stakeholders see the management alignment and support, they are more likely to support it themselves. | ||
+ | |||
+ | ===Cross-functional participation=== | ||
+ | Implementing Knowledge Management technology goes across functions in the organization, as such, it is a necessary part of the project to reach out into the whole organization by creating a virtual team. While at first glance this may seem cumbersome and time-consuming, the investment in involving all stakeholders in the initial planning stages is critical to the success of the project. Soliciting user requirements from all areas of the organization helps to ensure that nothing is missed; it also helps in change management, communication, implementation, rollout support, on-going maintenance, improvement, and governance activities. Without this kind of involvement across the organization, technology may very well be rolled out, but it will be perceived as something that IT or another organizational department is doing to the rest of the organization and it will not be adopted and used, resulting in sub-optimal ROI and productivity improvements. | ||
+ | |||
+ | Having implementation leads from across the business helps to ensure that as the technology and Knowledge Management activities are rolled out they align with the users and their processes. This allows for minor modifications in configuration if necessary. As previously mentioned, this distributed model helps ensure buy-in and support from all stakeholders. | ||
+ | |||
+ | Tied into these previous two points is the need for the KM initiative to have relationships with key knowledge network points within the organization. Understanding who these people are and the role that they play is critical to the successful adoption of the KM technology and programme as a whole. These people are thought leaders, gateways, to the legions of people in their network that they may work with regularly, or only on an occasional basis. Having the support of these individuals makes roll-out that much easier. | ||
+ | |||
+ | ===Technology is a means to an end=== | ||
+ | It must be remembered that technology is a means to an end, not the end itself. If stakeholders and business processes are not involved and considered as part of the process of determining what technology to purchase or create, the best software in the world can be rolled-out to the organization, but no one will use it. | ||
+ | |||
+ | ===Adequate budget=== | ||
+ | The last thing to consider in aligning business and IT around the Knowledge Management technology is that an adequate budget must exist. Users will provide lots of requirements and functionality requests that will make their jobs easier. All of this functionality does not need to be available at the initial roll-out, but the functionality does need to be prioritized and a set of "must-have" functionality must be incorporated into the initial technology release. If that core technology functionality is not present users will rebel against the implementation and will continue to do their jobs the way that they have always done them. The investment in planning, technology selection, and development will have been for nothing. | ||
==Common pitfalls== | ==Common pitfalls== | ||
− | + | ===Silos=== | |
+ | Silos are created when too much emphasis is placed on a single activity whether it’s the Technology, People, or Process to the exclusion of the other two key success activities. For example, focusing on technology and ignoring the people and process part of the programme. Technology is easy to focus on, but it only addresses one of three keys to success. Developing and implementing people and process initiatives in conjunction with the technology will enable the success of the over-all initiative. By ignoring people and process activities, an organization will have another technology platform that is underutilized. | ||
+ | |||
+ | To mitigate the risk of this occurring, it is important to have strong leadership and grassroots support for the initiative so that both management and front-line staff are involved and continue to be involved as the initiative moves forward. Both management and staff must recognize that it is important to maintain balance among People, Process, and Technology in order to be successful. | ||
+ | |||
+ | ===People/groups not participating=== | ||
+ | There is always a risk of people/groups not participating, i.e. they will create their own local solutions or will just not participate and that they will continue in their less efficient and effective behaviours. Lack of participation also results in a sub-optimal solution being rolled out, having user input is critical to designing a solution that will be user-friendly, and address pain points helping rather than hindering people’s ability to do their jobs. | ||
+ | |||
+ | A comprehensive management of change initiative will help to ensure that people and groups participate in the Knowledge Management programme. Management of change incorporates communication, education and training to help staff adapt to the new activities. Additionally, there are always early adopters and laggards. Sometimes people or groups will need to be re-prioritized until it is the right time to bring them on-board. | ||
+ | |||
+ | ===Loss of momentum=== | ||
+ | Loss of momentum occurs when the excitement, enthusiasm, and interest built up in the requirements phase of the project is lost due to delays in selecting and implementing the technology or otherwise moving forward with the KM initiative. At the early stages people are interested and involved, but it is easy for them to lose that focus and commitment /enthusiasm and transfer it to other initiatives. | ||
+ | |||
+ | This loss of momentum can be mitigated through ensuring an adequate budget is committed to by management which supports the Knowledge Management initiative, and a comprehensive management of change plan is in place and being executed. Management of change can help communicate any changes in the planned implementation and rollout of KM activities. | ||
+ | |||
+ | ===Passion to lead KM=== | ||
+ | Not identifying someone with the capacity, commitment and passion to lead the initiative. The KM initiative is not technically difficult but there are significant risks around how it is led, developed and implemented because people have to change their behaviours; facilitating/championing this change requires passion and commitment on the part of the leader. It needs to be someone who has credibility with both management and front-line workers. It also needs to be someone who is senior enough in the organization to have positional power, i.e. someone with influence and visibility. | ||
+ | |||
+ | This is a difficult risk to mitigate. Certainly the Knowledge Management programme can move forward without someone in this role, however, true organizational success will only come when there is someone with the availability (see above) and passion to lead the initiative. | ||
+ | |||
+ | ===Link to the business case is lost=== | ||
+ | Losing the link to the business case is a risk, especially when KM has been viewed as a quick fix for a problem or if a solid business reason for KM is not established. It is critical that the focus remains on solving the business issues that gave rise to this KM initiative in the first place. Losing that link will result in a lack of direction and potential failure of the initiative. | ||
+ | To help mitigate this risk, it is important, in securing support to move to the collect phase, to select a business case that is critical enough and with enough visible impact within the organization that it will not diminish in importance over time. | ||
+ | |||
+ | ===Organizational culture=== | ||
+ | The culture of the organization can result in implementation issues and failure. The culture must be taken into consideration and factored into in the change management activities for the programme through communication, and rewards and recognition initiatives. | ||
+ | |||
+ | The risks associated with the culture of the organization can be mitigated through a thorough analysis of the culture during the collect and analyse phase of the Knowledge Management initiative. It is during these early stages of the programme that an understanding of the culture becomes critical, to ensure success throughout the remaining phases. | ||
+ | |||
+ | ===Sponsorship=== | ||
+ | There is a risk that sponsorship of the initiative will not be clear and directed. Should the programme lose its sponsorship or that sponsorship wane, the programme will be in jeopardy. It is important that people understand the management team supports and endorses the initiative. | ||
+ | |||
+ | Like the risk identified above regarding availability and passion of the KM leader, this is a difficult risk to mitigate. Certainly the Knowledge Management programme can move forward without a sponsor, but, true organizational success will only come with the commitment of a sponsor who consistently promotes the KM initiative as opposed to limiting his/her involvement to providing funding. | ||
==Related articles== | ==Related articles== | ||
Line 49: | Line 176: | ||
[[Wiki]] | [[Wiki]] | ||
+ | ==External references and articles== | ||
+ | # Much of the content on this page is originally from [https://www.ark-group.com/product/aligning-people-process-and-technology-knowledge-management#.Vt2FmpMrL-Y Aligning People, Process, and Technology in Knowledge Management] by [http://missingpuzzlepiececonsulting.ca/about Stephanie Barnes] | ||
[[Category:Information technology]] | [[Category:Information technology]] |
Latest revision as of 12:26, 9 March 2016
Contents
Definition
Comprises the elements of computing, including software, servers, networks and desktop computing, which enable digital information to be created, stored, used and shared.
Purpose & benefits
The appropriately implemented information technology (IT) can enable the KM program and activities of the organization. Information technology can make or break a KM program: if it is done well KM can be very successful, if it is done poorly KM will fail, but IT is not the only part of a KM program, it is an enabler only.
Description
IT refers to both hardware and software, it can be owned and operated by the organization or it can be cloud-based, whatever makes sense for the size and operations of the organization.
Variations
Information technology may be referred to as knowledge management technology, technology, or as any of the various types of supporting technologies (see a partial list in the #Related articles section.
Implementation guide
Step 1: Collect
First analyse the organization’s existing Knowledge Management practices, starting with current information and knowledge processes or flows, business processes, and organizational culture. This analysis is crucial to understanding the current state of the People, Process, and Technology components that are part of the Knowledge Management activities.
Information collected through the use of interviews, questionnaires, and workshops is incorporated into a KM Strategic Plan document that becomes the basis for the next steps in the Knowledge Management initiative. It is only in understanding the current state that a plan can be developed to more to the desired future state.
Step 2: Analyse
The goal of the Analyse step is to review/interpret the information gathered in the Collect step and to create a framework of processes, knowledge, and information flows. These are then associated with Knowledge Management methods and best practices as well as the technology or technologies that will support them. Throughout this phase, the organization must work to understand how its processes can be evolved to create stability and flexibility to advance the maturity of the Knowledge Management activities within the organization.
Step 3: Resolve
The analysis from Step 2 is summarized in a strategic plan document that forms the basis for future phases in the Knowledge Management initiative. Key to this is to rationalize existing and desired processes and information flows, identifying dependencies, and defining metrics and key success factors. The finalization of the plan typically includes a maximum of two iterations/review sessions with identified stakeholders; more than two iterations results in loss of momentum and loss of interest/buy-in by the stakeholders. Reviewing the strategic plan with the stakeholders and getting input helps with buy in and support, but also ensures that nothing was misunderstood or overlooked. The plan often includes the following sections: • Baseline metrics and KPI’s (key performance indicators); • Best Practices; • Governance, e.g. policies and processes; • KM Requirements analysis; • Knowledge lifecycle process; • Management of change plan, including communication, training, and awareness-raising activities; • Plan for developing a high-level taxonomy and meta-data; • Roles and responsibilities; • Scalable, phased roadmap for KM within the organization; • Strategic direction.
Step 4: Select software application
Once the strategic plan is created, the organization can take the requirements developed and specified in the Collect-Analyse-Resolve steps and start looking at specific technologies. The organization may want to consider creating their own application rather than buying an application off-the-shelf, especially if they have needs that are not met by the marketplace. However, in most cases, the benefits of buying off-the-shelf software far outweigh the benefits of a custom development initiative. This make versus buy decision will be further discussed in a later chapter.
When selecting an application, it is important to compare the same features and functions against each technology being considered. The easiest way to do this is to create a scoring methodology and record scores for each application. Adding up the totals will give each application a score. Once each application is scored, appointments with the desired vendors can be made to review their product or depending on the organizational rules, an RFP can be issued to the desired vendors.
In making a final decision, each of the finalists must be rated and ranked on the same criteria, therefore the initial scoring system may need to be modified based on the results of the functionality review, e.g. some functionality may be available out-of-the-box from one vendor, while another requires it to be a customization, price is not the only criteria. Other factors that may influence the decision-making process are guidelines put forth by the IT department and / or any existing vendor relationships.
Step 5: Design/develop/test
Design, develop, and test, are a fairly standard set of IT activities. Design is creating and documenting the customization and configuration information in the case where software has been purchased off-the-shelf. In the case where the organization has decided to create a customized application, the design phase is quite detailed as users will be involved in detailed design sessions so that the application development team has the information they need to design and develop the application.
A critical part of the design/develop/test step is determining the high-level taxonomy and meta-data as planned in the over-all KM Strategic Plan. Detail level taxonomy and meta-data are created as needed as part of the implementation and evolution of the KM initiative. The taxonomy and meta-data may need to be revised as the application and processes are tested, this is expected and will help ensure the acceptance of the KM technology and processes once they are implemented.
If the organization has chosen a customized application, there are many software design lifecycle (SDLC) methodologies that could be followed. SDLC methodologies will not be discussed further as they are beyond the scope of this article.
Once the customization and configuration details have been determined, the application can be configured to meet the organization's needs. This is the develop activity for an off-the-shelf software application. Performing adequate testing is critical to the success of the implementation. There are many types and levels of testing that must be performed. Two of the key sets of tests are: functional testing, which ensures the application works the way users expect it to work; and stability testing ,which makes sure the application consistently performs at or above an acceptable level; this is often called load testing.
It is important to include users in the functional testing as the users are able to easily identify functions that do not work as they should. Catching these types of errors before the system goes live helps to ensure its success once it is operational.
The other important consideration with testing is that the final test environment should be the same as the production environment; this is often referred to as the user acceptance environment or staging environment. It should mirror of the production environment as this allows IT to monitor how the application behaves and predict as best as possible how it will perform in the production environment without it actually being in the production environment thus reducing the likelihood that the application will fail when it moves to production.
Step 6: Implementation
The implementation step involves organization staff as much as possible, so that the organization feels that it is part of the process and will be able to continue with KM on their own once the project is completed and the KM activities are completely implemented. This approach maximizes buy-in and acceptance among staff, helping to ensure the ultimate success of KM within the organization.
Implementation includes executing an initial Management of Change plan and evolving the plan for future phases of the KM initiative. The Management of Change plan will include training and communication activities to help inform and engage staff throughout the organization. Part of the Management of Change activities will be to assign roles and responsibilities as they were envisioned in the KM Strategic Plan.
Implementation activities also include a roll-out of KM processes, workflows, and governance as defined in the KM strategic plan and capture base-line metrics. Additionally, an evaluation of the need to select/develop further metrics is included in this step.
Step 7: Use
At this step of the KM programme, the organization is using the application in its everyday activities. Governance policies and programmes are being executed and monitored by the governance committee and future projects are being planned. Feedback and suggestions for improvements are being collected and implemented where possible and prioritized where they may require budget, longer-term planning, or additional resources not otherwise available as part of regular operational activity.
Step 8: Evolve
In the evolve step, the feedback and suggestions for improvement received during the Use step, are evaluated along with improvements based on new releases in the application from the vendor as well as changes made necessary by the maturation of the organization. As the organization matures in its use of the technology and KM processes , staff often become capable of using more complex functionality and features, and of generally performing more sophisticated tasks with the technology implemented to support their KM activities. This evolution is desired and necessary.
The other part of the evolve stage is the continued implementation of the strategic plan that was developed earlier as part of the road map process. As the strategic plan is implemented, it continues to evolve to meet the needs of the organization as they currently exist and as they are anticipated to change over a rolling 3 to 5 year time horizon.
A diagram of this process created by Stephanie Barnes is below.
Success factors
Understand business objectives
The first thing to do is to understand the business objectives. This means understanding the issue that the business is trying to resolve. For example, is the business trying to increase sales, are they trying to improve marketing campaign results, are they trying to improve communication, is there a collaboration problem that needs to be corrected? Just what is the problem that is being addressed and how does it align with the overall organizational strategy? Understanding the objective(s) underpins not only the selection of the right kind of technology but the determination of success criteria and metrics for the initiative.
Understand user requirements
Another activity in aligning the business and IT is understanding the user requirements from a business perspective. This means asking the users what functionality they currently have in any existing tools that they may be using and asking them what additional functionality they want. This is not as easy as it may seem as the users may not understand the functionality that is available or know what they want. In this case, it is incumbent upon the person collecting the requirements to know the functionalities that are available and discuss them with the users. In some cases this may involve showing users’ technology options; however, this should be avoided if possible, as jumping to possible solutions too soon can spell disaster for the project through misaligned expectations.
Part of understanding user requirements is understanding how people do their work. When do they work, how do they work, who do they work with, what tools do they use, and what expectations do they have about the availability of technology and information. These are all important questions to ask in determining the technology requirements. The technology requirements do not just mean the software but also mean the hardware requirement, for example, what is its availability level, where geographically should it be located, what kinds of bandwidth and redundancy are required.
In understanding user requirements it is important to identify groups of users based on the types of activities they will be doing using the technology. For example, Community of Practice leaders is one type of user group or profile. They will expect to be able to create a community, add members, send messages, and do other administrative and facilitative activities for their Community using the technology platform.
Embed KM in processes
Once the strategic and process driven requirements are understood it is important to determine how Knowledge Management will be embedded in these processes. Do the processes need to change, does the software need to be configured to accommodate existing processes, what needs to happen in order to enable the business processes with Knowledge Management.
Training and communications
Part of this alignment with business processes includes the training and communication plan. It is important to train staff in the new technology. Whether that training takes place in a classroom or through CBT (computer-based training), or through some other means is up to the implementation team to determine. Training will be different for different organizations and for different groups within an organization. The communication plan needs to assess the needs of various stakeholder groups and determine the frequency of the messaging to each group, in order to maximize buy-in and support.
Metrics
Metrics are an important part of ensuring the technology is aligned with the business needs. Understanding what the business needs to measure helps to identify the data that needs to be collected as part of the technology. In fact, that the technology must be able to collect data and report on it in order to meet business needs and objectives is itself a requirement.
Senior management support
Another component of business-IT alignment is ensuring that there is passionate and on-going senior management support. It is only through buy-in at senior levels and a relationship between business and IT management that the Knowledge Management initiative will be able to get the resources it needs to be successful. When other stakeholders see the management alignment and support, they are more likely to support it themselves.
Cross-functional participation
Implementing Knowledge Management technology goes across functions in the organization, as such, it is a necessary part of the project to reach out into the whole organization by creating a virtual team. While at first glance this may seem cumbersome and time-consuming, the investment in involving all stakeholders in the initial planning stages is critical to the success of the project. Soliciting user requirements from all areas of the organization helps to ensure that nothing is missed; it also helps in change management, communication, implementation, rollout support, on-going maintenance, improvement, and governance activities. Without this kind of involvement across the organization, technology may very well be rolled out, but it will be perceived as something that IT or another organizational department is doing to the rest of the organization and it will not be adopted and used, resulting in sub-optimal ROI and productivity improvements.
Having implementation leads from across the business helps to ensure that as the technology and Knowledge Management activities are rolled out they align with the users and their processes. This allows for minor modifications in configuration if necessary. As previously mentioned, this distributed model helps ensure buy-in and support from all stakeholders.
Tied into these previous two points is the need for the KM initiative to have relationships with key knowledge network points within the organization. Understanding who these people are and the role that they play is critical to the successful adoption of the KM technology and programme as a whole. These people are thought leaders, gateways, to the legions of people in their network that they may work with regularly, or only on an occasional basis. Having the support of these individuals makes roll-out that much easier.
Technology is a means to an end
It must be remembered that technology is a means to an end, not the end itself. If stakeholders and business processes are not involved and considered as part of the process of determining what technology to purchase or create, the best software in the world can be rolled-out to the organization, but no one will use it.
Adequate budget
The last thing to consider in aligning business and IT around the Knowledge Management technology is that an adequate budget must exist. Users will provide lots of requirements and functionality requests that will make their jobs easier. All of this functionality does not need to be available at the initial roll-out, but the functionality does need to be prioritized and a set of "must-have" functionality must be incorporated into the initial technology release. If that core technology functionality is not present users will rebel against the implementation and will continue to do their jobs the way that they have always done them. The investment in planning, technology selection, and development will have been for nothing.
Common pitfalls
Silos
Silos are created when too much emphasis is placed on a single activity whether it’s the Technology, People, or Process to the exclusion of the other two key success activities. For example, focusing on technology and ignoring the people and process part of the programme. Technology is easy to focus on, but it only addresses one of three keys to success. Developing and implementing people and process initiatives in conjunction with the technology will enable the success of the over-all initiative. By ignoring people and process activities, an organization will have another technology platform that is underutilized.
To mitigate the risk of this occurring, it is important to have strong leadership and grassroots support for the initiative so that both management and front-line staff are involved and continue to be involved as the initiative moves forward. Both management and staff must recognize that it is important to maintain balance among People, Process, and Technology in order to be successful.
People/groups not participating
There is always a risk of people/groups not participating, i.e. they will create their own local solutions or will just not participate and that they will continue in their less efficient and effective behaviours. Lack of participation also results in a sub-optimal solution being rolled out, having user input is critical to designing a solution that will be user-friendly, and address pain points helping rather than hindering people’s ability to do their jobs.
A comprehensive management of change initiative will help to ensure that people and groups participate in the Knowledge Management programme. Management of change incorporates communication, education and training to help staff adapt to the new activities. Additionally, there are always early adopters and laggards. Sometimes people or groups will need to be re-prioritized until it is the right time to bring them on-board.
Loss of momentum
Loss of momentum occurs when the excitement, enthusiasm, and interest built up in the requirements phase of the project is lost due to delays in selecting and implementing the technology or otherwise moving forward with the KM initiative. At the early stages people are interested and involved, but it is easy for them to lose that focus and commitment /enthusiasm and transfer it to other initiatives.
This loss of momentum can be mitigated through ensuring an adequate budget is committed to by management which supports the Knowledge Management initiative, and a comprehensive management of change plan is in place and being executed. Management of change can help communicate any changes in the planned implementation and rollout of KM activities.
Passion to lead KM
Not identifying someone with the capacity, commitment and passion to lead the initiative. The KM initiative is not technically difficult but there are significant risks around how it is led, developed and implemented because people have to change their behaviours; facilitating/championing this change requires passion and commitment on the part of the leader. It needs to be someone who has credibility with both management and front-line workers. It also needs to be someone who is senior enough in the organization to have positional power, i.e. someone with influence and visibility.
This is a difficult risk to mitigate. Certainly the Knowledge Management programme can move forward without someone in this role, however, true organizational success will only come when there is someone with the availability (see above) and passion to lead the initiative.
Link to the business case is lost
Losing the link to the business case is a risk, especially when KM has been viewed as a quick fix for a problem or if a solid business reason for KM is not established. It is critical that the focus remains on solving the business issues that gave rise to this KM initiative in the first place. Losing that link will result in a lack of direction and potential failure of the initiative. To help mitigate this risk, it is important, in securing support to move to the collect phase, to select a business case that is critical enough and with enough visible impact within the organization that it will not diminish in importance over time.
Organizational culture
The culture of the organization can result in implementation issues and failure. The culture must be taken into consideration and factored into in the change management activities for the programme through communication, and rewards and recognition initiatives.
The risks associated with the culture of the organization can be mitigated through a thorough analysis of the culture during the collect and analyse phase of the Knowledge Management initiative. It is during these early stages of the programme that an understanding of the culture becomes critical, to ensure success throughout the remaining phases.
Sponsorship
There is a risk that sponsorship of the initiative will not be clear and directed. Should the programme lose its sponsorship or that sponsorship wane, the programme will be in jeopardy. It is important that people understand the management team supports and endorses the initiative.
Like the risk identified above regarding availability and passion of the KM leader, this is a difficult risk to mitigate. Certainly the Knowledge Management programme can move forward without a sponsor, but, true organizational success will only come with the commitment of a sponsor who consistently promotes the KM initiative as opposed to limiting his/her involvement to providing funding.
Related articles
External references and articles
- Much of the content on this page is originally from Aligning People, Process, and Technology in Knowledge Management by Stephanie Barnes