Change Initiatives

From EITBOK
Jump to: navigation, search
Welcome to the initial version of the EITBOK wiki. Like all wikis, it is a work in progress and may contain errors. We welcome feedback, edits, and real-world examples. Click here for instructions about how to send us feedback.
Ieee logo 1.png
Acm logo 3.png

 

1 Introduction

Enterprise information technology (EIT) projects are rarely just about changes in technology. Projects that increase business value always involve an array of technical and non-technical people, also known as the stakeholders.

The greatest risk to the success of a change initiative project is the failure to consider major aspects of organizational change management (OCM). Poor communications, inadequate training, insufficient workforce planning, or fear of the unknown future state can result in partial or complete rejection of business changes as well as poor performance at the end-user level. In some cases, failure to provide adequate organizational change-management planning can result in a failed or delayed implementation and a loss of millions of dollars.

OCM encompasses all activities that help people within an organization successfully accept and adopt new technologies, accept changes to how they perform their job, and design new ways to serve their customers. The change itself is defined during the EIT strategic planning process, as described in the Strategy and Governance chapter. If needed, it can be broken down into multiple sequential or parallel projects, as the team examines the types and spans of the needed changes. Specific details for the EIT changes are defined during the requirements phase (see the Requirements chapter).

Effective change management enables the transformation of strategy, processes, technology, and people to enhance performance and ensure continuous improvement in an ever-changing environment. OCM is a comprehensive and structured approach. It is critical to the success of any project that brings about significant change. It needs to be embedded within a change project at every stage. An change-management approach can include performing change impact analysis, organizational change readiness, organizational effectiveness, communication, and stakeholder and process assessments.

The activities associated with OCM should be integrated and executed under the umbrella of the portfolio management discipline. Portfolio management’s purpose is to ensure that all EIT projects directly support an organizational strategy, and to ensure that a consistent prioritization process is used to initialize projects, whether for new or sustainment activities.

2 Goals and Principles

The two primary goals for OCM are:

  • Assess risks regarding planned business and IT change
  • Ensure the engagement of all stakeholders for the successful implementation of the change

The OCM model follows three guiding principles:

  • Principle 1: Change is decentralized.
    OCM activities, such as communications, leadership alignment, impact identification, organization redesign, role definition, and role mapping, are embedded within the process of change. The organization coordinates and orchestrates these efforts, and facilitates the identification and mitigation of issues throughout the project life cycle, from initiation to institutionalization of the change into the day-to-day operations. All team members are involved in these activities, helping to focus the work of change where it is occurring and increase buy in.
  • Principle 2: The business must own the solution.
    Ownership includes both ownership of the project’s solution and ownership of its successful, site-ready implementation. Organizations achieve ownership through robust stakeholder management, ongoing and timely communication, and training and development of the target organization's workforce and management.
  • Principle 3: Success is based on outcomes, not simply deliverables.
    This approach helps the organization understand the impacts, identify the local issues, and address the issues before they become unmanageable. The success of organizational change management is measured relative to the growing increase in commitment of the employees affected by the change, as well as their ability to use the new system, step into new roles and responsibilities, and adopt new processes as the way of doing business.

3 Context Diagram

03 Change Initiatives CD.png

Figure 1. Organizational Change Management

4 Levels of Organizational Change Management

There are typically multiple levels of change management within an organization. These levels span the organizational structure from strategic OCM, which is focused on the roles and responsibilities of senior leaders to drive change throughout the organization, to project-level and even individual-level change management. The individual in the organization is a key element that is often overlooked, and it is at the individual level where the change becomes the most tangible. Addressing the needs of individuals undergoing change is a key component of success. Portfolio-level change management needs to view the changes occurring across the organization in a holistic and integrated manner.

5 Strategic Organizational Change Management

StrategicOrganizationalChangeManagement.jpg

Figure 2. Strategic Organizational Change Management

Six key phases represent the core strategic OCM approach to assessing, planning, generating, executing, and evaluating the work of organizational change:

  • Establish change-focused leadership: Research has repeatedly confirmed that the presence and guidance of leaders during periods of intense organizational change is a critical factor in the success of change. OCM assesses the change-leadership needs, trains and coaches for those needs, and promotes leadership engagement throughout the project as a core accelerator of successful change.
  • Assess change: OCM performs in-depth assessments of the organization’s readiness for change and analysis of key stakeholder needs and business impacts of the change. The assessments provide qualitative and quantitative data that lead to comprehensive and effective OCM planning and execution.
  • Align executives: OCM facilitates the alignment of the organization’s leaders with the project mission, vision, and key success metrics that drive consistent communication and aligned behavior of organizational change agents. The results are increased organizational confidence and positive momentum in support of the change initiative.
  • Translate and communicate: OCM team members, including the change manager, training and communications support, sponsor, and other key stakeholders, translate knowledge gained from the assessment and alignment activities into detailed plans. These plans define how stakeholders are informed of project goals, progress, and impacts, as well as how stakeholders are prepared to function successfully in the new environment. These plans should include the elements described in the table below.
Plan Definition
Master change planProvides an overview of the business reasons for change. It also describes the change-management approach and implementation tactics, feedback mechanisms to be deployed, and schedule of activities.
Communications strategy and planProvides an overall framework for selecting, managing, and coordinating communication activities that prepare stakeholders and help build their commitment to change.
Training strategy and planIdentifies the audience, learning objectives, delivery methods, and timing of training activities.
Management assessment and development planAssesses and creates identifiable actions that senior and mid-level managers can use to sponsor the change and make it successful.

Tasks associated with these plans may also be integrated into the overall project management plan.

  • Execute plans — The project manager, OCM team, and the organization’s executive steering committee and functional change agents work together to facilitate the integration and coordination of the implementation from the core disciplines of OCM. Areas include project management, organization assessment, communications, management development, and training.
  • Evaluate — Evaluation of OCM progress and success contributes to the stabilization of organizational change. A standard practice is to provide onsite support following major change activities to assess where improvement is needed to help the new processes and procedures to take hold. This is also an important task for organizational learning and knowledge transfer.

6 Project OCM Approach and Framework

Organizational change does not happen overnight. It takes time and effort. Affected employees must first understand what the changes are, why they are important to the organization and them, and how they should personally prepare. Only then can employees embrace the changes as the organization transitions and operates under a new set of processes, using a new set of applications and technologies.

Each project is different and each organization has unique change-management challenges. There is no “cookie-cutter” approach to organizational change. Each organization (each division and location for that matter) can have different cultures, different ways of disseminating change, and different information. These challenges can be addressed by using the five-stage framework shown in Figure 3.

Project OCM Approach.gif

Figure 3. Project OCM Approach and Framework

6.1 Plan for Organizational Change

Plan.jpg  
During the Plan stage of any project, the OCM team takes into consideration the organization’s structure with various divisions and departments, as well as how processes flow cross-functionally through those departments. They consider the current state of the organization’s support structure including organizational culture, leadership style, history preferred training, and communications vehicles. All these factors affect what the change activities should be and how they are deployed. With this understanding and a basic picture of the desired future state, the team can solidify the approach, techniques, timelines, and staff responsibilities for the change process. There are three areas of planning in this stage:

  1. Define a leadership action and involvement plan for the change-leadership executive, and identified sponsors to align with the objectives of supporting the project and resulting change. Leadership actions and involvement may vary by role. For example, John, V.P. of Sales, should focus his involvement on the changes in his area, while Yvonne, Chief Information Officer, should focus her efforts on leading the change in EIT.
  2. Work with the organization to clearly understand and classify the affected business units. The team works to understand current roles and responsibilities, preferred communications methods, and the unit's unique culture. The team fine tunes the approach for later tasks to address those challenges in the most efficient manner possible. Next, it identifies the key subject matter experts (SMEs) who support the change-leadership process and serve as champions for their respective business units.
  3. Identify the end users and other stakeholders who are impacted by the project transition. The team also identifies which tools and communication venues are most effective in providing high-level overviews, summaries, and regular updates to keep all stakeholders engaged in the change process. The team should put end users through extensive functional training so that they can interface with the transformed environment effectively and efficiently.

