We’ve all heard the horror stories - those implementations that have become legends in their own right: 25 minute call center wait times, bills that didn’t go out for 9 months, full-page ads apologizing for service delays, overwhelmed staff yearning for the old system. Hopefully, such events are only remembered internally, but often they are recalled by the media or the regulators.
What makes the difference between those implementations that are viewed as seamless and smooth from a customer standpoint and those that make headlines? While some differences can certainly be the strength of the technology and the depth of the testing, the quality of the management of the transition is a core component.
As noted in a study by Market & Opinion Research International (MORI), over 80% of the time projects fail it is due to some type of human factor including communication/ perception issues, people (i.e. job definition) issues, or project/ program management1. Technical integration and other factors accounted for failure only 19% of the time. As you begin your CIS (or other) project, have you included enough focus on these factors?
Do You Know Where You’re Starting From?
As proven recently in a CIS implementation project kickoff, longer-term employees vividly recall what it was like the last time the CIS was changed out. Particularly when there is "baggage" from prior CIS (or even non-CIS) implementations, team members need to understand how this time it will be different. Projects rarely begin with a true "clean slate." For example, a recent ERP implementation at your company may have soured the employee base against large-scale system implementations. Or, recent organization changes may have sapped the energy of the workforce to respond to the next big challenge. Often there is simply too much "noise" to muster the singular focus required to achieve a successful CIS implementation. Ultimately, organization leadership must instill a sense of urgency that the project is not only good, but that not succeeding would constitute a true crisis.
While not frequently included in a vendor’s implementation plan, taking time to assess the change history and the target audiences’ skills and motivation can make or break your project’s
ability to chart a successful course. This article examines many of the key factors for successfully managing the various impacted workforces (IT and business) during a utility CIS implementation.
Are there hidden expectations?
Changing out a CIS is rarely a simple "replacement" initiative. The investment is too large and the project touches too many stakeholders to not get saddled with other stated, subtle or tangential expectations. These can include ideas to "empower the workforce," "raise the bar of accountability," "make the X department self-sufficient," or "rid us of the mainframe." Such expectations will color the views of senior executives who not only review the budget status of the project, but ultimately determine whether the CIS project is considered successful.
What are the risks?
One of the best ways to guard against a negative outcome is to define specifically the which could occur. For a CIS implementation, the outcomes tend to focus on delivery of service and collection of revenue. Impediments to either of these factors can prove damaging to the organization. These risks can not be wholly mitigated through the right software choice, leading edge technical architecture, thorough testing, or seamless data conversion. The following scenarios have been seen at CIS implementations around the world, regardless of software chosen and length of implementation project. These can be directly linked to human factors.
Revenue Slowdown
Utilities with poor CIS implementations have experienced temporary slowdowns (or, actually, stalls) in their revenue streams due to delayed billings. Root causes of delayed billing can be data, technology, or staffing related. Even with clean data and smooth operations, the surge of exceptions to be addressed can overwhelm a staff more accustomed to "steady state." The issues commonly encountered in a recently converted system can be unique and short-lived. At stake may be both skills and issues.
Employees who end up being good at solving billing or metering exceptions typically possess a deep understanding of both the realities of the current data and the processing of the new system. They have developed the necessary "wisdom" of seeing the causes and effects of system activities. Classroom training usually only prepares these employees to practice. Without experience in all of the realities of nightly batch runs (e.g. in a production readiness, parallel, or simulation environment), employees can be limited to the scripting of predictable and "perfect" scenarios. Issues in data that stem back months or even years can prove problematic when stricter data integrity rules are applied in a new system. Some of the issues that these employees will deal with will be short term and directly linked to the implementation while other issues will become the "new normal" and require time and practice to establish new norms and practices.
At the heart of performance is, however, both skills and motivation. Slippage in motivation can occur either before or after an implementation. Typically, the project team declares victory when conversion is completed. The reality, however, has just hit for both the call center and the back office. Jobs that had a known degree of decision-making and intensity may have changed without real notice or preparation. Staffing levels that were comfortable in the old system may not be appropriate for the initial transition or even possibly for steady state. The project team may have expected and prepared for certain issues but may not have fully prepared the user community for any "bad news."
With redefined business processes, work and judgment calls that were previously made in one department (i.e. Customer Accounting or Quality Assurance) might transition to another department (i.e. Meter Reading). Without job and organization analysis, utilities may find themselves short-handed in some areas that really matter and are surprised when the critical processes that ensure the revenue stream collection are stalled.
Slippage in existing service levels
Either by regulation or by choice, utilities frequently have published service levels such as speed to answer, time to complete vital services, etc. Your CIS project needs to ensure that there is a clear baseline analysis of the current factors of such service levels. Capturing relevant months of data such as call volumes and patterns, service order volumes, meter reading/ billing exceptions, and billing accuracy percentages, and average call handle time is a good start. Several factors will influence these numbers after implementation: user proficiency, process changes, system response time, etc. Are executives in your company prepared for any of your service levels to slip even temporarily? What is the definition of a successful implementation? 60% adherence to service levels? 99%?
As you review your project budget, you see a line item or two for training and perhaps for process/ procedure documentation. You may even see some plans for user practice. All of these activities can support the building of user skills, but do nothing for building and supporting user motivation. Group leaders must be engaged to both "set the bar" for the users’ performance, listen to issues, and communicate expectations. If fully engaged, they will ask project management for data and predictions that help them answer questions like:
- Exactly how proficient will my staff be?
- Have process changes made certain transactions longer or shorter? By how much?
- What kinds of exceptions will be generated? At what volume?
- What are the mission-critical items that must be made top priority (i.e. perhaps those that stall revenue or erode service)?
- How are external partners impacted? How have they been prepared for different processing schedules or process requirements?
Knowing the answers to such questions and conveying them to relevant staff builds confidence that ‘no stone has been left unturned,’ that management truly cares about the impacts to the business, and that both the ways and the means of performing well with the new software have been provided.
The question will emerge of whether service can or should be relaxed during the implementation. Clearly, the answer would depend on regulatory and business climate. If they cannot be relaxed, the project and all of the relevant stakeholders must be convinced that the appropriate level of investment and measurement are in place to ensure that the service levels are indeed achieved.
If you do choose a "honeymoon" phase for specific existing service levels, ensure that there is a clear path back to full performance. The honeymoon or transition state may include unique responsibilities that aren’t really necessary after the conversion aftermath is over. And, it may include some revised priorities i.e. where some tasks are ranked lower (i.e. launching new marketing campaigns) than others (i.e. reach out to commercial and industrial customers to ensure they understand their new bill format and rate calculations). Employees may need both a set of "transition period" role descriptions and performance management and a set of "steady state" expectations.
Decreases in Customer Satisfaction
Whether your service levels are formal or informal, how well you meet your customers’ expectations will determine your future success. You may have been convinced to change out your CIS to "enhance customer satisfaction." Do you know specifically how this is to be done? Is it linked to customer communications, i.e. bill format? Is the system (and the supporting processes) supposed to improve timeliness? Do you have a clear baseline of satisfaction before the process changes and a means to measure satisfaction point-by-point afterwards? Such approaches need to be clearly specified in your implementation plan.
In today’s world, your "customers" may include a broader cast of characters than simply your residential and commercial users. You may have service agreements with other business partners (i.e. billing services) or commitments to transmit transactions in a deregulated environment. Third party satisfaction and collaboration during a key transition may prove to be a milestone in your relationship.
Surprises take a greater toll than necessary
As individuals, we are all better able to respond to surprises or crises when we are healthy – mentally and physically. The same is true for the organization of individuals you rely on in your company. Minimizing surprises is one way to keep your team’s trust. Communicating
proactively – particularly the issues and troubling news – is a key component.
In one example, the utility issued large-scale public apologies for service after the CIS
conversion. Executives were scrambling to understand why they had previously only heard the ‘good news’ regarding the implementation’s expected outcomes. Dysfunctional behavior at all levels was observed during the chaos. In contrast, another utility (who implemented the same software) reflected back with comments like "we had expected a hurricane that never really hit. We were ready. We had some issues but they were manageable."
Preparing "for the worst" has almost always proven to be a winning strategy. Multiple utilities have termed their pending implementation as a potential "hurricane." This stirred a culture where extraordinary effort is frequently required and that new, urgent, tasks are taken on without question. The level of planning that goes into hurricane preparation (i.e. in southern U.S. states) should be a minimum for a CIS implementation.
Whether or not your organization finds issues "manageable" is directly related to its "mental health," sense of urgency, and confidence that it has prepared for identical or at least somewhat similar issues.
Planning for Business Success
Does your plan account for these risks? Your management team (which may include business sponsors, technology sponsors, system integrators, and software vendors) needs to staff the team with individuals skilled in managing organization change. You may also want your integrator to facilitate discussions for you with other utilities that have made similar changes. Your network of "change agents" (i.e. credible formal and informal leaders across your organization) need to hearrelevant lessons learned from other implementations.
Besides the inevitable configuration, testing, conversion, reporting, and technical architecture tasks, your workplan needs to also reflect the myriad of activities that create the required skills and ensures the needed motivation of many different players. Consider the needed time and skills for business impact analysis, communication management, organization/ job alignment, education/ training, sponsorship/ leadership support, and readiness measurement. Including the right people is equally important as including the right scope. Such managing change activities will most certainly fail without the right executive sponsorship. CIS projects tend to be run by either IT or the call center. To be successful, you need to make sure you have active involvement from the beginning from all key parts of the business that will be impacted. This will make the job analysis, process design and business impact assessment more effective. Otherwise, it is IT people trying to predict the impact on field operations with possibly low accuracy and even lower buy-in.
Such activities should not be isolated to a remote and part-time HR person. Nor can they be relegated simply as "training issues." They are best integrated with all of the other workstreams and managed as part of the overall program. No one but your core project team can project the workload impacts of revised processes.
Additional Strategies for Bolstering Required Skills and Motivation
Best practices to mitigate risk and integrate approaches across your project include:
• Early in the project (i.e. during Analysis):
- Qualify and quantify business impacts that stem from process and technology changes
- Prioritize and address impacts through
appropriate combination of interventions (i.e. performance management, education,
communication, go-live procedures,
permanent policy/ procedure change, etc.
- Root out issues through scenario planning and simulation
• Throughout the project
- Create a ‘no surprise’ culture which
• Fosters relentless communication – ideally equipping front-line supervisors with key messages (direct supervisors are always the most trusted source of information by employees – not CEO videos)
• Encourages and rewards issue identification and proactive resolution
- Maintain high awareness of other projects and activities impacting your target workforce. Encourage sponsors to move or defer non-essential activities that will prove to be distracting of company time/ resources.
- Prepare yourself that the new system may enable you to "count" things that previously were off the radar screen (no-bills, meter reading errors, etc). You've probably had many of these all along, but they were hidden on someone's desk and not glaring at you from an executive status report).
• At implementation:
- Create multi-disciplined go-live criteria. Go live only when readiness (and corresponding risk) reaches acceptable level.
- Ensure preparation for post-conversion support and transition to "steady state"
• Beyond implementation:
- Avoid "collapse" of communication and leadership activities
- Don't release knowledgeable project team members as the project gets close to
implementation. This is a common cost-cutting mistake, but these people (either utility, vendor, or integration partner personnel) can be invaluable in "the field" after implementation to help users resolve new system exceptions, filter technical issues back up to the project, etc.
- Measure and improve service metrics, particularly those that impact business case realization
- Reevaluate stalled projects – balance with ongoing enhancement needs that may impact workforce
- Take stock and adjust processes and organization if necessary
- Declare victory when success criteria (i.e. housed in business case, service levels, or organizational metrics) are achieved
The Real End in Mind
Such a point of view certainly expands the "horizon" of your implementation plan.
If your plan ends with the data conversion or when the software warranty period is over, you may have missed the measurement of customer satisfaction, the stabilization of service levels, and the confirmation that key success metrics were indeed achieved. While these principles do essentially apply to any large-scale business project, they have been repeatedly proven at the "ultimate" in complex projects for a utility – the CIS Project.
Notes: 1 MORI study conducted across industries in 1997.
About the Author
Elizabeth Russell is a Director with Alliance Data Systems. During her career, she has focused on the change management issues in utility CIS change management initiatives over the last 14 years in 3 countries and at over 10 clients. She can be reached at Elizabeth.Russell@alldata.net.
What makes the difference between those implementations that are viewed as seamless and smooth from a customer standpoint and those that make headlines? While some differences can certainly be the strength of the technology and the depth of the testing, the quality of the management of the transition is a core component.
As noted in a study by Market & Opinion Research International (MORI), over 80% of the time projects fail it is due to some type of human factor including communication/ perception issues, people (i.e. job definition) issues, or project/ program management1. Technical integration and other factors accounted for failure only 19% of the time. As you begin your CIS (or other) project, have you included enough focus on these factors?
Do You Know Where You’re Starting From?
As proven recently in a CIS implementation project kickoff, longer-term employees vividly recall what it was like the last time the CIS was changed out. Particularly when there is "baggage" from prior CIS (or even non-CIS) implementations, team members need to understand how this time it will be different. Projects rarely begin with a true "clean slate." For example, a recent ERP implementation at your company may have soured the employee base against large-scale system implementations. Or, recent organization changes may have sapped the energy of the workforce to respond to the next big challenge. Often there is simply too much "noise" to muster the singular focus required to achieve a successful CIS implementation. Ultimately, organization leadership must instill a sense of urgency that the project is not only good, but that not succeeding would constitute a true crisis.
While not frequently included in a vendor’s implementation plan, taking time to assess the change history and the target audiences’ skills and motivation can make or break your project’s
ability to chart a successful course. This article examines many of the key factors for successfully managing the various impacted workforces (IT and business) during a utility CIS implementation.
Are there hidden expectations?
Changing out a CIS is rarely a simple "replacement" initiative. The investment is too large and the project touches too many stakeholders to not get saddled with other stated, subtle or tangential expectations. These can include ideas to "empower the workforce," "raise the bar of accountability," "make the X department self-sufficient," or "rid us of the mainframe." Such expectations will color the views of senior executives who not only review the budget status of the project, but ultimately determine whether the CIS project is considered successful.
What are the risks?
One of the best ways to guard against a negative outcome is to define specifically the which could occur. For a CIS implementation, the outcomes tend to focus on delivery of service and collection of revenue. Impediments to either of these factors can prove damaging to the organization. These risks can not be wholly mitigated through the right software choice, leading edge technical architecture, thorough testing, or seamless data conversion. The following scenarios have been seen at CIS implementations around the world, regardless of software chosen and length of implementation project. These can be directly linked to human factors.
Revenue Slowdown
Utilities with poor CIS implementations have experienced temporary slowdowns (or, actually, stalls) in their revenue streams due to delayed billings. Root causes of delayed billing can be data, technology, or staffing related. Even with clean data and smooth operations, the surge of exceptions to be addressed can overwhelm a staff more accustomed to "steady state." The issues commonly encountered in a recently converted system can be unique and short-lived. At stake may be both skills and issues.
Employees who end up being good at solving billing or metering exceptions typically possess a deep understanding of both the realities of the current data and the processing of the new system. They have developed the necessary "wisdom" of seeing the causes and effects of system activities. Classroom training usually only prepares these employees to practice. Without experience in all of the realities of nightly batch runs (e.g. in a production readiness, parallel, or simulation environment), employees can be limited to the scripting of predictable and "perfect" scenarios. Issues in data that stem back months or even years can prove problematic when stricter data integrity rules are applied in a new system. Some of the issues that these employees will deal with will be short term and directly linked to the implementation while other issues will become the "new normal" and require time and practice to establish new norms and practices.
At the heart of performance is, however, both skills and motivation. Slippage in motivation can occur either before or after an implementation. Typically, the project team declares victory when conversion is completed. The reality, however, has just hit for both the call center and the back office. Jobs that had a known degree of decision-making and intensity may have changed without real notice or preparation. Staffing levels that were comfortable in the old system may not be appropriate for the initial transition or even possibly for steady state. The project team may have expected and prepared for certain issues but may not have fully prepared the user community for any "bad news."
With redefined business processes, work and judgment calls that were previously made in one department (i.e. Customer Accounting or Quality Assurance) might transition to another department (i.e. Meter Reading). Without job and organization analysis, utilities may find themselves short-handed in some areas that really matter and are surprised when the critical processes that ensure the revenue stream collection are stalled.
Slippage in existing service levels
Either by regulation or by choice, utilities frequently have published service levels such as speed to answer, time to complete vital services, etc. Your CIS project needs to ensure that there is a clear baseline analysis of the current factors of such service levels. Capturing relevant months of data such as call volumes and patterns, service order volumes, meter reading/ billing exceptions, and billing accuracy percentages, and average call handle time is a good start. Several factors will influence these numbers after implementation: user proficiency, process changes, system response time, etc. Are executives in your company prepared for any of your service levels to slip even temporarily? What is the definition of a successful implementation? 60% adherence to service levels? 99%?
As you review your project budget, you see a line item or two for training and perhaps for process/ procedure documentation. You may even see some plans for user practice. All of these activities can support the building of user skills, but do nothing for building and supporting user motivation. Group leaders must be engaged to both "set the bar" for the users’ performance, listen to issues, and communicate expectations. If fully engaged, they will ask project management for data and predictions that help them answer questions like:
- Exactly how proficient will my staff be?
- Have process changes made certain transactions longer or shorter? By how much?
- What kinds of exceptions will be generated? At what volume?
- What are the mission-critical items that must be made top priority (i.e. perhaps those that stall revenue or erode service)?
- How are external partners impacted? How have they been prepared for different processing schedules or process requirements?
Knowing the answers to such questions and conveying them to relevant staff builds confidence that ‘no stone has been left unturned,’ that management truly cares about the impacts to the business, and that both the ways and the means of performing well with the new software have been provided.
The question will emerge of whether service can or should be relaxed during the implementation. Clearly, the answer would depend on regulatory and business climate. If they cannot be relaxed, the project and all of the relevant stakeholders must be convinced that the appropriate level of investment and measurement are in place to ensure that the service levels are indeed achieved.
If you do choose a "honeymoon" phase for specific existing service levels, ensure that there is a clear path back to full performance. The honeymoon or transition state may include unique responsibilities that aren’t really necessary after the conversion aftermath is over. And, it may include some revised priorities i.e. where some tasks are ranked lower (i.e. launching new marketing campaigns) than others (i.e. reach out to commercial and industrial customers to ensure they understand their new bill format and rate calculations). Employees may need both a set of "transition period" role descriptions and performance management and a set of "steady state" expectations.
Decreases in Customer Satisfaction
Whether your service levels are formal or informal, how well you meet your customers’ expectations will determine your future success. You may have been convinced to change out your CIS to "enhance customer satisfaction." Do you know specifically how this is to be done? Is it linked to customer communications, i.e. bill format? Is the system (and the supporting processes) supposed to improve timeliness? Do you have a clear baseline of satisfaction before the process changes and a means to measure satisfaction point-by-point afterwards? Such approaches need to be clearly specified in your implementation plan.
In today’s world, your "customers" may include a broader cast of characters than simply your residential and commercial users. You may have service agreements with other business partners (i.e. billing services) or commitments to transmit transactions in a deregulated environment. Third party satisfaction and collaboration during a key transition may prove to be a milestone in your relationship.
Surprises take a greater toll than necessary
As individuals, we are all better able to respond to surprises or crises when we are healthy – mentally and physically. The same is true for the organization of individuals you rely on in your company. Minimizing surprises is one way to keep your team’s trust. Communicating
proactively – particularly the issues and troubling news – is a key component.
In one example, the utility issued large-scale public apologies for service after the CIS
conversion. Executives were scrambling to understand why they had previously only heard the ‘good news’ regarding the implementation’s expected outcomes. Dysfunctional behavior at all levels was observed during the chaos. In contrast, another utility (who implemented the same software) reflected back with comments like "we had expected a hurricane that never really hit. We were ready. We had some issues but they were manageable."
Preparing "for the worst" has almost always proven to be a winning strategy. Multiple utilities have termed their pending implementation as a potential "hurricane." This stirred a culture where extraordinary effort is frequently required and that new, urgent, tasks are taken on without question. The level of planning that goes into hurricane preparation (i.e. in southern U.S. states) should be a minimum for a CIS implementation.
Whether or not your organization finds issues "manageable" is directly related to its "mental health," sense of urgency, and confidence that it has prepared for identical or at least somewhat similar issues.
Planning for Business Success
Does your plan account for these risks? Your management team (which may include business sponsors, technology sponsors, system integrators, and software vendors) needs to staff the team with individuals skilled in managing organization change. You may also want your integrator to facilitate discussions for you with other utilities that have made similar changes. Your network of "change agents" (i.e. credible formal and informal leaders across your organization) need to hearrelevant lessons learned from other implementations.
Besides the inevitable configuration, testing, conversion, reporting, and technical architecture tasks, your workplan needs to also reflect the myriad of activities that create the required skills and ensures the needed motivation of many different players. Consider the needed time and skills for business impact analysis, communication management, organization/ job alignment, education/ training, sponsorship/ leadership support, and readiness measurement. Including the right people is equally important as including the right scope. Such managing change activities will most certainly fail without the right executive sponsorship. CIS projects tend to be run by either IT or the call center. To be successful, you need to make sure you have active involvement from the beginning from all key parts of the business that will be impacted. This will make the job analysis, process design and business impact assessment more effective. Otherwise, it is IT people trying to predict the impact on field operations with possibly low accuracy and even lower buy-in.
Such activities should not be isolated to a remote and part-time HR person. Nor can they be relegated simply as "training issues." They are best integrated with all of the other workstreams and managed as part of the overall program. No one but your core project team can project the workload impacts of revised processes.
Additional Strategies for Bolstering Required Skills and Motivation
Best practices to mitigate risk and integrate approaches across your project include:
• Early in the project (i.e. during Analysis):
- Qualify and quantify business impacts that stem from process and technology changes
- Prioritize and address impacts through
appropriate combination of interventions (i.e. performance management, education,
communication, go-live procedures,
permanent policy/ procedure change, etc.
- Root out issues through scenario planning and simulation
• Throughout the project
- Create a ‘no surprise’ culture which
• Fosters relentless communication – ideally equipping front-line supervisors with key messages (direct supervisors are always the most trusted source of information by employees – not CEO videos)
• Encourages and rewards issue identification and proactive resolution
- Maintain high awareness of other projects and activities impacting your target workforce. Encourage sponsors to move or defer non-essential activities that will prove to be distracting of company time/ resources.
- Prepare yourself that the new system may enable you to "count" things that previously were off the radar screen (no-bills, meter reading errors, etc). You've probably had many of these all along, but they were hidden on someone's desk and not glaring at you from an executive status report).
• At implementation:
- Create multi-disciplined go-live criteria. Go live only when readiness (and corresponding risk) reaches acceptable level.
- Ensure preparation for post-conversion support and transition to "steady state"
• Beyond implementation:
- Avoid "collapse" of communication and leadership activities
- Don't release knowledgeable project team members as the project gets close to
implementation. This is a common cost-cutting mistake, but these people (either utility, vendor, or integration partner personnel) can be invaluable in "the field" after implementation to help users resolve new system exceptions, filter technical issues back up to the project, etc.
- Measure and improve service metrics, particularly those that impact business case realization
- Reevaluate stalled projects – balance with ongoing enhancement needs that may impact workforce
- Take stock and adjust processes and organization if necessary
- Declare victory when success criteria (i.e. housed in business case, service levels, or organizational metrics) are achieved
The Real End in Mind
Such a point of view certainly expands the "horizon" of your implementation plan.
If your plan ends with the data conversion or when the software warranty period is over, you may have missed the measurement of customer satisfaction, the stabilization of service levels, and the confirmation that key success metrics were indeed achieved. While these principles do essentially apply to any large-scale business project, they have been repeatedly proven at the "ultimate" in complex projects for a utility – the CIS Project.
Notes: 1 MORI study conducted across industries in 1997.
About the Author
Elizabeth Russell is a Director with Alliance Data Systems. During her career, she has focused on the change management issues in utility CIS change management initiatives over the last 14 years in 3 countries and at over 10 clients. She can be reached at Elizabeth.Russell@alldata.net.
