Chapter 7 Modifying Existing Tools to Incorporate iOCMTM Principles – Managing Organizational Change


Modifying Existing Tools to Incorporate iOCM TM Principles

Using best-practice tools and templates is an integral part of every effective project management methodology. This principle does not change when implementing an iOCMTM project. But, it does require that these tools and template be slightly modified to ensure they adequately address best-practice organizational change management principles. Additionally, some may change from a one and done to an iterative living document approach, meaning the content will need to be re-evaluated and updated throughout the project.

The following are common project management tools that can be modified to address iOCMTM requirements. Please note that I have greatly simplified these examples to more easily demonstrate the concepts involved. Those documents that change to an iterative approach are noted by the symbol .

Project Resource Spreadsheet

A traditional Project Resource Spreadsheet includes the all project resource names, titles, and assigned roles. By updating this document to include a tab that outlines each team member’s role requirements, as well as a short statement on any support that will be provided by other project team members to assist the individual in fulfilling the role requirements, OCM principles will be integrated into the document. The following is an example using the executive sponsor role:

Executive sponsorship role description and requirements

Be the corporate face of the project and assure the organization that the change initiative supports corporate objectives and organizational values.

To support these activities, the project manager will ensure the project vision statement supports existing corporate vision statements, goals, and identified individual business unit goals.

Ensure the project remains aligned with the approved change strategy and objectives.

To support these activities, the project manager will ensure organizational change management best-practice tasks and activities are included in the project plan; that project tasks include outcome objectives; and that the governance success metrics are outcome-oriented, rather than task ­completion-oriented.

Participate as a member of the governance board.

To support these activities, the project manager will ­provide clear governance guidelines, based on ­iOCMTM principles, for each project gate review.

Ensure buy-in throughout ­personal down-line ­management.

To support these activities, the project team leads will be provided ongoing, audience-specific collateral (slide presentations, e-mail status updates; FAQs; and so on) to be used in staff meetings, manager meetings, and one-on-one sessions.

Build support and cooperation among business sponsors.

To support these activities, the project manager
and team leads will ensure potential technical and business risks are identified; and effective risk ­mitigation and resistance management plans are designed, executed, and updated throughout the project.

Including an ADKAR evaluation section in the Resource Spreadsheet allows the project manager to track each team member’s ADKAR status as they are brought onto the project and then reassessed periodically throughout the project so that any area that is not green can be addressed. Please note that adding this level of subjective information is only appropriate if this a restricted working document, available only to the project manager and change lead. If the Resource Spreadsheet is not restricted, then the ADKAR evaluation can be maintained as a separate document similar to the following sample.

Project Vision Statement

An effective project vision statement supports the existing organizational vision. As explained previously, this is not an explanation of how success will be achieved, nor is it a list of business benefits that will be gained. It is a statement that paints a picture of the organization after the project has been successfully completed. While there is no change to the traditional structure of the project vision statement template itself, it may be helpful to see examples of what is, and what is not, a project vision statement.

This is not a project vision statement

This is a project vision statement

This project delivers a new software solution that reduces production time by 11 percent, production costs by 5 percent, and production errors by 17 percent.

We will provide our clients higher-quality products, more quickly, without increasing their costs.

The processes and call trees currently used in our customer service call center will be updated to reduce the time needed to determine the best solution path for each incoming call and to ensure issues are handled by the most knowledgeable resources. As a result, issues will be closed more quickly, and customer satisfaction will improve.

Our call center members will have everything they need to provide our clients with superior customer service support.

This product lifecycle management (PLM) solution will use embedded workflows for design, engineering, and manufacturing and will work on desktop and laptop computers, tablets, and other handheld devices.

Everyone involved with designing, ­developing, manufacturing, and maintaining our products will have access to the information they need, when they need it, regardless of where they are or the device they use.

Project Requirements Spreadsheet

Many program management offices, consulting service providers, and experienced project managers maintain a variety of requirements spreadsheet templates that are prepopulated with fundamental questions for a specific type of change initiative (ERP, PLM, system integration, database migration, and so on).

