CHAPTER EIGHTEEN
Requirements Gathering and Analysis for Workforce Asset Management1
In this chapter, the role of business analyst (BA) is broken down into strategic and tactical tasks, which is a frequent role the Workforce Asset Management Professional (WAM-Pro) will play. Business analysis is a careful procedure of defining and then meeting the organization's requirements. What can be taken away from this chapter is that, like project management, the discovery, planning, and organizing stages are critical for achieving meaningful results. Numerous techniques are available. Consistency in method and application produces a clear definition of requirement and need and a workable solution to meet the mark. This chapter also gives a fictional example of a business analysis process for a set of simple workforce management (WFM) requirements and solution selection, which can be scaled and tested in a variety of formats and environments.
- Define the business analyst and systems analyst and how each role relates to the WAM-Pro.
- Explain the steps of business problem solving and develop connections to how these would apply to WFM problems.
- Identify the parts of a requirements analysis document.
- Outline business analysis processes for WFM requirements and solution selection.
18.1 BUSINESS ANALYST
The International Institute of Business Analysis (IIBATM) defines business analysis as “the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and recommend solutions that enable the organization to achieve its goals.”2
Barbara Carkenord, in her book, Seven Steps to Mastering Business Analysis, indicates that “business analysis involves:
- Identification of business problems and opportunities.
- Elicitation of needs and constraints from stakeholders.
- Analysis of stakeholder needs to define requirements for a solution.
- Assessment and validation of potential and actual solutions.
- Management of the ‘product' or requirements scope.”3
She further explains that the “business analysis elicits, analyzes, communicates, and validates requirements for changes to business requirements, policies, and information systems. The BA professional understands business problems and opportunities in the context of the requirements and recommends solutions that enable an organization to achieve its goals.”4
18.2 SYSTEMS ANALYST
Whitten, Bentley, and Dittman define the systems analyst as follows:
Systems analysts facilitate the development of information systems and computer applications by bridging the communications gap that exists between nontechnical system owners and users and technical system designers and builders.5
The difference between the business analyst and the systems analyst is that the systems analyst determines how technology can meet the needs of the business. The business analyst's analysis is independent from a specific technology and may not result in the development or purchase of a technology solution.
18.3 WHAT CAN THE BUSINESS ANALYST TEACH THE WAM-PRO?
Business analysts are involved in many general projects to support the impartial collection of requirements that are solution and vendor neutral. The analysis itself may be treated as a separate project, and the BA may support defining and scoping the project and implementing and verifying the selected solution. The BA will be the connection between business people and the technology people who know how to create and or implement technology to solve general business problems. A WAM-Pro would serve a similar role with WFM-specific problems. Like BAs, WAM-Pros should understand how to speak the language of the business as well as the language of technology. The BA should be able to interact with people from across organizations to effectively gather, document, and communicate business requirements and processes. Once requirements have been defined, the BA will also need to support the business in selecting the appropriate solution and to make sure the selected solution meets the business's requirements.
The business analyst is responsible for business problem solving. A WAM-Pro can follow these same general steps for WFM problem solving:
It is important to note that all analyses are not the same, and two business analysts may also document the analysis in a different manner. According to Barbara Carkenord, “business analysis work is complex, abstract, and dependent on current circumstances.” She goes on to explain that BAs will need to use “their problem-solving, communication, interpersonal, and teamwork skills and knowledge to tailor an approach to each new problem.”6 Organizations should seek a qualified and/or certified BA or WAM-Pro who selects or follows an acceptable methodology and creates documentation to capture the relevant business processes and requirements. The BA or WAM-Pro should be versed in project management methodologies; some are covered in Chapter 17.
A leading practice is to conduct the business analysis at the beginning of an upgrade or implementation effort. This is consistent with accounting requirements for Statement of Position 98-1, which provide guidelines for capitalizing and expensing costs related to internal software development and an industry standard life cycle, the systems development life cycle. Analysis work will occur, whether it is done at the very beginning of the project or during the course of the project. If analysis work is conducted while the project is in progress, it generally places the project at high risk of not delivering the needed quality. It is recommended that a detailed business analysis scaled to the needs of the company and the type of analysis be conducted before project work begins.
18.4 DOCUMENTS OF THE BUSINESS ANALYST
The BA will be required to read and to create multiple types of documents in the course of an analysis. If the analysis is organized and chartered like a project, the analyst will ideally have participated in creation of the project charter and initial work breakdown structure. If not, the analyst will need to review the project charter and work breakdown structure to become familiar with the analysis project.
The BA will create a requirements analysis document. This document can be based on a template that is already in existence within the organization or provided by an organization focusing on WAM. This document will start with introductory information about the analysis, including what is in and not in scope; certain parts of this document may overlap other types of project documentation such as the project charter. However, the requirements analysis document will expand the assessment as information is discovered, business processes are documented, and solutions are evaluated. The business requirements analysis document should include the following sections:
- An introduction (describes the project and the approach or methodology to be followed)
- Scope of the analysis
- Statement of purpose and objectives
- Problems and opportunities
- Business requirements, including functionality around rules, technical protocols, and stakeholder preferences
- Business and project risks
- Project assumptions
- Stakeholders from the affected departments
Once the analysis is in progress, the BA will need access to existing documents within the business to determine any problems and to analyze existing processes related to the WFM system. These documents might include historical timekeeping reports, specifications related to operational requirements, previous WFM analysis documents and diagrams if available, human resources and payroll policies, any handwritten tracking documents, compliance and audit reports, related industry regulations, and any other documents relevant to the existing workforce management system.
18.5 BUSINESS ANALYSIS PROCESSES FOR WFM REQUIREMENTS AND SOLUTION SELECTION
The following example is simplified and for illustration purposes only. Its similarity to any previous, existing, or planned project is coincidental and not intentional. Each analysis will be different, and this analysis is intended to illustrate a high-level business analysis related to a potential WFM upgrade or implementation. Anyone interested in conducting a proper business analysis is encouraged to review this chapter, continue to seek printed and online resources, and possibly consult with an experienced BA or WAM-Pro to provide at a minimum initial guidance in collecting analysis information. BA consultants are available to support small to large company efforts to conduct a full-scale, comprehensive analysis.
Our fictional analysis example will reference an in-home healthcare company called Personal In-Home Care (PIHC). PIHC has 300 full- and part-time employees that provide in-home healthcare support to clients that are elderly or clients that need long-term temporary healthcare support. Employees travel to client sites to provide services. PIHC has used a hosted solution for collecting employees' work hours, but with the emergence of several new technologies, the company would like to explore new features that would include mobile timekeeping, tracking employees' medical or care-giver certifications and expiration dates, and possibly GPS tracking to track mileage between client sites.
There are a few problems occurring with the existing system:
- Employees sometimes forget to clock in when they arrive at a client site.
- Workers have no way to report their location or client information when reporting time. That requires a separate paper process.
- Schedulers have assigned workers who have expired certifications.
- Clients have also indicated they feel they have been overbilled or billed for work employees did not complete.
PIHC's current application service provider has a solution that might meet its requirements, and PIHC wants to explore other options in the marketplace. Several departments in PIHC will be affected by a software change: accounting and finance, scheduling, human resources, information technology (IT), and payroll. The IT department has agreed to lead the analysis project because IT has two employees with business analysis skills. The project sponsor and members from all other departments will be involved in the analysis.
Introduction. The BA should document an introduction to the analysis and the approach the team will follow. The approach used by the PIHC project team to complete the analysis will include:
- An analysis utilizing the methodology developed by BAs in the information technology department at PIHC to define and to document the requirements as each business area is analyzed.
- Requirements will be documented using templates developed in products such as Microsoft Word and Visio.
- An in-depth analysis of the time and labor management function will be conducted as if all of the possible audience members were available to provide requirements.
- Findings and data will be benchmarked, analyzed, quantified, and visualized.
- Options and final recommendations from the analysis will be outlined.
Analysis scope. The project team should agree on what is being analyzed in the project and document the scope in the analysis document. For our example, the scope of the PIHC analysis consists of analyzing specific functions and data involved with time and labor tracking at PIHC.
Statement of purpose. The statement of purpose will outline the purpose of the project, its objectives, the problems the analysis should explain, and the outcomes the approach will deliver. The purpose and scope of the PIHC analysis is as follows:
PIHC currently uses On-The-Clock's timekeeping solution, Clocks-At-Work for timekeeping. It is a hosted solution, and On-The-Clock is the application service provider. Clocks-At-Work captures time via an Internet application (for employees in the main office) and telephony (for employees at client sites). Approximately 300 full- and part-time employees at PIHC use the system. New technology including mobile applications and GPS would reduce the issues with employees forgetting to clock in via telephone when they arrive at a client site. It could also allow for entry of task, certification, and client billing information. The purpose of the project is to analyze and document the problems with the current system and processes, to develop and document business and functional requirements to automate the processes, provide better data, and manage job assignments and certifications. The outcome will be to make a recommendation for a new solution.7
Objectives. Objectives are documented to clarify why the analysis is being conducted. Objectives of the PIHC analysis project include:
- Documenting the current processes and collecting data related to time and labor management as they exist today at PIHC.
- Redesigning existing processes for capturing employee time and activity data.
- Identifying functionality that can influence labor management and client satisfaction
- Documenting new processes as they should occur with a new system.
- Selecting and recommending a new time and labor tracking system.
Problems and opportunities. An analysis is conducted to determine problems with the current system, and problems can be turned into opportunities for the business to resolve the problems by correctly defining requirements. Table 18.1 shows some of the problems and opportunities documented in the PIHC analysis.
Table 18.1 Problems and Opportunities in the Example PIHC Analysis
| ID | Problems | Opportunities |
| 1 | Employees frequently forget to clock in using the telephone when they arrive at client sites. | Mobile devices can be used to track employee arrivals at client sites. |
| 2 | Manual time tracking sheets are used to collect time worked when employees forget to clock in. Paper is also used to report task or client information. Both are prone to error and potential fraud. | Employees will not be required to complete manual time tracking sheets if mobile devices track arrival times at client sites. Paycheck accuracy and consistency will improve with WFM automation and electronic audit trails. |
| 3 | Certification status is not accessible and often not up to date resulting in employees working without proper credentials. | Qualified personnel are deployed and service compliance and quality improve by reporting and enforcing staff assignment protocols. |
| 4 | Clients feel they have been billed for work that was not completed or overbilled for work that was completed. | Automated tracking will reduce or avoid overbilling of clients. Revenue will increase with greater customer satisfaction. |
Business risks. Business risks are possible problems that affect or may affect the business area that is being analyzed. This part of the PIHC analysis is focused on the risks for PIHC shown in Table 18.2.
Table 18.2 Example of Business Risk for PIHC
Project assumptions. An analysis should include a list of assumptions that are in place prior to and during the analysis. Assumptions for the PIHC analysis include:
- Subject matter specialists in each group will provide acceptable and timely feedback.
- Requirements documentation will be reviewed by appropriate stakeholders.
- The analysis will receive stakeholder focus to stay on time and within the schedule.
- The appropriate manpower will be provided as needed.
- Stakeholders are willing to change the way time and labor tracking functions are currently handled.
- The functions that are identified will not change in the short term.
- PIHC anticipates budgeting monies for future software purchase or upgrade.
- The business direction will not change in the short term.
- No external costs are associated with the analysis work.
Stakeholders. Stakeholders who are involved in the business area or participate in the processes should be listed in the stakeholders list. Individuals from the following groups and departments will be stakeholders in the PIHC analysis project:
- Employees in the main office and client support services
- Payroll and human resources departments
- Scheduling Functions
- Information technology department and business intelligence groups
- Accounting and finance department
Inputs, processes, outputs. A process takes one or more inputs, then transforms them into outputs that have value to a department or a person that needs the output. A business analysis should identify inputs, processes, and outputs and the departments and people who need to use the output. A few inputs, processes, and outputs for the PIHC analysis are outlined in Table 18.3.
Table 18.3 Inputs, Processes, and Outputs for the Example PIHC Analysis
| Source | Inputs | Outputs |
| Employees in the main office and client support services | Time worked Tasks performed and clients served |
Confirmation received |
| Operations managers | Certification credentials Schedules of client appointments |
Status of employee certifications Reconcile billing to schedule and timecards |
| Payroll | Manual time entry | Approved time worked |
| Human Resources | Compliance rules Schedule policies and goals |
Exception reports, productivity analysis |
| Information technology | User profiles | System performance, error logs |
| Accounting and finance | Client information and billing codes Financial targets |
Invoices, budgets, and revenue reports Client retention reports |
Processes. The following outlines one type of event to which PIHC must respond in the CURRENT STATE.
Context level dataflow diagram. Figure 18.1 shows a depiction of the sources, inputs, and outputs of the PIHC timekeeping system.
Figure 18.1 Context Level Data Flow Diagram
Business process requirements. Business process requirements outline the important processes and decompose them into smaller processes. These processes are performed within the analysis area and describe that work in detail.
Processes. The following processes are performed at PIHC:
Analysts may wish to create a decomposition diagram to graphically depict essential processes.
Process details. Processes need to be further decomposed into additional detail. The analyst may choose to add more details to further outline each process using supporting templates that are available from outside Workforce Asset Management (WAM) professionals and associations. One PIHC process (enter employee time worked) is outlined in more detail in Table 18.4.
Table 18.4 PIHC Process Questions and Sample Answers
| PIHC Process Details—CURRENT MANUAL PROCESSES | |
| Process ID number | 1 |
| Process name | Enter employee time worked. |
| Detailed description | Employee time worked must be manually entered if employees forget to clock in and/or out at the worksite. |
| Who is involved? | Employees |
| What causes the process to occur? | The manager forwards the accepted time sheet form to the payroll department. |
| What happens after the process is finished? | The time sheet form is filed for compliance reporting. |
| Business rules | Employees must complete the manual time sheet form, and managers must accept the form before it is entered into the timekeeping system. |
| Who performs this process? | Payroll department |
| How is the process performed? | The payroll person receives the accepted time sheet form and enters the employee's time into the timekeeping system. |
| How often is the process performed? | Weekly |
| How many occurrences of the process are completed? | 120 times a week |
| Who uses the output? | Payroll, human resources |
| How long does it take? | 10 minutes |
| Total time spent? | 120 times a week x 10 minutes per entry = 1,200 minutes, approximately 20 hours per week |
| Adapted from B2T Training. Essential Skills for the Business Analyst (Atlanta, GA: B2T Training, 2004), 108. | |
All the important processes should be documented using a methodology similar to Table 18.4.8
Documenting business information. For the PIHC example, a textual table will be used to capture some of the PIHC analysis information (see Table 18.5).
Table 18.5 PIHC Textual Details
Business information requirements. Multiple ways exist to capture business information requirements, and no one way is consistently desirable. One or more of the following techniques can be used to help the business analyst collect requirements:
- Conducting interviews and/or surveys with the involved areas
- Brainstorming with the involved areas
- Analyzing existing documentation
- Reverse engineering of the system
- Holding a requirements workshop
- Prototyping a potential solution
- Observing personnel at work
- Doing an interface analysis
- Conducting focus groups
Business information requirements may be captured in any of the following formats:
- Textual templates
- Entity relationship diagrams
- Decomposition diagrams
- Use case diagrams
- Work flow diagrams
- Swim lane diagrams
- Data flow diagrams
- Storyboards
- Object modeling
Depending on the business needs, several of the previous techniques and formats may be used to fully capture and document business information requirements. This information is necessary to conduct company business. Business information requirements translate to business problems and needs and should be thoroughly documented using techniques and formats that are acceptable to the BA and to the company conducting the analysis.
Business rules. Operational and policy conditions that govern the procedures, computations, and outputs are known as business rules. Business rules for our PIHC analysis might include some of the following:
- Each employee has one particular record in the timekeeping system.
- Paid time off is taken in one-hour increments.
- Supervisors must approve timecards weekly and employees must attest to the validity of their time record daily.
- Managers are responsible for collecting and maintaining proof of subordinate's current certification status and reporting expired credentials to human resources. HR updates the HRIS system.
- Overtime should be charged to the business unit where the work was performed with “borrowing departments” assuming the first overtime charges for the week, regardless of the day of the week when an employee works over 40 hours.
Technical specifications. Business rules are translated by the WAM-Pro into technology requirements that are documented in a technical specification (tech spec) document. This falls to the WAM-Pro or product specialist because he has the necessary technology knowledge to convert the business terms into technology verbiage that adequately describes the need. The tech spec is used for the timekeeping system to guide the application configuration developers in how to build the rules, profiles, and on-screen workspaces so that the system properly calculates paychecks, records used PTO, accrues sick time, integrates with attendance policies and scheduling processes, and provides credible business data among other requirements. Business rules in the existing system should be thoroughly detailed and documented in the tech spec. Failure to properly document business rules may result in the purchase and design of a solution that does not meet the business' requirements.
Tech specs are used in many disciplines such as engineering and programming. Often they include all aspects of form, fit, and function for the new product. Language in a tech spec is very precise and product neutral so that the spec describes only the function and not any particular product. Tech specs can be very lengthy and detailed when describing an entire system or brief when used for limited functionality. The tech spec focuses on the desired features for the new system and is architected to distinguish between must have critical requirements, nice to have essential requirements, and wish to have nonessential enhancements. They should be worded so that when used for scoring in the selection process or design work the answers are more yes or no than descriptive—leaving very little for interpretation.
The PIHC example concludes in this chapter with documenting business rules, but this is not the end of the analysis for PIHC. The WAM-Pro will want to continue to follow the methodology outlined by PIHC to fully detail and document PIHC's requirements. The business analysis will likely need project stakeholders, outside consultants, and WFM product specialists to review the prepared documentation and determine if requirements were defined properly. Adjustments may need to be made to the requirements before they are advanced to the next steps in the project or are used to begin a new project.
Example Technical Specification Outline for WFM Telephony System
- Scope. Establishes the general requirements for the design, development, production, testing, and implementation of the telephony system. Identifies the system's primary functions. Describes the functional specification, including critical and optional level capabilities.
- Applicable documents (data flow diagrams, punch import table layout, call flow diagram, telephony system main menu).
- Requirements
- System definition (fit). Interfaces and telephony system form and function. Describes how the system interfaces with other systems, how it will use a bank of phone numbers, what other functions the WFM telephony system might also support (e.g., surveys, benefit hotline, etc.).
- System characteristics. Performance, architecture, maintainability, redundancy, flexibility (skills required for customization), functional capabilities and capacity, system security.
- Reporting capabilities. Reports on line usage, transaction details, call statistics, administrative configuration reports, user data, automated number identification (ANI) data, and so on.
- Test and evaluation requirements
- General test requirements.
- Integrated test plan—including test verification categories,acceptance criteria, inspection verification, and so on.
- Delivery—hardware, software, and documentation/data package
- Documentation specifying the desired documents such as data field listings, table relationship diagrams, maintenance plans, troubleshooting guides, data flow and configuration diagrams, voice program documentation, services overview, user instructions, administrator guide, abbreviations and terms, and the printable version preferences of the documents.
- Periodic progress reports and milestone charts.
- Prepilot meetings, production and postinstallation meetings, and technical verification plans.
- Training and support
Creating formal business requirements documents is a leading business practice. Using multiple techniques to document those requirements will make sure that audience and subject matter expert (SME) needs are met with textual and graphical depictions of data and information flows. It is up to the WAM-Pros to understand the audience and subject matter advisors so that they can apply the appropriate techniques to fully capture and document the requirements. Stakeholders can help the WAM-Pro to determine how formally the requirements should be documented so that an appropriate requirements document is prepared.
18.6 KEY POINTS
Business analysis work involves the following:
- The BA will focus on analyzing business problems separate from technology.
- The systems analyst determines how technology can meet the needs of the business.
- The BA is the connection between business people and the technology people who know how to create or implement technology to solve problems.
- BAs will need to know how to follow multiple methodologies and how to use software tools for conducting an analysis.
- One of the most important documents the BA will create is the business requirements analysis document.
- Multiple analysis techniques exist that are flexible and support various types of analyses. Businesses need to decide on a repeatable process for conducting analysis work and plan to reuse that process each time an analysis is needed.
Leading practices for business analysis and project management recommend that the following attachments be included with the analysis project document:
- Glossary of terms. To completely define the departments, individuals that interact with the system, acronyms, regulatory agencies, and so on, that are involved with, interact with, or use outputs from the business area.
- Problems and issues log. To track problems and issues related to the analysis project. This keeps stakeholders and analysis participants informed of problems, issues, and resolutions.
- Work breakdown structure. A detailed worksheet to track the analysis schedule and tasks to be sure they are completed on time and within the budget.
NOTES
1. The International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge (BABOK Guide), v. 2.0 (Ontario, Canada: Author, 2009). PDF. Page 3.
2. Barbara A. Carkenord, Seven Steps to Mastering Business Analysis (Fort Lauderdale, FL: J. Ross Publishing, 2009), 2.
3. Ibid.
4. J. L. Whitten, L. D. Bentley, and K. C. Dittman, Systems Analysis and Design Methods, 5th ed. (New York: McGraw-Hill, 2000), 9.
5. Carkenord, Seven Steps to Mastering Business Analysis, 2.
6. On-The-Clock and Clocks-At-Work are fictional service providers and products.
7. B2T Training, Essential Skills for the Business Analyst (Atlanta, GA: B2T Training, 2004), 108.
8. This chapter was contributed by Natalie Sword.