CHAPTER TWENTY

Design Reviews for New Methodology, Technology, and Processes1

IN THIS CHAPTER, THE DESIGN work processes—from basic define and select to advanced programming—are discussed. Workforce management (WFM) systems are structured to allow employers to use and configure the application in accordance with their particular business requirements. Some software applications provide templates and preconfigured rules and on-screen workspaces. Other applications may be structured around a platform that requires writing code or modules that involve a substantial amount of programming. Even the most simplistic employer model does not implement a complete plug-and-play application. Pay cycles, wage types, and accounting codes must be selected or set up to make the system work. And for each design there is a decision, a plan, and a mission to accomplish. This chapter describes a process for effective design of WFM systems.

Design reviews are needed any time functionality, inputs and outputs, and cost are likely to be highly variable depending on the design. Design reviews may add a significant effort because the objectives are more complex, more far reaching, and involve more than a single stakeholder. In the past, timekeeping was primarily a stand-alone device involving a small set of computations at a specific point in time. These devices mechanically handled discreet data inputs and outputs where the process was narrowly defined. Older timekeeping solutions had a common singular mission—data collection and reporting.

WFM systems today are, by contrast, not operating at this mechanical level. They operate using many technical components, handle numerous computations and processes, and involve varied timing of operations. Their mission is customer specific—meaning they should solve for specific problems such as cost containment, effectively meeting the demand for skilled workers to drive quality and revenue or providing schedule stability and pay fairness among employees. Being able to take solutions and design them to penetrate through multiple levels of employee involvement and execution requires carefully designed system setup.

A simple analogy is the difference between buying a mailbox and purchasing a home. Mailboxes come in a lot of shapes and sizes, but they primarily serve one purpose—mail in, mail out once a day. The functionality of a house, by comparison, depends on the occupants, the climate, covenants in the neighborhood, and a host of inputs, outputs, and style (e.g., gas versus electric, sewer versus septic, energy efficiency, lot topography, or number of rooms). You can buy and install a mailbox without consulting an engineer, but you would not build a home without engaging an architect and designer in the process.

20.1 DESIGN REVIEW MODELS

Design reviews are events, not product demonstrations or project status reports. As a sort of knowledge management exercise, design reviews allow decision makers to assess what is and is not working as well as what might and might not work before committing to the work. They are limited in concept and work in concert with other activities such as communications, planning, and execution activities as well as the six A.C.T.I.V.E. principles (see Chapter 2, Section 2.1 for details). The design review is a highly structured, technical test of the blueprint and rationale for the WFM system. It is led by a program manager supported by technical personnel. Yet it is important to involve people outside of the design team who can represent the end user as well as the stakeholders who will pay for the system. Their focus is a translation exercise to determine if the system designers understand the system mission and have a blueprint for execution that is comprehensive, functional, and feasible. Successful design reviews will leave little to chance and lead to more predictable outcomes, enhanced usability and fit, and less rework after implementation. It avoids the trap of relying on work-around processes, training, and “good faith” to fill any gaps in system design. It is commonplace in intricate and detail-oriented disciplines such as engineering.

Prior to conducting a design review, the system mission should be defined and understood. The mission is included in the business case (reference Chapter 3, Section 3.1). A WAM-Pro should combine the mission with the specifications (spec) developed during the initial system assessment and request for proposal (RFP) process for the new WFM system and operational model. The spec should include an itemized listing of functionality that produces future state capabilities such as reducing overtime by flagging unplanned shifts over eight hours, setting up minimum rest between shifts, instituting meal attestation, or increasing sales or production output. The design review is not the activity that creates the requirements; rather, the specifications are a prerequisite for the design review. The spec guides the technical team in determining how the system will be configured.

The specifications should provide a clear picture of what the organization needs at each level. The organization's objectives begin at the top and flow down through the system so that activities and decisions at each level are supporting the top-level goals. This is done by aligning with the system mission hierarchy.

