Initiation 2 - Goals, Scope & Success Criteria

Google Project Management Certificate · Course 2: Project Initiation - Starting a Successful Project

---

The running example

The whole course leans on one worked scenario, so it is worth pinning down once. Imagine being the lead project manager at a commercial landscaping company that decorates offices with plants. The product director has an idea for a new service - call it the desk-plant service - that would sell small, low-maintenance plants (little cacti, leafy ferns) to the company’s biggest customers for their desks. The job handed over is to manage the roll-out of that service. Every concept below - goals, deliverables, scope, success criteria - gets illustrated against this same project.

Tip

Why it matters: a lack of preparation during initiation is what causes problems later. Getting goals, scope, and success criteria nailed down now is the cheapest insurance the project will ever buy.

---

Goals and deliverables

Before any work starts you need a clear picture of three things: what you are trying to accomplish, how you will accomplish it, and how you will know when it is done. That is exactly what goals and deliverables give you.

Note

Project goal - the desired outcome of the project; what you have been asked to do and are trying to achieve. Goals are the roadmap to the destination: without a clear one you can’t know where you’re going or how to get there.

Note

Deliverable - the tangible or intangible product or service produced or presented at the end of a task, event, or process, and handed to the customer, client, or sponsor. Deliverables let you quantify and see the impact of the project.

A goal and its deliverables are linked. For the desk-plant service the goal might be “increase revenue by 5% through a new service by the end of the year,” and two deliverables that make that revenue visible could be launching the service and a finished website showcasing the plants on offer. A common deliverable type is a report - a chart, graph, or presentation that documents a result.

Well-defined goals

The single biggest difference between a good goal and a weak one is how well-defined it is - how clear and specific it is. A well-defined goal tells you what you’re achieving, and the best ones also tell you how and by how much.

Specific - clear, unambiguousMeasurable - you can prove it was met

Review your goals at the start of a project and, if they aren’t well-defined, get more information from stakeholders: talk through their vision, ask how it aligns to the company’s larger mission, and make sure everyone agrees to support the goal before work begins.

Caution

A real cautionary tale: a team’s stated goal was to deliver an early feature and collect user feedback. They delivered on time, but the customer had nobody free to try it, so no feedback was collected. The team then wasted time arguing over whether the goal was actually met. The lesson - agree precisely on what “done” means up front, or you’ll debate it later.

Deliverables should likewise be decided up front with stakeholders, because they hold everyone accountable and are usually central to hitting the goal. Ask what each deliverable should be and have everyone share their expectations so you’re all on the same page.

---

SMART goals

The SMART method turns a vague goal into a well-defined one. You may not personally set the project’s main goals as an entry-level manager, but you must be able to identify and clarify them - and SMART is the tool for that.

SpecificMeasurableAttainableRelevantTime-bound

The five SMART criteria - together they check that a goal is within reach and clearly defined.

Letter	Stands for	What it checks	Questions to ask
S	Specific	No ambiguity the team could misinterpret	What do I want to accomplish? Why? Who is involved? Where? To what degree (requirements & constraints)?
M	Measurable	Metrics prove when the objective is met	How much? How many? How will I know it’s done?
A	Attainable	The team agrees it’s realistic	How can it be accomplished? Does breaking it into steps make sense?
R	Relevant	Fits the org’s strategy and supports the charter	Is it worthwhile? Does the benefit balance the effort? Right timing?
T	Time-bound	A documented deadline	By when? How much per quarter / month / week?

Note

You’ll see variations - A as achievable or actionable, R as realistic - but the intent is always the same: keep the goal within reach and clearly defined.

Zooming in on the “M”. Measurable goals leave little room for confusion about expectations. Metrics are what you measure with (numbers or figures) - revenue for a revenue goal, kilometres for a running goal. Not every metric is valuable, so pick the ones that genuinely reflect the goal (measuring how many meetings engineers attend is a poor productivity metric; features shipped or issues flagged per day is better). Use benchmarks - points of reference like last year’s data - to keep targets accurate: if revenue rose 3% last year, aiming for 5% in a strong economy is reasonable; aiming for 50% without evidence is not.

Tip

Worked personal example: “I want a career certificate” becomes SMART as “Obtain a career certificate by taking one course per month within the next six months.” Specific (the certificate), Measurable (a tangible certificate at the end), Attainable (one course a month), Relevant (supports a career change), Time-bound (six months).

---

OKRs - Objectives and Key Results

OKRs are a popular goal-setting tool that takes SMART goals a step further. Where a SMART goal packs everything into one statement, an OKR separates the aspirational aim from the metrics that prove it - and clarifies both.

Note

OKR = Objective + Key Results. The Objective defines what needs to be achieved and describes a desired outcome (aspirational, motivational). The Key Results are the measurable outcomes that define when the objective has been met (tactical, specific).

