Project Management 101

The Fundamentals of Getting Things Done Right

About This Module

Project Management 101 is a foundational course designed to give every VMG team member a working understanding of how projects are planned, executed, and closed. Whether you are managing a full client onboarding, rolling out a new internal process, or simply trying to get a complex task done on time, the principles in this course will help you work smarter, communicate better, and deliver consistently.

Overview #

This course is divided into eight modules. Each module builds on the last, taking you from the very basics of what a project is, all the way through to closing a project and learning from it.

Module 1  —  What Is a Project?

Module 2  —  The Project Lifecycle

Module 3  —  Defining Scope, Goals & Deliverables

Module 4  —  Planning: Time, Resources & Budget

Module 5  —  Roles & Responsibilities

Module 6  —  Risk Management

Module 7  —  Communication & Stakeholder Management

Module 8  —  Monitoring, Control & Project Close

How to Use This Course Read each module in order — the concepts build on one another. After each module, reflect on how the concepts apply to your own work at VMG. Complete the assessment at the end to test your understanding. There are no right or wrong questions during learning — ask, discuss, and challenge.

Module 1: What Is a Project? #

1.1  Defining a Project #

Before we can manage projects well, we need to agree on what a project actually is. This might seem obvious, but many problems in the workplace arise because people treat a project like routine daily work, or treat daily work like a once-off project.

A project is a temporary, focused effort undertaken to create a unique outcome — a product, a service, a result, or a change.

Every project has three defining characteristics:

• Temporary: It has a clear start and a clear end. It is not ongoing.
• Unique: The result or outcome is different from anything produced as part of routine operations.
• Progressive: It develops step by step, with increasing detail as the work unfolds.

1.2  Project vs. Operations #

It is important to understand the difference between a project and day-to-day operations.

A PROJECT is…	OPERATIONS is…
Temporary — has a start and end date	Ongoing — runs continuously
Creates something new or unique	Repeats established processes
Has a defined budget and resources	Uses an ongoing operational budget
Team may be assembled specifically for it	Performed by permanent staff in fixed roles
Example: Onboarding a new dealership	Example: Logging daily support tickets

💡 At VMG, onboarding a new client is a project. Answering support calls every day is operations. Both matter — but they need to be managed differently.

1.3  Why Projects Fail #

Understanding why projects commonly fail is just as important as knowing what to do right. The most common reasons are not technical — they are human and organisational.

• Unclear goals: No one agreed on what success looks like.
• Poor communication: The right people did not have the right information at the right time.
• Scope creep: The project kept expanding without adjusting time or budget.
• Unrealistic timelines: Too much was promised in too little time.
• No clear ownership: Everybody was responsible, so nobody was.
• Weak risk management: Problems that could have been foreseen were not addressed.
• Poor stakeholder engagement: Key people were not kept informed or involved.

Key Takeaway — Module 1 A project is temporary and unique. It has a defined start, end, goal, and set of resources. It differs from day-to-day operations in that it is designed to produce a specific outcome. The most common causes of failure are not technical — they are about clarity, communication, and accountability.

Module 2: The Project Lifecycle #

2.1  The Five Phases of a Project #

Every project, regardless of size or industry, moves through five natural phases. Understanding these phases helps you know where you are, what you should be doing, and what comes next.

• Phase 1: Initiation: Define the project. Identify the need, establish goals, get approval to proceed.
• Phase 2: Planning: Map out exactly how the project will be executed — timeline, resources, risks, and responsibilities.
• Phase 3: Execution: Do the actual work. Teams carry out tasks according to the plan.
• Phase 4: Monitoring & Control: Track progress, manage changes, and take corrective action when needed.
• Phase 5: Closure: Complete deliverables, hand over the outcome, document lessons learned, and formally close the project.

2.2  Phase 1 — Initiation #

The initiation phase answers the most fundamental question: should we do this project at all?

Key activities in this phase:

• Identify the business need or problem being solved.
• Define the high-level goal and expected outcome.
• Identify the key stakeholders (the people who care about this project).
• Conduct a basic feasibility check — is it realistic? Is it affordable?
• Get formal approval to proceed (sign-off from a manager, sponsor, or client).

The main output of this phase is a Project Charter or Project Brief — a one-page document that summarises the purpose, goals, stakeholders, and high-level plan.

2.3  Phase 2 — Planning #

The planning phase is where most of the intellectual work happens. A well-planned project is far less stressful to execute. Poor planning is the single biggest predictor of project failure.

Key activities:

• Define the full scope of work (what is included and what is not).
• Break the project into tasks (a Work Breakdown Structure).
• Set realistic timeframes and deadlines.
• Identify the resources needed (people, tools, budget).
• Identify risks and plan how to manage them.
• Define how the team will communicate.

💡 Time spent in planning saves time in execution. For every hour of planning, you save three to five hours of rework.

2.4  Phase 3 — Execution #

This is where the plan becomes reality. The team does the work. The project manager coordinates, removes obstacles, and keeps everyone aligned.

Key activities:

• Assign and kick off tasks.
• Hold regular team check-ins.
• Manage team performance and resolve blockers.
• Communicate progress to stakeholders.
• Manage changes to scope, timeline, or budget.

2.5  Phase 4 — Monitoring & Control #

Monitoring and control runs in parallel with execution. You cannot just set a plan in motion and hope for the best.

Key activities:

• Track actual progress against the plan.
• Identify variances early (is the project on time? On budget? On scope?).
• Take corrective action when things go off track.
• Manage and document changes through a formal change process.
• Report status to stakeholders regularly.

2.6  Phase 5 — Closure #

Projects often lose their closure phase to the excitement of the next project. This is a mistake. Proper closure is what transforms an experience into organisational learning.

Key activities:

• Confirm that all deliverables have been completed and accepted.
• Obtain final sign-off from the client or sponsor.
• Release team members and resources.
• Document lessons learned.
• Archive all project documentation.
• Celebrate the win!

Key Takeaway — Module 2 Every project moves through five phases: Initiation, Planning, Execution, Monitoring & Control, and Closure. Each phase has specific deliverables and activities. Skipping or rushing a phase — especially Planning and Closure — significantly increases risk.

Module 3: Defining Scope, Goals & Deliverables #

3.1  What Is Scope? #

Scope defines the boundaries of your project. It answers: what are we doing, and equally important, what are we NOT doing?

Scope has two components:

• Product Scope: The features and functions of the thing being created (e.g., what the software will do).
• Project Scope: The work required to deliver that product (e.g., the tasks, processes, and activities involved).

3.2  Writing a Clear Project Goal #

Vague goals produce vague results. Every project must begin with a clear, measurable goal. The SMART framework is the most widely used tool for this purpose.

Letter	What It Means
S — Specific	Clearly defined. No ambiguity about what needs to happen.
M — Measurable	You can track and measure progress and completion.
A — Achievable	Realistic given the resources and time available.
R — Relevant	Aligned to a real business need or priority.
T — Time-bound	Has a clear deadline or timeframe.

Example — Vague Goal:

“Improve the onboarding process.”

Example — SMART Goal:

“Reduce the time to complete new dealership onboarding from 21 days to 14 days by 31 March, without increasing the onboarding team headcount.”

3.3  Scope Creep — The Silent Project Killer #

Scope creep happens when the scope of a project expands beyond what was originally agreed — usually without adjusting the timeline, budget, or resources.

It most commonly occurs because:

• Stakeholders add new requirements after the project has started.
• Team members do extra work to “be helpful” without checking the impact.
• The original scope was not documented clearly enough.

How to prevent scope creep:

• Document the scope in writing and get it signed off before work begins.
• Use a Change Request process — any new request must be formally assessed for time, cost, and resource impact before it is accepted.
• Keep stakeholders informed so they understand what happens when scope changes.

