--- title: "Project Management for the Unofficial Project Manager — Kogon, Blakemore & Wood" section: "Book Notes" sectionId: "book-notes" date: "2026-05" --- *Notes by Nicholas Tickle. The core argument: everyone is already a project manager — the question is whether you're a good one.* 45% of projects are either overdue or cancelled altogether. The authors' answer is not more formal methodology but better leadership and four foundational behaviours. --- ## Why Projects Fail - Lack of commitment or sponsorship - Unrealistic timelines or resources - Too many competing priorities - Unclear outcomes and expectations - People pulled away mid-project - Poor planning and lack of leadership - Scope creep and changing standards - Lack of or mismanaged budget --- ## Leadership Comes First Project management is fundamentally about leading people, not managing tasks. - People want to be part of something that mattered — they follow for the journey - You cannot push people to do better; they must volunteer their best efforts, and you must be their inspiration - Informal authority is more powerful than a title — it makes people *want* to play on your team - Get to know your team. Share what motivates and inspires you. Create a sense of shared purpose - Good project managers admit mistakes — which is why you so rarely meet one --- ## The Four Foundational Behaviours 1. **Demonstrate respect** — treat people as capable contributors 2. **Listen first** — understand before directing 3. **Clarify expectations** — ambiguity is the enemy of execution 4. **Practice accountability** — hold yourself to the same standard you hold others --- ## The Five-Phase Process | Phase | Core question | |---|---| | **Initiate** | What exactly are we trying to achieve, and for whom? | | **Plan** | What could go wrong, and what does the schedule look like? | | **Execute** | Are people moving and staying accountable? | | **Monitor & Control** | Are we on track, and how do we handle changes? | | **Close** | Did we deliver, and what did we learn? | --- ## Initiating Without a clear and shared picture of the outcome, the project is doomed. Front-loading clarity is a basic principle of project success. **Questions to answer before anything else:** - Who will this project impact? - Who determines success, and what are their expectations? - What are the project's constraints and limitations? - How do we create a shared understanding of the outcome? **Steps:** 1. Identify *all* stakeholders — brainstorm with others so you don't miss anyone 2. Identify the *key* stakeholders — anyone who determines success or failure 3. Interview key stakeholders early and thoroughly; understand their unique perspectives and desired results **Write a scope statement** covering the why, what, when, and how. It describes what success looks like and explicitly states what is and is not in scope. Draft it, review it, get approvals. --- ## Planning ### Risk Management Assess risk *before* building the schedule — it will shape every timeline and resource decision. - Score each risk: **Impact (1–5) × Probability (1–5) = Risk score** - Risks scoring **12 or higher** require a mitigation strategy - For each high-scoring risk, choose one response: **Transfer**, **Accept**, **Mitigate**, or **Eliminate** - Be honest with stakeholders about high-scoring risks — accountability demands transparency ### The Project Schedule The schedule should be visible, constantly updated, and open to every team member. **Build it in this order:** 1. **Work Breakdown Structure (WBS)** — list every deliverable and its component tasks 2. **Sequence activities** — map dependencies (finish-to-start, start-to-start, finish-to-finish) 3. **Identify the project team** — assign the right people, not just whoever is available 4. **Estimate task durations** — duration is calendar time, not pure effort. If you can only spend 1 hour/day on a task, an 8-hour task takes 8 days. Add float; don't promise what you can't deliver. Don't make durations too long either — people fill the time allocated (Parkinson's Law) 5. **Identify the critical path** — the sequence of tasks that determines the project's end date. Put your best resources here. Non-critical-path tasks have "slack" or "float" — those people can be redeployed if the critical path falls behind 6. **Create milestones** — especially for long tasks, to maintain visibility and accountability 7. **Create the budget** — add 10% for contingency; disclose this to key stakeholders *Ways to estimate duration: draw on experience, ask for a reference, consult an expert, or use the PERT formula.* ### Communication Plan Determine who needs what information, when, how, and from whom. Most stakeholders want to know project status and how they can help. Know each stakeholder's preferred communication style — it's another way to mitigate risk. If you don't keep your own communication commitments, you give others permission not to keep theirs. --- ## Executing ### Lead with Accountability Keep your own commitments with precision — this is how you earn the right to hold others accountable. - Every request, every commitment, every missed deadline matters - Your job is not to manage people but to help them manage themselves — "clear the path" for them - Don't let people miss commitments without consequence; if you do, even reliable team members start to slip ### Weekly Accountability Sessions (~30 minutes) Run short, focused weekly huddles — not another meeting, but a cadence of visibility: - Review the schedule and budget: are we where we should be? If not, why not? - Surface blockers and agree on how to clear them - Each team member reports on last week's commitments and makes new ones - The whole team sees the project as a whole — no one feels isolated This cadence produces reliable results *and* builds a high-performance team. ### Performance Conversations If someone consistently misses commitments, address it directly — either one-to-one or in front of the team, but the team needs to see it being handled. Frame conversations around outcomes, not character. ### Positive Feedback When giving positive feedback, state: 1. **Intent** — why you're having the conversation 2. **Facts** — exactly what they did 3. **Impact** — the effect it had on results This gives people everything they need to replicate the good work. --- ## Monitoring & Controlling Good control reveals problems early — which means you have more time to solve them. ### Stakeholder Communication - Drive progress through transparent communication — no sugar-coating - Deliver bad news early; don't wait until it's unrecoverable - The status report should be an "at a glance" document: are we winning or losing? - Sometimes a stakeholder can unlock something with a stroke of a pen that you can't do alone **Always bring ideas for solving your problems** — never arrive with a problem and no proposed solution. ### Managing Scope Creep Anything that can be changed *will* be changed, until there is no time left to change anything. Managing scope change means: 1. Influencing the factors that create changes before they become formal requests 2. Recognising when a scope change has occurred 3. Managing changes systematically when they do happen For every proposed change, ask: What is the intent? What is the impact? What would it take to implement? Communicate change orders to key stakeholders throughout the project, not just at the end. Small changes accumulate — treat them seriously. **Scope creep vs scope discovery:** sometimes the scope *must* change because new information has made the original scope statement inadequate. That is legitimate — the process is the same, but the reasoning is different. The better you scope the project upfront, the easier it is to monitor and control. Nearly all project problems are people-related — you can't control people, but you can influence them. --- ## Closing The most important reason to formally close a project is to formalise the learning. **Closure checklist:** - Evaluate the task list — no loose ends - Confirm all change requests were fulfilled - Confirm project scope was met: goals, timeline, cost, risk management - Complete procurement closure - Document lessons learned (causes of variances, reasoning behind decisions) - Submit final status report to key stakeholders - Seek feedback from key stakeholders - Obtain all necessary sign-offs - Archive project documents - Publish and celebrate success — thank people personally ### Lessons Learned: Interview the Core Team - What was done well? - What needs to be done better or differently? - What unexpected risks did we have to deal with? - How does our process need to change to meet goals in the future? --- ## Rules of Thumb - The biggest job of a project manager is to engage and inspire the team - Successful projects are transparent - Front-load clarity — ambiguity at the start compounds into failure later - You cannot push people; you must inspire them to volunteer their best - The stench of failure is the inability to learn from it - Celebrate what you've accomplished, then raise the bar a little higher each time