As an optional final step in the Plan stage, the team prepares the change-leadership executive, sponsors, and SMEs for the remaining stages, their respective responsibilities, and methods and tools to be used.

At the end of the Plan stage, the following items should be true:

  • The high-level approach for transition is fully defined and shared.
  • The executive change leader, key stakeholders, and SMEs are defined and recruited.
  • The leadership action and involvement plan is defined and implemented with the change-leadership executive and sponsors.
  • Change-leadership executive, sponsors, and participants are informed about the benefits of the change and aligned with the project goals.
  • Roles and responsibilities are understood by the entire team.

6.2 Understand the Nature of the Change

Understand.jpg  
In the second stage in the change life cycle, the OCM team defines areas across the impacted organization where changes occur across the impacted organization. The areas include processes, policies, procedures, required skills, roles/responsibilities, and organizational structure. Defining these areas improves impacted staff success in the future. In identifying these changes, the team also identifies where potential risks may exist. By minimizing the degree of change and associated impact to staff and ongoing business operations, the team minimizes the level of change required of the staff.

The OCM team works closely with SMEs during the Understand stage to evaluate the as-is and to-be business process models for all areas of service support to define potential impacts. These business process models are simple tools used to compare the current state (as is) with the desired future state (to be) and document the gaps that exist between those two states (described in the Enterprise Architecture chapter). For example, if in the current state a paper sales receipt is provided to a customer and in the future a receipt will be emailed, the as-is/to-be analysis documents the differences between how receipts are provided to the customer now and in the future. The gap, or change, in that process is then categorized as a potential communications or training need. Use your best SMEs and all available documentation to prepare your as-is business process models. In many instances, these models use standard process flow and swim lane diagrams (see Figure 4) outlining both processes and ownership and, where necessary, shows an iterative progression following project stages.

Swim-Lane-Example.jpg

Figure 4. Swim Lane Example

Work products generated during the Understand stage (such as the as-is/to-be analysis, process reengineering artifacts, glossary of new terms, new policies and procedures, data maps, and application configuration and design documents) provide the required to-be process information, which includes both new and modified processes. Potential risks are also defined through an analysis of the new and modified business processes by a combined effort of the organization team and the OCM team. The team needs to be rigorous in documenting all gaps. They need to be patient and make sure that their understanding is correct. Ignoring potential areas of resistance can result in confusion, miscommunication, or at worst, subversive behavior in the future. The results of the analysis are then communicated across the affected organizations.

At the end of the Understand stage, the change-leadership team has a broad understanding of several areas:

  • The specific functional areas and cross-functional processes within the organization that are impacted, often reflected in a change map showing a series of changes for the people, process and data changes
  • The source of the impact and how it occurs
  • The risk assessment of associated potential risks (such as miscommunication, resistance, and confusion)
  • A listing of to-be processes and associated gaps with the future process (that is, new and modified processes)
  • A listing of required policy changes
  • Documentation of the to-be processes to share with the organization

6.3 Assess the Impact of Change

Assess.jpg  
In the Assess stage, the team works with the organization to jointly analyze each area of potential change to understand the overall change impact. Also it analyzes each potential risk to define mitigation strategies. This assessment involves the organization both by functional areas and by geographic areas. It is very important that non-core locations participate in this assessment process to provide a successful transformation. Using a series of surveys, workshops, and small working groups to complete the analysis and capture the results is often useful. The team then classifies each change area as low, medium, or high with respect to the amount of change. Business process, policy, skill set, staff roles and responsibilities, and training requirements should all be included in this classification.