💡 It is fine for scope to change. What is not fine is for scope to change without anyone adjusting the plan.

3.4  Defining Deliverables #

A deliverable is a tangible output produced by the project. Deliverables can be documents, software features, trained staff, installed systems, or any other concrete result.

Every deliverable should have:

• A clear description of what it is.
• Acceptance criteria — how will you know when it is done and good enough?
• An owner — who is responsible for producing it?
• A due date.

Key Takeaway — Module 3 Scope defines what the project will and will not deliver. SMART goals give everyone a clear, shared picture of success. Scope creep is the slow expansion of work without adjusting plans — prevent it by documenting scope and using a Change Request process. Every deliverable needs a clear description, acceptance criteria, an owner, and a due date.

Module 4: Planning — Time, Resources & Budget #

4.1  The Work Breakdown Structure (WBS) #

Once you know what the project needs to deliver, the next step is breaking that work down into manageable tasks. This is called a Work Breakdown Structure, or WBS.

A WBS decomposes the project from its major phases, down to specific tasks, and finally to individual actions. Think of it as an org chart for your work.

Example WBS structure (simplified):

• Project: New Dealership Onboarding
  • Phase 1: Preparation
    • Gather client information
    • Configure system environment
  • Phase 2: Training
    • Schedule training sessions
    • Deliver DMS training
    • Deliver WMS training
  • Phase 3: Go Live
    • Confirm data migration
    • Run parallel testing
    • Sign off and close

4.2  Estimating Time #

Estimating how long tasks will take is one of the hardest skills in project management. People consistently underestimate how long things take — a bias known as the Planning Fallacy.

Practical tips for better time estimates:

• Base estimates on past experience, not optimism.
• Break tasks down to the smallest logical unit before estimating.
• Ask the person doing the work for their estimate — not just the manager.
• Add buffer time (contingency) for unknown issues.
• Consider dependencies — some tasks cannot start until others finish.

A useful technique is Three-Point Estimating:

Estimate Type	Description
Best Case	How long if everything goes smoothly?
Worst Case	How long if things go badly?
Most Likely	How long in a realistic, normal scenario?
Final Estimate	Use a weighted average: (Best + 4×Most Likely + Worst) ÷ 6

4.3  Building a Timeline #

Once tasks are identified and estimated, arrange them into a timeline. A Gantt chart is the most common tool for this — a horizontal bar chart showing tasks on a timeline.

Key concepts when building a timeline:

• Dependencies: Task B cannot start until Task A is finished. Map these carefully.
• Critical Path: The longest sequence of dependent tasks. Any delay here delays the whole project.
• Milestones: Significant checkpoints in the project. Not deliverables, but markers of progress (e.g., “Client sign-off received”).
• Buffer: Time built into the plan to absorb the unexpected.

💡 A good rule of thumb: add 20% to your total estimated time as buffer. Projects rarely run exactly to plan.

4.4  Resource Planning #

Resources are everything you need to do the work: people, equipment, software, facilities, and money. Resource planning ensures that the right things are available at the right time.

For each task, ask:

• Who will do this? (Do they have the skills? Are they available?)
• What tools or materials are needed?
• Are there any external dependencies (vendors, approvals, third parties)?

A common pitfall is resource over-allocation — assigning the same person to multiple tasks that run at the same time. Always check availability before committing.

4.5  Budgeting Basics #

Every project has a cost, even if no money changes hands directly (time has a cost). A project budget estimates the total cost of completing the project.

Common cost categories:

• Labour costs (time of team members).
• Tools, software, or equipment.
• Third-party services or contractors.
• Travel or facilities.
• Contingency reserve (typically 10–20% of total).

Track budget vs. actual spend throughout the project, not just at the end. By the time you notice a budget problem at the end, it is too late to fix it.

Key Takeaway — Module 4 Break work down into specific, manageable tasks using a WBS. Estimate time carefully — base it on data and experience, not optimism. Build a realistic timeline that includes dependencies, milestones, and buffer. Plan your resources carefully to avoid over-allocation. Track budget regularly throughout the project.