Objectivewhat to achieve - inspiring & aspirational

↓

Key Result 1measurable · time-bound

Key Result 2measurable · time-bound

Key Result 3measurable · time-bound

One objective, typically 2-3 key results. The objective says what you want to do; the key results say how you’ll know you did it.

A key difference from SMART: key results should be ambitious - even stretch goals. If a team hits 100% of its key results every time, the OKRs were probably set too easily.

OKRs at different levels

Organisations set OKRs at several levels that must all line up:

Level	Purpose	Cadence
Company-wide	The ultimate goal shared across the whole organisation; supports the mission	Usually annual
Team / department	Support company OKRs; often specific to a job function	Varies
Project	Define measurable project goals during initiation; tracked through planning & execution	Set at initiation

Project OKRs must align with and support both company- and department-level OKRs. A company key result (e.g. “the top three most-requested new offerings are in pilot by end of Q2”) can itself become a project - which is exactly how the desk-plant service could be born.

Writing good OKRs

1. Set the objective - aspirational, aligned with org goals, action-oriented, concrete, and significant. Ask: does it help the overall goal? Does it align up and down? Is it inspiring? Will it make a real impact?

2. Add 2-3 key results - each should be results-oriented (not a task), measurable and verifiable, specific and time-bound, and aggressive yet realistic. Ask: what does success mean, and what metrics would prove we achieved the objective?

3. Document and share - link OKRs in the project plan, present them to the team, and assign an owner to every key result so accountability is clear.

---

SMART goals vs OKRs

The two methods overlap heavily - in essence, key results are SMART goals, and both trace back to management-by-objectives thinking. The difference is structural and cultural.

	SMART goals	OKRs
Structure	Everything in one statement	Aspirational objective + measurable key results
Metrics	Usually a single metric	Multi-metric (each key result is its own measure)
Ambition	Must be attainable	Deliberately a stretch; a “useful fail” is fine
Cadence	Often annual (some quarterly)	Quarterly or monthly - more agile
Contains an objective?	No - stands alone as a quantitative result	Yes - a strategic, inspirational objective
Best when…	You need a clear, discrete, trackable target	Goals are big-picture, will evolve, and need org-wide alignment

Tip

A neat way to remember it: SMART is “a necessary but not sufficient condition” - one piece of the puzzle. OKRs wrap that measurable piece (the key result) inside an inspiring objective that ties to strategy. Use SMART for discrete, well-defined targets; use OKRs when you want stretch, agility, and alignment across the whole organisation.

---

Project scope

Note

Scope - the boundaries of a project: an agreed understanding of what is and is not included. Scope covers who the project is for, its complexity, and its timeline, budget, and resources.

A clearly defined scope keeps the project mapped out and everyone aligned on the same expectations. Because a poorly-defined scope (or a big change to it) can blow up the budget, timeline, or final outcome, scope should be defined early, during initial planning, and then documented so anyone can refer back to it.

How do you actually figure out the scope? Talk to sponsors and stakeholders, understand their goals, and - critically - establish what is not included. Useful questions:

Where did the project come from & why is it needed?What is it expected to achieve?What does the sponsor have in mind?Who approves the final result?

When a request arrives underspecified - imagine a manager phoning to say “update the dining space” and hanging up - you probe across every dimension of scope: stakeholders, goals, deliverables, resources, budget, schedule, and flexibility (what’s the top priority - deadline, budget, or quality?). Cover the who, what, when, where, why, and how, and you reduce rework, expense, and confusion later.

---

In-scope, out-of-scope & scope creep

In-scope	Out-of-scope
Tasks included in the project	Tasks not included
Contribute to the project’s goal	Would add time, cost, or risk
Inside the agreed boundaries	Outside the agreed boundaries

It’s the project manager’s job to set and maintain firm boundaries. If a designer suggests expanding the plant range mid-project, the right response is to flag it as out-of-scope - it would add time and cost.

Caution

Scope creep - changes, growth, and uncontrolled factors that affect the project’s scope at any point after it begins. It’s one of the most common and hardest-to-control problems in project management; it happens on every project, in every industry. Even the smallest “harmless” change can mean major risk - there are no small impacts to scope.

A classic creep story: a simple task to refresh some icons on a keyboard app grows when the team decides to also touch a couple of nearby icons (“minimal effort, lots of value”), and then a stakeholder asks for keyboards in other languages too - turning a quick update into a complex multi-layout roll-out that wrecks the timeline, resourcing, and budget.

Where scope creep comes from

