Task: Develop Business Process Change Management Plan |
|
 |
This task focuses on developing the business process change management plan. |
Disciplines: Project Management |
|
Purpose
-
To create an effective and documented plan to increase the likelihood of successful implementation of user business
process change including:
-
Who must change
-
What change is required
-
What will motivate people to change
-
To provide a structured approach to managing the human elements critical to achieving strategic business objectives
ensuring that business process change management is recognized at all organizational levels as a process that
touches many of the socio-technical tasks at work in the organization and not just an isolated task
|
Relationships
Roles | Primary Performer:
| Additional Performers:
|
Inputs | Mandatory:
| Optional:
|
Outputs |
|
Steps
Define Scope
The first step in developing the Business Process Change Management Plan is to define the scope of the business
process change effort. The scope is to clearly describe and gain agreement on the logical boundaries of the business
process change effort. The scope statement will be used to define what is within the boundaries of the business process
change effort and what is outside those boundaries based on the organizations and departments that are impacted and the
major business functions being eliminated, re-engineered, or added.
The following artifacts can be helpful in defining scope:
It is a good practice to include as part of your scope definition those organizations that are in scope and those
related organizations that are out of scope. The readers can then determine more easily if they are impacted or
expected to assist in the project. Also, it might make sense to identify the organizations that are in scope so that
you can have people from those organizations represented on the project team, perhaps on a steering committee.
Additionally, include as part of your scope definition:
-
Constraints
-
Identify constraints based on business functions, such as:
-
Political constraints
-
Geographical constraints
-
Customer service requirements
-
Budgetary considerations
-
Identify the constraints and critical success factors that must be present to maximize the success of
business process change effort such as:
-
Project team resources
-
Proposed development environment
-
Expected delivery dates
-
End-user availability
-
Proposed system delivery budget
-
Risks - Risk refers to future conditions or circumstances that exist outside of the control of the
project team that will have an adverse impact on the project if they occur. In other words, whereas an issue is a
current problem that must be dealt with, a risk is a potential future problem that has not yet occurred. See Guideline: Risk List).
-
Assumptions - Assumptions are external events that must occur for the project to be successful. If
it looks more than likely that these events will occur, they should be listed as assumptions. Assumptions can be
identified through your own experience of knowing what tasks or events are likely to occur in your organization;
brainstorming sessions with the clients, stakeholders and team member; and by looking at items that were identified
as low risk in the risk management process.
|
Build Schedule
-
Review the scope definition to ensure you understand the artifacts produced, the overall timeframe, risks and
assumptions, and so forth.
-
Create a Work Breakdown Structure (WBS)
-
Assign resources.
-
Adjust schedule and add milestones.
|
Perform Review
The initial Business Process Change Management Plan review is held near the end of the inception phase, when the
initial project plan is developed and includes a high-level phase plan that the project team has a high
degree of confidence in.
Subsequent Business Process Change Management Plan reviews are held at scheduled points where project plans are
expected to be revised for example, at the end of each iteration. They are also held at "unscheduled" points triggered
by the need to make changes to the plan as a result of problems in the project.
|
|
Key Considerations
In a world of rapidly changing products and punishing competition, mastering the management of business process
changes can be a key competency that distinguishes winners from losers. (Approximately 70% of business process
reengineering efforts, or redesigns, fail [KOC99].) The adoption of a powerful concept, process, method, and/or tool often
holds the promise of dramatic benefits to an organization. Efforts to realize these benefits, however, often result
in frustration and anger from precisely those people who should benefit from the adoption. Business process change
management is, therefore, not an isolated task but a process that touches many of the socio-technical tasks at work
in an organization. A structured approach to managing the human elements is critical to achieving strategic
business objectives.
The quality and appropriateness of a new technical solution has been shown to be a poor predictor of the success of
a fielding in terms of the actual utilization of the new useful capabilities. A one-size-fits-all approach to
fielding and utilization of a solution seldom works. Successful fielding and utilization requires an appreciation
of the unique characteristics of each organization into which the technical solution will be fielded, and tasks to
support utilization will be tailored to fit those characteristics.
Gaining predictable value from a new technology solution might require a number of people in the organization to do
their jobs differently. End-user business processes may change specifically to meet business objectives or they may
change to accommodate the business processes inherent in components under consideration within a technical
solution. An integral part of building and fielding a new technology solution requires anyone affected by the
solution to participate in defining and evaluating the solution so that they understand and support the tradeoffs
between business process changes required in various aspects of their jobs and an evolving understanding of the
capabilities of the components available "off-the-shelf", the design of the architecture that links the components,
and the costs, schedule and risk of implementing the solution. This support must survive any turnovers and changes
in priorities, leadership, management, and reorganizations that occur in the organization from the time the change
is discovered to when it is fully implemented across the organization.
|
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|