Step 5: Validate Responses

Purpose: This step has been included to act as a fail-safe to ensure that quality data is entered into the repository.

Summary: As was explained in the previous steps, the questionnaire will comprise of two sections. The first section will gather personal or descriptive information about the employees while the second section will collect their data presentation preferences. Although employees will be guided through the questionnaire, there are still opportunities for the wrong data to be recorded.

Potential problems which may occur as well as possible solutions to restrict the effects of those problems are subsequently discussed.

Problems in section collecting personal information:

In the section of the questionnaire where employees are required to indicate descriptive information which will be used to create clusters, spelling mistakes can occur or wrong information can be filled in mistakenly. If designers try to form clusters using information which is encoded incorrectly, the preferences of those employees with erroneous information will be ignored by the framework. This can be avoided if the section collecting personal information is designed so that employees have to choose a single option out of a list showing all the possible options. For example, if an employee has to indicate his or her de- partment, a list containing all of the departments in the organisation can be provided in the questionnaire with boxes next to them that can be marked if the employee belongs to that department. This will eliminate spelling mistakes and will ensure that the responses provided by users are usable and compara- ble.

There are two possible disadvantages to this approach. Firstly, the de- signer of the questionnaire might not consider all the possible departments to which an employee can belong. Secondly, the list of options might be inap- propriately long. For example, consider a situation where the framework is implemented at all of the departments in a government. Including a list of all possible departments would be impractical and place unnecessary additional strain on an employee completing the questionnaire. If the information can be recorded electronically, cascaded drop down lists can be used to dissect large lists into several smaller options which follow on from each other. A typical use of cascaded drop down lists is on websites of second hand car dealers. In- stead of providing customers with a long list of all the available cars, customers are asked to answer certain questions to narrow down the number of choices until only a few cars remain. For example, customers might first be asked to fill in the manufacturer, then the year, then the model to find the car they are looking for. By using these three attributes of the car, a very long list of possible cars can be reduced to a shortened list only containing cars similar to the one the customer is looking for. Using the same approach, a designer can drastically reduce the list of all the departments in an organisation by merely providing a few identifying attributes.

If the wrong information is filled in deliberately (for whatever reason), the questionnaire cannot be designed to prevent it. One solution would be for someone with enough knowledge of the employee to be present while the section pertaining to the employee’s personal information is filled in. Another, more ideal solution would be to link the Database Management System (DBMS) in

which the employee preferences are stored (see Step 6) to the organisation’s HRIS. This will prevent employees from entering wrong information and will ensure that the information stored in the preference database is in agreement with the official information stored by the HR department. Even if the em- ployee preferences are not stored in a database, it would still be beneficial to obtain and use as much of the information from HR as possible.

Problems in section aiming to collect employee preferences:

The second opportunity for wrong data to be recorded is in the section where employee preferences for the various task codes are determined. Ta- ble 3.6 describes how the primary and secondary preferences for each task should be indicated as well as how an employee can show that a presentation format should be avoided. The following four rules summarise instructions for each task code:

1. A primary preference is compulsory and should be indicated one time only.

2. A secondary preference is compulsory and should be indicated one time only.

3. A presentation format not indicated as a primary or secondary preference can either be left blank or marked to be avoided.

4. A particular presentation format cannot have more than one choice as- signed to it. In other words, each presentation format should be indicated as either a Primary preference (P), Secondary preference (S), Avoid (A) or left blank.

Should any of the four rules be broken by an employee, the data stored in the repository will not be accurate. If more than one primary choice has been indicated for a task or if it has been omitted altogether, the framework will not provide the designer with an appropriate recommendation when reporting data to that respective employee. Although more than one primary prefer- ence improves the odds of a designer choosing a presentation format which the employee prefers, the chosen format will ultimately still be determined by the designer and not the receiver of the information. In the case where no primary preference has been indicated, the designer will be forced to use the secondary preference. However, the secondary preference might indicate a format which the employee will be least dissatisfied with if the primary preference cannot be used.

The same is true if more than one secondary preference has been indicated or if it has been omitted altogether. If a single primary preference has been

indicated, having more than two or no secondary preferences will not affect the recommendations made by the framework if it is applied to a single employee (as only primary preferences are considered). Nevertheless, the wrong amount of secondary preferences will influence the recommendations of the framework if it is applied to a cluster of employees as the results will be biased.

Finally, the last possible problematic outcome is when a presentation for- mat is indicated as being more than one of either P, S or A. Although there might be means to narrow down and identify the possible mistake(s), it would be in violation of the framework’s requirement to be structured (see Sec- tion 3.1.2) as different report designers might use different reasoning and logic to identify the mistake(s). Consequently, if a task contains a presentation for- mat which has been indicated as being more than one of either P, S or A, the responses for the entire task will be disregarded.

By collecting the preferences electronically, the four rules can be set as conditions that need to be satisfied before a response can be saved. For exam- ple, if an employee has indicated one primary preference and tries to indicate another for the same task code, an error message can warn an employee that there can only be one primary preference per task code. Notice that, by col- lecting the information in both sections of the questionnaire electronically with predefined conditions for each section, the collection of invalid or faulty data can be reduced substantially.

Failure by any employee to adhere to the four rules mentioned above will require that employee to undergo Step 4 an additional time (or until all rules have been adhered to). However, it should be noted that only the tasks that were problematic would have to be readdressed. It has also been explained that this step will be redundant if the information can be collected electron- ically with conditions governing the possible user responses. Once all of the responses to the different task codes have been deemed valid, the information should be stored in a repository.

The combination of primary and secondary preferences as well as the for- mats which the employee would like to avoid should receive a status of uncon- firmed upon entry into the repository in the next step of the framework. Value proposition: Including this step will ensure that the data entered into the repository is in the correct format and that it satisfies all the con- straints. This step will also prevent errors in the application phase of the framework.