In these cases, the project manager will start with the appropriate template (with prepopulated baseline requirement options), then hold a number of workshops with business process and technical SMEs to identify the full list of prioritized change requirements. The purpose of these workshops is to ask probative questions about each high-level requirement that is identified, in order to define an accurate and in-depth list of technical requirements. For example, if deploying a PLM solution was a high-level requirement, the group would be asked questions like “are you looking to implement an ‘off-the-shelf’ solution or will the solution need to be customized?” “If the software will need to be ­customized, will the work be done internally or by an outside software services ­provider?” And, “If it is customized, who will be responsible for updating the ­customizations to ensure compatibility with each new software release?” “Will the ­software be standardized across all user groups or will business units or functional groups require their own, specific instances?” “If data migration is required, who will clean the data, prepare the data, and migrate the data?” “Will the software be provided to all users across the organization at the same time, or will it be phased in, based on ­location, business unit or functional group?” To align the requirements document and requirements gathering process with iOCMTM principles, it will be necessary to include questions and considerations that apply to people, as well as technology.

The following is a very elementary example of specific questions that could be used during requirements workshops to populate the requirements spreadsheet, using a security requirement as an example (please note that while the following example provides only one who, what, when, where, why, and how question with two associated if/then, there are often multiple questions in each category, followed by multiple if/then choices).

Requirement: Multiple levels of control access or privileges

Priority Level: Must Have

Who: will be responsible for assigning security access?

If this requires a systems admin, then . . . .

If this requires a user with a specific system role, then . . . .

What: data or processes or outputs require controlled access

If this includes customer data, then . . . .

If this is business unit specific, then . . . .

When: will this change be rolled out to the business units?

If rolled out to all business units simultaneously, then . . . .

If rolled out consecutively, then . . . .

Where: will individuals go to request changes to control access or privileges?

If the individual can apply online, then
. . . .

If this must be requested by a director or above, then . . . .

Why: does business unit A require a ­different control access model than business unit B?

If multiple access models are required, then . . . .

If a single, shared access model is chosen, then . . . .

How: will customizations to the software access model be maintained when the new software updates are installed?

If the in-house IT group will be responsible, then. . . .

If a software service provider will be ­contracted, then. . . .

In addition to the more detailed questions associated with the requirements gathering process discussed earlier, an iOCMTM requirements spreadsheet should include a column for a simple priority rating (i.e., must have, should have, would like to have), and each requirement should be associated with a stated business objective. This information will be critical when circumstances require the project team to work with the business team to prioritize, eliminate, change, or delay the delivery of certain requirements.

Req. ID

**** (high-level solution requirement)



Must have

Sub-level Req. ID

Sub-level requirement

Technical owner

Business owner


Bus Req. ID

Sub-req. priority



Must Have



Should Have



Nice to Have

Business Case Document

A set of business requirements will be used to create the business case document. Business requirements focus on the needs, concerns, and issues of a specific business unit, functional group, or end-user community, not the high-level organizational goals. Things like access to more accurate data, less cumbersome processes, more reliable tools, and a platform that is compatible with client or supplier networks, all fall into the category of business expectations. When creating a list of business requirements, it is important not to add assumptions regarding how they will be achieved: this will be addressed in the formal requirements document.

The following are examples of eight high-level business requirements, followed by possible statements that provide details needed to understand (and agree on) the metric that will be used by the business to determine success.

Increase Profitability

  • Maximize return on existing investments
  • Improve profitability of product line
  • Provide maximum shareholder value
  • Shorten sales cycles to increase revenue
  • Increase the return on operating assets

Cost Control

  • Projects to be completed on time and within budget
  • Spread the costs over departments or projects
  • Reduced prototyping costs
  • Reduced waste
  • Decrease bottom-line expenses
  • Cost monitoring
  • Decrease costs of doing business
  • Identify areas for cost savings
  • Avoid trial-and-error costs
  • Minimize admin costs
  • Reduce in overhead costs
  • Lower working capital requirements

