CHAPTER TWENTY-ONE

Implementation of the Workforce Management System

IN THIS CHAPTER, IMPLEMENTATION IS explained as a process that relies on carefully executing previous project activities. If the project followed the system's development life cycle, the analysis and design phases are complete and the implementation is ready to proceed. This chapter describes the two major subphases, construction and delivery, and related documentation to support implementation activities. The construction phase is a review of the activities in prior phases as one final check to make sure all the necessary work is completed. System delivery releases the new system to its awaiting new user community. Projects conclude with documenting lessons learned to add to the historical records for future workforce management (WFM) upgrades and implementations. The steps and documentation described in this chapter will help support a successful WFM implementation and provide a good end-user experience.

21.1 ELEMENTS OF IMPLEMENTATION

Many people think of WFM system implementation as the entire project. However, from the systems perspective it is not. The implementation is considered to be the last phase of the overall project; the one that turns the new WFM system over to the user community. The implementation is the final step in the planning effort to provide the business with a new way of doing business.

The implementation of a WFM system can be challenging if an organization is not prepared. One way to think about an implementation is the culmination of all the previous efforts involved in the project. If the project activities were not done correctly or were skipped, the implementation may be difficult and require substantial follow-up work to fix or complete the effort.

The following information contains activities and planning items that need to be accomplished prior to having the WFM system go-live in the organization and user community. As with all implementations, organizations will be different so the activities may vary. However, there are common core activities for the transition to a new WFM system.

In general, implementations should include the following activities. It is better to be prepared than to have major problems the day the new WFM system is turned on. A weak implementation structure or effort can start the organization off on the wrong foot and may cause ongoing credibility issues with the new WFM system and those who were involved in the implementation.

The first phases of the project consist of the analysis (planning requirements gathering) phases that identify the business problems and determine the organizations requirements (see Chapter 18). Next is the vendor and product selection phase (see Chapter 19). The design phase follows and is used to design the WFM system based on the requirements (see Chapter 20). As the last major phase in a project, the implementation phase—construction, testing, and launch of support mechanisms and resources—consists of placing the developed or configured system into the operations environment and then turning it over to the organization's user community. The implementation phase generally involves two major subphases with the first being construction and the second being delivery. Some of the important activities for each subphase are listed in the following sections.

21.2 SYSTEM CONSTRUCTION SUBPHASE

The purpose of the system construction subphase is to perform a full check on the prior activities of the analysis and design phases. If all the tasks have been completed, the WFM system is ready to be delivered to the organization. The activities include reviewing and doing final preparations before the complete turnover. The activities in this subphase are discussed in the following sections.

(a) Project Review

When the analysis, design, and selection work is considered complete, a project review is needed to make sure that nothing was missed or is incomplete. The review should include stakeholder representatives. The goals, objectives, and documentation are reviewed to inspect that the WFM system deliverables are correct and that the goals have not changed.

(b) Engage People

The project review should reveal the makeup of the project team required to construct the new systems. The resources may primarily be internal, but quite often there are activities that the vendor's staff must complete. There may also be a need for additional external resources during the implementation phase to augment a large team or provide subject matter and product expertise during construction. These resources may not need to be on the project for the entire duration based on their skill sets. Timing their engagement with the proper implementation phase will help keep costs down.

(c) Set Schedules and Verify with Stakeholders

Based on discussions with the stakeholders, the actual implementation delivery schedule should be finalized and approved. Schedules may cover several weeks or months for large WFM projects. When an organization is dispersed across a large geographic area and large population of workers, the schedule may be broken down into “waves,” with certain groups beginning and completing the project before other groups even begin the project. The schedule may include post-go-live activities such as benchmarking, replacing consultants with full-time Workforce Asset Management Professionals (WAM-Pros), or planning for an upgrade if the implementation starts shortly before the latest application version is available. With project schedules, keep in mind that holidays, seasons, and personnel time off needs to be considered.

(d) Implementation Checklist Development

