Planning 1 - Beginning the Project Planning Phase

Google Project Management Certificate · Course 3: Project Planning - Putting It All Together

---

Initiation answered should we do this, and what exactly is it? Planning answers the far more practical question: how will we actually get there? This module opens the second phase of the life cycle and works through the first half of that answer - launching the phase, aligning the team, and breaking the goal down into work small enough to hand to a person.

The through-line is decomposition. A project goal is too big to act on, so you split it into deliverables, then into milestones that mark progress, then into tasks that someone can start on Monday morning. The work breakdown structure is the tool that performs that split, and it is the module’s practical activity.

Everything here assumes initiation actually finished. The instructor is explicit that planning starts only once the project manager is assigned, the goals, scope, and deliverables are approved, people are named with roles, and the charter is signed off by stakeholders.

Note

Where this sits: first half of the planning phase. This page covers kickoff, milestones, tasks, the WBS, and task assignment. The schedule, time estimates, budget, and risk plan build on these and come next.

---

Why planning matters

Planning is where you and the team decide the processes and workflows needed to hit the goal. Old projects are a useful reference, but every project is different, so a new approach is often the right one rather than a risky one.

The benefits stack up in two groups - the obvious mechanical ones, and the softer ones that matter just as much.

Benefit	What it gives you
Maps the full project	You can see the whole body of work needed to reach the goal
Coordinates outward	Aligns timelines with other teams, contractors, and vendors
Surfaces risk early	Timeline slips, a key person leaving, a stakeholder changing direction
Room to mitigate	Time to brainstorm responses before the risk actually lands
Buy-in	The team’s active support for the plan, because they helped build it
Stakeholder confidence	Shows the project is starting from a detailed plan, not improvisation
Teamwork	A group of assigned individuals becomes a real team by the time planning ends

Tip

The strongest argument for planning is the shared understanding it creates. A senior Google program manager in this module puts it plainly: planning sets the tone, aligns everyone on what success looks like, and makes people comfortable flagging problems. Without it, you talk to the wrong people, things get delayed, and nobody can explain why.

Planning also does not have to be right first time. Plans will change as the project evolves, and that is expected rather than a failure.

---

What gets worked out in planning

The phase varies by project, but three big artefacts come out of it.

Schedulestart, end, and every date between

Budgettotal cost, broken down by element

Risk management planwhat could go wrong, and the response

The three core outputs of the planning phase.

Output	What it contains	Plant Pals example
Schedule	A timeline: start date, end date, and the dates in between, set using time estimation techniques	When to request vendor proposals, when to kick off with web designers, when plants must be delivery-ready, when the design must be approved, the launch date
Budget	The total cost, broken down across the individual elements of the project	Cost of designing and launching the webpage, cost of hiring the plant vendor, and so on
Risk management plan	A deliberate hunt for where trouble could occur, plus planned responses	Developer estimates push you past the launch date - so reduce scope, adjust it, or negotiate a new launch date with stakeholders

Caution

Risk itself is inevitable. What is not inevitable is its impact. The planning question is always the same pair: where might the schedule slip, and where might the budget overshoot the estimate?

---

The project kickoff meeting

Note

Project kickoff meeting - the first meeting where the project team, stakeholders, and sponsor come together at the start of a project or a new phase. It grounds everyone in a shared vision, builds a shared understanding of goals and scope, and makes each person’s role clear.

It is the formal start of planning. Invite the people named in the RACI chart built during initiation, plus your stakeholders and sponsor so they hear the high-level plan and can share their perspective.

Why not just send the charter?

A fair objection - meetings cost time, and sometimes an email is enough. But on a project, especially a larger one with several people involved, the meeting does things a document cannot:

Establishes a shared visionAligns everyone on scopeBuilds team rapportLets people ask questions and offer insightSets expectations on individual contribution

The agenda

Templates vary, but most follow the same shape and run about an hour. Treat the timings as a starting point and flex them to the project.

Time	Agenda item	What happens
10 min	Introductions	Names and roles; a fun fact if time allows, to build rapport
5 min	Project background	How the project came about, why it matters, and the shared vision
5 min	Goals and scope	What is in scope and out of scope, the target launch date, key milestones
5 min	Roles	Who is responsible for what, for the whole duration
10 min	Collaboration	Shared tools (a plan in a spreadsheet, or work management software such as Asana) and how the team will communicate: daily email updates, a chat room, weekly check-ins
10 min	What comes next	Expectations for the coming period and each person’s next actions
15 min	Questions	The team’s chance to get clarity, and yours to hear their thinking