Module 5: Roles & Responsibilities #

5.1  Who Does What? #

One of the most common causes of project failure is confusion about who is responsible for what. People wait for others to act, or they duplicate effort, or decisions fall through the cracks. Clear roles prevent all of this.

5.2  Key Project Roles #

The Project Sponsor #

The sponsor is the person who owns the project at a senior level. They authorise the budget, provide strategic direction, remove major obstacles, and approve changes to scope or timeline. They are not involved in day-to-day execution.

The Project Manager (PM) #

The project manager is responsible for planning, executing, monitoring, and closing the project. They are the central point of communication, the person who keeps the plan alive, and the one accountable for the overall outcome.

Core PM responsibilities:

• Define and maintain the project plan.
• Coordinate team members and ensure tasks are completed.
• Track progress and manage risks.
• Communicate status to stakeholders.
• Manage scope changes and escalate issues when needed.

The Project Team #

Team members are the people who do the actual work. Each team member has specific tasks assigned to them and is accountable for completing those tasks on time and to standard.

Good team members:

• Know exactly what they are responsible for.
• Raise problems early rather than waiting until the deadline.
• Communicate clearly about their progress or obstacles.
• Support their colleagues.

Stakeholders #

A stakeholder is anyone who has an interest in the project or is affected by its outcome. This includes the client, internal departments, end users, and leadership.

Not all stakeholders need to be involved in the same way. Part of good project management is knowing who needs what information, and when.

5.3  The RACI Matrix #

The RACI matrix is a simple, powerful tool for making roles and responsibilities crystal clear. For every task or deliverable, it defines:

Letter	What It Means
R — Responsible	The person who actually does the work.
A — Accountable	The person who is ultimately answerable for the outcome. Only one per task.
C — Consulted	People whose input is sought before or during the task.
I — Informed	People who are kept updated on progress and outcomes.

Example RACI for a training delivery task:

Task	Responsible	Others
Design training content	Training Lead	PM (A), Senior PM (C), Client (I)
Deliver training session	Trainer	Training Lead (A), Client (I)
Collect sign-off	PM	PM (A), Client (R), Sponsor (I)

💡 If a task has no “A” (Accountable), it probably will not get done. If it has more than one “A”, prepare for conflict.

Key Takeaway — Module 5 Every project needs a sponsor, a project manager, a team, and identified stakeholders. Ambiguity about roles is one of the most common causes of project failure. A RACI matrix assigns clear responsibility, accountability, consultation, and information roles for every major task.

Module 6: Risk Management #

6.1  What Is a Risk? #

A risk is an uncertain event that, if it occurs, could have a positive or negative effect on the project. In most contexts, when we talk about risks, we mean the negative ones — the things that could go wrong.

A risk is not the same as an issue. An issue is a problem that has already happened. A risk is something that might happen. Good project managers think about both.

RISK	ISSUE
Uncertain — it may or may not happen	Has already happened — it is a fact
Requires proactive management	Requires reactive management
Example: “The client might not return the signed document in time”	Example: “The client did not return the signed document”

6.2  The Risk Management Process #

Risk management is an ongoing process, not a once-off checklist. It runs throughout the project lifecycle. There are four steps:

• 1. Identify: What could go wrong? Brainstorm with the team. Consider every phase of the project.
• 2. Assess: How likely is each risk? How bad would the impact be? Prioritise accordingly.
• 3. Respond: What will you do if the risk occurs? Plan a response in advance.
• 4. Monitor: Keep watching for risks throughout the project. New risks emerge as the project evolves.

6.3  Assessing Risks #

Once risks are identified, assess them using two dimensions: Likelihood and Impact.

Risk Level	Priority
High Likelihood + High Impact	🔴 CRITICAL — Prioritise immediately
High Likelihood + Low Impact	🟡 MEDIUM — Monitor and manage
Low Likelihood + High Impact	🟡 MEDIUM — Have a contingency plan ready
Low Likelihood + Low Impact	🟢 LOW — Document and monitor