20.2 SYSTEM MISSION HIERARCHY

The system mission hierarchy in Figure 20.1 displays the organization by level. On the right side of the pyramid are the company and its hierarchy of business objectives. On the left side is the system itself. Its processes and features are paired with the business mission (the breakdown of organizational goals into a multilevel set of responsibilities). From the executive level on down to supervisors and employees, and from the end-user task and system workspace on up to system success—everyone in the organization and each aspect of the system has a role to play in accomplishing the mission. Each end-user task and each instance of manager insight will not have a positive impact on the mission.

Figure 20.1 System Mission Hierarchy

A high-performing system will involve each level of the hierarchy. High-level benefits are derived from actions at each level. For example, to increase store sales people need to be at their assigned work stations. In a grocery store, cashiers that arrive late or take a long break leave customers waiting or, worse, result in some leaving the store without making a purchase. Directors need metrics to measure attendance and productivity. Managers need to pinpoint shifts where this is a problem or lead cashiers who have a habit of not managing their team. Supervisors need to be alerted immediately to late occurrences or heavy customer traffic to fix the coverage issue immediately. Employees need to be alerted if they have violated the tardy policy and disciplined consistently to encourage good work habits. There should be no gaps in the process of working toward the goals. If supervisors know that the policy is in place but no one above them has the tools to watch (visibility), they will be lax in their managerial responsibilities, ignoring system flags and WFM-generated metrics and disciplinary prompts for attendance violations. If unplanned overtime is to be reduced but the system is not designed to distinguish between necessary (planned) overtime and incidental overtime, supervisors may be using system tools to prevent employees from inflating their time with incidental overtime (OT) but directors will be frustrated that their dashboards give them no way to measure improvements. The design review will illuminate how the system is architected to produce meaningful solutions at each person and process level.

At the core, the design review demonstrates how the technology and data are to be used to create the desired outcomes and fix whatever needs improvement. Using a detailed road map that specifies each piece of configuration and functionality allows the organization to test the concepts and features before full-scale implementation. Not only does it avoid design choices that will not work, it also serves to prove the relationships between business problems and technology solutions. The design review proof also allows the organization to look for unintended consequences and to probe for gaps, indirect outcomes, and any imbalance between employee and organizational needs. The purpose is to design the WFM system to create outcomes that support the overall business mission and successful design.

20.3 TYPES OF DESIGN REVIEW

When the system mission, business requirements, and technical specifications are ready, the design review process can begin. There are two types of design review—limited and critical. The limited design review is a rough estimate and is the first review undertaken. It defines in general the construct of the system. During the limited design review (LDR), agreement is reached on the overall design, and a prototype is understood. The technical team obtains a clear idea of what it is the stakeholders want. They understand a detailed list of objectives and who is requiring it. The spec has identified the form, fit, and function. Now the designers understand what may limit feasibility and how they might integrate the new product into the existing environment using the available tools, resources, and processes. The limited design establishes parameters of the prototype.

The LDR is the critical first step in aligning the system with the organization's goals. It is a high-level analyzing process that the system owners and organizational decision makers use to make certain that the stated purpose for the investment in a WFM system is understood by the people who will actually configure the system and roll it out. The deliverables from the LDR include a list of accepted targets and documentation of decisions for design (if not/why not discussions). The documents should be crafted to meet the needs of various audiences, including participants from information technology (IT), payroll/human resources (HR), finance, project management, and operational leadership.

Preparation for the Limited Design Review

The design review is an iterative process, not necessarily a one-time event. It will likely take more than one meeting to work through all of the design questions. Each meeting further refines the functionality and moves the discussion from concept to technical design. After the LDRs are complete and the team has prepared a prototype, it is time for the critical design review.