Better Data for Improved Decision-Making

  • Give managers quality data needed to better ­manage their department or ­operation
  • Access detailed, integrated, accurate data from the system to create a variety of standard and ad-hoc reports
  • Rapidly respond to changing business conditions
  • Focus on solving the real problems, not wasting time
  • Providing key information to line managers at an accelerated pace
  • Alignment with business objectives
  • Track and analyze key information for decisions
  • Manage risk
  • Accurate, up-to-date snapshot of performance
  • Better decisions on budget management; improve decision-making (getting it right the first time)
  • Transform data into ­meaningful information
  • Deliver information deeper, faster, and more accurately
  • Ensure accuracy of ­information
  • More accurate forecasting
  • Drive smarter decisions that identify noncore ­business processes
  • Support business strategy

Customer Satisfaction, Retention, Attraction

  • Improve customer satisfaction
  • Better match available products with customers’ needs
  • Maintain a reputation for high standards of business conduct
  • Strengthen customer loyalty
  • Respond quickly and more accurately to customer needs and demand

Competitive Edge

  • Keep up with changes in the marketplace
  • Retain and grow market share
  • Beat the competition to market
  • Competitive edge over the competition
  • Adapt to the global ­marketplace
  • Reduced time to market

Improved Process

  • Ensure projects are billed accurately
  • Dramatically improve collaboration
  • Achieve higher efficiencies
  • Link between the project activities and company financials
  • Avoid resource under use or misallocation
  • Continually monitor ­business performance
  • Timeliness of billing
  • Metrics are consolidated from global sources into a single, unified view
  • Track and manage data in realtime
  • Business process transparency, greatly improving visibility and efficiency
  • Secure intranet portal
  • Ability to meet regulatory requirements

Employee Retention

  • Provide development plans to increase employee skills effective training program
  • Attracting and keeping talented employees

Save Time

  • Identify the right resource the first time
  • Streamline business processes
  • Save an average of XX minutes daily per employee
  • Reduced defects or rework
  • Speeds the overall process
  • Avoid delay and disruption
  • Enhancing productivity by reducing complexity
  • Higher efficiencies
  • Ensure that projects are completed on time

The formal business case will set out the As Is state and define the desired To Be state, based on the identified list of business requirements. On an iOCMTM project, the business case document will need to include:

  • A unique ID for each business requirement
  • A prioritization of each business requirement (must have, should have, or nice to have)
  • A link between the agreed business benefits and the organization’s stated strategy, goals, or vision
  • A clear definition of the metrics that will be used to measure project success in achieving the stated business case
  • High-level cost or benefit analysis with options to meet business objectives (including tradeoffs if necessary)
  • Proposed resource sourcing options (existing IT and business employees or new hires, contractors, business management firms) needed to deliver the stated objective
  • Milestone dates for delivering stated business objectives, with dependencies or risks

As noted previously, each business requirement will be cross-­referenced in the requirements spreadsheet by its unique ID, and be associated with a specific solution requirement.

Stakeholder Analysis Spreadsheet

The stakeholder analysis process begins by identifying a project’s stakeholders. Depending on the size of the stakeholder group, this may be done at the individual stakeholder level; by stakeholder role or group; or a combination of these (i.e., named stakeholders down to the manager level, then stakeholder group based on role or function).

Once the project stakeholders (or stakeholder group representatives) have been identified, a specific set of data will need to be identified for each group. This data will be used to select the appropriate recipients for project communication; attendees for workshops, solution demonstrations, and various project update meetings; develop participation requirements for audience-specific training, and so on. It will also help to identify potential high-risk stakeholder groups. Initially, the project manager will populate the spreadsheet with information on the project sponsors, a select group of business managers, and perhaps a list of the roles or functions that will be impacted. Business leaders and SMEs will provide additional stakeholder information throughout the project. This revision or updating process will begin in the requirements gathering workshops and continued in subsequent workshops, planning sessions, and project meetings throughout the project.

Typical Primary Stakeholders

  • Executive ­leadership
  • Program ­management
  • Business ­managers
  • Business leadership
  • Business SMEs
  • Governance board
  • Functional leads or SME
  • Super users
  • End users

