How to Set SMART Goals and Get Results | Google Project Management Certificate

SPEAKER: Welcome back.

By now, you should have a better sense of how the different parts of initiation come together to form the beginnings of a project.

So far you've outlined the key components of project initiation, and most importantly, you've learned that a lack of preparation during this stage can lead to problems later on.

We're going to continue honing your project preparation skills.

Once we're done here, you'll be able to define and create project goals and deliverables, the guiding stars of your project.

You'll also be able to define project scope, the boundaries of your project that state what is and is not part of your project.

You'll be able to identify what's in scope and out of scope for our project, and you'll be able to recognize scope creep, something you need to keep a close eye on to help you reach your project goal.

Finally, you'll be able to explain different ways of defining and measuring your project success criteria.

Before we get started, I'd like to talk through an example that will follow for the rest of this course.

Imagine that you're the lead project manager at Office Green, a commercial landscaping company that specializes in plant decor for offices and other businesses.

The director of product at office green has an idea for a new service called plant pals to offer high volume customers small low maintenance plants like little cacti, leafy ferns for their desks.

As the project manager, you've been tasked with managing the rollout of this new service.

As we go through this course, we'll return to your role as the project manager at Office Green to help teach you about project goals, deliverables, and success criteria.

You'll also see the role your team and stakeholders play in creating and following these three important components.

At the end, you'll compile everything you've learned into a shared document that you can use as a portfolio to share with future employers.

After this course, you move on to the next phases of the project lifecycle and so will your Office Green project.

Enjoy.

[MUSIC PLAYING] First things first, to set up a project for us and to make your job easier, you want to figure out what needs to be done before you actually get started.

You need to define exactly what your goals and deliverables are so that you'll be able to tell your team members what to do.

You need a clear picture of what you're trying to accomplish, how you're going to accomplish it, and how you know when it has been accomplished.

Let's define project goals so that you can start to figure out what your project team needs to do to reach it.

A project goal is the desired outcome of the project.

It's what you've been asked to do and what you're trying to achieve.

For example, your goal could be to improve the response time to customer inquiries via email by 20%.

The goal of your office green project might be to increase revenue by 5% through a new service called Plant Pals that offers desk plans to top customers by the end of the year.

Goals are important because they give you a roadmap to your destination.

Without a clear goal in mind, how can where to go or how to get there?

Now, one of the biggest differences between what makes a good goal and a not so good goal is how well it's defined, meaning how clear and specific is the goal.

If the goal is your destination, are you confident you'll know when you've arrived?

The examples I mentioned before to improve the response time to customer inquiries via email by 20% and to increase the office green revenue by 5% are too well defined goals because they tell you what you're trying to achieve.

But wait, there's more.

These goals also tell you how to do what you've been asked to do.

In this case, it's via email, through a new service offering, and that's not all.

These goals clarify the goal even further by saying to improve by 20% and increase by 5%.

Now we know where we're going.

Well defined goals are both specific and measurable.

They give you a clear sense of what you're trying to accomplish.

Really great goals have even more detail, but I'll get to that soon.

When you start a project take time to review your goals and make sure they're well-defined.

To do this, you might need to get more information from your stakeholders.

Talk to them about their vision for the project.

Ask how this aligns to the company's larger goals and mission.

By the end of that conversation, you and your stakeholders should agree to support the project goals in order to avoid running into issues later on.

Here's an example from my own experience as a project manager.

Our team have finished a new product feature.

Our stated goal was to deliver an early version of this feature and collect user feedback.

When we delivered the feature to one of our key customers for user feedback, the customer didn't have anyone available to try it out.

Our team debated whether or not we have met our goal if we hadn't collected user feedback.

Some felt that we hadn't achieved the stated goal while others thought we did.

The customer was satisfied with our team's ability to deliver a feature in the timeline stated, but our internal team wasted valuable time going back and forth about it.

That said, make sure that before you start your project, you, your stakeholders, and your team are all clear on the project schools so that you are making the right kind of progress.