6.4  Risk Response Strategies #

There are four main ways to respond to a risk:

• Avoid: Change the plan so the risk cannot occur. (Example: use a different supplier with a better track record.)
• Mitigate: Take action to reduce the likelihood or impact. (Example: start a task earlier to reduce the risk of delays.)
• Transfer: Pass the risk to a third party. (Example: insurance, or contractual penalties for supplier delays.)
• Accept: Acknowledge the risk and decide to deal with it if it occurs. (Used for low-priority risks.)

6.5  The Risk Register #

A Risk Register is a living document that captures all identified risks, their assessments, owners, and response plans. It is reviewed and updated regularly throughout the project.

A basic Risk Register entry includes:

• Risk ID and description.
• Category (e.g., resource, technical, external, financial).
• Likelihood (High / Medium / Low).
• Impact (High / Medium / Low).
• Risk Owner (who is responsible for monitoring it).
• Response plan.
• Status (open, monitoring, closed).

Key Takeaway — Module 6 A risk is something that might go wrong. An issue is something that already has. Proactive risk management is far less costly than reactive crisis management. Assess risks by likelihood and impact, prioritise accordingly, and assign an owner. Maintain a Risk Register throughout the project and review it regularly.

Module 7: Communication & Stakeholder Management #

7.1  Why Communication Is Everything #

Studies consistently show that poor communication is the number one cause of project failure. Not technical problems. Not budget issues. Communication.

As a project manager or team member, you cannot over-communicate. But you can communicate the wrong things, to the wrong people, at the wrong time. Good project communication is intentional and structured.

7.2  Identifying Stakeholders #

Before you can communicate well, you need to know who your stakeholders are and what they care about. A stakeholder is anyone who:

• Has a decision-making role in the project.
• Will be affected by the project outcome.
• Has resources or authority that the project depends on.
• Has a strong interest in the project (positive or negative).

Not all stakeholders are equal. They differ in their:

• Power: Their ability to influence the project (high or low).
• Interest: How much they care about the project outcome (high or low).

Map your stakeholders across a Power/Interest grid to guide how you engage them:

Stakeholder Type	Engagement Approach
High Power / High Interest	Manage Closely — these are your primary stakeholders. Keep them fully informed and involved.
High Power / Low Interest	Keep Satisfied — they have influence but are not closely involved. Give them regular high-level updates.
Low Power / High Interest	Keep Informed — they are invested in the outcome. Regular updates keep them on board.
Low Power / Low Interest	Monitor — minimal engagement. A periodic update is sufficient.

7.3  The Communication Plan #

A Communication Plan documents how information will flow through the project. It answers:

• What information needs to be shared?
• Who needs to receive it?
• How often?
• Through which channel? (Email, meeting, report, WhatsApp, etc.)
• Who is responsible for sending it?

Example elements of a Communication Plan:

Communication	Audience	Owner & Frequency
Weekly Status Report	Project Sponsor, Client	PM — every Friday by 3pm
Team Stand-Up	Project Team	Team Lead — every Monday morning
Risk Review	PM, Senior Lead	PM — every two weeks
Client Milestone Update	Client Stakeholders	PM — on milestone completion
Escalation Alert	Project Sponsor	PM — immediately when critical issue arises

7.4  Status Reports #

A Status Report is a regular update on the health of the project. It is one of the most important communication tools in project management because it creates transparency, accountability, and a written record.

A good status report includes:

• Project name, reporting period, and date.
• Overall project health indicator (On Track / At Risk / Critical).
• Progress summary — what was completed this period.
• What is planned for the next period.
• Key issues or risks, with status and owner.
• Budget and timeline status.

💡 A status report that only reports good news is not useful. The purpose is to tell the truth, so that decisions can be made with accurate information.

7.5  Managing Difficult Conversations #