An iOCMTM stakeholder analysis spreadsheet includes more than just those stakeholders who are impacted as a result of the project itself (primary stakeholders). It also includes secondary stakeholders. Secondary stakeholders are those individuals who, while not impacted by the change project or the change solution first hand, are impacted in other ways.

Typical Secondary Stakeholders (and Possible Impacts)

  • Finance (changes to customer data reports; budget re-allocations or over-runs; and so on)
  • Union or trade group (compliance with existing agreements; changes to job descriptions or requirements; and so on)
  • Regulatory or Legal (data security or access rights; contract compliance; SEC and other requirements; and so on)
  • Corporate security (access rights; cloud software; VPN rules; and so on)
  • Auditors (document retention; workflow process documentation; and so on)
  • Quality control (proof of compliance; automated workflow documentation; supplier selection criteria; and so on)
  • HR (changes to existing role requirements; new roles; role elimination; and so on)
  • Marketing (updated product information; customer impacts; changes to offerings; and so on)
  • Client companies (changes to products; online ordering or customer support processes; software compatibility; and so on)

In addition to stakeholder groups and names, the iOCMTM stakeholder analysis spreadsheet should include the following information:

Location or site


Report to


Report to

System role

(Location may impact deployment dates; local regulations; hardware requirements; and so on)

(Area of expertise, not level of expertise)

(Based on formal organizational chart reporting structure)

(Project-specific reporting structure)

(That is, designer; approver; ­editor; manager; and so on)

There are many criteria used to analyze a project’s stakeholders. Because of this, the project manager may choose to include data in the stakeholder analysis spreadsheet that is subjective or sensitive in nature. If this is the case, this document should not be classified as a public ­document, but rather, it should be classified as a project management document and shared on an as needed basis only.

Formal Governance Process Documentation

A project’s governance model defines how successful completion of ­project tasks and project phases will be determined. All governance ­models require periodic project status reviews to ensure project deliverables are on track, and to review any proposed changes to project requirements or budget before the project is approved to move forward. A common cadence for governance review is at the end of each project phase: this is known as a phase gate review process because this model requires the project to through (and pass) a formal approval process before entering into the next phase. During a governance review, a predetermined set of questions will be asked by the governance committee to evaluate a project’s progress and determine its preparedness to move forward. These questions must be shared with the project leadership prior to project initiation so that the project plan is designed to ensure the tasks, activities, and milestones are in alignment with the governance success metrics that will be used.

An iOCMTM governance model is based on an outcome-oriented success metric, rather than the traditional task completion model. The following are examples of iOCMTM-specific requirements that could be used in a phase gate governance model ( indicates an iterative requirement that will be required in following project gates reviews). This list is not exhaustive, but is provided as an example of how to move the governance process from a simple task completion metric to an outcome-oriented success metric.

Plan or Design Governance Questions

  • Is the project plan complete and does it include outcome goals for each task?
  • Have all project phase tasks been completed and what is the proof that they met their stated outcome goals?
  • Has the functional conceptual design been completed and reviewed by business SMEs?
  • Has the technical conceptual design been completed and reviewed by business SMEs?
  • Have the system test scenarios been created and reviewed by business SMEs?
  • Have the detailed business processes that will impact end users been identified and confirmed by business process SMEs and communicated to business sponsors and primary stakeholder groups?
  • Have final business impact analysis results been captured and reviewed with and agreed by business SMEs and have outcomes been incorporated into training and communications plans?
  • Have business readiness scorecards results been captured and have business SMEs reviewed and signed-off on phase-end ­business readiness scorecards results
  • Is the risk and issue management plan up to date and does it include both technical and business and organizational risks
  • Are regular status update meetings being held and do they include both executive and business leaders
  • Are there regular meetings between functional and technical teams and do they include business SMEs
  • Has communication planning started and does it include executive leadership, business leadership, mid-level managers, business SMEs, primary stakeholders, and secondary stakeholders?
  • Has the stakeholder engagement roadmap been completed and shared with executive and business leadership?
  • Have regular status reporting meetings being held with audience-­focused materials for executives, business leaders, and business SMEs

