◇ OpenCyber Academy
Technical · Chapter 18 · English

Chapter 18 — Supervised technical project

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 18 — Supervised technical project

Lesson map

Lesson 18 published. Map, example, EX052.

flowchart TD
  N0["Learning outcomes"]
  N1["18.1 Project choices"]
  N2["18.2 Plan"]
  N3["18.3 Execution"]
  N4["18.4 Report and handover"]
  N5["18.6 Hands-on activity"]
  N6["18.7 Reflecting on the project"]
  N7["18.9 Assessment"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX052"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["18.1 Project choices"]
  N2["18.2 Plan"]
  N3["18.3 Execution"]
  N4["18.4 Report and handover"]
  N5["18.6 Hands-on activity"]
  N6["18.7 Reflecting on the project"]
  N7["18.9 Assessment"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX052"]

[Learning outcomes]
    |
    v
[18.1 Project choices]
    |
    v
[18.2 Plan]
    |
    v
[18.3 Execution]
    |
    v
[18.4 Report and handover]
    |
    v
[18.6 Hands-on activity]
    |
    v
[18.7 Reflecting on the project]
    |
    v
[18.9 Assessment]
    |
    v
[Worked example] --> [Exercise EX052]

Learning outcomes

You will (1) plan and complete a supervised operations project; (2) apply checks, configuration, verification and documentation end to end; (3) report results with evidence; and (4) hand over to the team.

18.1 Project choices

Examples: enable and verify hybrid key exchange on one service in staging and production under supervision; build the negotiated-group dashboard for a set of services; write and test runbooks for post-quantum failure modes; build the CBOM for one property.

At HHG, the channel SFTP project in the worked example below is a typical choice. Pick a project small enough to finish under supervision, with a clear way to verify its result, and agree it with your supervisor before starting. Write down the expected result.

18.2 Plan

Scope and authorization; steps with evidence for each; risks and rollback; timeline; supervisor checkpoints.

Write the plan on one page. Name the scope reference, list steps with the evidence each will produce, state risks and the rollback for each change, and set dates for supervisor checkpoints. For the channel SFTP project, that includes the staging upgrade, client tests, the production ticket and the partner notice. Get written approval before starting. Revise the plan if scope changes. Keep the approved plan with your evidence.

18.3 Execution

Follow change control; save evidence; verify from both sides; update documents. Ask for help early when blocked.

Keep a dated log of what you did and what evidence was saved. At HHG, the channel SFTP project followed change control for the production change and verified from both client and server sides. Update runbooks and the dashboard as you go, not at the end. If a step fails, stop and record it before trying again. Record any deviation from the plan.

18.4 Report and handover

Report: aim, what was done, evidence, results, remaining issues and recommendations. Handover: runbooks, scripts, dashboards and the list of open items, each with an owner.

At HHG, the channel SFTP handover to Network Ops listed the four agencies as open items. Check that every open item has an owner and a date before handover, and ask the receiving team to confirm they accept each one. Keep the report factual, and include the evidence behind every result. Keep a copy with your project evidence.

18.5 Worked example

Project (synthetic): "Hybrid SSH for channel SFTP." Steps: upgrade OpenSSH in staging; configure KexAlgorithms; test six agency client types; production change under ticket; verify; dashboard panel for KEX share; runbook for "no shared group"; partner notice. Results: 5 of 9 agencies hybrid after a month; four on notice. Handover to Network Ops with open items for the four agencies.

The project produced lasting results: configuration, a dashboard panel, a runbook and a partner notice. The handover makes clear who follows up the four agencies.

18.6 Hands-on activity

Write your project plan and get it approved by your supervisor.

Use the plan format: scope reference, steps with evidence, risks and rollback, timeline and supervisor checkpoints. Pick a project from the examples, or propose one of similar size. Keep it to one page. Ask your supervisor to review it, record their comments and how you addressed them, and keep the approved version with your project evidence. Revise it once after feedback. Note which project you chose and why it fits the time available.

18.7 Reflecting on the project

Finish with a short reflection: what went as planned, what surprised you, which skill you used most, and what you would do differently. Share it with your supervisor; it is often the most useful input for the next trainee's project.

Keep it short and honest, with examples. At HHG, a reflection on the channel SFTP project might note that four agencies needed longer than expected and that earlier partner contact would have helped. Write it soon after finishing, while the details are fresh.

18.8 Common errors and limits

Each error undermines the project. Starting without approval puts changes outside scope and can end your authorization. A report without evidence cannot show what was achieved, however well the work went. A handover without owners leaves open items, such as the four agencies on old clients, with nobody to follow them up. Check your project for all three before presenting it. Correct any you find. Note any fix in the report.

18.9 Assessment

Your supervisor will assess the project on: staying within scope; quality of evidence; correctness of configuration (hybrid preferred with controlled fallback); verification from both sides with a negative control; usefulness of the documentation; and the handover. Before the assessment, check each item yourself and link the evidence. Being able to show where each piece of evidence lives is part of the skill being assessed.

Finally, present the project to your team in ten minutes: the problem, what you changed, the evidence, what remains and who owns it. Short, factual presentations of completed work are how operators build trust with the teams whose systems they change.

Exercises

Synthesis

A supervised project puts every hands-on skill together — scope, configuration, verification, documentation and handover — and leaves the team better equipped.

Continue studying — chapter 18 of 18

← Chapter 17 (draft) · Course chapter index · Worked results ↓ · Next course via chapter index →