I'll teach you a process for how to do this coming up.

Once you have the goals nailed down, it's time to examine the project deliverables.

Project deliverables refer to the tangible outcomes of the project.

In other words, a deliverable is what gets produced or presented at the end of a task, event, or process.

Take the goal to improve customer response time.

A deliverable for that goal could be the creation of email templates for responding to typical questions.

Your office dream project goal to increase revenues could have two deliverables, launching the plant service and a finished website the highlights the new kinds of plants being offered.

These are considered deliverables because they describe tangible outputs that show stakeholders how additional revenues will be generated.

There are all sorts of project deliverable examples.

A pretty common one is a report.

When a goal is reached, you can visibly see the results documented in a chart, graph, or presentation.

Deliverables help us quantify and realize the impact of the project.

Just like needing well-defined goals, you need well-defined deliverables for pretty much the same reasons.

Deliverables are usually decided up front with the stakeholders or clients involved in the project.

They hold everyone accountable and are typically a big part of achieving the goal.

Make sure to ask questions about what the deliverables should be and have everyone share the vision and expectations of the deliverables so you're all on the same page.

Coming up, you'll practice the art of defining your goals even further by following the SMART method.

Enjoy.

I already mentioned that goals should be Specific and Measurable.

The SMART method to evaluate goals adds three more considerations for success, be Attainable, be Relevant, and be Timebound.

Put them all together, and what do you have?

SMART goals.

As an entry level project manager, you may or may not be setting the project's main goals, but you will need to be able to identify and clarify them as needed.

And that's where the SMART method can be a valuable tool.

Let's take a closer look at each term.

As I've already mentioned, if your goal is not specific you will have trouble figuring out how long it should take to complete and whether or not you've accomplished it.

For example, if the goal was simply to improve customer service response time, that's not very specific.

It does tell you what you want to achieve in general, but it doesn't say anything else.

If you improve response time by 1%, is that enough?

If after five years response time finally goes up, is that enough?

How about if only half of your staff improves their response times, but the other half stays the same?

Specific goals should answer at least two of the questions I'm about to ask.

What do I want to accomplish?

Why is this a goal?

Does it have a specific reason, purpose, or benefit?

Who is involved, and who is the recipient, employees, customers, the community at large?

Where should the goal be delivered, and finally, to what degree?

In other words, what are the requirements and constraints?

Next, we want to set goals that are measurable meaning we can determine that they were objectively met.

Measuring is not only a way for people to track progress but also a tool to help people stay motivated.

You can tell if a goal is measurable by asking how much, how many, and how will I know when it's accomplished.

Sometimes the success of a goal can be measured with a simple yes or no.

Did you learn how to play guitar?

Yes or no.

You will need to measure most of the goals you have with metrics.

Metrics are what you use to measure something like figures or numbers.

For example, if your goal was to run a 5K, 5 kilometer race, then distance in kilometers is your metric.

At Office Green, the project goal is to increase revenue by 5%.

In this case, revenue is the metric.

Lastly, consider benchmarks or points of reference to make sure you're choosing accurate metrics.

For instance, if your overall goal is to increase revenue, you can look at last year's data as a benchmark for deciding how much to increase revenue this year.

If last year's revenue increased by 3%, then an increase by 5% in a booming economy would be a reasonable goal for this year.

OK, so the goal is specific and measurable, but is it attainable?

Can it be reasonably reach based on the metrics.

Typically you want goals that are a little challenging to encourage growth.

Otherwise, what's the point of the goal if nothing's going to change.

However, you don't want it to be too extreme, or you'll never reach it.

You'll have failed before you even started.

Aim to find a balance between the two extremes.

For example, let's take the goal to run 5K.

Say you regularly run 2.5 kilometers three times a week.

An attainable goal would be to go from running 2.5 kilometers to running five kilometers within four weeks.

An unattainable goal might be earning first place in 5K.

I mean, it could happen, but it's not likely, especially if you've never run a race before.

But how can you know if a goal is attainable if it's unfamiliar.

A clue to helping you figure out if your goal is attainable is to ask how can it be accomplished.

Break down the goal into smaller parts and see if that makes sense.

Going from 2.5 kilometers to 5 kilometers over four weeks means increasing your distance by a little over half a kilometer each week.

That's not so bad.

Use the same process on your Office Green project goal.

Businesses usually conduct quarterly reviews.

So let's assume the increase is expected to occur over the course of a year, four quarters.

In order to meet the goal, you need to see an increase of at least 1% each quarter.

Seems pretty reasonable to me.

What wouldn't be reasonable is setting a goal of increasing revenues by 50% or 100% unless your research showed that business was improving that quickly.

Your goal is specific, measurable, and attainable.

Now let's see if it's relevant.

In other words, does it make sense to try and reach this goal?

Think about how the goal lines up with other goals, priorities, and values.

Ask whether the goal seems worthwhile.

Does the effort involved balance out the benefits?

Does it match your organization's other needs and priorities?

Everyone from the client and the project team and the people who will ultimately use the product need to feel like the goal is worth supporting.

Also consider the timing.

Both the amount of time the project will take as well as the larger economic and social context can have big impacts.

There might be a budget to complete the project now, but will the company be able to sustain the project over time?

Is there an audience that will continue to use the product or service once it's delivered.

Once you've got the answers to these questions, you should have a clear goal to help steer the project.

If you still don't feel confident about the project's goals, keep digging.

It's OK to ask questions if you have doubts.

Communicate your concerns with the project senior stakeholders and your direct supervisor if you have one.

They should be able to address some of your concerns so that you can feel confident about moving forward.

All right, if you're feeling good about the project being relevant and attainable and you've made sure it's measurable and has the specifics to keep you and your project team focused, the final item on the checklist is to make sure it's timebound.

Timebound means your goal has a deadline.

Deadlines give you a way to track your progress.

Otherwise, you might never reach your goal or never even get started.

Time and metrics often go hand in hand because time can also be used as a metric.

Making your goal timebound gives you a way to break down how much needs to be accomplished over time.

For example, if you need to increase revenues by the end of the year, you can break down how much you need to increase each quarter, month, and week.

And there you have it, specific, measurable, attainable, relevant, and timebound, a nearly foolproof method to create and evaluate your project goals.

And you know what they say, work smarter, not harder.

[MUSIC PLAYING] Simply put your project scope includes the boundaries of a project.

The way we define a [INAUDIBLE] is an agreed upon understanding as to what is included or excluded from a project.

Scope helps ensure that your project is clearly defined and mapped out.

That means knowing exactly who the project will be delivered to and who will be using the end result of the project.

You also need a firm understanding of the project's complexity.

Is it straightforward with an easily manageable list of tasks, or will it require extensive research, multiple rounds of approvals, and a large scale production process that will take years to complete?

Scope also includes the project timeline, budget, and resources.

You'll need to clearly define these so that you can make sure you're working within those boundaries and what's actually possible for the project to work.

Poorly defined scope or major changes to your scope can cause changes to the budget, timeline, or even final outcome of the project.

Let's look at the scope of your Office Green project as an example.

As a reminder, the new Plant Pals service offers customers small low maintenance plants like cacti and leafy ferns that they can place on their desks.

Customers can order them online or from a print catalog, and Office Green will ship the plants straight to the customer's work address.

Things to consider for your scope then might be whether or not to provide replacement plants, which customer segments will be offered the service, whether or not the online catalog is an app, a website, or both, and how to ensure customers can purchase from the online catalog whether by phone, PC, Mac, iPhone, or Android.

You might also consider the dimensions of the paper catalog and whether it needs to be in color or black and white and on what kind of paper.

Now how do you actually figure out the scope of your project?

It's simple talk to your sponsors and stakeholders.

Understand what their goals are and find out what it is-- and this is really important-- what is not included in the project.