Source	Why it happens	How to keep it in check
External (easier to spot)	Customer requests changes; business environment shifts; underlying technology changes	Give stakeholders full visibility; get clarity on requirements before contracts are signed; set ground rules for involvement; agree who can make change requests and how they’re evaluated - and get it all in writing
Internal (trickier to spot)	Team members push process or product “improvements” - a developer gilding the product, a lead changing a process without seeing the ripple effects	Make clear that any out-of-scope change comes off the bottom line, threatens the schedule, and adds risk; know your project inside-out so you’re always ready with the right response

The leading cause of external creep is not being clear on requirements before scope is defined and formally approved - which is exactly where specific, measurable goals and deliverables pay off.

Tip

Note the sibling term: when the client adds scope it’s scope creep; when the project team adds unrequested polish it’s gold plating. Both expand scope without a matching change to time or cost.

Controlling scope creep

1. Define requirements and document them during initiation.

2. Set a clear schedule listing every requirement and the tasks to achieve it.

3. Determine what is out of scope and get agreement on the impact of proposed changes.

4. Provide alternatives - suggest other solutions and, if needed, run a cost-benefit analysis.

5. Set up a change control process - define how each change is reviewed and approved or rejected before it enters the plan.

6. Learn to say no - politely, by explaining the hit to budget, timeline, and resources.

7. Collect costs for out-of-scope work - document every cost incurred, including indirect ones, and say what they’re for.

Note

You can only avoid scope creep if everyone agrees on responsibilities, boundaries, and timelines. It takes clear communication, expectation management, and a well-defined path to the outcome. Sometimes the right call is to keep the original scope and point back to the original goal - for instance, refusing to expand a program’s audience when doing so would change the goals and strategies entirely.

---

The triple constraint

Managing scope goes hand in hand with goal-setting - redefining scope can change the goal, and vice versa. To judge whether a scope change is acceptable, project managers use the triple constraint model (also called the iron triangle).

Note

Triple constraint - the three biggest restrictions on any project: scope, time (schedule and deadlines), and cost (budget, resources, and people). The three are linked: you can’t change one without impacting at least one of the others. Quality sits in the middle - it suffers when the constraints are pushed out of balance.

Scopewhat’s delivered

Timeschedule & deadlines

Costbudget & resources

Change one side and another must give - you can be fast, cheap, or good, but rarely all three at once.

The skill is knowing your priorities so you can weigh trade-offs. A few worked scenarios for the desk-plant service:

Request	The trade-off you make
Add a product feature (self-watering pots) - a scope increase, but budget is fixed	Accept the scope change and extend the timeline (as long as cost doesn’t rise)
Reduce the budget with no change to scope	Keep the scope but extend the timeline
Finish early without increasing budget	Cut scope (e.g. limit shipping options) to free up time
Deadline is everything	Stakeholders increase the budget and accept scope changes to hit the date

Tip

Just because you can make a change doesn’t mean you should. Scope decisions usually need the sponsor’s and stakeholders’ approval - you don’t decide alone. The real value of the triangle is explaining to stakeholders why “faster” or “cheaper” always costs something elsewhere. (Modern practice notes there are often more than three constraints - quality, risk, resources, compliance - so think “octagon,” but the triangle remains the core mental model.)

---

Launch vs landing

A crucial idea that’s easy to miss in initiation: delivering the project is not the same as succeeding.

Note

Launch - delivering the final result of the project to the client or user (the build is done, deliverables handed over). Landing - actually measuring the project’s success against the criteria set at the outset, once the outcome is put to the test.

Like a pilot, getting the plane off the ground (launch) isn’t enough - you have to land it safely. The desk-plant service can launch perfectly - website live, catalogs printed, orders arriving, revenue ticking up - and still fail to land if the plants wilt and customers turn unhappy weeks later.

Caution

The common mistake is “launch and forget”: handing over the project, the client accepting it, and nobody ever checking whether the deliverables actually satisfied the user. If a five-year recycling-education goal is set but nobody checks back over those five years, the project only launched - it never landed. Launch and landing work in tandem.

---

Success criteria

Note

Success criteria - the specific, measurable details of your goals and deliverables that tell you whether you accomplished what you set out to do. They’re the standards by which the project is judged after delivery, and they clarify for the team what they’re really aiming at (beyond just “launching something”).

There’s no single fixed process, but the approach mirrors the measurable part of SMART goals - swap the question “How will I know when it’s accomplished?” for “How will I know when it’s successfully accomplished?”

1. Identify the measurable aspects - review the goals, deliverables, scope, budget, and schedule and pull out the metrics.

2. Get clarity from stakeholders - ask who decides success, what criteria are measured, and what success is based on. Every stakeholder pictures success differently, so forcing this conversation surfaces disagreements early.

3. Choose metrics aligned to the goal - often more than one; pick the ones that map most closely to what the project is for.

4. Decide how to track each metric - pick tools (a spreadsheet or dashboard for revenue, surveys for satisfaction, PM tools for task/timeline efficiency).

