Personal Development Plan
Concrete development goals built from the gaps surfaced by the Skills Matrix, with the actions that will achieve them, resources required, success measures and target dates.
The PDP is the actionable counterpart to the Skills Matrix. For every gap the matrix surfaces (between baseline and end-of-module position), the PDP records what I will do about it, by when, and how I will know I am done.
The PDP is updated at module start and at module end to reflect what was achieved during the module and what remains as ongoing work.
| What I want / need to learn | Why | How (action) | Success measure | Target review |
|---|---|---|---|---|
| Workstream architecture that genuinely distributes the project’s centre of gravity, not just its boundaries | IA and Track 1 both ended with role concentration on me; the design split alone is insufficient if execution capacity is unbalanced | In the next group project, match scope to availability before committing the brief; consider sequencing tasks so the project lead is not on every critical path | Workload distribution within plus or minus 20 percent across team members; no single member on the critical path of every phase | End of next module |
| Generative-AI usage practices for ML projects | The Machine Learning module dropped the AI-declaration and restriction regime present in earlier modules. Worth establishing my own personal practice for transparency rather than relying on a programme-level rule | Document my own AI-usage transparency convention, even when not required by the module; carry it into professional projects | A consistent personal AI-usage statement across modules and into professional practice | Next module |
| Deeper feature engineering beyond the module’s seminar pattern | Track 1 stayed within the Unit 2 seminar encoding pattern (numeric mapping). One-hot encoding, target encoding, and feature interactions are common in production ML | Explore one-hot vs numeric encoding sensitivity on a separate dataset; read Heaton (2016) and Duboue (2020) end-to-end | Comparative analysis on at least one personal project | Within 3 months |
| ML deployment and monitoring (post-CRISP-DM Phase 6) | Track 1 stops at Communication / Deployment as a report. Real ML deployment includes monitoring, drift detection, A/B testing | Read Loukides (2021), Gama et al. (2014); experiment with a deployed model on a personal project | A small deployed model with drift-monitoring | Within 6 months |
| Causal inference techniques beyond observational regression | Multiple Track 1 limitations bullets (Leetaru, 2019; Chernozhukov, 2024) acknowledge correlation versus causation. Worth investing in actual causal inference methods | Read Chernozhukov (2024) end-to-end; complete a short causal-inference course | A demonstrable causal claim in a portfolio piece | Within 6 months |
| Extending the three-tier justification framework into professional practice | The framework structurally interrupts “just-because” reasoning that is common in commercial decisions. Track 1 demonstrated its value in academic work; worth porting into delivery contexts | Apply the framework on the next two professional decision documents I author; refine the tier definitions if patterns emerge | Two professional decision documents using the framework, reviewed for clarity by a peer | Within 3 months |
| Strengthen literature-grounded data-cleaning rationale | Track 1 demonstrated that anchoring each cleaning rule to a citation is a defensive multiplier; worth building deeper familiarity so future cleaning specifications can be anchored as a matter of habit, not as a one-off effort | Continue building familiarity with the cleaning literature (Tukey, Patil, Harmadi, Brownlee); maintain a personal annotated bibliography of go-to citations for the common cleaning patterns | An annotated bibliography of at least 10 frequently-cited cleaning patterns, with notes on when each applies | Within 3 months |
| Build a personal artefact-design checklist for handovers | The Track 1 cleaning-script-alongside-Word-brief is a representative example of designing handover artefacts for the actual recipient and tool chain, not for an idealised reader. Codifying the discipline makes it portable | Produce a short, reusable list of questions: who is the recipient, what tool chain will they use, where is the failure mode, what is the cheapest countermeasure; apply on the next two handovers | Checklist authored and applied on at least two handovers in the module; refined based on what the handovers surface | Within 3 months |
| Develop the project-management voice further | The Coordinator role demonstrated value in this project; continuing to develop project-management literacy extends the toolkit beyond the ad-hoc patterns I have used so far | Read on RACI matrices, dependency mapping, meeting cadence design; apply at least one of these formally on the next project | A RACI matrix or equivalent dependency map produced and used for the next project | Within 6 months |