Develop or Test Governance Questions

  • Have the reports been completed and reviewed or approved by business SMEs?
  • Have the roles been completed and reviewed or approved by business SMEs?
  • Have the forms been completed and reviewed or approved by business SMEs?
  • Have the workflows been completed and reviewed or approved by business process SMEs?
  • Have all unit tests been completed with the support of business SMEs?
  • Has communication planning started regarding training deployment rollout and have ADKAR assessments been completed for each planned training group?
  • Has the stakeholder analysis been updated and have identified risks been added to the risk mitigation plan
  • Has the impact analysis been updated and have risks associated with new impacts been added to the risk mitigation plan, and have these additional impacts and risks been communicated to the executive and business sponsors
  • Has the business readiness scorecard been updated by the receiving organization updated and has a plan been developed to improve business readiness
  • Has the go-live support plan been complete and does it include “at-elbow” support by local SMEs?
  • Have unit tests been completed with considerations of usability or functionality discussed with business SMEs?
  • Have UAT test plans designed as role-based, end-to-end processes that will be facilitated by business process SMEs; performed by actual end users; and including a formal feedback process for all identified issues, errors, concerns,or questions?
  • Has training material been developed as role-based, end-to-end style, and has it been reviewed by all business SMEs?

Deploy or Close Governance Questions

  • Has the data conversion migration been completed and have the results been reviewed by business SMEs?
  • Has the deployment plan been completed and approved by the business sponsor and impacted ­business managers?
  • Has the team met with the business resources providing long-term support and the business SMEs who will be providing at-elbow support to their local teams during go-live
  • Has the team handed over deliverables to the long-term support team and provided them contact information for the functional SMEs familiar with both the technical and business aspects of the change solution within each business group?
  • Have the users’ access been set up, trained, and metrics gathered and shared with business managers to confirm that all end users have been given the necessary access rights?
  • Have all readiness criteria been evaluated by the stakeholders, project team, IT, and receiving organization and is there a plan to address all identified issues?
  • Has the stability scorecard been baselined with the receiving organization and is there a plan to perform periodic reassessments over the next six months, as well as a plan to address all currently identified issues?
  • Has a go or no go decision been made and approved and details shared with the executive committee and the business leaders?
  • Has production support readiness been completed and shared with the business leaders to ensure possible negative business impacts have been identified and addressed?
  • Has knowledge handover been conducted from the ­project team to the production support team and the business ­functional SMEs?
  • Have the lessons learned been scheduled with the teams ­(project, production support, receiving organization, and so on), and has a plan been put in place to integrated these findings into future projects to gain value from these findings?
  • Have the project deliverables been archived and transferred to the appropriate teams after being reviewed with the PMO to identify any customizations to the documents that would be appropriate to add to existing template?

Communication Plan

A traditional communication plan sets out the high-level strategy for communicating project information to the organization, as well as detailed information on the specific key messages, venues, timelines, and communication owners for each primary stakeholder group.

An iOCMTM-based communication plan will also include planned communication to secondary stakeholders, as well as communication tasks owned by informal project change agents (rather than the OCM lead). And, just like outcome-oriented project tasks, all communications must include an intended outcome statement. The following are samples associated with sections that can be included:

Stakeholder Communications Overview



Key communication methods

Steering committee

High-level issues and resolutions; milestones

Slide presentations; update reports; e-mail notifications; list of updated job descriptions and SOPs

Executive sponsor

Any changes to scope or timeline; resource needs; possible project and personnel issues

White board meetings; change log; project schedule; communication plan; updated job descriptions and SOPs

Project manager


Daily project status; feedback from all executive groups; risk mitigation action plans, open issues; task assign - ments; changes to project and assignments; project timeline; training

All plans associated with project; core team white board sessions; timesheets; memos; hands-on testing; online training; group activities; app-shares; one- one-one updates



Training responsibilities; project timelines and over - views; as is and to be process flows; role definitions; what is expected of them; project vision; training; mentoring; support

