Person demotivated by evaluation - Fault tree analysis diagram

"Subjective performance evaluation allows the use of a subtler, more balanced assessment of employee performance, and is typically used for more complex jobs where comprehensive objective measures are difficult to specify and/ or measure. Whilst often the only feasible method, the attendant problems with subjective performance evaluation have resulted in a variety of incentive structures and supervisory schemes. One problem, for example, is that supervisors may under-report performance in order to save on wages, if they are in some way residual claimants, or perhaps rewarded on the basis of cost savings. This tendency is of course to some extent offset by the danger of retaliation and/ or demotivation of the employee, if the supervisor is responsible for that employee’s output. ...
Another problem relates to what is known as the "compression of ratings". Two related influences—centrality bias, and leniency bias—have been documented ... The former results from supervisors being reluctant to distinguish critically between workers (perhaps for fear of destroying team spirit), while the latter derives from supervisors being averse to offering poor ratings to subordinates, especially where these ratings are used to determine pay, not least because bad evaluations may be demotivating rather than motivating. However, these biases introduce noise into the relationship between pay and effort, reducing the incentive effect of performance-related pay. ... this is the reason for the common separation of evaluations and pay, with evaluations primarily used to allocate training.
Finally, while the problem of compression of ratings originates on the supervisor-side, related effects occur when workers actively attempt to influence the appraisals supervisors give, either by influencing the performance information going to the supervisor: multitasking (focussing on the more visibly productive activities...), or by working “too hard” to signal worker quality or create a good impression...; or by influencing the evaluation of it, e.g., by "currying influence"... or by outright bribery..." [Principal–agent problem. Wikipedia]
The example "Person demotivated by evaluation - Fault tree analysis diagram" was created using the ConceptDraw PRO diagramming and vector drawing software extended with the Fault Tree Analysis Diagrams solution from the Engineering area of ConceptDraw Solution Park.

The FTA diagram sample "Fault tree analysis - Insulin delivery system" was redesigned from the illustration of "CMSI 641: Introduction to Software Engineering. Design of Critical Systems. B.J. Johnson. 2005. Loyola Marymount University".
"Another way of assessing hazards is using fault tree analysis. In this process, each of the identified hazards is covered by a detailed analysis to find out what might cause it. Either inductive or deductive reasoning is applied. In the case of software hazards, the usual focus is to determine faults that will cause the system to fail to deliver a system service, such as a monitoring system. A "fault tree" is constructed to link all the possible situations together, to help identify the interrelationships of the failures, which modules may cause them, and what "trickle-down effects" there might be. Here is an example of a fault tree, as applied to the Insulin delivery system from Sommerville...
Note that this tree is only partially complete, since only the potential software faults are shown on the diagram. The potential failures involving hardware, such as low battery, blood monitor or sensor failure, patient over-exertion or inattention, or medical staff failure are noticeable by their absence.
The fault tree and safety specification processes are two ways of helping with system risk assessment tasks. Once the risks are identified, there are other assessments that need to take place. First, the likelihood of the risk occurrance must be assessed. This is often quantifiable, so numbers may be assigned based on things like MTBF, latency effects, and other known entities. There may be other non-quantifiable contributors to the risk likelihood, however, such that these must be assessed and estimated by experts in the domain. (Don't short-change this process when dealing with critical systems!) Finally, the risk assessment must include the severity of the risk, meaning an estimation of the cost to the project in the event the risk item actually does occur. "Cost to the project" means all associated costs, including schedule delays, human injury, damage to hardware, corruption of data, and so on."
[myweb.lmu.edu/ bjohnson/ cmsi641web/ week15-2.html]
The FTA diagram example "Fault tree analysis - Insulin delivery system" was created using the ConceptDraw PRO diagramming and vector drawing software extended with the Fault Tree Analysis Diagrams solution from the Engineering area of ConceptDraw Solution Park.