With the assistance of the organization’s SMEs, the team defines the expected degree of resistance that they could encounter. People naturally resist changes in how they to do their work (unless, of course, they initiated the change!), because it means additional work to learn the new ways. Think, for example, of how EIT developers often resist new processes for branching code and checking in changes! Similarly, enterprise users of EIT services can resist changes to user interfaces or changes to how they manually do their work. Knowing in advance where resistance is likely results in a more efficient process of transition.

The team should classify each potential risk as low, medium, or high, along with a degree of probability that the risk will occur. Then, the team should look for a mitigation strategy for each potential risk. Results from this stage need to be carefully communicated across the affected organizations and are important inputs to designing an effective transition plan.

At the end of the Assess stage, the OCM and organization teams have:

  • A broad understanding of the areas and processes that are impacted
  • A list of policies and business issues to be resolved to facilitate the desired change in the future
  • An initial list of possible pockets of resistance
  • Descriptions of potential barriers to success
  • A broad understanding and categorization of potential risks

6.4 Design/Approve Change Activities

DesignApprove.jpg  
With the changes and potential risks defined, categorized, and understood, the team updates the planning stage information to include all of the detailed activities and specific communications used to facilitate transition to the new state. Workshops, broad communications, specific outreach activities, group meetings, demo sessions, and intranet sites are all typical avenues for communicating change, and are a common part of our change-leadership process.

The OCM team may review staff training and the knowledge transfer plans created by the instructional designers and training specialists to verify that these plans contain the necessary elements to adequately prepare the staff for their new roles and responsibilities, and that any pockets of resistance are adequately addressed. This is a crucial communication point for the entire organization as it provides a roadmap for how the change will be accomplished and, more importantly, how each person should prepare to interact with the system after transition.

The various audiences and stakeholders provide significant input to the activities. Not all activities are appropriate for all audiences. Therefore, specifically target the most effective communications for each group. Some of these activities may include outreach presentations, workshops, web sessions, and training. Ultimately, the change-management efforts involve all impacted parties. To address this larger audience, engage organization managers and supervisors to deliver change messages. The change-management activities are designed, approved, and finalized during this process.

At the end of the Design/Approve stage, the organization has:

  • An updated plan outlining the specific tasks and techniques to be employed throughout the remainder of the project for enabling change
  • Verification that training and knowledge-transfer activities are in place to fully prepare staff to be efficient and effective in the new environment
  • Broad and detailed communications supporting the transition process

6.5 Transform

Transform.jpg  
The Transform stage implements the various plans and activities defined in the Design/Approve stage and carefully monitors the success of the change-leadership activities. Activities continue until the system is live, and well beyond, as the organization adjusts to the new environment, processes, and technologies, and fine tunes daily roles and responsibilities. As the team receives feedback from the affected organization, they update plans and activities, and define new activities as required to address any problem areas. In reality, the transform process begins with the planning stage activities, but the difficult work occurs when the communications and outreach activities are underway, and the organization begins to assimilate the information.

At the onset of the project, the team may send out a formal survey to business units affected by the transformation. This survey includes questions about transformation awareness, such as system knowledge, leadership visibility, and identification of issues and concerns, just to name a few.

At the end of the Transform stage, several things should exist:

  • Updated and revised change-leadership plans to address feedback on the changes
  • Results of the execution the change-leadership activities designed to support the transition
  • Staff that have been guided and supported through the transition and prepared for the transformed environment
  • Reinforcement of the changes for several weeks to monitor and address or any problem areas

At the end of the project, business units participating in this change initiative have a thorough understanding of the processes employed for the transformation. In addition, a set of tools and techniques exist that can be used to fine tune the organization post-implementation or during later stages of the maintenance agreement. Knowledge transfer is a key reason for creating the initial partnership and working together through the five-stage process.

7 Portfolio OCM Approach and Framework

Portfolio-level OCM constructs an approach to understanding, evaluating, and managing the suite of changes occurring in the organization. Because the organization often has multiple projects and initiatives occurring simultaneously, OCM involves taking stock of the changes happening across the enterprise and analyzing their collective impact.

Portfolio change-management processes typically occur in five phases.

PhaseDescription
1) IdentifyThe Identify phase sets the boundaries for portfolio analysis. This phase includes establishing the scope of the analysis, which could be the entire enterprise or an examination of the changes impacting a specific group or type of change (for instance, changes initiated by the EIT group). This phase looks for both project and non-project change.
2) InvestigateThe Investigate phase involves collecting or generating data on the changes occurring across the portfolio. The first step is collecting data on each initiative in the portfolio, including budget, schedule, and key resources. This data is assessed to gauge the change-management risk and the overall level of change in the portfolio. The results of the investigation are mapped to show which groups in the organization are impacted by each of the changes in the portfolio.
3) AnalyzeThe Analyze phase is where conclusions are drawn about the portfolio changes. This phase may include a visual representation indicating the level of change impact or change capacity on groups throughout the organization.
4) ActIn the Act phase, the team captures specific risks to projects, groups, points in time, and the organization as a whole and establishes an action plan. Typically, a report is produced and presented to the business leaders and others in the organization who need insight into the portfolio of changes. Based on the information provided, mitigation strategies are identified and acted upon.
5) Monitor, Manage, and ControlThe Monitor, Manage, and Control phase determines how an organization manages changes occurring across the portfolio on a go-forward basis. How changes enter and exit the portfolio, and what lessons the organization can learn by taking an enterprise perspective are used to fine tune the change-management process.

The goal of portfolio change management is to create a clear understanding of the portfolio of changes. With solid data about the portfolio of changes, senior leaders are prepared to prioritize and mitigate the consequences of change fatigue and change impacts. Following a structured process to portfolio change management provides leaders a new perspective on the portfolio allowing them to manage the changes more holistically.

8 Organizational Change Leadership

Organizational change leadership can be thought of as the driving forces, visions, and processes that fuel large-scale transformation. Change leadership has its own unique demands and requires a different leadership mindset to lead the organization to a new place.

In his seminal book Leading Change, former Harvard Business School Professor Dr. John P. Kotter describes the eight steps crucial for leading change in an organization. [1]

1-Create Sense Urgency.jpgCraft and use a significant opportunity as a means for exciting people to sign up to change their organization.
2-Build Guiding Coalition.jpgAssemble a group with the power and energy to lead and support a collaborative change effort.
3-Form Strategic Vision.jpgShape a vision to help steer the change effort and develop strategic initiatives to achieve that vision.
4-Enlist Volunteer Army.jpgRaise a large force of people who are ready and willing, and urgently want to drive change.
5-Enable Action.jpgRemove obstacles to change, change systems, or structures that pose threats to the achievement of the vision.
6-Generate Short Term Wins.jpgConsistently produce, track, evaluate, and celebrate volumes of small and large accomplishments, and then correlate them to results.
7-Sustain Acceleration.jpgUse increasing credibility to change systems, structures, and policies that don’t align with the vision; hire, promote, and develop employees who can implement the vision; reinvigorate the process with new projects, themes, and volunteers.
8-Institute Change.jpgArticulate the connections between the new behaviors and organizational success, and develop the means to ensure leadership development and succession.

There are specific links between leadership, project management, and change management. The connection between leadership and project management is related to decisions that are made by leaders. The connection between leadership and change management is tied to the actions of the senior leader.

Key change-leadership responsibilities include:

  • Repeatedly and regularly communicating directly with employees; explaining why the change is happening and the risks of not changing, and aligning the change with the planned future state of the organization.
  • Building a coalition of key leaders in the organization to consistently communicate the reasons for the changes across all levels.
  • Participating actively and visibly throughout the entire change process and gathering feedback from employees.

Making change a success requires leaders to play a pivotal role. One of the biggest issues is that senior leaders don’t know what good sponsorship looks like in concrete terms. The change manager with their suite of tools and related experience is in a unique position to educate and coach senior leaders to fulfill their change-leadership role.

