Focus groups consist of a sample of people representing a larger population who gather together to discuss a topic; in this case, the topic would relate to the HRIS. Focus groups are important because they can provide as deep of information as interviews, but it has the added advantage of bringing people together, which can lead to greater and more effective information sharing than if only interviews were utilized. Participants in focus groups are asked for their opinions and attitudes, and the results can help to shape system requirements. Although it can seem challenging to pull together the perfect combination of people at the same time, small discussion groups such as these may uncover needs not previously found and help the analysts identify new requirements. Recommendations for effective focus groups include the following:
• Limit the size of the group to no more than 8 to 12 people.
• Allow sufficient time to cover the material, generally one to two hours, and keep the meeting focused to make good use of everyone’s time. Consider having a moderator to keep the
meeting focused.
• Before starting the focus group, explain the objectives clearly.
• Encourage group members to speak freely, and ensure that everyone participates. An icebreaker exercise can be a great way of opening up group communication.
• Use a variety of group facilitation methods, such as brainstorming, prioritizing, and consensus building to encourage and promote discussion on differences of opinion and to clarify issues.
• Take notes and/or video or audio tape the session, so that nothing is lost.
• Thank participants for their time and ideas.
4. Evaluation
Several activities occur during the evaluation stage of needs analysis. Once the data have been collected, they must be reviewed and assessed to create a clear picture of the current and desired processes, data sources, and issues. Next, the data should be arranged in a format useful for the next phase of the SDLC:
design. Third, the data should be reviewed by the project team to gain additional perspective and
encourage suggestions, noting any duplications or omissions. For example, consider whether data must be collected and stored in the new system or if it could be calculated from data already in the system. For example, if employer-paid life insurance is twice an employee’s annual salary, there is no need to store that value in the system, as it can simply be calculated from the existing salary data. In addition, it is important to consider how other areas of business interface with human resources and how HR data may come from, and be sent to, other systems. As an example, production or sales data may be used by HR as part of a performance appraisal or compensation process, but they would likely be provided from a non-HR module or system.
There are several ways of assessing and analyzing the system data, functions, and processes, and these may be organized in any way that assists in this process. For example, visual representation of priorities may be displayed in check sheets, graphs, Pareto charts, flowcharts, or data flow diagrams to support and summarize the analysis. When this information is organized, it can then be prioritized according to, for example, the time when it must be present or the level of importance, as shown below. The prioritization method is up to each organization.
Priority Description
1 Must be present at implementation
2 Must be present within six months of implementation
3 Nice to have, but not essential
4 Not needed in the near future, but may be needed due to environmental changes
Importance Description
1 Mandatory
2 Strongly desired
3 Nice to have
The result should be an operational depiction of the HR system needs, including a visual representation and descriptive text that lists the particular processing required to support each function. These documents will serve as the primary reference for the remainder of the project, and they also serve as a key
communication tool for HR staff, consultants, vendor representatives, and technical staff. For example, given that no organization has unlimited budget to implement all functionality desired by the organization, prioritizing ensures that the most important functionality will be given first focus. In fact, for many
projects, desired functionality will often have to be eliminated because of budget or time constraints.
5. Reporting
The final stage of the needs analysis process, reporting, involves preparing a report that summarizes the findings and presents recommendations for the design phase. The final report should include an overview of the current systems and processes, along with a description of how a new system could address the issues and weaknesses with which the function deals. This report should contain the formalized
requirements definition, the document that lists each of the prioritized requirements for the new system.
The requirement definition can include specifications geared toward solving problems identified in the analysis as well as any that focus on new functionality that HR requires in the new system. These
requirements should be written in such a way that when the new system is tested, each requirement can be verified as being met.
Although the report can be, and often is, viewed as a sales presentation to management and other constituents that presents a business justification for continuing the project, it is also a roadmap for
moving forward. The report becomes the basis upon which the new system will be designed. There is no standard format for the requirements report. Instead, the format will depend on the intended audience and corporate and/or information technology reporting standards. A potential outline for the report is shown in Figure 4.4. The written report is generally accompanied by an oral presentation where stakeholders can ask questions and receive additional information about the project.
Figure 4.4 Sample Report Outline
1. Executive Summary 2. Project Background
2.1. Project Initiation 2.2. Project Charter 2.3. Project Scope 2.4. Project Team
2.5. Steering Committee 2.6. Project Schedule 3. Current Systems
3.1. Description
3.2. Components and Functions
3.3. Interfaces
3.4. Strengths and Weaknesses 4. General Operational Requirements 5. Functional Requirements
5.1. Function 1
5.1.1. Function 1 Description 5.1.2. Function 1 Requirements 5.2. Function 2
5.2.1. Function 2 Description 5.2.2. Function 2 Requirements 5.3. Etc.
6. Information Technology Requirements 7. Support Requirements
8. Next Steps 9. Appendices
SUMMARY
Organizations faced with the need to update, upgrade, or implement changes to HR processes and to consider new software should follow a formalized, structured process to give them the best chance to succeed. In this chapter, we briefly introduced this structured process: the systems development life cycle that helps organizations better manage the design and implementation of new or upgraded systems.
The chapter further focuses on the analysis phase of the SDLC, particularly on the needs analysis portion of this phase. Needs analysis is designed to help the organization discover the disparity between the organization’s present HR system(s) and desired HR systems. The chapter outlines an effective, formal, multistaged approach that starts with naming the project team, reviewing current processes and systems, and determining future needs and priorities. The resulting requirements
definition can provide the ongoing project team responsible for vendor evaluation and/or system design with a clear picture of what the organization requires and when it must be delivered. It establishes the structure for future phases of this project, as well as a framework for ongoing operations. Needs analysis can, therefore, rightfully be viewed as one of the most critical to the success of the entire project.
KEY TERMS
adaptive maintenance
analysis phase
corrective maintenance design phase
evaluation exploration focus groups
implementation phase interviews
maintenance phase needs analysis
needs analysis planning observation
perfective maintenance performance gaps planning phase
preventative maintenance questionnaires
reporting
requirements definition
SDLC (systems development life cycle) stakeholders
DISCUSSION QUESTIONS
1. What are some critical success factors for effectively conducting an analysis of HRIS needs?
2. Explain how planning and analysis integrate and inform further steps in the systems development life cycle (SDLC).
3. Compare and contrast the different methods of data collection, explaining the conditions under which each is most effective.
4. Which prioritization method is most useful in establishing the appropriate values for system requirements, and why?