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
RolesPrimary Performer: Additional Performers:
InputsMandatory:
  • None
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
      1. Review the scope definition to ensure you understand the artifacts produced, the overall timeframe, risks and assumptions, and so forth.
      2. Create a Work Breakdown Structure (WBS)
      3. Assign resources.
      4. 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.