9 Individual Change Management

Change happens at the individual level, one person at a time. Even large, complex organizational changes are only successful if the individual changes how, where, or when they do their day-to-day work. When we speak of organizational change, we are describing the end result of many individuals moving from their own current state to their own future state.

The ADKAR model was first published in 1998 after research with more than 300 companies undergoing major change projects. In 2006, Prosci [2] released the first complete text on the ADKAR model in Jeffrey Hiatt’s book ADKAR: A Model for Change in Business, Government and our Community[3] The ADKAR model is an individual change-management model. It outlines the five building blocks of successful change, whether that change is occurring at home or work.

Research shows that the most commonly cited reason for project failure is problems with the people dimension of change. Effective change management with employees is one of the top overall success factors for the project.

There are five key goals that form the basis of the ADKAR model:

  • Awareness of the need to change
  • Desire to participate and support the change
  • Knowledge of how to change (and what the change looks like)
  • Ability to implement the change on a day-to-day basis
  • Reinforcement to keep the change in place

Individuals move through these phases when confronted with a change. Say, for example, you find out (become aware ) that a highway construction project that was begun several years ago is finally complete. If you took that route to work, it would shorten the distance from home to work, but could shorten or lengthen the actual time to get to work. You decide to try it ( desire ) because it seems more direct and could save time. So you use your GPS service to find out the best way to access (knowledge ) this new possibility. Armed with that knowledge, you create the ability to change your route by plugging it into your navigation system and trying it out. You find it works well! Now, you reinforce the change by reminding yourself every morning to take the new route until it becomes second nature.

All of us go through these phases at different rates and times when asked to change. Being aware of this process helps the change manager plan for and execute activities that support employees through a transition.

ADKAR Model.gif

Figure 5. AKDAR Model

Organizational change happens one person at a time. To manage this, a model is needed that describes individual change. Understanding this model empowers change managers to enable successful organizational change. It is not enough to create fancy communications materials or develop presentations for a kick-off meeting. It is critical to understand how to support each individual through changes to provide context and purpose for your change-management activities.

10 Summary

Successful change management encompasses all activities aimed at helping the people within an organization successfully accept and adopt new technologies, accept changes to how they perform their job, and design new ways to serve their customers. Often, multiple levels of managing change must be deployed within an organization. These levels span the organizational structure from strategic OCM focused on the roles and responsibilities of senior leaders to drive change throughout the organization, to project-level change management, and down to the individual. The individual in the organization is a key element that is often overlooked, and it is at the individual level where the change becomes the most “real” or tangible. The OCM approaches described here and supported by experienced project management create a structured and integrated approach to the execution of organizational change management. The associated activities gradually prepare the leaders, individuals, and whole organization for the upcoming change and engage key stakeholders at the right level and most beneficial time.

11 Key Maturity Frameworks

Capability maturity for EIT refers to its ability to reliably perform. Maturity is a measured by an organization’s readiness and capability expressed through its people, processes, data and technologies and the consistent measurement practices that are in place. Please see Appendix F for additional information about maturity frameworks.

Many specialized frameworks have been developed since the original Capability Maturity Model (CMM) that was developed by the Software Engineering Institute in the late 1980s. This section describes how some of those apply to the activities described in this chapter.

11.1 IT-Capability Maturity Framework (IT-CMF)

The IT-CMF was developed by the Innovation Value Institute in Ireland. It helps organizations to measure, develop, and monitor their EIT capability maturity progression. It consists of 35 IT management capabilities that are organized into four macro capabilities:

  • Managing IT like a business
  • Managing the IT budget
  • Managing the IT capability
  • Managing IT for business value

Each has five different levels of maturity starting from initial to optimizing. The three most relevant critical capabilities are Relationship Management (REM), Organization Design and Planning (ODP), and Programme and Project Management (PPM).

11.1.1 Relationship Management Maturity

The following statements provide a high-level overview of the Relationship Management (REM) capability at successive levels of maturity.