Running it well

1. Set the right time and length. Pick a slot that works for everyone, mind the time zones, and cap it at one hour. Front-load the key information so leftover time goes to questions and team building.

2. Invite the right people. Everyone with a role in developing or executing the project, and nobody who has no business being there.

3. Share the agenda in advance. Send it a day or two ahead, naming a speaker for each topic, so people can prepare, plan what to present, and arrive with questions.

4. Designate a notetaker. You will be leading most of the meeting, and presenting while taking notes does not work. Ask a teammate up front to capture key points and each person’s action items.

5. Stick to the agenda. Discussions drift; redirecting them back on topic is your job.

6. Consider recording it - useful for a large or dispersed team that wants to revisit it - but get every attendee’s permission beforehand.

7. Follow up afterwards. Email the group a summary of key points, outcomes, and action items, and invite anyone with further questions to reach out.

Tip

Two habits from the instructor. Invite people to add questions and feedback to a shared document as well as asking out loud, which creates space for quieter contributors. And poll the team’s confidence on the day’s topics on a scale of one to five, then ask the low scorers what would help. Only do this if you will actually deliver - your reputation for removing roadblocks is what the relationship runs on.

---

Milestones and tasks

These two terms carry the rest of the module, and the distinction is the thing to hold onto.

	Project milestone	Project task
Definition	An important point in the project schedule that shows progress, usually signalling a completed deliverable or phase	An activity that must be finished within a set period, assigned to one or more people
Nature	A moment in time - a checkpoint	A piece of work - something you do
Size	Big enough that a stakeholder would want to see it	Smaller; typically nothing a stakeholder needs to review
Relationship	Reached only by completing multiple tasks	Ladders up into a milestone
Example	Finishing the first draft of a report; getting customer sign-off on a major deliverable	Hire a writer; conduct research; draft a section

Project goalpublish the report / launch the service

↑

Milestonescheckpoints that prove progress

↑

Tasksthe actual work, owned by named people

Tasks ladder up to milestones, and milestones ladder up to the goal. Tracking runs on the middle layer.

Plant Pals worked example. One deliverable is a website where customers place orders and get support. Milestones on the way to launch include securing approval on the website design and implementing feedback from user testing. To hit the design milestone, the designer creates initial mockups, you review them and give feedback, and the designer implements that feedback - three tasks, one milestone.

---

Setting milestones

How to identify them

1. Evaluate the project as a whole. Go back to the project charter and re-read the goal.

2. List what the team must do to achieve that goal.

3. Pull out the big items that indicate progress - those are your milestones. Anything smaller, such as work no stakeholder would review, is a task.

4. Assign a deadline to each milestone, spacing them so the team has fair time for the tasks underneath.

For Plant Pals, securing design approval, completing website development, and implementing user feedback are milestones; mocking up initial designs and building a landing page are tasks.

Two ways to work out the split

Approach	How it runs
Top-down scheduling	Lay out the higher-level milestones first, then break the effort down into tasks, working with the team so nothing is missed
Bottom-up scheduling	Start from all the individual tasks that must happen, then roll them into manageable chunks that add up to a milestone

Setting the deadlines

There is no correct number of milestones - some projects have two or three, others dozens. Aim to mark the most important events rather than hit a number. When spacing them:

• Do not expect several milestones in a single week on a months-long project. Mocking up designs and gathering user-testing insights genuinely take time.
• Ask the team for estimates on the tasks under each milestone, then set the deadline from what they tell you.
• Consider stakeholder expectations - when will they expect to see a given deliverable? They want regular signs of progress, and milestones are how you show it.

Pitfalls to avoid

Too many milestones - each one loses its weight, and the project looks bigger than it isMistaking tasks for milestones - milestones are moments, not workListing milestones and tasks separately - they must be visible together in one plan

Beyond tracking, milestones do quieter work: they show how much effort is really required, reveal where you need extra resources, motivate the team, and make a large project feel manageable.

---

The work breakdown structure

Note

Work breakdown structure (WBS) - a deliverable-oriented breakdown of a project into smaller components. It sorts the milestones and tasks into a hierarchy, in the order they need to be completed.

Its value is psychological as much as organisational. Publishing a report or organising a conference is intimidating as a single lump; broken into a step-by-step path from start to finish, it stops being daunting. A thorough WBS also makes the surrounding work easier - estimating cost, building the schedule, assigning roles, and tracking progress all depend on seeing how the pieces fit.