We've covered a number of different ways to help you determine scope.

Here are a few more helpful questions to add to the list.

Where did the project come from?

Why is it needed?

What is the project expected to achieve?

What does the project sponsor have in mind?

Who approves the final results?

Now you'll really be set.

As for timing, defining project scope to happen during the initial planning stage.

You want to start figuring out the scope early on so that everyone can't agree to the same set of expectations.

It will help mitigate the risks of big changes down the line.

Although you can always adjust the scope as planning continues if you need to.

Once you understand your project scope, you want to document all the details so that anyone can refer back to it throughout the lifecycle of the project.

We'll talk about some best practices for that at the end of this module.

Let's recap.

A clearly defined scope describes all the details of a project and regulates what can be added or removed as it progresses.

While it's ultimately the project manager's responsibility to monitor the project and make sure all the work and resources fall within its scope, team members and stakeholders can be encouraged to do their part by focusing on the tasks that are the most important to reaching the project's goal.

[MUSIC PLAYING] Tasks that are included in the project and contribute to the project's overall goal are considered to be in scope.

Tasks that aren't included are called out of scope.

It's your job as a project manager to set and maintain firm boundaries for your project so that your team can stay on track.

For example, if the copywriters or designers of the Plant Pals catalog came up with the idea to expand the type of plans being offered to top customers, you would have to point out that their suggestion is out of scope and would take extra time and add to your budget costs.

As you progress through the project lifecycle, you're going to encounter unexpected challenges or have new details or ideas brought to your attention that could impact your project success.

Changes, growth, and uncontrolled factors that affect a project scope at any point after the project begins are referred to as scope creep.

Scope creep is a common problem, and it's not always easy to control.

It's one that we struggle with on every single project.

It can happen on any project in any industry.

Imagine you're working in a tech company, and your project involves working with designers and engineers to update the language icons design on a mobile keyboard app for a smartphone.

While the team is making the update, they realize that the Search icon and the Voice Input icon also need a design refresh.

These are very small features.

And while technically not in scope, the team feels it would take minimal effort and provide lots of value.

So they go ahead and make the updates.

During a stakeholder review, it's pointed out that there is a keyboard in English but no keyboards for other languages, and the suggestion is made to design additional keyboards.

At this point, the project scope is in danger of expanding from a fairly simple icon update to a complex rollout of multiple keyboard layouts.

Adding the keyboards would impact the team's timelines causing the project to take longer to finish.

It would also impact resourcing because you would need to hire more people or existing team members would have to work over time.

And it would increase the budget since the team did not anticipate costs for extra working hours or keyboard translations.

This is just one example of scope creep.

Sometimes it's subtle, just design one or two more icons, or more obvious, hey, can you tack on designing keyboards for other languages.

By identifying scope creep and being proactive, you protect your project and your project team.

To help you combat scope creep, it's good to know that there are two major sources from which it comes, external and internal.

External sources of scope creep are easier to recognize.

For example, if you're working on a project with one main customer, the customer might request changes or the Business environment around you might shift or the underlying technology you're using might change.

While you can't control everything that happens, there are some useful tips to keep in mind.

First, make sure the stakeholders have visibility into the project.

You want them to know the details of what's going to be produced, what resources are required, how much it will cost, and how much time it'll take.

Also get clarity on the requirements and ask for constructive criticism of the initial product proposal.

It's important to get this information before any contracts are signed.

Be sure to set ground rules and expectations for stakeholder involvement once the project gets started.

Come to an agreement on each of your roles and responsibilities during execution and status reviews.

Once you're clear on the project scope, come up with a plan for how to deal with out-of-scope requests.

Agree on who can make formal change requests and how those requests will be evaluated, accepted, and performed.

And finally, be sure to get these agreements in writing.

This way you always have a documentation to point to if you, a stakeholder, or the customer have a disagreement down the line.

One of the leading causes of external scope creep is not being clear on the requirements before defining the scope and getting formal approval to move forward with the project.