Level 1 There is no formal or organized relationship management, nor are there any formal communications or information gathering structures in place.
Level 2 A basic understanding of the organization’s networks and how to leverage them begins to emerge. Defined communications and information gathering processes are emerging at a managerial level between the IT function and other business units.
Level 3 Standardized approaches to relationship management are in place across the IT function. There are robust communications and information gathering processes between the IT function and many of the other business units, and these enable increasingly timely communication of issues.
Level 4 There are dedicated relationship management teams in place within the IT function for all key business units. There are communications and information gathering processes between the IT function and all other business units, and these enable rapid communication of issues as they arise.
Level 5 There is a comprehensive and up-to-date understanding of the formal and informal networks and information flows within the organization. The IT function and the rest of the business always communicate effectively with each other.

11.1.2 Organization Design and Planning Maturity

The following statements provide a high-level overview of the Organization Design and Planning (ODP) capability at successive levels of maturity:

Level 1 The organization structure of the IT function is not well defined or is defined in an ad hoc manner. Internal structures are unclear, as are the interfaces between the IT function and other business units, suppliers, and business partners.
Level 2 A basic organization structure is defined for the IT function, focused primarily on internal roles, responsibilities, and accountabilities. A limited number of key interfaces between IT and other business units, suppliers, and business partners are designed.
Level 3 The IT function’s organization structure is harmonized across internal functions, with a primary focus on enabling the mission and values of the business. Most interfaces between IT and other business units, suppliers, and business partners are designed.
Level 4 The IT function is able to adopt a range of organization structures simultaneously, from industrialized IT to innovation centres, in support of the organization’s strategic direction. All interfaces to entities external to the IT function are designed.
Level 5 The organization structure(s) adopted by the IT function are continually reviewed, taking into account insights from industry benchmarks. All interfaces are continually reviewed and adapted in response to changes in the business environment.

11.1.3 Programme and Project Management Maturity

The following statements provide a high-level overview of the Programme and Project Management (PPM) capability at successive levels of maturity:

Level 1 Approaches for programme/project management are inconsistent, or may not exist at all. Performance of programmes and projects is unpredictable.
Level 2 Basic programme/project management approaches are emerging within the IT function. Performance is tracked within the IT function for a limited number of key programmes and projects.
Level 3 Standardized management approaches are present for most parts of a programme/project life cycle, and they are increasingly used across the IT function. Performance is tracked for most programmes and projects.
Level 4 Management approaches are comprehensive across the entire programme/ project life cycle, and are adopted organization-wide. Performance is tracked for all programmes and projects.
Level 5 Programme/project management approaches are adaptive to business and technology changes, and are regularly reviewed based on input from lessons learned internally and from relevant business ecosystem partners. Performance management is continually reviewed to minimize variances in performance.

12 Key Competence Frameworks

While many large companies have defined their own sets of skills for purposes of talent management (to recruit, retain, and further develop the highest quality staff members that they can find, afford and hire), the advancement of EIT professionalism will require common definitions of EIT skills that can be used not just across enterprises, but also across countries. We have selected 3 major sources of skill definitions. While none of them is used universally, they provide a good cross-section of options.

Creating mappings between these frameworks and our chapters is challenging, because they come from different perspectives and have different goals. There is rarely a 100% correspondence between the frameworks and our chapters, and, despite careful consideration some subjectivity was used to create the mappings. Please take that in consideration as you review them.

12.1 Skills Framework for the Information Age