Projects almost always include a moment where you have to deliver bad news — a delay, a budget overrun, a quality issue. Avoiding these conversations makes things worse. Here is how to handle them:

• Be early: Raise issues as soon as you become aware of them, not once they become crises.
• Be factual: Stick to what you know. Avoid speculation.
• Come with a plan: Do not just present a problem. Present the problem and your proposed solution.
• Be direct: Vague messaging creates anxiety and confusion. Say what needs to be said clearly.
• Own your part: If something went wrong on your watch, say so. Trust is built through accountability.

Key Takeaway — Module 7 Poor communication is the leading cause of project failure. Know your stakeholders, what they care about, and how to engage them. A Communication Plan ensures the right information reaches the right people at the right time. Status reports create transparency and accountability. Difficult conversations handled early are far less damaging than crises handled late.

Module 8: Monitoring, Control & Project Close #

8.1  Why You Must Monitor Actively #

A project plan is a prediction. Reality rarely matches a prediction perfectly. Monitoring is how you detect the gap between plan and reality early enough to do something about it.

Without active monitoring, you will only discover problems when they have already become crises. With monitoring, you can intervene while there is still time to recover.

8.2  Key Metrics to Track #

Track these four dimensions throughout your project:

Dimension	What to Check
Schedule	Are tasks being completed on time? Is the critical path still intact?
Budget	Is actual spend tracking in line with planned spend?
Scope	Are we still working within the agreed scope, or has scope crept?
Quality	Are deliverables meeting the agreed acceptance criteria?

8.3  Managing Changes #

Change is inevitable in projects. What matters is how you manage it. Uncontrolled change is the enemy of project success.

A Change Request process works as follows:

• Step 1 — Identify: Someone requests a change to scope, timeline, or budget.
• Step 2 — Document: The change is written up clearly: what is being requested and why.
• Step 3 — Assess: The PM analyses the impact: What will this cost? How long will it take? What are the risks?
• Step 4 — Decide: The sponsor or relevant authority approves or rejects the change.
• Step 5 — Implement: If approved, update the plan, budget, and timeline accordingly.
• Step 6 — Communicate: Inform all affected stakeholders of the change and its implications.

💡 All changes — even small ones — should go through this process. It protects the PM, the team, and the client.

8.4  Escalation #

Not every problem can be solved at the team level. Escalation is the process of raising a problem to a higher authority so that more power or resources can be applied.

Escalate when:

• A risk or issue has materialised and cannot be resolved within the team.
• A decision is required that is beyond the PM’s authority.
• Scope, budget, or timeline is about to be significantly impacted.
• Stakeholder relationships are breaking down.

Escalation is not failure. It is good judgment. The failure is when problems are hidden because people are afraid to escalate.

8.5  Closing the Project #

Closing a project is more than just finishing the last task. It is a deliberate phase that ensures:

• All deliverables have been completed and formally accepted.
• The client or sponsor has given written sign-off.
• All contracts and supplier relationships are formally closed.
• Resources (people, equipment) are formally released.
• Lessons learned are documented and shared.
• All project documentation is archived in an accessible location.

8.6  Lessons Learned #

A Lessons Learned session is a structured conversation held at the end of the project to capture what went well, what went badly, and what the team would do differently next time.

Format: Gather the team and ask:

• What worked well that we should do again?
• What did not work that we should stop doing?
• What should we do differently next time?
• What advice would you give to someone starting this kind of project for the first time?

The output is a written document, not a verbal chat. It becomes part of the project archive and is reviewed before similar projects begin in future.

💡 The most valuable projects are the ones you learn from. A project that was difficult but generated strong lessons learned is worth more than a smooth project with nothing documented.

Key Takeaway — Module 8 Monitor schedule, budget, scope, and quality continuously throughout the project. All changes must go through a formal Change Request process, however small. Escalate problems early — it is not failure, it is good judgment. Close the project formally: get sign-off, release resources, archive documents. Conduct a Lessons Learned session and write it up — it is an investment in future projects.