“To-Be” Validation

Description

• A “reality check” or validation of the proposed processes, technology architecture and organization model (and their expected benefits) with employee representatives, customers, etc.  This validation confirms expected performance improvements from the new process design one or more of the following means:
• Independent evaluations
• Process “walkthroughs”
• Simulation / prototyping models
• Challenge Sessions with client personnel.

Business Value

• This deliverable provides an in-depth scrutiny of the new processes and validates whether or not the promised performance improvements are realistic.  Opening up the proposed business solution to a broader audience of affected managers and employees—before the Business Case is finalised—enables the client organisation to assess the “workability” or feasibility of the proposed changes.  The results of testing the design enables the team to explore potential design modifications
• In addition, it provides affected employees with a legitimate opportunity to provide input into the shaping of the future organisation.  Since most contentious issues (i.e. concerns that later will lead to “resistance to change”) surface during the “To-Be” Validation, this deliverable serves as one of the most important tools for fostering the “buy-in” of employees and managers.  (Often, employees are willing to accept management’s final decision regarding changes, provided that staff feel they have had an opportunity to “let their voices be heard” by management.)
• If the “To-Be” Validation is neglected, the redesigned processes may, in reality, fall short of the defined Stretch Targets.  Furthermore, constraints to implementation, employee concerns and pockets of resistance to change may be uncovered until “damage control” becomes necessary midway through implementation.

Approach

“To-Be” Validation can take many forms, ranging from sophisticated computer simulations to simpler communications techniques such as role-playing or “town-hall” (all-staff) meetings.  Depending on the complexity of the project, the degree of automation and the client’s preferences for detail, any or all of these methods may be appropriate.  For example, if a “process walk-through” visualisation is not sufficient to prove the performance, Implement Pilots may be necessary.

1. Select method(s) of process validation (e.g. Challenge Sessions).
2. Conduct validation activities
1. Visualise and/or simulate the new design
2. Identify buy-in, issues and other comments as they pertain to the new design.
3. Analyse validation results and present them to senior management.
4. Make applicable changes to new processes based on results of validation activities.
5. Utilise the confirmed visualisation as the basis for further communications throughout the organisation.

Guidelines

Problems/Solutions

• If performance relative to Stretch Targets cannot be predicted with any more accuracy than a “best guess”, document and communicate all assumptions clearly.
• Most proposed process designs that represent a dramatic change from the past are initially met with employee skepticism and/or resistance.  The design team should present its solution as the best solution that a cross-functional team could come up with within the short timeframe of a few design workshops, and should encourage skeptics to come up with even better solutions that meet the Stretch Targets.
• Often, those individuals who complain most vehemently about the weaknesses of the proposed solutions are, in fact, signaling that they have not “bought into” the Case for Change.  To them, no solution other than the status quo is acceptable.  Referring back to the Sponsorship Role Map, identify one or more managers in the organisation whose opinions the skeptical individual respects.  Solicit the help of these opinion leaders to meet one-on-one with the dissenting individual, so as to “arouse” them to the inevitability of the impending dramatic changes.
• Simulation and prototype models may be too complex for many clients to understand at first glance, and may therefore be rejected outright.  Ensure that decision-makers can easily understand and validate the structure (and underlying assumptions) of the simulation so that they can readily ac­cept its results.  Begin simulation models as very simple represen­tations, that are validated / improved upon gradually.

Tactics/Helpful Hints

• Due to the potential high cost of testing the new process (especially simulating and prototyping) many clients request the Business Case be done first.  On the other hand, very often it is difficult to complete the Business Case without testing the new process.  Use an iterative approach as a possible solution.  Create a preliminary Business Case to obtain funding for a simulation or prototype, then use results of these tests to complete the final Business Case.
• In some cases, the design team may not see the need to go beyond detailed flowcharts and “bullet-point” presentations to explain the proposed new design.  While these approaches may suffice for people who have been involved in the project, they may not have the same impact on individuals who are seeing the process and the project for the first time.  Use a degree of “showmanship” to help wider audiences understand what the new process will look like, particularly if it the organization’s first process redesign project.
• Simulation models are often be used when the prime requirement is to understand and portray the process.  However, if data about the process can be collected and analysed using simpler tech­niques, do not insist upon the use of a simulation model.   Instead, ensure that the visual presentation is sufficient to communicate clearly what the process will look like in the future.

Resources/Timing

Depending on size, complexity and level of detail, this activity may require one week to one month.  The time needed for the deliverable will vary greatly depending on whether or not a prototype or pilot project using the new process is required.