Project Management: Step by Step — Condensed Notes
Step 1: Understand the basics
A project is a task with a known end point, delivering defined outputs within a planned time and cost. The end result should change something in a useful way, such as a new product, a system, or a new building. Projects are characterized by five interdependent dimensions: . The scope defines what is included; quality sets the required level of deliverables; time and cost bound the schedule and budget; risk captures the level of uncertainty. A simple model uses a small, concrete example (e.g., redecorating a room) to show how changing one dimension affects the others. The project lifecycle follows a generic lifecycle: specify why and what, plan, execute/deliver, check results against needs, and close. The project customer is the person or group who wants the project done; the project team carries out the work; the project manager coordinates, guides, and controls the effort. Deliverables are the concrete outputs the project promises to deliver, and delivery means completing the project on time and to the agreed cost and quality. The five dimensions can be traded off, so decisions adjust scope, quality, time, cost, or risk to achieve the required outcome. In practice, a project often uses a simple lifecycle rather than heavy methods, and its jargon should be understood only when useful.
Step 1: Understand the basics (continued)
The central point is that project management is a structured approach that aims to deliver the end point predictably. The project manager’s role is to apply structure and rigour so the project completes on time and within budget, with the intended deliverables. The customer’s involvement is crucial: they define why the project is needed, what it should deliver, access resources, and make key decisions. The project team performs tasks under the project manager’s guidance, often working alongside their regular line managers. Delivery is measured by whether the deliverables meet the defined scope, quality, time, and cost, and whether the deliverables fulfill the customer’s needs.
Step 1: Understand the basics (lifecycle, roles, and tips)
Chapter guidance emphasizes that most projects can be managed with simple steps, avoiding excessive jargon. The lifecycle typically includes five stages: specify in detail what the project is for (why), plan to determine how long and how much it will cost (what and how), do the work and produce deliverables, check that the deliverables meet needs, and close the project with finalization and handover. A useful practical tip is to keep the five dimensions in balance and to trade them off to reach the optimal result for the given constraints. Key tasks for the project manager include ensuring a clear why and what, producing a plan, managing progress, and completing the project with the required quality. A standard definition of “project” helps avoid scope creep and misaligned expectations.
Step 2: Define the ‘why’ and the ‘what’
Success hinges on clarity about why a project exists and what it will deliver. The Project Definition captures both elements in a concise document, typically including: the project name, the deliverables (the end state you will have), the reason for the project (the ‘why’), and what will be delivered (the ‘what’). Additional considerations include whether there are gaps or overlaps with other projects (dependencies), explicit exclusions (scope boundaries), assumptions, potential significant problems, and any customer-imposed conditions or constraints. The ‘why’ must be precise; the ‘what’ must be traceable back to the why. If more than one customer or stakeholder is involved, align and sign off the definition to avoid disputes later. After defining the project, the next chapter explains how to translate the Project Definition into a practical Project Plan.
Step 2: Define the ‘why’ and the ‘what’ (examples and cautions)
The book emphasizes the risk of engineering the ‘why’ to fit a desired ‘what’. True alignment means the deliverables should actually realize the underlying reason for the project. Examples illustrate how the same objective (e.g., increasing revenues) can imply different deliverables (new product vs. improved channels). The discussion also covers role clarity: typically you are responsible for delivering the defined outputs (the ‘what’), not necessarily achieving the ‘why’ unless you are explicitly responsible for benefits realization. A well-constructed Project Definition includes explicit gaps, overlaps, dependencies, and assumptions to guide later planning and to set realistic expectations with the customer.
Step 3: Create your Project Plan
Planning translates the definition into a workable schedule and budget. The core steps are:
Step 3.1 Brainstorm a task list: involve others with relevant experience; capture tasks on post-its to allow iteration.
Step 3.2 Convert the task list into a skeleton plan or Work Breakdown Structure (WBS): assign a simple numbering to tasks (and a hierarchical WBS like 1, 1.1, 1.2, …) to delineate components versus sub-tasks.
Step 3.3 Estimate times, add dependencies and delays: estimate effort (e.g., ) rather than duration; include delays and external dependencies; introduce contingency: typically – for low-risk and familiar tasks, – for higher risk, up to + for very unfamiliar tasks.
Step 3.4 Add who will do what: assign tasks to people who are available and capable; avoid overcommitment.
Step 3.5 Build the plan into a schedule: determine start and end dates based on predecessors, resource availability, and non-working days; use external dependencies to reflect tasks outside the project boundary.
Step 3.6 Work out costs: distinguish between project-running costs (people time, overhead) and deliverable costs (hardware, materials); identify fixed vs. variable costs; include your own time as part of the project budget where appropriate.
Step 3.7 Add milestones and contingency: milestones mark meaningful progress (e.g., completion of phases); contingency provides a buffer; total budget and time should reflect these buffers.
Step 3.8 Review and amend: verify feasibility, ensure alignment with the why/what, and refine as needed.
Step 3.9 Review the plan with the project customer: obtain sign-off on the plan to ensure commitment and avoid scope disputes later.
Step 3: Create your Project Plan (practical structure and planning basics)
A practical planning approach uses a Work Breakdown Structure (WBS) to decompose work into manageable parts, with tasks numbered to reflect hierarchy. The plan includes a schedule showing start and end dates, predecessors, and resource assignments; it also includes a budget broken into staff costs (variable) and deliverable costs (variable and fixed). The critical path identifies the sequence of tasks that determine the project duration; activities on the critical path govern the end date, while non-critical tasks can slip or be rearranged to compress the schedule. In practice, the plan is a living document: you may reorder tasks by person, by date, or by priority to optimize resource usage and ensure the project remains on track. The use of planning software can help with calculations, but the quality of the plan ultimately comes from clear thinking and realistic assumptions.
Step 4: Manage delivery
Delivery requires active management throughout the project life cycle. The core activities are:
Step 4.1 Start the project: reconfirm the Project Definition, obtain customer buy-in on the plan and contingency, and ensure access to required resources.
Step 4.2 Plan your day: each day, identify the biggest obstacles, anticipate risks, and decide on priority actions.
Step 4.3 Collect information and reports: hold regular (weekly) updates from the team; gather evidence of progress (deliverables, results, etc.).
Step 4.4 Monitor and manage progress: compare actual progress to the plan, track costs and schedule slippage, and determine recovery options if needed.
Step 4.5 Identify and resolve issues: log issues, assign owners, set deadlines, and monitor resolution progress. An issues log (Table 4.2 in the text) is a common tool.
Step 4.6 Identify and manage risks: maintain a risk log (Table 4.3), prioritize risks by a simple impact × likelihood score, and implement risk responses with assigned owners and due dates.
Step 4.7 Manage changes: changes require formal control; use a change form to document the change, its impact on time/cost/quality/risk, and customer sign-off.
Step 4.8 Take action to ensure the project’s success: the project manager must actively drive progress, coordinate the team, and remove obstacles; the metaphor of the conductor is used to emphasize active leadership.
Step 4.9 Keep your customer informed: regular, honest communication reduces surprises; share milestones and risks, and explain deviations and recovery plans.
Step 4.10 Update the Project Plan or Project Budget: revise plans only when needed due to justified changes or significant risks; obtain customer agreement for changes that affect time or cost.
Step 4: Manage delivery (measures and flows)
Progress is measured against the plan; a plan is a baseline, not a guarantee. Slippage is common and should be managed day-by-day, not left to accumulate. Tasks are tracked to completion (0% or 100%), with evidence of progress collected from team members. If delays occur, possible recovery options include speeding up work, adding resources (with cost implications), overlapping tasks where dependencies permit, reducing scope, or accepting contingency usage. Regularly reviewing risks, issues, and changes ensures you can act quickly and keep stakeholders informed. The project manager must be proactive and hands-on, not merely an observer.
Step 5: Complete your project
Ending a project properly involves testing deliverables, implementing them, providing customer support for a defined period, and releasing resources (both people and money) when appropriate. A formal project review captures lessons learned: what to continue, what to stop, and what to start in future projects. Where possible, celebrate success and recognize the team. The finishing steps include: test the deliverables; implement and hand them over to the customer; provide post-implementation support; release unused resources and funds; and conduct a post-project review to extract learning for future work. Appendix materials cover requirements collection, external contractors, testing, integration, implementation, and change management—areas that may be crucial for larger or more complex projects.
Key concepts to remember
Projects are bounded by five interdependent dimensions: . The project lifecycle consists of five steps: specify the why and what, plan, deliver, check, and close. The Project Definition captures the why and what in a concise document used to anchor planning and execution. A detailed Project Plan translates the definition into a schedule and budget, using a Work Breakdown Structure (WBS) and milestones, with contingency to cover risk. Managing delivery relies on progress measurement, issue/risk/change management, and keeping the customer informed. Finally, completing a project requires testing, implementation, post-implementation support, releasing resources, and conducting a lessons-learned review, often supported by an Appendix with detailed forms and templates.
Quick reference: typical formulas and notations
Risk priority is calculated as with a simple 3-point scale: Low=1, Medium=2, High=3.
Contingency is a time and/or budget buffer, commonly expressed as a percentage: for low-risk tasks, for higher risk, up to for very high risk or unfamiliar tasks.
The unit of effort is (or similar) and duration is the elapsed time including waiting periods; note that 1 day of delay on a task may not equal a whole day of schedule slippage if there are parallel tasks.
The critical path defines the sequence of tasks that determines the project duration; those tasks control the end date, while non-critical tasks can be adjusted to optimize timing.