The critical design review is a detailed discussion of WFM system solutions, including pay rule design, user workspaces (on-screen view, reports, navigation and query tools, etc.), reports, outputs, inputs and demographic data, integration with other systems, timing, processes, and outcomes. The review is a negotiation between designer and system owner. It assumes that everything is possible but limited by budget, time, and culture. The discussions during the review can include demonstrations of the product (using mock-up or scenario-based live demonstrations). This is the time to resolve the cost thresholds that will limit parts of the design such as the number of custom reports or devices, the user population, or extra creature features to enhance system usability. The CDR workshops serve to translate the organization's goals into the finely detailed solutions for systems, processes, and people.

This can be where configuration of the new WFM solution begins. The CDR is used before, during, and after the system implementers construct and configure the components of the application or devices. Use the WAMBOK as an important guide in configuration planning, as well as in validating the business issues, processes, and outcomes in combination with product specific configuration training materials.

The CDR verifies the ability of the WFM system and processes to satisfy the requirements while educating the owner about how it can happen. The CDR determines the time line for implementation and goal achievement, resources, cost, risks, and critical path. It identifies the dependencies along the way, alerting the organization to how this new business solution will impact other areas.

20.4 ROLE OF THE DESIGN WORKBOOK IN DESIGN REVIEWS

The design workbook maps specific organizational goals to the precise features within the WFM system that will be used to reach the goal. The workbook is a product of the reviews and is used by the actual designer or programmer. The mapping includes each level of system stakeholder, from executive leadership down to the frontline employee. Each user has a touch point and a need that is explained in detail. A single goal may have a number of solution paths that describe precise features designed to help hit the target.

For example, when overtime reduction is a stated goal, the design workbook establishes what each level of user needs to manage overtime's root causes. The design workbook channels the design effort around fixing root causes, not reporting problems such as overtime. Using an overtime report is easy and requires no design because many systems will come with a canned overtime report. Designing a fix for overtime requires understanding the various root causes, such as working through meals. Therefore, in the design workbook, the mapping of the goal of reducing overtime is worked out by addressing system features that can help manage meal breaks, a root cause, and how meals are managed at each level (see Figure 20.2).

Figure 20.2 Sample WFM Design Review Workbook

Breaking down working through meals by user level might look like the following:

• Executive: WFM dashboard of missed meal breaks and key performance indicators (KPI) by week. WFM communication plan to establish corporate expectations (and commit leadership publicly—build integrity).
• Director: WFM dashboard of missed meal breaks by department showing cost. WFM corrective action plans and disciplinary policy. Use WFM data to create metrics and budget for incidental overtime due to missed meals. KPI representing operational demands that may have impacted staffing.
• Manager: Alerts and flags built inside WFM system to report employees who have not taken a meal today and quantifying the cost. WFM schedule solutions turned on to realign staffing to relieve workers from their duty so that they can take a meal, or send the person home early to reduce their total hours worked for the week. WFM corrective action plans, including disciplinary guidelines. Department quota for acceptable missed meal breaks.
• Employee: WFM attestation feature turned on to produce reporting of time worked and waiving of meal break rights. WFM pay rules that flag missed meal breaks. WFM corrective action plans, meal, and disciplinary policies for working through meals.

The outcomes from the CDR and design workbook give the organization confidence that the system will deliver on its mission. It creates a tangible, measurable blueprint of success. It gives a detailed description of the form, fit, and function of the system configuration and surrounding processes and responsibilities. And it can be leveraged to improve organizational integrity (see Figure 20.3).

Figure 20.3 Steps of Design Review Process

It costs more to go through a design review but it has been tested to lower the production and use cost. Without the design review, the system is not fully tailored to the employer and there will be gaps in meeting all of the requirements. The limited and critical design reviews drive the probability that the investment will meet the organization's needs at rollout and as the organization evolves (see Figure 20.4).

Figure 20.4 Cyclical Tasks of the WAM-Pro during Design Review and Implementation

1. This chapter was contributed by Lisa Disselkamp.