This is where those specific immeasurable goals and deliverables come into play.

If the requirements aren't specific and if you haven't agreed on the project's processes, deliverables, and milestones, then you're almost guaranteed to be dealing with scope creep once the project begins.

Internal sources of scope creep are trickier to spot and harder to control.

This kind of creep comes from members of the project team who suggest or even insist on process or product changes or improvements.

It's possible that a product developer will justify a decision on the grounds of making the product better even though it's going to cost more, or a team lead might decide that a certain process is more efficient without realizing the impact the change in process will have on other team members tasked with different parts of the project.

What you need to make clear to your team is that any change outside of the project scope comes off the bottom line, threatens the schedule, and increases risk.

There are no small impacts to project scope.

Any time a team member takes on an unplanned task, more is lost than just the time spent working on that task.

It's your responsibility as the project manager to maintain the limits of the project.

The best defense is to know the details of your project in and out so you're always prepared with the most appropriate response to a new idea or request.

Let's recap.

Monitor your project scope and protect it at all costs.

Even the most minor change can mean major risks to your project's success.

Coming up, I'll tell you about the triple constraint model and how you can use it to help determine how your project changes affect scope.

Stay tuned.

[MUSIC PLAYING] Managing scope goes hand in hand with goal setting.

For example, redefining the scope can change the goal, and a revision of the goal can change the scope.

The concept of project scope is important throughout the project.

While your project will have its own specific goals, the overall goal for you as the project manager is to deliver the project according to the scope of agreements.

This includes delivering the project within the given deadline and the approved budget.

You'll quickly find that this is easier said than done.

As you progress through your project, you will continually need to make compromises and weigh trade offs as new challenges and changes and factors present themselves.

Any time a team member takes on an unplanned task, more is lost than just the time spent working on that task.

In order to decide if a scope change is acceptable and what impact it will have, project managers usually refer to the triple constraint model.

The triple constraint model is the combination of the three most significant restrictions of any project, scope, time, and cost.

We've talked a bit about what scope is, so let's focus now on time and cost.

Time refers to the project schedule and deadlines.

Cost includes the budget, and it also covers resources and the people who will work on the project.

Both time and budget have to be carefully managed alongside scope.

All three of these are linked.

You can't change one without having an impact on the others.

For example, a decrease in costs means a change in time or scope.

An increase in time means a change in scope or cost or both.

Understanding how changing one impacts the other two constraints is key.

It's important to consider what trade-offs you're willing to make as the project progresses.

To do this successfully, you need a clearer understanding of the project priorities.

You have to know what is most important when it comes to scope, time, and cost.

If there's a specific deadline that must be met, then you need to limit any changes to the scope that might cause the project to go past the deadline.

If the product must look or function in a certain way, then the requirements are a priority.

And you could justify changes in costs or time in order to meet the scope requirements.

But just because you can make a change, that doesn't mean you necessarily should make a change.

And even though the limits of scope, time, and cost have been set, you can still make changes if there's a good reason to do so.

Don't worry.

You won't have to decide on these changes all by yourself.

If there are scope decisions that need to be made, the project manager will likely need to consult with the project sponsor and stakeholders to get their approvals.

Let's go through a few scenarios.

So you can get familiar with weighing the value of a trade off and understanding the impacts of any changes.

In the first scenario, a request has been made to improve the Plant Pal's product features.

The director of product at Office Green wants to use pots to indicate when the plants need to be watered.

Making changes to the product is a scope change.

You know that you can't change the budget, but you can extend the timeline.

So you can accept the scope change request and extend the timeline as long as the budget doesn't increase.

Here's another possible scenario, a request has been made to reduce the budget without making any changes to the scope.

The final outcome of Plant Pal still needs to look and function as you all originally agreed.

If you're going to reduce the budget and keep the scope, you may need to extend the timeline.

OK, here's another scenario.

There's a request to tighten up the timeline and finish early, but you can't increase the budget.

