Chapter 28 — Human factors and cyber policy: implementation I

Lesson map

Lesson 28 published. Map, example, EX082.

flowchart TD
  N0["Learning outcomes"]
  N1["28.1 Implementation"]
  N2["28.2 Managing change"]
  N3["28.3 Launch and support"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX082"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["28.1 Implementation"]
  N2["28.2 Managing change"]
  N3["28.3 Launch and support"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX082"]

[Learning outcomes]
    |
    v
[28.1 Implementation]
    |
    v
[28.2 Managing change]
    |
    v
[28.3 Launch and support]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX082]

Learning outcomes

You will (1) implement the reporting button and feedback service; (2) manage organisational change; (3) launch with staff support.

28.1 Implementation

Aiko joins Greyford's IT team to implement the reporting service. They configure the email platform's report button on desktop and mobile, connect it to the triage tool, set up automatic thank-you messages and create templates for verdict messages. They test each path with synthetic emails before launch. They also set up the aggregate dashboard and remove the individual export, as planned in chapter 22. Implementation follows the requirements from chapter 21, which provide a checklist for acceptance. Each test result is logged with the date and the tester, so that later changes can be checked against the same paths and nothing is assumed to still work.

28.2 Managing change

Aiko knows that new processes fail when people do not understand why they exist. She writes a short explanation for staff: why reporting matters, what happens to reports and the promise that nobody is blamed for clicking. She briefs team leaders first so they can answer questions. Staff representatives co-sign the announcement. She avoids fear-based messages, which Bada, Sasse and Nurse (2019) identified as a reason campaigns fail, and focuses instead on how reporting protects colleagues and the public. Team leaders also receive a short list of likely questions with suggested answers.

28.3 Launch and support

The service launches on a Tuesday, avoiding Mondays when email volume is highest. Aiko staffs a help channel for the first two weeks and records questions. Most concern whether to report newsletters and supplier invoices. She updates guidance to say that unexpected invoices should be reported, while known newsletters can be ignored. Reports in the first week triple compared with the previous email address used for reporting, and the thank-you messages work on both desktop and mobile. The help channel log becomes the first source for the frequently asked questions page published a month later.

Worked example

Aiko implements reporting and feedback, manages change through team leaders and co-signed messages, and launches with a help channel.

Synthetic case. Implementation details and figures are synthetic; Bada et al. (2019) is real.

Errors and limits

Launch spikes may fade. Help channels need staff time.

Exercises

• EX082 — Acceptance checklist. What served as the acceptance checklist?
  Show marking criteria

  Rubric: 3 = the requirements from chapter 21;; 2 = requirements;; 1 = vague;; 0 = none.
• EX083 — Avoided message. Which message style did Aiko avoid?
  Show marking criteria

  Rubric: 3 = fear-based messages;; 2 = fear;; 1 = vague;; 0 = none.
• EX084 — Common question. What did most early questions concern?
  Show marking criteria

  Rubric: 3 = whether to report newsletters and supplier invoices;; 2 = newsletters;; 1 = vague;; 0 = none.

Synthesis

Implementation succeeds when technical setup is matched by clear, non-fear change management and early support.

Continue studying — chapter 28 of 50

← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →