01202 006 464
learndirectPathways

Project Planning Techniques: Gantt Charts, Milestones and Risk Registers

Podcast episode 33: Project Planning Techniques: Gantt Charts, Milestones and Risk Registers. Alex and Sam explore key concepts from the Pearson BTEC Higher Nationals in Computing. Full transcript included.

Series: HTQ Computing: The Study Podcast  |  Module: Unit 6: Planning a Computing Project  |  Episode 33 of 80  |  Hosts: Alex with Sam, Computing Specialist
Key Takeaways
  • A Gantt chart visualises a project schedule by displaying tasks as horizontal bars across a timeline, showing start dates, durations, and dependencies.
  • Milestones mark significant points in a project, such as the completion of a phase or the delivery of a key output.
  • A risk register documents identified risks, their likelihood, potential impact, and the mitigation strategies assigned to each.
  • Critical path analysis identifies the sequence of tasks that determines the minimum time needed to complete the project.
  • Regular project plan reviews ensure that the plan remains realistic as circumstances change, allowing adjustments to be made before problems escalate.
Listen to This Episode

Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.

Start learning →
Full Transcript

Alex: Today we're looking at project planning techniques. Sam, what are the essential tools of the project planner?

Sam: The three I'd highlight as most important are Gantt charts, milestone planning, and risk registers. Together these give you a schedule, a set of checkpoints, and a proactive approach to things that might go wrong.

Alex: Let's start with Gantt charts.

Sam: A Gantt chart is a type of bar chart that visualises a project schedule. Each task is listed on the left, and a horizontal bar extends across the timeline for the duration of that task. You can also show dependencies between tasks: task B can't start until task A is complete. Gantt charts make it very easy to see the overall shape of the project, which tasks are running in parallel, and which are sequential.

Alex: How detailed should a Gantt chart be?

Sam: It should be detailed enough to be useful for managing the work but not so detailed that it becomes unwieldy to maintain. For a student computing project spanning a few months, breaking work down to approximately week-level tasks is usually appropriate. For a large enterprise project, you'd typically have a high-level project Gantt chart broken down into sub-project plans for each workstream.

Alex: What about milestones?

Sam: Milestones mark significant points in the project: the completion of a major phase, the delivery of a key document, the sign-off from a stakeholder. They're shown on the Gantt chart as points rather than bars. Milestones are important because they provide natural checkpoints for assessing progress and demonstrating to stakeholders that the project is on track. Missing a milestone is an early warning sign that the project may be in trouble.

Alex: Critical path analysis was mentioned earlier. How does that relate?

Sam: The critical path is the sequence of tasks that determines the minimum time needed to complete the project. Any delay to a task on the critical path will delay the project completion. Tasks that are not on the critical path have some float or slack; they can slip slightly without affecting the overall timeline. Identifying the critical path helps you focus management attention on the tasks where delays matter most.

Alex: Now risk registers. How do those work?

Sam: A risk register is a document that lists all identified project risks along with information about each one. For each risk you record a description, the likelihood of it occurring, the potential impact if it does, the overall risk rating combining likelihood and impact, and the mitigation strategy: what you'll do to reduce the likelihood or impact. You also record a contingency plan for what you'll do if the risk materialises despite your mitigation efforts.

Alex: What kinds of risks appear in computing projects?

Sam: Technical risks like a chosen technology not performing as expected. Resource risks like a key team member leaving. Requirement risks like stakeholders changing what they want partway through. External risks like a supplier failing to deliver. Schedule risks like underestimating task durations. Security risks like discovering a vulnerability in a component you're using. The more thoroughly you think through potential problems upfront, the better prepared you are to handle them.

Alex: And the plan should be reviewed regularly?

Sam: Weekly at minimum in most projects. Plans are not set in stone; they need to be updated as circumstances change and as you learn more. A plan that's out of date is worse than no plan because it gives a false sense of control.

Alex: Brilliant. Thanks Sam. Our final Unit 6 lesson covers presenting recommendations.