The Skills Framework for the Information Age (SFIA) has defined nearly 100 skills. SFIA describes 7 levels of competency which can be applied to each skill. Not all skills, however, cover all seven levels. Some reach only partially up the seven step ladder. Others are based on mastering foundational skills, and start at the fourth or fifth level of competency. It is used in nearly 200 countries, from Britain to South Africa, South America, to the Pacific Rim, to the United States. (http://www.sfia-online.org)

SFIA skills have not yet been defined for the this chapter.


12.2 European Competency Framework

The European Union’s European e-Competence Framework (e-CF) has 40 competences and is used by a large number of companies, qualification providers and others in public and private sectors across the EU. It uses five levels of competence proficiency (e-1 to e-5). No competence is subject to all five levels.

The e-CF is published and legally owned by CEN, the European Committee for Standardization, and its National Member Bodies (www.cen.eu). Its creation and maintenance has been co-financed and politically supported by the European Commission, in particular, DG (Directorate General) Enterprise and Industry, with contributions from the EU ICT multi-stakeholder community, to support competitiveness, innovation, and job creation in European industry. The Commission works on a number of initiatives to boost ICT skills in the workforce. Version 1.0 to 3.0 were published as CEN Workshop Agreements (CWA). The e-CF 3.0 CWA 16234-1 was published as an official European Norm (EN), EN 16234-1. For complete information, please see http://www.ecompetences.eu.

</tr>

e-CF Dimension 2e-CF Dimension 3
C.2. Change Support (RUN)
Implements and guides the evolution of an ICT solution. Ensures efficient control and scheduling o software or hardware modifications to prevent multiple upgrades creating unpredictable outcomes. Minimises service disruption as a consequence of changes and adheres to defined service level agreement (SLA). Ensures consideration and compliance with information security procedures.
Level 2-3
D.9. Personnel Development (ENABLE)
Diagnoses individual and group competence, identifying skill needs and skill gaps. Reviews training and development options and selects appropriate methodology taking into account the individual, project and business requirements. Coaches and / or mentors individuals and teams to address learning needs.
Level 2-4
E.7. Business Change Management (MANAGE)
Assesses the implications of new digital solutions. Defines the requirements and quantifies the business benefits. Manages the deployment of change taking into account structural and cultural issues. Maintains business and process continuity throughout change, monitoring the impact, taking any required remedial action and refining approach.
Level 3-5

12.3 i Competency Dictionary

The Information Technology Promotion Agency (IPA) of Japan has developed the i Competency Dictionary (iCD), translated it into English, and describes it at https://www.ipa.go.jp/english/humandev/icd.html. It is an extensive skills and tasks database, used in Japan and southeast Asian countries. It establishes a taxonomy of tasks and the skills required to perform the tasks. The IPA is also responsible for the Information Technology Engineers Examination (ITEE), which has grown into one of the largest scale national examinations in Japan, with approximately 600,000 applicants each year.

The iCD consists of a Task Dictionary and a Skill Dictionary. Skills for a specific task are identified via a “Task x Skill” table. (Please see Appendix A for the task layer and skill layer structures.) EITBOK activities in each chapter require several tasks in the Task Dictionary.

There is no correspondence between this chapter and the iCD Competency Dictionary. The complete iCD Task Dictionary (Layer 1-4) and Skill Dictionary (Layer 1-4) can be obtained by returning the request form provided at http://www.ipa.go.jp/english/humandev/icd.html.


13 Key Roles

The following are key ITSM roles:

  • Change Manager
  • Risk Manager
  • IT Service Continuity Manager
  • Supplier Manager
  • Service Owner
  • Service Design Manager
  • Information Security Manager
  • Enterprise Architect
  • Technical Analyst
  • Financial Manager

Other roles include:

  • Business architecture team
  • Change agents
  • C-level officers
  • Executive sponsor
  • Governance body
  • Regulatory authority
  • Solution architecture team

14 Standards

ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology – Service management – Part 1: Service management system requirements

ISO/IEC/IEEE 12207:2016, Systems and software engineering—Software life cycle processes (in preparation)

ISO/IEC/IEEE 15288:2015, Systems and software engineering—Systems life cycle processes

15 References

[1] Kotter, John P. 1996. Leading Change.

[2] Prosci. 2014. An overview of Prosci's ADKAR Model. http://www.change-management.com/tutorial-adkar-overview-mod1.htm.

[3] Hiatt, Jeffrey M. 2006. ADKAR: a model for change in business, government and our community.