Based on the project review and schedules, a checklist should be assembled to help identify all activities and tasks. The checklist helps keep track of the items that need to occur for the implementation. The WAM-Pro creates the checklist to represent the tasks and their interdependencies, prerequisites (items that must be available or completed) before certain tasks can be performed, assignments (who is responsible), due dates, where the activity is documented, and who approves the finished product. Because WFM systems are highly integrated with other systems, they may directly result in immediate cost and compliance outcomes. In addition, because WFM systems are structured around and rely on related business activities, the checklist is a particularly complex and critical tool that must be thoroughly prepared and closely followed.

(e) Communications to Stakeholders

Correspondence with all stakeholders and project champions is critical for smooth transition and adoption processes during the implementation. These participants are responsible for making employees at each level aware of when the changes will occur and how their daily responsibilities and interactions will be specifically impacted. Not only should they be notified, a communication plan should be used to encourage acceptance of any changes and understanding of how they impact the goals of the organization. WFM systems impact employee salaries, making change and increased controls a potentially unwelcome event. Communication plans can help maintain organizational integrity and reduce unnecessary resistance or confusion, and help the entire organization feel represented and engaged during this time.

(f) Hardware, Software, Infrastructure, and Environment Setup and Preparation

During the planning phase the required hardware, software, network, devices, and other infrastructure may need to be ordered.

Often there are delivery lag times for the transport of purchased equipment. There may need to be some site inspections particularly for device (e.g., clock) placement to survey the logistics of installing new devices and connectivity. Throughout the construction subphase each technology component will need to be delivered, installed, and tested to make sure that the new WFM functions as designed.

(g) Installation of the WFM Software

The selected or developed WFM software will need to be installed on the operational production environment for use by the user community. Or, if the selected WFM system was an online service model, the communications and access protocols will need to be installed or configured. This may include multiple environments such as development, test, training, and production instances of the application.

(h) Installing Training and Testing Data

For user training and testing, a repository of data designed for training may need to be installed in the training environment. For better results, the data for training should be a version of the organization's real data to simulate what users will be working with on the new WFM system. One set of data for training and testing may not be appropriate for all rules and users—particularly in large organizations. Training and testing should cover those situations most likely to create errors as well as recurring activities.

(i) Test Plan, Testing, and Scripting

As the new WFM system is constructed, a plan should be developed to address the systems test that checks if the WFM system is working as expected. This effort will include developing simulated testing formats and scripts for use during testing.

(j) Training Environment

The training database is the environment where trainers and users learn how to use new WFM technology. It is important that users have access to some type of hands-on training outside of the production environment where they can practice new features and procedures without causing harm. It is recommended that users be required to pass a competency test before being granted user access to the production system. Training is not a one-time event for WFM systems. Each new employee and promoted supervisor will need time to learn and practice his new role using the training environment. In large organizations, a permanent test environment may be needed. For smaller employers, the vendor may be able to provide an online training solution.

(k) Training Materials

For training, there need to be materials and scenarios designed for users so they can become familiar with the new WFM. The materials can include textbooks, workbooks, scripts and scenarios, online courses, or a variety of other resources. (For more details on training materials, see Chapter 23, Section 23.2,”Workforce Management Technology Training.”)

(l) Systems User Guide

The systems user guide is the official manual for using the WFM system. It describes to the user community, through the use of clear, plain language (avoiding jargon) and simplified graphics, the functions of the system and how to use them. It may also include a differences document describing how processes and policies are changing with the new system. This guide covers only the product aspects that appear to the public, or what is otherwise called the front end of the application. Vendors often provide basic application user guides covering general features. The WAM-Pro helps identify the organization-specific user instructions that are needed, including customizations, business rule configuration, new policies, and new processes. The user guide may even include differences in related business systems that share data with the new WFM system.

(m) Technical Guide

The technical guide is the assembled technical materials used to configure, install, and maintain the WFM system. This guide will consist of documentation used in the implementation, including components outside the software, such as networking, Internet, and other communications information. The technical guide is a reference for back-end resources who need to understand how the application is designed at its core. The technical guide may include the layout of database tables, the formatting of fields, the mechanics of processes running in the background of the application, and how the application communicates with its various components and external devices. Having this information is important to help with troubleshooting problems and for future changes.