In order to do this, you need to make changes to the scope like limiting shipping options.

Doing this will give your project more time because you'll have one less shipping contract to negotiate.

The end result won't be exactly what was originally agreed on, but it means getting it up earlier as requested and within budget.

Let's try one more.

In this last scenario, the director of product informs you that the project deadline must be met.

It's the most important thing.

In this case, your stakeholders are willing to increase the budget and make any necessary changes to the scope requirements in order to meet the deadline.

In the end, it's all about prioritizing which element of the triangle matters the most in the project.

Are you getting the hang of trade-offs?

Keeping in mind scope, time, and costs as you manage a project will help you navigate different conditions while still achieving your goals.

Remember, change is inevitable when managing projects, and understanding this framework can set you up to plan and communicate accordingly so your project will succeed.

[MUSIC PLAYING] Many people think the time to decide if a project is successful is when you've produced the final outcome and presented it to the client.

That's getting close.

Delivering the final result of your project to the client or user it's what's called a project launch.

You finish building or creating the project, the tasks are completed, and the deliverables are done.

You've hit your goal.

The project is successful and considered complete in that sense, but does it work well?

Did it achieve your desired outcome?

The real deciding factor of project success is when you put the final outcome to the test.

Landing is when you actually measure the success of your project using the success criteria establish at the outset of the project.

This is a crucial part of goal-setting that is often overlooked in the initiation phase.

For example, think about taking a trip on an airplane.

It's not enough for the pilot to be able to get the plane of the ground.

To arrive safely at your destination, they've got to know how to land.

Your success has to continue beyond the point of delivering the final project.

You need to be able to measure whether the project functions as intended once it's put into practice.

Let's take the example of your project Plant Pals.

You've managed to launch the new service with success.

The website has launched.

The catalogs have been printed and delivered.

Orders have been received, and revenue is starting to go up.

It will be easy to call this a win and move on, but what happens if the customers are unhappy once the plants are delivered?

What if the plants start to wilt and lose color after a couple of weeks?

Just because launching the project and getting it out the door looks like success on paper, that doesn't mean the project has managed to land.

For most projects, a launch itself isn't a meaningful measure of success.

It's what comes after the launch that really counts.

Launches are only a means to an end.

And looking beyond the launch, it's important to ensure the launch achieves your overall goals.

If you start off looking beyond the launch to the landing, you're more likely to get where you're trying to go.

Since landing is a concept and not a finite definition, it's important to define what a successful landing looks like for a particular project.

Luckily, we have a way to measure and help you ensure the success of your project.

It's called success criteria.

And if you can managed to follow it through the lifecycle of your project, you'll ultimately have a smooth landing.

The success criteria includes all the specific details of your goals and deliverables, and it can be a guide so you know whether you've accomplished what you set out to do.

Success criteria will set the standard for how your project will be judged.

[MUSIC PLAYING] At the beginning of the project, you defined goals and deliverables that are measurable meaning that you can determine if they were met.

Similarly, you need to define success criteria that can also be measured, so you'll know whether they were met.

The success criteria will tell you whether or not the project as a whole was successful.

They are the specific details of your goals and deliverables that tell you whether you've accomplished what you set out to do.

They are the standards by which the project will be judged once it's been delivered to stakeholders and customers.

Defining success criteria also clarifies for your team what they're trying to accomplish beyond just launching something to users.

Is it to increase customer satisfaction with the service, so they can continue to purchase more products?

Enhance an existing feature to retain customers?

Depending on the project, the answers will be different, but it's important that a team is aligned and working towards a shared goal.

Sometimes forcing the conversation and clarifying what the end result looks like can bring to light questions and areas of disagreement.

There isn't a set process for determining success criteria, but I'll break down a couple of key points to consider.

Remember the measurable part of your SMART goals?

One of the questions to ask when making your goals measurable is how will I know when it is accomplished.

The same question applies to your project.

How will you know when it's done?