5. Document, share, and get sign-off - record each criterion with how, how often, and who measures it; have the appropriate stakeholders approve, and keep it visible and communicated throughout.

Kinds of metrics

Metric type	What it measures	Example
Happiness	User attitudes, satisfaction, perceived ease of use	Customer satisfaction rate of 85% within three months (via surveys)
Adoption	How readily customers start using the product/service	How many customers sign up for and use the new service
Engagement	How often / how meaningfully customers interact over time	How many renew, post about it, or share feedback
Business	Sales and growth	Revenue tracked in a dashboard to spot gaps and trends
Product quality	Completeness and quality of features, defects, unit cost, usability	% of priority requirements delivered; number of technical defects

Measure success throughout the life cycle, not just at the end - monthly project reviews, task checklists against deadlines, live user-feedback sessions - so you can adjust and ensure a smooth landing. Clarity around success metrics also helps the team prioritise the work that most impacts users.

Using OKRs to track and score progress

OKRs double as a way to define, communicate, and score shared success criteria. Share them, assign an owner to each key result, and grade them at regular checkpoints.

Scoring method	How it works
Yes / No	Simplest - 1 if the key result was achieved, 0 if not
Scale (e.g. 0.0-1.0)	Grade each key result (launch 3 of 6 features → 0.5), then average for the OKR’s score
Percentage complete	Score by how much of the objective was completed
Traffic light	Red = no progress, yellow = some, green = done

Tip

On a 0.0-1.0 scale the aim is an average of about 0.6-0.7, not 1.0. Scoring too low means the team is underperforming; scoring too high (consistently hitting 1.0) means the goals weren’t ambitious enough. Hold monthly check-ins and grade OKRs at the end of the quarter.

---

Same project, different perspectives

One reading is worth carrying forward: stakeholders will interpret the same project differently, and that’s completely normal. A resource owner cares about their people’s workload, a finance representative about spend, a customer about the end product - so conversations that you’d expect to clarify things can seem to complicate them.

1. Understand - learn each stakeholder’s position and why they hold it (including their standing relative to other stakeholders).

2. Assess - weigh each position against the organisational view; the sponsor is usually the baseline, but even sponsors carry bias, so keep reassessing motives if the project hits trouble.

3. Adapt - adjust to manage the variance. Often this means tailoring communication rather than changing the project: money-focused updates for finance, team-workload updates for resource owners, and always the context (why changes happened, how problems are being solved) - never one generic status update for everyone.

Tip

Focus on what each stakeholder needs and why, assess their motivations, and respond appropriately. You won’t remove the friction entirely - stakeholders are one of the most challenging parts of delivery - but you’ll build a far more satisfied group around the project.

---

Revision summary

Must-know	One-line recall
Project goal	The desired outcome - what you’re asked to achieve; the roadmap’s destination
Deliverable	Tangible/intangible output handed to the customer at the end of a task or process
Well-defined goal	Both specific and measurable; agreed with stakeholders before work starts
SMART	Specific, Measurable, Attainable, Relevant, Time-bound
OKR	Objective (aspirational what) + 2-3 Key Results (measurable, stretch, time-bound)
SMART vs OKR	Key results are SMART goals; OKRs add a strategic objective, multi-metric, more agile & aspirational
Scope	Agreed boundaries - what is and isn’t included; define early, document it
In / out of scope	In-scope tasks serve the goal & stay in bounds; out-of-scope adds time, cost, risk
Scope creep	Uncontrolled scope change after start (external + internal sources); gold plating = team-added
Triple constraint	Scope · Time · Cost - change one, another must give; quality suffers if unbalanced
Launch vs landing	Launch = deliver it; landing = measure success against criteria - don’t “launch and forget”
Success criteria	Measurable standards for judging success; documented, tracked throughout, signed off
Metrics	Happiness, adoption, engagement, business, product-quality
OKR scoring	Yes/No, scale (aim ~0.6-0.7 on 0.0-1.0), % complete, or traffic light

Tip

Key takeaways to remember for a quiz:

• SMART = Specific, Measurable, Attainable, Relevant, Time-bound - the test that a goal is clearly defined and within reach.
• An OKR pairs one aspirational objective with 2-3 measurable, deliberately ambitious key results; key results should stretch the team, unlike the “attainable” SMART criterion.
• Scope is the agreed in/out boundary; scope creep is uncontrolled change after the project starts, driven by external (customer/environment) and internal (team) sources - control it with clear requirements, a change process, and the confidence to say no.
• The triple constraint (scope, time, cost) means every change has a trade-off; know your priorities before you agree to one.
• A project succeeds when it lands, not just when it launches - measure against success criteria defined up front and tracked all the way through.