(n) Data Conversion or Setup

If the new WFM system is being converted from another system, the previous data may need to be converted to the new system as well. Or, if the system is new with no conversion it will need to be prepared to begin collecting and saving data. This may involve translating terms (e.g. changing or combining names or data) and formatting data to fit inside the new application once it is built and ready. Aligning data from old systems with the new WFM system allows the organization to maintain reporting continuity and track its performance and spending over longer periods of time.

(o) Documentation

Design activities—both application and process—should be formally documented and quality checked for accuracy and completeness. This phase provides a critical change control tool for ongoing system integrity and change management. With WFM systems this is an important part of creating a defensible timekeeping system. Although documentation should be ongoing during the planning, design, and build, it can only be finalized once the system is built and tested, and post-go-live, when it has proven its workability.

21.3 SYSTEMS DELIVERY SUBPHASE

The purpose of the systems delivery subphase is to turn the system over to the user community to begin using on an operational basis. The activities of this subphase are primarily concerned with making sure the appropriate users can access and use the WFM system as intended.

(a) User Access Requests

The new WFM system will provide user rights for those who will be using and entering data into the system. The normal process is that each user or their manager will be required to request access to the system as well as state what levels of access they will need. When going from paper to an automated system, the WAM-Pro needs to plan for an internal channel to gather information on user needs and the proper approval process to avoid overextending user rights. This effort will need to be completed before the system is deployed. (Reference Chapters 8 and 16 for more information on roles and responsibilities as well as security and access rights.)

(b) System Turn-On and Release

Once the system is turned on and released, the user community will be allowed to begin using and entering data into the system. This well-planned event is orchestrated with all the interdependent systems and reporting cycles as well as work schedules and pay requirements. WFM systems may present some of the trickiest timing issues for business systems. Every employee is made aware of when the old system is no longer available, processes and policies have changed, and access is allowed in the new environment.

(c) WFM Reporting and Analytics Validation

The WAM-Pro is positioned to interface with the various business areas evaluating whether the data coming into and out of the WFM system is credible, timely, and meaningful. Seeing data flow between systems is not a sufficient measure of success. The WAM-Pro should be resolute in making certain the WFM model is producing acceptable data on a continuing basis. The go-live of the new system is only the beginning. To address the challenges of data integrity, the WAM-Pro designs an ongoing audit schedule and can initiate a data review board that meets periodically to assess how well the WFM data is serving the organization. Problems with data are a sign that the Design Review process may need to be used to find the root cause of those problems. The objective is that data becomes an enabler helping the WAM-Pro find ways to refine the system and improve the business.

21.4 PITFALLS OF IMPLEMENTATION

The implementation of any Workforce Asset Management system project can be rife with pitfalls. These issues and problems could potentially cause the delivery of the new system to be inadequate, disruptive, or, in the worst case scenario, the wrong system. Unfortunately some organizations end up with problems that require adjustments and additional investments to make things right. Without effective guidance, organizations may fall victim to incorrect approaches and assumptions. Table 21.1 highlights some of the more common pitfalls that occur and what can be done to prevent falling into them.

Table 21.1 Avoiding Common Pitfalls during WFM Implementation

http://www.wiley.com/WileyCDA/Section/id-816176.html

The pitfalls listed are not all inclusive but do represent the more common ones that occur with WFM implementations. When threatened by one or more of these issues, an organization should refer to and realign its vision with the A.C.T.I.V.E. principles, certified WAM-Pros, and the workforce management office (WMO) for solutions and options for going forward.

21.5 SETTING UP AND OPERATING A TECHNOLOGY HELP DESK1

The continuing effectiveness of a system implementation after a go-live is largely dependent on the support structure that an organization builds to provide assistance to users. A help desk structure allows an organization to support its users beyond the initial implementation and may include a clearinghouse style technology area help desk that refers problems and issues not related to hardware and access issues to other areas of the company, such as a workforce management office (WMO).

When an organization goes through an implementation, it is important to consider a number of elements:

• Role and benefits of a help desk.
• Personnel models that can be modified to meet the changing needs of the organization's users.
• Constantly evolving training plans that reflect updates to the system and the organization's policies and procedures.
• Importance of incorporating processes, procedures, and tools to evaluate system performance and document issues.
• Convergence of people and systems and what performance issues arise as a result.
• Role of external vendors and contracts and how they influence a help desk structure.

Each of these elements is discussed in more detail in the coming paragraphs.

(a) Role and Benefits of a Help Desk

The need for a help desk is inherent in a WFM system implementation. As users encounter questions about how to use the system, issues in performing tasks, or even basic technological difficulties, they need a single point of contact that can help them navigate or escalate their issue to reach a resolution. A help desk provides a standard set of processes, procedures, and resolutions that increase the likelihood that users in an organization are receiving similar support, regardless of geography, function, or other organizational division. Additionally, creating a single entity to handle user issues means that reports of system-wide problems are realized more rapidly, thus facilitating quicker problem resolution.

Help desks direct users' expectations toward the person(s) in the organization who can help them with their system-related question. By implementing a help desk, an organization can route users away from one-off help requests to colleagues and instead send them to one location with questions ranging from How do I reset my password? to How do I run a report for the last pay period to check for overpayments? Managers may also inquire about timecard or attendance or compliance problems, which may reveal a gap in training and not a true system problem—relieving the system support personnel from needless interruptions due to lack of training. The help desk structure is designed to absorb the gamut of user questions and issues and route them to the appropriate person for resolution, and helps users recognize the benefit of having dedicated system support personnel at their disposal.

Keep in mind that some of the issues that will be routed to other support areas, such as a WMO, are business and functional issues that need to be addressed by a professional familiar with those specific areas of specialization. The help desk will screen for these calls and then forward them to the appropriate locations. This means the support calls are still being tracked, but some resolutions will come from the subject matter advisers and WMO leaders.

One question often asked is about when the help desk should be planned and structured. The answer is: during the analysis phase of a project. During the analysis the requirements are being defined. The requirements should include training requirements, the user materials, and the expected support needs for the WFM being implemented. This will provide the time to hire new personnel or to create or make adjustments to an existing help desk. Quite often these requirements are not initiated until right before the actual WFM system implementation and release. This usually means the organization is not ready to support the WFM system when released to the user.

A final thought about structuring a help desk that needs to be emphasized: The structure of a help desk is based on scalability. Resist the tendency to think that it must be staffed by a large number of people using complex technology. The help desk area should be designed to address the needs of the organization. Consider the many ways that the help desk function avoids problems and supports system adoption leading to increased ROI and organizational success.

(b) Help Desk Personnel Model

The ongoing system support and ownership model that an organization embraces with the implementation of a WFM system requires a dedicated personnel structure. In order to appropriately staff a help desk, it is important to take into account the number of users in the organization and which areas across the organization may require more support. Support personnel should be trained specifically in the functionality they will be covering and the relevant policies behind it. They should also be knowledgeable with basic system navigation and troubleshooting, escalation processes and issue prioritization, help desk tools, and customer service.

For implementations with a large number of systems users beginning to use the system concurrently, it may be advisable to assemble a “war room.” This war room would be a designated area where system super users reside for a short period of time during go-live while users enter data and work with the system for the first time. This room can be both virtual and offer onsite users access to unscheduled drop-in training sessions. This type of go-live support and user remediation can help the initial period go more smoothly for operations and payroll. Staffing this group should come from those familiar with the new system as well as the old processes and system to facilitate effective conversion learning and adoption. The staff who built, tested, and trained users on the system are ideal candidates for this role.

It is important to consider the number of calls or tickets a person can take in one day—this will vary based on the software chosen and where in the life cycle of the implementation the organization is. Call volume may be higher just after a go-live and during peak periods (e.g., the end of a pay period). It is also possible that calls may take more time during these periods, also changing the number of calls each person can take.

When aligning potential user count with a support operations model, a number of factors come into play. These factors will vary per organization but will include some of the following items:

• Size of the company. The size of the company will determine the help desk model. The larger the company the larger the help desks and supporting areas. Generally there will be a ratio of help desk personnel to company population to determine the size. Caution is needed here. Do not rely solely on articles with recommended ratios. These may not fit what is needed. A better approach is to create a help desk area and allow it to grow based on the demand and needs of the users.
• Type of company business. Some companies may need significant help desk support while others may not. For instance, a firm in which employees only clock in and out may need minimal support. However, a company in which employees need to clock in and out, self-schedule, or track their activity as it is associated with premium pay, work orders, or billing may need significant support.
• Working locations. Help desks are often situated in a centralized location, not at each building or facility. The structure of the help desk will also depend on the working locations of employees who need support. For instance, remote employees will need immediate assistance via computer and telephone. However, employees who are not remote may not need immediate support and can report issues by computer, by phone, or by visiting the help desk area. Covering a wide geographic area may require expanding hours of operations across time zones or even operating 24 hours a day to support business units that operate 24/7.
• Type of technology being used. Generally, the more sophisticated or complex the hardware and software, the more help desk support that will be required.
• Employee WFM backgrounds and familiarity with technology. The background of employees may impact the level of support that needs to be provided by the help desk. For instance, an information technology (IT) company where the employees are familiar with the use of systems may need minimal support. Jobs where a WFM system introduces the first software application workers have access to may need significant assistance.

Staffing models should be flexible based on roll-out schedules for the implementation. It is likely that different staffing requirements will exist just after a go-live until users acclimate to the system. There may also be certain times when additional personnel are needed to handle specific issues, such as the close of a pay period, holiday pay periods, and times of increasing business demand or change.

The help desk personnel mix should also account for both front-end and back-end procedures and be tiered accordingly. For day-to-day operational matters, a broader number of support staff may be required to answer questions about access, passwords, or conducting basic transactions. For functional and policy questions and for technical fixes and upgrades, a number of advisers or super users will be required to receive and resolve issues that frontline staff may not be trained to handle. For instance, a help desk will most likely not be familiar with financial budgets and expenses that are reported on WFM systems. In this case the support call should be routed to the subject matter adviser on that topic or to the WMO.

In some smaller organizations, a help desk role may be taken on in addition to standard duties because a certain employee is deemed to have the most knowledge about the subject matter. If this is the case, it is important to tailor this employee's role very specifically to maintain both effectiveness as a worker and schedule. The organization should consider creating a specific breakdown of work hours where the employee is expected to perform help desk work and those in which she should be performing her regular tasks. Another option is to create an SLA for the employee, effectively placing contractual guidelines around time spent on each help desk task and/or a minimum or maximum number of tickets the employee should take on in a given period of time. Because these are often instances in which the employee is the help desk, it is important for both the employee and the organization to have a clear agreement on how the employee will perform the job going forward.

(c) Maintaining an Effective Help Desk: Training, Processes, and Tools

Training for personnel across the help desk organization should be consistent and provided routinely, thus facilitating a standard level of service to users regardless of issue. As system upgrades or policy changes take place, support staff should be trained to understand the impact those changes have on the system and their responses to incoming questions. Similarly, if functionality changes between system rollouts in a phased approach, members of the support organization should be trained on the system updates in order to maintain consistency in service provided to users.

Training should cover a standard set of call and ticket tracking tools and processes to document and resolve issues and efficiently handle help desk inquiry volume. In general, the tools will include an online tracking system that has standard information (date, submitter, department) that allows the user to describe their problem or question. When a new issue is brought to the attention of the help desk, there should be a standard sequence of steps to resolve the problem and a process to document the issue and the resolution. Repeat issues should be reported and escalated so that a strategy can be put into place for mitigation; once a strategy is created, the support staff should be trained to understand the new solution.

A number of tools are available to support help desk operations. Especially in larger organizations, it may be necessary to implement a telephone management system that places users into queues based on when their call was received and/or the function they are calling about. For those organizations using e-mail to receive help desk requests, a forwarding system may need to be put into place. For a smaller organization, even a simple spreadsheet or laptop-based customer service management database can be used.