Use-case testing; screen mock-ups; swimlanes; updated job descriptions and Operating Procedures (OPs) and Business Procedures (BPs); presentations, posters; lunch and learns; executive sponsor meetings; hands-on training and documentation; stop, start, or continue guides

Key stakeholder

High-level issues and resolutions; milestones: emphasizing their associated What’s In It For Me (WIIFM)

Slide presentations; update reports; e-mail notifications, executive sponsor one-on-ones

Primary stakeholder

Weekly or monthly project status; timeline; hot-spot plan of action regarding open issues

Slide presentations; update reports; executive sponsor one-on-ones; updated job descriptions and SOPs

Secondary stakeholder

Project overview; what is needed from them; how the project will affect them; project vision; project timeline

Slide presentations; update reports; executivesponsor one-on-ones; lunch and learns; updated job descriptions and SOPs

Communication Vehicles Overview





Macro level

Intra group


Project website

Intranet portal


  • Deliver both general PLM program updates and specific targeted messages to impacted business groups


Project newsletter

Internal newsletter


  • Deliver messages about PLM Program milestones, success, members of teams, and so on to all associates


Team or group-specific e-mail


  • Deliver specific targeted messages to a specific team or group


Business lead meetings

Internal meeting or webcasts

  • Delivers high-level PLM program updates to inform, prepare, gain buy-in, and monitor feedback regarding executive sponsorship and commitment to business units


Site all-hands meetings

Meeting and webcast


  • Provide PLM program and Release E project updates
  • Demonstrate executive commitment to sites


Department or business unit meetings

Meeting and webcast

  • Provide PLM program and Release E project updates
  • Demonstrate executive and business unit or site management commitment to end users


Road show


  • Introduce PLM program vision and business benefit
  • Provide clear expectations of specific business unit or stakeholder groups
  • Provide PLM program and Release E project status updates
  • Demonstrate executive and business unit management commitment to the PLM program in general and Release E in specific


Lunch and learn


  • 15–30 minute how to, tips and tricks, or updates provided by subject matter experts (SMEs) or key users to end users


Change introduction video


  • Deliver OCM benefits message as a way to set the stage for future OCM communication. Can be used at global meetings, as well as with specific associates or subgroups


= primary target

X = secondary target

Communication Calendar

Communication’s Plan Story Board


The story for the month

Strategy to communicate (share) the story

Objective of each communication




Impact Analysis

Impacts related to change initiatives are seldom felt equally across all stakeholder groups. This can happen for a number of reasons. In some cases, the advantages achieved for one group of stakeholders may place added burden on a different group of stakeholders. Or, there may be incentives in place (formal or informal) that would motivate one stakeholder group not to make the required changes. The importance of identifying stakeholder impacts associated with a proposed change is not a new concept.

A common (and ineffective) stakeholder analysis exercise is to rely on a review of aggregate of data on how this or similar change solutions have impacted stakeholder groups implementing a similar change within a similar industry.

Another stakeholder analysis process that organizations use does require an actual analysis of internal stakeholders, but because it relies on input from a limited number of participants (often those business resources seen as most likely to support the change), it does virtually nothing to identify unintended change impacts.

To provide maximum value, an iOCMTM impact analysis requires a much deeper and broader process. This would include a number of one-on-one interviews and small group meetings, as well as a formal feedback process to document (and respond to) additional input, questions, suggestions, and questions gathered during this process.

Yes, this analysis process does take longer than either of the other approaches. But, by investing time and resources in this more robust stakeholder analysis process, the development team, deployment team, and business team will all have a much clearer understanding of the organizational issues that must be addressed to address resistance, build support, reduce unnecessary project delays, and maximize actual ROI.

Saving time upfront by skipping this task sets the stage for a stakeholder community that actively and aggressively opposes the change implementation. The following are examples of headers in an iOCMTM impact analysis spreadsheet:

  • Stakeholder name or Group name
  • Contact info
  • Location
  • Impact (H, M, L)
  • Current level of support (H, M, L)
  • Required level of support (H, M, L)
  • Potential risks or rewards
  • Notes