Only in this case, you want to ask how will I know when it's successfully accomplished.

You can measure to determine your project's success in a similar way to measuring a goal.

So go through your project goals and deliverables, review the scope, and identify the measurable aspects of your project.

These are going to be any of the metrics used in the goals and deliverables along with your budget and schedule details.

Another thing you'll need to do is get clarity from stakeholders on the project requirements and expectations.

This is key.

There are lots of people involved with any project, and that means lots of ideas about what success looks like to each person.

You want to ask questions such as who ultimately says whether or not the project is successful, what criteria will be measured to determine success, what's the success of this project based on.

Once you've collected clarifying information, document and share all of it so that you, your team, and your stakeholders can refer to it later.

Let's try creating success criteria with the Office Green project.

For example, the goal is to increase revenue by 5% by the end of the year.

One of the deliverables is a website with a gallery of the different plant selections that are offered.

It's not enough just to make a list of criteria.

You need a process for measuring success from start to finish throughout the entire project lifecycle.

This way you can make adjustments and ensure success by the time you're ready to land.

There are many metrics you can use, and for some products, it will make sense to use more than one.

The metrics you choose should be as closely aligned to your project goal as possible.

For example, happiness metrics measure user attitudes and satisfaction or perceived ease of use.

And you can measure these through surveys.

For the plant pals project, we may consider a customer satisfaction rate of 85% within the first three months of launching as a way to measure success.

You can also consider customer adoption and engagement metrics along with more business oriented metrics that track things like sales and growth.

Adoption refers to how the customer uses and adopts a product or service without any issues.

Engagement refers to how often or meaningful customer interaction and participation is over time.

Adoption metrics might include launching a new product to a group of users and having a high amount of them use or adopted.

Engagement metrics might include increasing the daily usage of a design feature or increasing orders and customer interactions.

Using the office screen example, tracking how many customers initially sign up for and use the Plant Pal service is an adoption metric.

Tracking how many customers renew their plant service, post about it, or share feedback are engagement metrics.

Once you've defined the metrics that you'll be measuring, think about how you track these metrics.

Evaluate which tools can help you collect the data you need to ensure you're staying on track.

For example, if you're measuring business metrics like revenue, consider tracking that in a spreadsheet or dashboard where you can easily spot gaps and trends.

If you're measuring customer satisfaction, you can think of a way to incentivize customers to participate in regular email surveys and create a system to measure their responses when they participate.

You can also utilize your project management tools to check on efficiency metrics like what of tasks are completed or whether the project is progressing alongside the planned timelines.

It's smart to measure success with your team, as a project or product is in progress.

For example, you can hold a project review once a month, have team members complete tasks checklist by certain deadlines, or hold life feedback sessions with your users or customers.

There are many different ways to measure success.

The key is to pick the methods that work best for your success criteria.

It's a good idea that along with each success criteria on your list to also include the methods for how success will be measured, how often it's measured, and who's responsible for measuring it.

Share your success criteria document with your stakeholders and ask if they agree with how the project success will be determined.

It's also a good idea to have the appropriate stakeholders sign off on the success criteria.

This way everyone will be clear on who is responsible for which tasks, and you'll all thoroughly understand what the path to success entails.

Keep this documentation visible throughout the duration of the project and clearly communicate it with your team every step of the way.

They're the ones who will be attempting to meet all the different requirements, so don't keep them in the dark about what they're supposed to do or how they're supposed to do it.

If done correctly, defining your success criteria should create greater alignment within the team and give everybody better visibility into how to achieve success.

Clarity around success metrics also helps teams prioritize which efforts are most impactful to their users.

Defining project success is a complex but crucial part of project management.

With more and more practice, this process will come more natural to you in the planning stages and throughout your project.

ROWENA: Congratulations on finishing this video in the Google Project Management Certificate.

Access the full learning experience, including job search help, and start to earn your official certificate by clicking on the icon.

To view the next course in this video, click here.

And subscribe to our channel to learn more from Google Career