If this is the first call center function, it may be time to purchase phone line management software and high capacity phone lines (such as a T1 line). To determine the number of phone lines needed there are special calculations to assist in estimating the equipment and personnel needed. Erlang calculators can be used to measure and establish help desk call volume. They take into consideration dimensions such as number of calls per hour, length of call, how long callers should be expected to wait for their call to be answered (hold time), and so on.

System users will approach the desk in a number of ways—phone calls, e-mails, and even walk-up visits. Regardless of how the issues are brought to the help desk, a ticket tracking system helps ensure that help desk issues continue to move forward. By using a ticket tracking system, an issue can be located at any time by status, area, owner, date submitted, and others. Help desk managers can monitor response time, escalation issues, and even places in the system that might be causing more issues to users than others.

Using these tools and steps maintains the help desk's ability to track both system performance and user difficulties. It is imperative that help desk personnel consistently use the tools associated with each task to track and resolve issues. Though the temptation often exists to bypass creating a ticket for something as simple as resetting a password, tickets are critical for monitoring system performance, user competency and adoption of the system, and effective utilization of help desk resources and personnel.

Another effective way to monitor user adoption of the system is through the use of audit data. By reviewing the issue and ticket logs discussed earlier and system reports, the organization can identify both gaps and bottlenecks in processes and determine a mitigation strategy. For example, evaluation of a ticket log might indicate that 50 percent of users since go-live have had the same question about a specific function. The organization might revisit its training material and determine that the issue in question requires additional training coverage and create a new course or training materials to fill that need.

One thing to keep in mind about maintaining a help desk is that the help desk will need to adapt to changes to the system or other needs of the organization. One of the common complaints about help desks is that they are out of date or cannot provide the assistance that they used to be able to provide. These complaints are indicators that the help desk process and personnel need to be updated.

(d) Vendors and Contractors

The use of vendors and external contractors is a common element of a help desk operation. If an organization elects to engage a vendor to serve as its partner in a help desk model, the organization can use SLAs, which have very specific parameters about hours and level of service the vendor will provide, expected response time to any given issue, and expected resolution time to any given issue. An SLA also provides guidance for the organization about what to expect if an issue becomes something that the vendor has to spend time on as a fix or enhancement to the system. For employers who expect a significant volume of complex issues to be routine, ask the vendor for an assigned support person to handle their calls so that the vendor is familiar with the employer's system and personnel.

The requirements, priorities, and criteria for evaluation used to measure vendor performance should be determined ahead of time and explicitly noted for both entities. The organization should use the reports and logs discussed earlier to monitor progress over time and make sure that both parties are adhering to the agreed-upon requirements. Contracts and SLAs should be constructed in a clear, concise way that defines these requirements and obligations. They should also reflect how the organization will manage instances in which the vendor does not meet these obligations. In these cases, payment is often contingent upon the vendor meeting minimum service level requirements, and it may be withheld or reduced if those requirements are not met. Over time, these evaluations may reveal that the employer is more self-sufficient and the vendor support needed has diminished.

A final consideration for vendor management relates to how and when the organization will use vendor resources. Leading practices indicate that a help desk issue goes through a standard routing procedure as illustrated in Figure 21.1, and the vendor is only contacted after other levels of internal support have been included. As indicated in Figure 21.1, there is not an instance in which an employee or supervisor contacts the vendor directly; rather the super user does so, and then the resolution is handled according to the solution identified between those two individuals.

Figure 21.1 How an Issue Reaches a Vendor

Figure 21.1 shows the sample escalation path of an issue from initiator to vendor, showing layers of support between initiator and external parties.

The life of a system is only just beginning when implementation is complete. It is important to put great consideration into how to support the system and its users and how an organization can utilize the help desk model to do so. When the project ends, a list of items should be compiled about what worked well and what did not work well during the project work. The lessons do not require a major write-up. Nevertheless, they serve as valuable reminders when future projects occur.

During implementation, every effort is needed to facilitate a good user experience at the start-up of the new system and to deliver a compliant and defensible system and meaningful data. Using this chapter as a guide to create your own formal checklist approach is a way to enable efficient implementation and follow-through.

1. This section was contributed by Brittany Larson.