The shape of it

A common design is a tree diagram: the project name at the top, milestones on the second level, and tasks on the third.

Plant Pals website launchlevel 1 - the project

↓

Secure design approval

Develop the site

Implement user feedback

↓

Mock up designs

Collect feedback

Build landing page

Run user testing

Level 1 the project, level 2 the milestones, level 3 the tasks that ladder up to each.

Building one

1. Start high-level. Brainstorm with the team and list the major deliverables and milestones. Planning a company event, those might be secure venue, finalise guest logistics, and establish agenda.

2. Identify the tasks needed to meet each milestone. Secure venue breaks into research venues, tour and decorate space, make down payment, and so on.

3. Break tasks into sub-tasks. Tour and decorate space breaks further into organise decorating committee, purchase decorations, assign decorating responsibilities.

Caution

The diagram itself is a thinking tool, not a deliverable - you would not normally put the tree into the official project plan. Instead you transfer the tasks it surfaced into a spreadsheet or your work management software, where owners can actually be assigned. Note also that the example above covers one deliverable (the website); in a real role you would build a WBS covering the entire project.

Once the WBS is done and the tasks are in a spreadsheet, two things are true: you have a set of discrete tasks laddering up to each milestone, so everyone knows what has to happen to reach the next checkpoint, and you are in a position to assign those tasks to named people in a sensible order.

---

Assigning tasks

Who gets what

Assignment normally follows a person’s role on the project. On the Plant Pals website: the designer mocks up the initial design, you review it and give feedback, the designer implements that feedback, and a developer then builds the site.

When several teammates share the same role, two extra factors decide:

Factor	How it steers the decision
Familiarity	Give each person the work they already know best - one developer takes the landing page, the other the contact page
Workload	Weigh time on this project against their other commitments; keep loads balanced

Caution

Overloading one person is not just unfair, it is a schedule risk. When people feel overloaded, work quality drops or the tasks take longer, and the project timeline is the thing that pays for it.

Writing a good task

Habits that prevent the classic miscommunication, using a tool such as Asana:

• Start the task name with a verb. Not website, but mock up the website or add images to the website.
• Add an assignee and a due date, so who-does-what-by-when is never ambiguous.
• Add detail in the task itself: a description, links to files or attachments, and comments on the work.

Why assignment pays off

The obvious benefit is that it frees you to manage the project rather than do it. The less obvious ones matter more over time:

Personal responsibility - assigning is an agreement that the person owns it to completionOwnership makes people more invested in the projectSpace for personal growthBuilds your own skill as a supportive delegatorKeeps the team motivated to finish on time

Tip

Full ownership can feel overwhelming for some people. Encourage teammates to support one another on their tasks - it lightens the load and builds rapport at the same time.

---

Revision summary

Tip

One-minute recap

• Planning starts only once the PM is assigned, goals, scope, and deliverables are approved, roles are set, and the charter is signed off.
• Planning maps the work, coordinates other teams and vendors, surfaces risk early, wins buy-in, and turns individuals into a team. Plans are expected to change.
• Three outputs of the phase: the schedule, the budget, and the risk management plan.
• The kickoff meeting is the formal start of planning - team, stakeholders, and sponsor, invited from the RACI chart.
• Agenda, roughly an hour: introductions, background, goals and scope, roles, collaboration, what comes next, questions.
• Kickoff practice: share the agenda in advance, designate a notetaker, stick to the agenda, follow up with a summary and action items.
• A milestone is a moment in the schedule that marks progress; a task is an activity done within a set period. Tasks ladder up to milestones.
• Set milestones by reviewing the whole project against the charter, pulling out the big progress points, then spacing deadlines using team estimates and stakeholder expectations.
• Top-down scheduling starts from milestones and breaks down; bottom-up starts from tasks and rolls up.
• Milestone pitfalls: too many, confusing tasks with milestones, and listing the two separately instead of together.
• A WBS is a deliverable-oriented hierarchy - project, then milestones, then tasks - usually drawn as a tree. Build it high-level first, then tasks, then sub-tasks.
• The WBS diagram is a thinking tool; move its tasks into a spreadsheet or work management software to assign owners.
• Assign tasks by role, then by familiarity and workload. Name tasks with a verb, add an assignee, a due date, and detail.

---

Next: Building the Project Plan → - schedules, estimates and the Gantt chart.