COMPLETE Google Project Management Certificate Course in just 2 HOURS

Hi everyone. If you've worked in or around project management over the last 5 years, or if you've wanted to learn about project management, you've probably heard about the Google project management certificate. This is a wonderful way to get up to speed quickly and also to see how Google thinks about running projects. So, we can get an insight into that.

More than 2 million people have enrolled for the Google project management certificate. And it's a great field to be in because there are over 400,000 open jobs with a median entry-level salary of $87,000. So that's in US dollars.

Now, there's just one problem, and that's the Google project management certificate takes more than 240 hours to complete. Now, I don't have 240 hours spare, unfortunately, and maybe you don't either. So, I've distilled the entire course all the way down into around an hour.

There are six courses and over 27 modules and it's a wonderful way to learn because it actually goes through the same way a project would be run from project initiation, project planning, execution and then agile project management which is very popular way to run projects at the moment and then looking at a project in the real world from start to finish. And of course we're starting with the foundations of project management just to get us up to speed. Here are all of the 27 modules and we'll go through these individually.

Let's get straight into the foundations of project management. Now, what is the definition of project management? A project is a unique temporary endeavor. So, it has a start and a finish date. It's not ongoing. It's not operations or regular business as usual. And it has a specific goal to deliver value. Project management is applying the knowledge, skills, tools, and techniques to meet those project goals and to meet the customer requirements.

The core responsibilities for project managers include gathering requirements from stakeholders, ensuring the project achieves valuable outcomes, so we're delivering value for the organization. Developing our project plan so we can see where we're going and how we're going to get there. Tracking and coordinating progress as we're going along, communicating those key milestones as we reach them to our stakeholders and to our project customers, and managing the project budget.

What is the value of project management? A 2017 project management institute study predicted that over 80 million project management aligned roles will be needed by 2027, and that's coming up quite quickly. Fast growing industries also include manufacturing and construction for project management, information services and publishing, management and professional services, finance and insurance, utilities and oil and gas. So all of these can have project managers which means that project management is a great skill that can move across many different industries. So that also makes it a great skill to learn.

The roles and responsibilities for project management. Junior project roles can often provide admin support. So the career pathway for a junior project manager might go from junior project manager to project manager to program manager who manages multiple projects to portfolio manager who uh manages multiple programs. We might also have project administrator, project assistant, project coordinator and project support specialist. The junior project management role might be called different names in your industry, but usually they're very similar in what they're doing. They're supporting the project manager and the admin of the project.

Traditional project management roles include the project manager who leads project initiation, planning, execution, monitoring, and closing. A project analyst who supports the projects with data analysis and information sharing. a project leader or director who drives project decisions and direction and is knowledgeable about the product. That could be a product owner or a product spon a project sponsor depending on the project type that you're running agile or waterfall for example and we'll get into that later don't worry. A project controller who focuses on project planning common in engineering or construction industries. A technical project manager who manages technical projects ensuring the requirements timelines and budgets are met. A project management office analyst who oversees complex projects and ensures timely progress potentially across multiple projects. Scrum master and product owner. These are agile roles and a scrum master facilitates the agile teams and ceremonies using scrum and teaches the scrum principles which we will get into later. The product owner guides product development and direction usually through the product backlog. So prioritizing the next feature to be delivered. Those are your roles and responsibilities.

Now, how do we become an effective project manager? Here are the core project management skills. We guide projects from start to finish. And the key skills include focusing on the customer value and clarifying the project goals so we make sure we're delivering something valuable to the organization. Building a high-erforming team and managing a high performing team. Effective communication with our team, with our stakeholders, with our customers. Prioritization of project tasks so we're doing the right next things next. Delegation of project tasks to our project team and the right people. Holding team members accountable for their tasks so we make sure that they are getting done. Tracking tasks issues and risks and measuring and reporting on that project progress. We're also planning and organizing, budgeting and cost control. And one of the main things is handling and working through ambiguity because we have to take a lot of these requirements from our customers heads and turn them into deliverables that we're going to deliver to make sure that they receive that value and we do that with calm discipline if we can. Negotiation is also needed working with teammates to find compromises when we need to.

The project management life cycle and methods that we might use. Here are the general project phases and tasks. So, every project is unique with different resources, people, products or systems, locations and constraints, many different things, but they typically follow four major phases. We initiate the project, then we plan out our project from start to finish, then we execute and perform and do our project. And then we close our project once we've delivered that value with transitioning the project into operations. The last step this is launching our project. So we're releasing the product versus landing which is ensuring it is embedded and gets the results that we wanted. That's one key thing in the Google project management certificate that they do call out launching which is releasing versus landing.

As we initiate our project, we're going to define clear project goals and deliverables. We'll identify the resources needed, the people, tools, locations, and even vendors. We'll create a project proposal and get approval to proceed with all of these resources and access to those resources.

As we plan out our project, we're going to develop the project budget and schedule, define team roles and responsibilities with our team, plan for risks and possible changes or delays without budget, technology or legal issues, and we'll communicate the plan to the team and stakeholders so everyone is aligned. Never skip planning. Good planning reduces risks in the future. And we'll even do planning on an agile team which we will come across later on. So don't let anyone fool you into thinking that we don't plan on different projects.

As we execute our project, we're going to manage the project progress. So we're not doing every task oursel, but we're making sure that those tasks are getting done. Ensure the team knows what to do, when to do it, and how to do it. We'll remove obstacles that slow down progress, so any blockers and anything that we need to escalate. Communicate frequently with our team and stakeholders via meetings, emails, chat, and reports. And we'll adjust the schedule, the budget, and the resources as needed, and keep everyone informed on our progress as we're going along.

When we close our project, we're going to verify all tasks and deliverables are complete. will get formal acceptance from the project's requesttor or client, which could be the project sponsor, whoever is paying for the project, that the outcome meets their expectations. We'll conduct a retrospective with our team to reflect on what worked and what didn't work. This is our lessons learned. We'll make sure that invoices are paid, resources are returned, and documentation is finalized. We'll share the project results and the lessons learned with stakeholders, the people impacted or who are interested in the project, and then we'll celebrate our team's hard work with thank you emails or even a party for big projects.

There are many different project management methodologies, but there are two broad types that we're going to look at, and those are linear and iterative approaches. Linear being step by step or sequential which is commonly referred to as a waterfall project. Iterative uh meaning that we're taking feedback and improving and changing our approach as we're going which is commonly referred to as an agile approach.

The waterfall method was created in the 1970s by Dr. Winston W. Royce and it follows a sequential order of phases initiating, planning, executing and closing. It's useful when scope is clearly defined or when there are not going to be many changes or when changes are going to be very difficult once we've started. Changes require a formal change request in this case. So we are going to be an active leader prioritizing and assigning tasks with our team.

For agile on the other hand, its roots go back to the 1990s according to the Google project management certificate, but actually it's from 1986 and even earlier in the Toyota production system. 1986 was the new new product development game which was developed in Japan and that's where the term scrum originally came about which is very very cool. It became official in 2001 with the agile manifesto. Now agile follows the project life cycle but phases can overlap. Tasks are completed in short iterations. An iteration could be 1 to four weeks usually where we deliver something useful or usable to our customer so they can see it, feel it and give feedback and then we can adjust our approach. Typically we combine agile with K with a KBAN board for visual progress. This focuses more on client feedback and delivering quickly and adapting to changes. The product owner will rep prioritize the list of features for the next highest value feature in their product backlog. In agile, we're more of a facilitator. We're removing blockers and removing barriers for our team and helping them grow.

Now, there is also lean six sigma which follows the demake methodology. This aims to reduce variation or defects in a process. uh six sigma itself means 3.4 defects per million. So a very very low defect count. Deic stands for define the problem. Measure the problem. Collecting all of our data and understanding the current process. Analyzing the problem. Identifying the root cause of the issue and gathering making sure that we're analyzing that data. Improving the problem. Developing and implementing solutions. and then controlling the problem, making sure that it remains a low variation with low defects in the future and improving again if we need to.

In six sigma and lean six sigma, we'll also come across the eight wastess and 5S. These are real these are a really great way to look at quality and to improve processes. The eight wastes also have a great acronym which wasn't in the Google project management certificate, but this is the way that I like to remember it. It's downtime. We're looking for defects and rework because we want to remove those to improve. We're looking at over production. Hopefully, we're not producing too much when it's not needed. We're looking at waiting. Can we reduce weight time in our process? Nonutilized talent. If we've got a lead engineer working on sweeping the streets, it's probably not a great use of their time or the money that we're spending on having them there. Transportation is also seen as a waste. uh as we're traveling with our transportation, uh that takes time and that time is a waste. It's not adding value to our customer. Inventory. Too much inventory piling up is also money that we have spent. And if it's not going out and being sold to the customer, that's also a waste. Extra motion, extra movement, and excess process steps or excess processing. Common causes of these eight wastes are lack of proc proper documentation or process standards, not understanding the customer needs, lack of communication, and inefficient process design. And I love that because that's just such a wonderful way to get up to speed on improving a process quickly. The eight wastes, fantastic stuff.

5S is also pretty cool. We have sort our area, which is removing unnecessary items, set them in order, organize them and label them. Now we're starting to work more quickly because we can access things quickly and there are no unnecessary items. We'll shine and clean and maintain our area daily. Standardize with a uh consistent tasks and a process and sustain all of this by doing it over and over again to maintain discipline and maintain perfection. Now all of these things they can work in an engineering or in a software development environment. Also look at refactoring our code and look at look at keeping things in repositories where it makes sense and the naming conventions are clear. So 5S is still a wonderful way to work, not necessarily just in a physical environment.

As we work in projects, we're going to come across the organizational structure and culture which can influence how we do things. Organizational structure is the arrangement of company roles and relationships. It can usually be shown as a visual map just like this on an organizational chart. So that shows our business owner and the different departments and who's the lead and who are the teammates in that area. That's a classic or functional top-down hierarchical chain of command. For example, the CEO goes down to managers goes down to teams. But we also might have a matrix structure which is a crossf functional team. This is where we come across our product teams because we have someone over here from development, someone over here from analysis, someone over here from testing, someone over here from the business. And all of those people come together to form a team from their different disciplines. That's our matrix structure. And this is why we need a project manager to help coordinate all of these people towards that common business goal. Organizational structures define accountability and communication frameworks.

Now, one extra thing that they didn't mention, but we might have a flat structure where we've got our CEO and we've got someone talking to the customers on the phones. Because it's flat, they can talk directly to the CEO. But a more hierarchical structure, we have to go through layers to get to and talk to the CEO. That's just a little sidebar there. Different styles will give the project manager different levels of authority. So be aware of the structure that you're working in. Either way, we want to clearly define our roles and responsibilities with our team.

We might have a project management office, which is a group within an organization that defines the project management standards and acts as a centralized hub to coordinate all the projects. They typically do strategic planning and governance defining and aligning project selection criteria. So how are we selecting projects? What are the business goals that we are trying to meet? Best practices in project management with standardized processes and tools to use. Project common culture where we train employees on our project management approaches just like this Google project management certificate for example. Resource management, where we're allocating people, equipment, and budget across projects based on the right business goals and priorities, and project documentation and tools, where we're developing and maintaining tools and software for project management. That's our PMO or project management office.

Governance is the management framework that defines who makes decisions, who is accountable and responsible, and how activities are controlled. There is governance for the organization and governance for the project. Organizational governance is usually around performance metrics. Are we meeting those metrics? Accountability structures just like we saw. Is it flat or is it hierarchical? Organizational goals and values that we are trying to meet. But project governance is more around project policies and procedures, roles and responsibilities within the project, monitoring and change control, how a change is made and regulations and compliance that we need to meet.

Organizational culture is the shared values, mission, history and behaviors within a company. It's like the company's personality and it influences how employees work, communicate, and make decisions. Culture eats strategy for breakfast, says Peter Ducker. It influences how do people prefer to communicate? How are decisions made? What rituals welcome new employees? What project management styles do they prefer? And what behaviors and expectations exist? Is it overtime, social events? Is there a work life balance? All of these things become part of our organizational culture.

Change management on a project is the process of delivering your completed project and getting people to adopt and accept those changes in the organization. It's often led by someone else. So, a change manager or even a manager within the organization, a senior leader, or perhaps a change team. Best practices for change management include being proactive. We include stakeholders in the upcoming changes. Incorporate change management into the project steps. So don't forget about change management. We need to get feedback and perform demonstrations to the people who are receiving the product. Communicate regularly with our stakeholders and follow a consistent change management process. You might come across ADCAR or ProSai or the William Bridges model. There are many different change management processes uh that we can look into and follow. Practice empathy because change can cause anxiety with people and use tools to support adoption with surveys, flowcharts, and even culture mapping. We can ask how will the organization react to our change? Who are the influencers who can drive or resist the change? And what are the best communication channels? Are we doing a demonstration? Are we doing a a big bang release? Are we doing emails or training or process changes? what change management practices will lead to that successful adoption of our new product.

And there we have our foundations of project management. Well done. You've gotten through the first course. Now, we're going to go into our project process from start to finish and into agile with project initiation.

What is project initiation? It starts when a problem or opportunity is identified by senior leaders. We perform research on its feasibility. Is the benefit for the problem or solving the problem worth the cost of solving it? We determine the necessary resources to solve the problem and we document the initial project scope that we'll need to deliver to solve the problem. The key components of project initiation include our project goals. What are we trying to achieve? What opportunity are we going after? The project scope or deliverables which is the work required to complete the project and it could be tangible or intangible with product features, training sessions or even documentation that we're delivering as part of our product. Success criteria, how do we measure and know that we've met our goal? Stakeholders, who are the people affected by the project or involved in the project, and the resources that we're going to need, the money or the budget, the people or the physical materials that we need to complete that project and deliver that value.

Once we have that, we can create our project charter. This summarizes the project goal, the project scope, any milestones, and any resources that we're going to need. The project charter requires approval before the project proceeds because we're going to need access to all of these things which usually comes from the project sponsor and that gives us access to all of these things. The uh the resources that we need and the funding that we need to start and complete our project.

We perform a cost benefits analysis. To assess our benefits, we ask things like what value is this project going to create? How much money can it save or earn the company? How much time will it save? And how will it improve our user or customer experience? There could also be things like intangible benefits, which is an improved customer or employees satisfaction. Maybe we're rating our satisfaction out of 10 and it's gone from a two to an eight. That's definitely an intangible benefit that can help us in the future. Increased employee productivity, enhanced brand perception and recognition. All of these things, they can actually translate into monetary benefits down the track, too. So, they're a good thing to know.

Now, to assess our costs. How much time are people going to spend on creating this product or this project? What are the one-time, ongoing, or long-term costs that we're going to need to spend money on? Now, there are intangible costs as well. We could have risks to customer retention, employee morale, or brand image. So, these things can be harder to measure, but they're still very important. We can estimate values by reviewing similar past projects, conducting industry research, and consulting experts to get the values on those costs that we might be spending for our project.

We put it all together with a return on investment or ROI calculation. Now, with an ROI calculation, we use the expected financial gains minus the total project costs. Uh, and that's upfront and ongoing. So, remember those ongoing costs because it doesn't just stop sometimes once we've delivered our project. But now we've got 6,300 divided by 10,000. That gives us 63%. Typically, Google recommends to go for anything above 10% with our return on our investment.

As we initiate our project, we're going to define the goals and success criteria and the scope for our project. We can clearly define our project goals before we begin using smart goals. You might have heard of these. This is where we h want specific goals that clearly define what's to be achieved, who is involved, and any requirements or constraints. We want it to be measurable, including metrics to track progress and how we determine what success looks like. We want them to be attainable. The goal does have to be realistic based on the data that we have. We want them to be relevant. We want the goal to be worth pursuing and it aligns with our company objectives. and timebound. The goal does have to have a dead deadline. When are we going to deliver it by?

Another great way to define project goals is with OKRs, which is objectives and key results. An objective is just a statement of what we want to achieve. And the key results are how we measure it. The metrics that we're going to use to measure success. So again, a great way to define our success criteria for our project. They can be at the company level, the department level, or even at the project level that we're delivering.

There are many different metrics that we can use to define success. We can have happiness metrics, customer satisfaction via surveys that we send out. Adoption metrics, how many customers are are using our product or service and how many more are we getting? Engagement metrics, which is the frequency of use or the quality of user interactions. and business metrics which is sales growth or revenue growth, money coming in to the company.

As we define our project goals, we can align our team and stakeholders. We want to clarify success criteria early as early as possible. Document what will be measured, how often it will be measured, and who is responsible for measuring it. Share this widely with the team and get sign off from our stakeholders so everyone is on the same page.

Once we have our goal, we can define our project scope. This defines the boundaries of the project and it includes the deliverables. What are we producing? Our stakeholders, who are we producing it for, and our timeline, which is our budget and our resources included, when are we delivering it by? With scope, we want to be very careful and avoid scope creep. This is uncontrolled changes in the scope after initiating the project and it can come from many different places. It could be external where we've got requests or changes coming from customers as we're as our project is going along. Shifts in business or technology and these things really do happen and it's a difficult thing to manage. But this is why we have our change control process on our project and this is why we're clear on our goals so that we know where we're heading. Changes can come internally with the team improving the scope without considering the impacts maybe where uh this might actually be called gold plating as well. You'll come across it where we're adding features or making it better but the customer didn't actually ask for it and now we've spent more time on it than we should have and our project's a little bit behind.

There are three main constraints on a project and that is our project scope which are our deliverables, the schedule or time that we're delivering it in and the cost that we or the budget or the money that we have to pay for the resources that we need to deliver it. Typically we can ask do we want it fast so low time do we want it cheap so low cost or do we want it good with more features? Changing one of these will usually affect the others. So if we have more scope, it's going to increase the time and increase the cost. Or if we want to reduce the time and cost, it's probably going to reduce the scope. All of these things, one of them will affect the other.

We're going to work with stakeholders as we initiate our project. Selecting the right team is critical. We want to start with the roles based on the project needs. For example, if it's a software project, we're not going to get people from our construction project team. Consider the team size. Too large can make communication difficult. In fact, the more people we have on our team, uh, communication channels increase exponentially. There's a formula for this, and I won't go into into it here, but just know that the complexity increases quite quickly with the more people we have. So try and keep your team small if you can. Check availability and motivation of our team. People excited by the project will work better towards our project goals. Match our skills to the roles. If skills are missing, we can select people by their attitude. A great attitude willing to learn and then plan for training as we go through our project.

Typical project roles include our project sponsor who's accountable for the project. They control the funds and resources. They ensure the project delivers the agreed business value. They're also an escalation point if we need to and they sign the project charter and get us access to the funds and resources to start our project. Team members who do the day-to-day work to get the project done. Customers who receive the value from the project. The users who are the end users of the system or the item that we're delivering. Not always the same as a customer. For example, we could be we could have users of a a system, but they use that system to serve external customers. So now we have both and we have to keep both in mind. Stakeholders who are anyone invested or affected by the project and the project manager who plans, organizes and oversees the entire project. That's you.

With our team, we want to put together a racy which stands for who is responsible for an item. Who is accountable or signs off? Who is consulted? Who provides their expertise? And who is informed? Who do we need to keep informed of the changes? This will help clarify roles and responsibilities with our team. So, put down any deliverables or any tasks and write down your racing. We want to list all the stakeholders impacted by the project and then assess their influence and interest. So their level of interest in the project, for example, if we're delivering it to their particular department, they're going to have a high level of interest. And if they control the funds and the resources for our project, then they're going to have a high level of influence. That's typically our project sponsor, high on both of those things, and we want to collaborate very closely with those people. If they have a low level of interest, but a high influence, we can consult and meet their needs. and a low level of interest and a low level of influence. We just want to monitor our stakeholders. You might come across a steering committee which is made up of the high interest and high influence stakeholders for our project. They have the power over the budget, scope and schedule. The project manager provides them updates on how the project is going but is not a member of the steering committee.

To get buyin from our stakeholders, we want to explain how the project aligns with their goals. If in doubt, overcommunicate and overcommunicate as early as possible. Projects fail because of unclear expectations, unrealistic expectations. Maybe we want to get it done in a week when really it's going to take uh two or 3 months. Miscommunication, a lack of the necessary resources, and of course, our favorite scope creep.

Now, how about the resources and tools that we need to succeed on our project? During initiation, we typically want to identify the resources we need to achieve our project goals. The typical resources are our budget, which is how much the project will cost, including materials, vendors, taxes, and fees, and people that we need. The people, internal team members, external vendors, and even the project manager themselves, materials, for example, physical items, lumber or plant inventory, or even locations, uh, an office space that are needed if we need to pay for those. Then the tools to track and manage project tasks, the budget, and team collaboration. And we'll look into team tools later on.

Project managers track and communicate decisions on the project. Documentation ensures that nothing gets lost so everyone can stay informed and it creates a historical record of those decisions and ensures that we have transparent ways of working and we can see why we made decisions even if we look back from some time in the future. We will document project goals and the problems that are being solved, the scope and deliverables, the stakeholders who are involved, the required resources, and any major decisions and changes that we've made along the way. We can use emails, presentations, and shared digital documents to communicate some of this documentation and the things that we've done and the decisions that we've made.

The project's charter during initiation formalizes our project. It outlines the goals, the scope, and the stakeholder agreement to proceed that we do need this change and we're going to do it. It demonstrates that the benefits outweigh the costs of our project. And once it's approved by our project sponsor or our project customer, it gives the project manager authority to begin the project. A senior leader might start initiation with a project proposal within their company to persuade stakeholders and gain buyin, but we end initiation with a project charter to officially begin our project.

The tools that we're going to use will help us centralize information, communicate with our team, and then track things like our task progress, deliverables or milestones that we're reaching, the budgets and how much we've spent, contracts or licenses that we're working with, and any updates from our stakeholders, which might include changes to our scope. We're going to have tools like scheduling and work management software, Asana, Trello, Smart Sheet, Jira or Microsoft Project. You might come across productivity tools for example Excel, Word or PowerPoint or Google Sheets and and the Google equivalents of those and collaboration tools which include email, Slack messaging things or MS Teams, many different ways to collaborate. Video messaging or video software that we're going to have conferencing tools. All of those things are ways that we're going to collaborate. And now we've done our project initiation and we've done two courses in the Google project management certificate. Well done. You are doing an amazing job. It's time for us to start moving into planning our project.

As we begin the planning phase, planning is important because it helps everyone understand the work that's going to be needed to get the job done. It coordinates efforts across many different teams with our cross functional uh team members, remember from all those different areas, different contractors, different vendors. It identifies and prepares for any risks that might come up, delays, staff changes or scope shifts as we're proceeding and and progressing with our project. It enables brainstorming and mitigation strategies for those risks. It builds buy in by gaining team support and stakeholder support. And it fosters teamwork and shared understanding of everything that's going to happen.

We're going to plan for things like our project schedule, putting our scope items and seeing when we can deliver them based on our team's estimates for their duration and cost. We're going to plan out our budget, how much all of that might cost to deliver. And then we'll plan out our risk, so any things that might impact our project in the future so we can plan for them and mitigate those and hopefully keep them under control.

Get the team aligned with a project kickoff meeting. Get everyone together. It's the first formal meeting where the project team comes together to align on a shared vision, understand the project goals and the scope. So, we'll tell them about the project scope and what we're going to deliver and also clarify individual roles and responsibilities. And remember how we do that? We've seen some of those already. We've seen our REI. What does that stand for? Again, it's respons who's responsible, who's accountable, who is consulted with their expertise, and who do we need to inform. We've also got our organizational breakdown chart. And we can do that for our project, too. So, here's our project manager, Billy, and he's got some business analysts, developers, and testers on his project. And the project sponsor who is paying for all of those things to happen. Project stakeholders and our here our project sponsor again. Very important people to include in our project kickoff meeting.

We're going to plan for milestones and tasks. There are significant points in the project schedule that mark progress. Usually, they indicate completion of a deliverable or a project phase. And they help track whether the project is on schedule or if we're offtarget. They also help clarify the workload and boost stakeholder confidence that we are delivering what we said we would deliver. And that it's great to break these down into smaller chunks. So instead of delivering it in one big bang, now we can see whether we're on track because we've delivered these milestones and they've been delivered on time.

Now how do we set project milestones? We review the project goal. We list the key deliverables or phases. We determine the number of milestones and assign deadlines to those milestones. Consult our team for estimates on how long things might take. And with that, because it's early days in our planning, we want to build in a small buffer. We'll talk about this a little bit later in this course. We want to consider stakeholder expectations. So, do they expect that it's going to be delivered sooner, but we have to negotiate and manage those expectations with our stakeholders depending on the estimates that our team give us and the buffer that we build in. So, now it's all starting to come together, isn't it? It's actually pretty cool.

We're going to have project tasks, which are specific activities that need to be done within a set time frame. Multiple tasks make up the work required to reach a milestone. So, we're going to have many different tasks and ultimately deliver on this particular milestone on this particular date. For example, we might have hiring a writer and conducting research is the first draft complete milestone. So, they make up that milestone.

How do we set tasks? There are two main ways. Top down and bottom up. Top down is where we're breaking down. We come up with the milestones first, then break them down into tasks to complete those milestones. Similar to a work breakdown structure where we have the project name, then we have our main milestones or features that we're delivering, and then we break those down into the tasks that we need to deliver those features. But we can do it the other way, bottom up, where we start with all of the tasks that we're going to perform and then we group them together by their features or a certain progress date. We want to assign tasks clearly by role. Again, making sure the right people are assigned to the right tasks. Balancing the workload across our team and using those tools like Asana, Jira, Microsoft Project to track those tasks, make sure they're getting done and making sure that they are on track.

As we build a project plan, this is our living document that serves as the road map for the team throughout the project. It's basically our process. So, our strategy, how are we going to deliver this project? This is our project plan. And we can include things like the project goals, the scope and the work breakdown structure which we just saw, milestones which we've seen as well, the stakeholders roles and responsibilities, our budget and costings and any other management plans like change management, risk management and communications or stakeholder management. All of these things are how we're going to operate our project.

Project managers assign tasks and estimate their duration with the team's input. Our team will know best on how long it's going to take them to complete their work. So, we need their input. We can estimate with them for time or effort. And we want to ask the right questions. For example, use open-ended questions. How long does this usually take? Not, can you have it done by next week? Now, both of those question formats are useful, but as we're gathering information from our team, we want to use open questions if we can negotiate effectively and dig deeper to uncover work when necessary. For example, is there anything else that we're going to need to deliver as part of this feature that we might have missed? Practice empathy with your team and appreciate their efforts because they are the ones uh putting their information out there. And beware the planning fallacy, the human tendency to underestimate time costs and risks due to optimism bias. So we're being too optimistic. I have seen this happen so often, especially with new product owners or new project managers. Uh, we have to be so careful with this. As you do more projects, you'll start to see and build in the right amount of buffers for the time that it takes to do things.

Now, and here we are here. Build-in buffers. Thanks Google. That's great advice. Um, to absorb unforeseen delays, task buffers and project buffers. Task buffers is for our individual pro uh tasks. And then for the overall project, we might build in a slight buffer as well. Generally the earlier we are in planning the more buffer we want to build in because there's more uncertainty around what uh is going to get done and the risks or the changes that might arise. Just keep that in mind.

Now we're going to create our network diagram which is basically the sequence of tasks and dependencies. Some tasks might have to happen before another task can happen. That is our dependencies. uh but some might be able to happen at the same time. And when we're doing our network diagram, this is where we come to find our critical path. The critical path is the longest path of tasks that must be done in sequence. So in other words, if any tasks move on that critical path, it's going to affect our overall project schedule because there's no wiggle room. And in fact they call that wiggle room float or slack in the schedule. So I hope that makes sense. But for example, if this was our uh critical path here and this task moved out, then that's going to make uh that's going to impact our overall project schedule. But if, as you can see, we've got some wiggle room here. So if this task moved out, then we've got float or slack that we can use and it's not going to impact our overall project end date. So that's pretty cool. That's our critical path.

And once we have all that, we can create our schedule or a which is usually a Gant chart using spreadsheets or it could be Microsoft Project or we could use Jira or Asana. Many different ways to do it. It's basically our uh deliverables or tasks who it's assigned to and then it shows it on a calendar. When are we proposing that we're going to finish these? This is one in Excel that I've done and it's just so beautiful. I use it all the time and stakeholders just love that particular Gant chart. It's a great way to show our deliverables and when we're going to deliver them.

We might use a KBAN board especially in agile to give visual insight into our tasks and to help smooth handoffs between our team members. What we've got here is uh typically we have columns so to do uh development or in progress testing and then done. You can call these columns anything you like but it just shows the flow of our work from left to right. And when it moves into analysis, then one of our analysts can pick up that work. When it moves into development, one of our developers can pick up the work. A user story card can have a unique ID or a title, a brief description of the task or the deliverable, an estimate of the effort required, and usually that's in user story points. So we might have three user story points here or five. Uh, we'll get into this later actually. So we'll talk about that in more detail and who it's assigned to. And so now we can clearly see the flow of our work on our KNBAN board.

We're going to manage uh our budget and procurement. A project budget estimates the monetary resources needed to achieve project goals. It's created during initiation and the planning phases and it's continually reviewed throughout the project life cycle. Budgets are also broken down by milestones. So we saw on our milestone chart, how much does it cost to get to this particular milestone and this one and then the third one. This is a great way to break down our budget. Budgets aren't arbitrary. We need to understand the real costs out there in the marketplace. We want to estimate with our team, get expertise from vendors or maybe commercial databases. And we want to budget for surprises by including a buffer if we need to for any unforeseen delays. Project sponsors, finance departments or executives usually review and approve the budget and any changes. And our initial approved budget is our baseline. So we need to monitor that once we start the project and update it as necessary if we're spending more or less. and we may need to rebaseline our budget if a significant change happens. So keep that in mind and that's when we're going to need that review and approval process with our sponsor, finance department or other executives depending on who we've agreed for our project process. So that's a lot but I hope that makes sense. Uh, like generally we need approval if it's a large change.

Types of cost that we're going to come across we might have direct costs and indirect costs. Direct costs are wages and salaries of our people, materials, equipment rental, software licenses, traveling related to the project, and training related to the project. Indirect costs could be things like administrative over expenses or overhead, utilities, insurance, security, or general office equipment.

As we mentioned, we want to leverage the expertise of our team when we're estimating costs. We can also reference historical data. For example, another project might have cost a similar amount on a similar project. So, we can use that as a guide. We also can use a bottom up approach where we uh estimate all of the tasks, the cost for all of these tasks and then we aggregate all that cost up to the total project cost. That's a bottomup approach.

The cost of quality is something that we need to be aware of in project management where we also budget for the costs associated with preventing any quality issues. So how do we prevent quality issues? Maybe we refactor regularly and we build in time for that. Maybe we train our staff correctly uh or maybe any different things to prevent quality issues. To appraise quality issues, this is our testing or quality assurance activities. we're finding defects and fixing those defects. Internal failure is if we find a defect within our project and external failure is if we find a defect or if the customer finds a defect, if it reaches outside of our team, outside of our project team. So be aware of the cost of quality.

Other budgeting terms that we're going to come across are cash flow, which is the movement of cash in and out of our project. Are we getting funding into our project? And are we spending money on people and materials and resources? So, in and out. Capex and OPEX is another thing that you'll come across. Capital expenses are upfront investments like buildings, equipment, or vehicles. And OPEX are operating expenses, things like wages, rent, utilities. And this is often recurring costs. You might need to know these because this is where our funding comes from within the business usually. So it might come out of someone's capex budget or it might come out of their OPEX budget. But either way, we need to be aware of this. This might impact how much money we have and how easy it is for changes to happen in our budget.

Other things are our contingency reserves and management reserves. Contingency reserves are is a buffer for any risks that might happen. And management reserves is another buffer on the overall project that requires project sponsor approval to use and it's usually a percentage of the total project cost for any unexpected issues outside of our control.

We're also going to want to plan procurement and any vendors that we're going to want to use. Procurement is the process of obtaining all the materials, services, and supplies needed to complete the project, especially if it's external from our organization. Vendors are individuals or businesses that provide those things. So those goods or specialized services, they could also be contractors or they could be providing physical goods. Typical procurement steps are we research and

source the vendor. We get quotes comparing costs. We select the best fit for the project's needs. We write and review and negotiate the contracts. Then we set the deadlines and manage vendor performance as we're going along and ensure that we're making or receiving timely payments.

Other procurement tips include always check the vendor's reputations for quality and timeliness and interview them if you can or do site visits if possible. It's really like hiring an employee. We want them to be the very best and make sure they're delivering the quality that we need. Always review contracts with legal and compliance teams for clarity, for the legality of them and how do we enforce those things and the ethics behind those contracts. Conduct regular check-in meetings to track and control progress with our vendor as our project is going along.

Common procurement terms we're going to come across are NDAs, RFPs, and SOW. So, non-disclosure agreements are when we protect confidential information and prevent leaks to competitors or the public. So, we can't talk about things in our project. It's like the first rule of our project. We don't talk about this project if we have an NDA. We're going to have the request for proposal to get bids from vendors by outlining project details and requirements. What do we need? What are we proposing uh that they provide for us? The statement of work is the details that we want them to deliver. So the the work agreements with our selected vendor and it typically includes uh a header, the revision table, which revision version is this, the purpose of the statement of work, the scope and deliverables that we want them to deliver, the milestones and maybe dates that we need them to deliver by, the hours and schedule that they'll be working, any other terms, conditions, and disclaimers, and the terms of payment. So, that's a great little cheat sheet just for our statement of work that might go into our vendor's contract.

We're going to want to manage risk on our project. And risks are things that might impact our project or our product in the future that we can brainstorm and create responses for. Now, we can use many different ways to find risks and see what might impact us. We can use brainstorming with our team discussing all the possible risks with our team and stakeholders. Expert interviews where we consult subject matter experts or SMEs who can see operational risk in their particular area. They're going to be experts in the business that they do every day. Checklists. There might be existing risk checklists in the organization. SWOT analysis, which is analyzing the project's strengths, weaknesses, opportunities, and threats. That's a great way to brainstorm risks. Assumptions analysis. What did we assume to be correct when we started the project? Uh, and maybe those things are changing. That's going to cause us some issues in the future. Document reviews, for example, our contracts, the processes, even previous retrospectives for lessons learned. Uh, risk workshops with our team and any historical data, past project data and performance to find recurring risks, risk tools and techniques that we're going to use. We can look at our RACI chart. Remember that very handy to see who we need to invite to these risk workshops. And then a cause and effect diagram, which is also known as a root cause analysis diagram or an Ishikawa diagram after the person who created it. This is uh to find the root cause of risks and hopefully to try and solve them that way. There are different ways we can look at cause and effect. The basically it's a bunch of buckets that we brainstorm into. So uh what are the issues around people? What are the issues around the process, the system or any information? And a great way to remember this is PIPS, people, information, process and system. There are other buckets that you can include. It's not locked down. So just do something that makes sense for yourself, your product, and your team.

When we're analyzing these risks, use a judgment-free approach and focus on the conditions. So the processes and how it comes to be, not the people themselves. The people are usually uh a byproduct of the system or the conditions that they're operating within. So keep that in mind and and be nice and be gentle and be open with our team. Use a risk register to list potential risks with their description of the risk, the owner, and our risk response and then a risk rating. We can get our risk rating by multiplying the probability of the risk occurring. Is it one or five? So one might be low, five is going to be high. So how high a probability is this going to happen? Let's say it's a five. It's very probable it's going to happen. And then the impact, what is the impact if it does occur? Again, is it one to five? And we multiply these two things together. This is a really nice and easy way to do it. Let's say the impact is only going to be a two. It's quite a low impact. So we multiply those two things together and we have 10 overall. If you could guess, the highest uh risk rating would be 5*5 and 25. So this is just a nice way to do it. Consider the organization's risk appetite. Maybe we already have a bunch of risks in the organization, an overall risk profile of let's say uh 12 or 15 and we don't want to go above that when we're delivering our new product. And we'll look more into risk later on. All of these great things, the risk uh risk matrix over here and the risk register for keeping our risks.

Common types of risks could be time risks where things take longer than expected. Budget risk where items cost more than we expected. Scope risk where deliverables fail to meet our project goals that we started out with. External risk, for example, natural disasters or legal changes. And single point of failure when we rely on one critical person or one critical system and there's no backup then that's a pretty nasty risk especially if it does happen. What's the impact? The impact could be quite high then maybe that's a five. Dependencies could be internal or external when one task relies on another and those tasks become delayed. Now that is starting to get risky. There are different types of dependencies that we're going to come across. Finish to start, which is where task B can't start until task A finishes. Now, here's the trick with this uh finish to start. So, the second one can't start until the first one has finished. And the second one can't finish until the first one has finished. And we'll see an example of that. As you can see, this second one can't finish until the first one has finished. Now the second one can't start until the first one has started. So that matches up. So that's a start to start. And the last one, the second activity cannot finish until the first activity has started. So that's the trick to showing your dependencies and the different types of dependencies that you'll have. The most common one, of course, is our finish to start that you'll see on a normal project under normal circumstances.

There are also four different risk mitigation strategies that we're going to come across. We could avoid the risk. For example, we might use a different supplier. We could minimize or mitigate the risk, which is reducing the impact of the risk. Typically, we call this putting in a risk control. So now we're reducing that risk impact or the probability of it happening. We might transfer the risk and typically that one is done with insurance. Remember we pay a premium like your car insurance. We pay $1,000 to car insurance for example and they take on the risk if we have an accident. That's transferring the risk. Or we could accept it. We could set aside extra budget with active acceptance. Or we could just do nothing with passive acceptance of the risk. And all of these things will help contribute to our project risk management plan. Again, our plan, which is our risk management process. We're going to have a header, the document objective, an executive summary, and the included risk register of all of our risks. Now, that's what's mentioned, but I'll add a few things just from my own experience. We're going to have risk classifications. So how are we classifying our risk high impact high uh high probability the risk categories and this is a wonderful way to brainstorm risks with a a list of existing risks in the company. Uh this is just the categories risk definitions. So what does low probability mean? What does low impact mean? Is there a dollar figure? Is there a time figure? We define those risks roles and responsibilities and the acceptable delivered risk. So our risk thresholds for the organization. So that's just a little bit added there. A little bit of bonus risk things for your risk management plan that I really enjoy including in my own risk management plans.

Now communicating and resolving risk. We want to identify and assess risks. It's useful only if we're also communicating those things to our stakeholders. We're going to have low-level risks. We can just make a simple mention of it in weekly emails or reports. Medium level risks. Maybe we want to give more detailed explanations and use a direct email to the affected person and include a link to the risk management plan if we need to. Now, high-level risks, we're going to want to present these or discuss them in meetings with the affected person and add a special risk review as a formal agenda item so everyone is on the same page and we know that those things have been communicated.

As we plan our project, we're going to need to communicate a lot. Communication is the most important tool for project success. Success or failure often depends on how well everyone understands their roles and their tasks. So, communication should be clear, honest, relevant, and frequent, but not overwhelming. If in doubt, typically we want to overcommunicate uh and especially give people the opportunity to receive that communication or not if they're not interested. It includes clarifying goals and client expectations, following up on action items with our team, reporting delays or issues as they arise, and it can be done with meetings, emails, phone calls, written documents, and formal presentations. Some people say that more than 90% of running a project is communication. So, we want to get really good at it.

When we create our communication plan, it should address what needs to be communicated. Who needs to receive that communication and when do we need to send that communication? Why do we need to communicate it to them? How are we going to communicate? And where is the communication information stored. So these are a wonderful uh list of things that we can include in our project management plan. To fill out a communication plan, we want to identify the communication types and we can use our stakeholder map or our trusty RACI chart. We want to define the recipients who's going to get it. Set the frequency and key dates. Choose the delivery methods. as it meetings or presentations or emails. Define the communication goals and assign senders and owners for each communication type. It might not always be us. So, we need to make sure that the roles and responsibilities again are very clear when we're communicating.

Documentation is important because centralized storage improves accessibility and efficiency. If everyone can access those communications, then they can see it and act on it as necessary. Documentation builds visibility and accountability with our team. If we've assigned tasks to people and it's visible, then everyone can see it's assigned to them. There's more accountability. Permissions and information sharing control for sensitive information. Continuity and knowledge management. If someone leaves then we have that documentation and that can have the information that we might have needed. Sharing the right information with the right people at the right time. So don't overwhelm senior leaders with the minutiae or the minor details. Communication artifacts that we might have. They describe and showcase the work that we're doing on a project or a program. Examples can include executive briefs or summaries that we send out to high-level leaders, roles and responsibilities sheets, project plans and timelines so everyone is clear on what's being delivered and when and status reports for our project that we might give to our steering committee. If you remember, we can provide that information. Vendor instructions or contracts and any documentation that captures our process and the progress that we're making on our project.

And now we've made it all the way through initiation and project planning. You have done a fantastic job. In fact, so fantastic we can move all the way onto project execution. It's time to perform the things we need to perform and do the things we need to do to deliver that value. And the first thing we're going to do in project execution is look at tracking our project. Project tracking is following the progress of project activities to monitor work completion. So how are how is the work going? We want to track the status of key tasks. We want to track the project schedule and progress towards our milestones to make sure that the project stays on track. We also want to track the project costs to make sure that we're not overspending or even underspending. Making sure that we're still on track. Any scope changes to avoid any unforeseen project impacts. Remember our triple constraint. If we're adding a whole bunch of scope, what's that going to do? That's going to impact our cost and our schedule at the same time. Changes in capacity or personnel. If our best developer leaves, then that's really going to impact the time and potentially the cost and maybe even the scope on our project. So, we need to track that risks to avoid future issues and key decisions and dependencies that we make on our project as we progress. We can use Gantt charts, road maps, and even burndown charts that we'll come across in agile. We've seen the Gantt charts. Road maps can just be the high-level tracking of big milestones. Could be a milestone chart. Could be a schedule network diagram like this with the order of things that we're delivering. And a sprint burndown chart shows us the ideal trend of our work over time and then how we are actually going. So is it going uh slower or is it going faster? Uh that's our burndown chart. It's the burndown of our work until it gets to zero.

We can communicate tracking with our project status report which includes the project name and the report date, a current summary of the project. So key accomplishments and key challenges that we've faced in this maybe it's in a two-week period for example. The status so red, amber or green is it uh typically we want it to be green. Uh, if it's amber, then we might need a little bit of help or to escalate it. If it's red, then it's well behind or it's well over budget or there's a real issue that we need to look at straight away. Milestones and tasks and any current issues that we're facing or that need to be addressed as we execute our project.

We're going to need to manage the dependencies. This is when one task relies on another to start or finish. Like we saw, remember our start to start, finish to start, all those different dependencies, they're often the biggest source of risk because delays in one task can cascade to others. It's like dominoes falling. So all of a sudden a small problem becomes a big problem, which is why we need to track it and stay on top of it. We might have internal dependencies within the same project or system, external dependencies outside the project team, mandatory dependencies that have to happen legally or contractually required. And discretionary dependencies, they're at our discretion. They're not required, but we decided to do them for better risk control or better project control. We're going to need to manage all of those dependencies and those different types. To manage them, we need to identify them, uh, brainstorm them with our team, record the dependencies, make sure they're noted, use a risk register if we need to, or, uh, use the dependency when we're putting in our features. So, is this feature dependent on that particular one? Monitor and control those dependencies. Hold regular meetings to check progress on related tasks. And watch for any of those dominoes because we don't want them to start falling and we want to communicate those dependencies. Make sure all our team members are clear that this particular task uh has future dependencies and we need to get it done so that they can happen at the same time. Uh, so very, very important again it comes back to our communication.

As we manage changes on our project, there are different types of changes that can impact us. We might have new or changing dependencies. For example, like we've seen, it's the biggest source of risk. Uh, we don't want those dominoes to fall. Changing priorities. Uh, let's say the technology changes and we've got new circumstances. That's going to be a change for our project. Changes in capacity or the people who are on our project. Team members might change and that's going to impact us. Any budget or resource limitations, scope creep, that big bad thing that we saw earlier on, try and keep that uh to a limited amount or try to limit scope creep because it could gradually expand and then that's going to affect our triple constraint, our cost, our uh schedule, all of those things. And the last one, force majeure. Uh, I hope I've pronounced that correctly, but unforeseen major crisis preventing contract fulfillment. So just one big horrible uh crisis basically that's going to happen. And that's why we put buffers into our schedule and our budget to to just in case those things do happen. Always compare any changes that we make against our project baseline, which is what we planned at the very beginning. So, we might have our ideal scenario and are we spending more? Then that's not good. But we need to track it either way. We can use our statement of work and our RACI chart to see who's responsible, accountable, consulted, and informed. If milestones are at risk, customer sign-off might be required before adjusting the scope, budget, or deadlines. So, keep that in mind.

In agile, scope change is expected. So, we actually remember it's an iterative approach. All the way back when. Uh, so we actually expect change and we just re-prioritize the backlog to make sure we're always delivering the next most valuable feature. That's how we use how we do change and that's typically done by the product owner who owns the product. In waterfall, we're going to use a change request though. Now that is a form to document and manage changes. Important fields that we can include on a change request might be the project name, discussion owner, discussion type, so is it a risk, is it a change, is it an opportunity, the teams involved, the expected outcome, is it a priority change? What's the impact? Uh, what's the impact on our goals or our milestones? The target date for the discussion, the description of the current situation and what we're proposing the change is going to be and any tradeoffs with data and background information so we can really make an informed decision on the nature of this change. It's very important.

And the last one here, risk management, is where we identify potential risks and issues that could impact our project and then we brainstorm and apply any steps to address those risks. Key techniques to manage risks include managing changes, dependencies and scope creep. So controlling our dependencies, remember we can brainstorm with our team to find risks that might happen based on that. And then we want to prioritize those risks based on remember our risk impact and our probability. And we multiply those one to five and one to five. Multiply those together. And that gives us our different types of risks. Is it severe? Is it sustainable? Or is it critical? You can see on this risk matrix I've got uh words. So very low to very high. But that also corresponds with one, two, three, four, five. Just so you know, that's another way to do it. We can use the ROME technique for managing risks. This means uh we say the risk is resolved. We eliminated it. It's no longer a problem. Is it owned by someone? So it's assigned to a team member to manage. Is it accepted or it's agreed to be accepted without any action? Or is it mitigated? we've taken actions to reduce the impact or the likelihood of that risk.

As we proceed on our project, we're going to manage quality and continually improve as much as we can. There are four key concepts of quality management and we'll see these a few times in the Google project management certificate. We've got quality standards which are requirements or guidelines that we have to meet. We've got quality planning which determine which standards apply. So we're planning this is our strategy remember our quality management plan. We've got quality assurance which is uh the ongoing evaluation of the product. So we're testing the product over its life cycle. We might do tests, audits, reviews, uh shoulder checks, stakeholder check-ins, many different ways to make sure that we're catching those defects before they reach the customer. And then quality control happens after the product delivery to identify and fix issues. And just down here, it's a bit small, but this is a control chart. If we've got different defects occurring, uh this is going to show us whether our process is in or out of control. If we've got too many defects occurring, then we really need to have a look and see if we need to improve that process.

We can measure customer satisfaction for quality. The goal is to create a high-quality product after all and it meets our customer expectations. Understanding what the customer wants is essential and it's the best way to do this is through structured methods. for example, surveys to our customer, feedback surveys, interviews or focus groups with our customer, online surveys or tools, and even user acceptance testing with our customer. So, we're testing and they're getting their hands on the product to see if it works for them.

As we perform user acceptance testing with our users and our team, these are the steps that we're going to go through. We'll define the acceptance criteria. So step by step to reach our goal. We'll create the test cases that we want them to execute. We'll select real end users of the system. We'll write UAT scripts based on user stories. This is uh typically for a user story. As an employee, for example, I want to locate and email the vacation policy so I can uh get the response that I need or whatever it is. What's the outcome that they need there? That's a typical way to write acceptance criteria based on a user story. We'll communicate our expectations to our users. Prepare the testing environment. Make sure we have the correct testing environment and the data involved. Provide step-by-step instructions to our team. And then document everything, any defects or issues, and document the ones that worked, outcomes with screenshots, and track those bugs or defects, and track the change requests that we might get as we find defects and need to improve them.

For quality, we'll look at data-driven improvement, always finding the data. Continuous improvement is ongoing effort to improve products or services. Process improvement is improving our existing processes. You guessed it, could be for our team or our customer. And we can often use things like DMAIC, which we've seen. Remember, define the problem, measure the problem, analyze it, find the root cause, improve it, and then keep it under control. Or we might use PDCA or Plan-Do-Check-Act. This is the Deming cycle from W. Edwards Deming or the Shewhart cycle as well. It's also called Plan. We identify the problem and brainstorm solutions. We implement a fix. We do it. Then we check the results to see if we got what we wanted and then we act or sometimes we adjust. So refine the solution to ensure long-term uh success. That's our Plan-Do-Check-Act, quality cycle.

There are projects, programs, and portfolios that we need to be aware of in project management. A project is our just our single temporary effort to deliver a single change usually uh or a new product or a new service. A program is multiple projects related to the same issue or area uh to achieve long-term business goals. A portfolio is a collection of projects and programs and sometimes operations. So it's everything that's required uh to manage centrally those things across the entire organization. So that's our portfolio. And then lastly for quality management, we can have a retrospective which is a meeting or workshop where the team comes together to reflect on their process or the project in a in a project or phase to see how we're going and what we can improve. So we can hold them at the end of a sprint. Remember our sprint could be one to four weeks. Could be after a key product launch or key deliverables. Could be after we've missed a deadline or miscommunicated somewhere or if there's any other issues or after major milestones or project completion. And for our retrospective, we're going to typically ask a few things. We'll ask what worked well, what didn't work well, what did we learn, and what still puzzles us with the aim to get this information and feedback so we can improve our process going forward. So, we want to do it as often as possible, usually every two weeks. Keep a positive tone. Use anonymous feedback if we have to. If our team are not comfortable giving their feedback or changes or challenges, work as a team and don't blame and take action items for any challenges that do arise.

As we're improving and executing our project, we're going to want to make data-informed decisions. So, there's different data types on a project. We might have productivity metrics which is our project uh our progress output and milestones that we've reached. Quality metrics which are defects or even missed requirements with our customer. Happiness and satisfaction metrics and this could be for our team. Uh for example, a team temperature from one to 10 or customer satisfaction in the product from one to 10. Again, it's a nice easy way to measure it. Or you might have the Net Promoter Score. You'll probably come across that. Um, it's not in scope for this, but just another way to do it. Adoption and engagement metrics for our product. Data are raw facts and numbers about a project. Metrics are when we're measuring and defining those measurements to track a specific part. For example, productivity or our schedule or our milestones. Analytics is analyzing all of that data to find patterns and answer questions and even to predict outcomes. For example, how are we spending more on our project? So, we could possibly predict that we might continue up in this particular trend instead of the trend that we had planned, which uh again, what's that going to do? Impact our other things in the triple constraint. So, very good to know. Quantitative data is numerical, measurable facts. Qualitative data is descriptive and subjective information. For example, user feedback.

We also want to be ethical when we're looking at and using data. Uh, data ethics include data privacy. Make sure we're securely handling personal data. Encrypt it. Anonymize it if we can and if it's necessary. And be aware of data bias, which is ensuring our survey doesn't skew answers in a particular direction. Maybe we want a a particular answer, so we ask a question in a certain way. And uh politicians are great at that by the way, but we want to be aware of those biases and we don't really want to put them in our questions because we want the true facts if we can so that we can act on them properly. We want to present that data fairly.

Now, we'll compare and analyze all of that data to draw meaningful conclusions on our project like our cost. Is it too much? Is it not enough to solve problems? How do we solve that budget problem? Do we need to reduce the resources? Do we need to reduce the scope? Is it impacting our triple constraint? And make smart decisions as we analyze our data. We're going to ask, define the problem clearly and specifically prepare and collect the right data, process the data, so clean the data, remove any duplicates, ensure it's complete, analyze the data to find trends and patterns and insights. And we might use Excel for example, Microsoft Excel to do this or a similar program. We can share those our findings with data visualization. Make sure we've got nice charts so people can see it clearly and then act and implement solutions based on the insights that we get out of all of our analysis. I do love visual and data analysis. It's very, very good especially when we're getting the right decisions. It's wonderful stuff.

We can visualize and present that data in many ways. Dashboards, burndown charts, remember our burndown chart, uh shows the ideal trend, bar charts, you've seen pie charts, uh in infographics, we might see. Use visuals to illustrate your trends, frequency, relationships, values, and risks. And it's just good to show so our audience can understand. Define our audience. Who are we showing the data to? Choose a focusing question that we want to answer with our data. Gather the right data, choose our visualization method from one of these methods. Uh then and we use that to tell our story. So where are we? Where do we want to be? What does the data show? Gather feedback by performing a practice run with someone on our project before we present that to an executive so they don't get the wrong idea. We get some practice as well, which is really nice.

Now, leadership and influencing on our project, as we're executing our project, we're going to need project teamwork. Leadership is enabling the team to create something meaningful. Use active listening and remove obstacles or blockers with our team. Five key factors of team effectiveness. And this is from Google research. I think I remember this one. If I'm not mistaken, this was Project Aristotle. Uh, now when was this? Was this in 2011 or 2016? Maybe somewhere in the 2010s. Uh, project psychological safety a really big thing. Uh, these are the things of high performing teams basically that Google found so very handy to know. Team members feel safe to have an open dialogue without fear of embarrassment or punishment or rejection. Uh, psychological safety means that everyone has a voice. Dependability. Team members can reliably complete their work on time and meet expectations. We can rely on Bill to finish his work. Structure and clarity. Everyone understands their roles and responsibilities and how it fits into that bigger picture. Our project goal meaning is team members find personal or collective purpose in their work and its outcomes. So we're doing something for a higher purpose. And impact means team members believe their work makes a difference and advances the project or the broader mission. So everything they do does have an impact. It's they're not just doing it for busy work sake.

For example, as a project manager, we want to create systems that turn chaos into order. And we do that with our project management process. Planning, executing, planning our scope, schedule, cost, risk, communications, stakeholder involvement. That is the job of a project manager. We're turning all of these chaotic things into a nice, beautiful plan. And then we have to manage that to make sure it doesn't turn into chaos again. We communicate and listen. We promote trust and psychological safety. Demonstrate empathy with our team and create motivation with our team. We want to delegate responsibility to the right people and prioritize the right items. Next, provide air cover for our team, shielding them from the politics or from external requests. This one is very important. I think on one of the projects I managed 50% of my job was just providing air cover for the team cuz there was a group of executives who just wanted to add something uh from for their departments that was and that was what what do we call that that's scope creep. So all of these things are starting to relate, isn't it great? Anyway, that was a lot of fun. So at the end we celebrated our team success which is another great thing that we want to do.

Now the stages of team development. This is one of my favorite things. Tuckman's model or the Tuckman ladder where we've got and it rhymes so it's nice and easy to remember. Forming, storming, norming, performing and adjourning or adjourning if we're going to rhyme. Forming. We're coming together and the project manager needs to provide clear guidance on what's going on. But as we come together, we're coming together from different departments, different areas. We're new. Uh, so we go through a period of storming. We have conflict and disagreements and we need to focus on conflict resolution and listening with our team. As we work through that, we come to a norming stage where we establish workflows. We get into our rhythm of work. We know that Bill is going to complete his work and and that Anne is going to do a good job if we give her what she needs to do. And so we become uh we start to get into that rhythm. Performing is when now we can start to finish each other's sentences because we've been working together and we really know what everyone does. We're very clear. We can delegate, motivate, and provide feedback as we go along. At adjourning, sadly, every project must come to an end. The team dispands and we organize celebrations and clarify the next steps for our team members as they move off onto other projects.

Ethical decision-making is another important part of being a project manager. Here is a five-step ethical decision-making framework which I think is really great. We want to recognize if there is an ethical issue. Question if the decision negatively impacts others or if it goes beyond legality. So if it's legal or if it negatively impacts others, we want to be aware. Get the facts. Consult policies. Consult relevant people. Gather the right data. Evaluate alternative actions. We want a few options. Consider which option produces the most good and respects rights and treats people fairly if we can, if it serves the community, and if it aligns with our personal values. All of these things are wonderful filters for our decisions. Make a decision and then test it because sometimes we'll make a decision and it will have the opposite effect to what we wanted in the real world and that's no good. So we check it out and then we adjust if we need to. We plan, do, check, and adjust. It's the Deming cycle. It's back again. It's all starting to come together. And lastly, we act and reflect. Implement your decision thoughtfully and evaluate the outcome. Of course, wonderful things to do.

Now, sources of power on our project really important to be aware of project managers. We are going to need to influence others because we've got people from all over the organization and we may not uh have direct power over these people. There are four steps to effective influencing. And I think this is really great from the Google project management certificate. First of all, establish credibility. Show your expertise. Build trust with your audience. So, show the reason why. Show why you have credibility to speak on this particular issue. Frame for common ground. Highlight how your idea benefits the other party, not just benefits yourself. Now, now that we're benefiting them, if we're benefiting them, then it's harder for them to say no. We're influencing them in that way. Provide evidence, use data and storytelling to support your idea. And connect emotionally, show your passion, and match the emotional tone of your audience. Now, this four-step framework is absolutely fantastic. So, even if you just took this away from this entire course, it would be worth the price of admission. Definitely use this as you're trying to influence and get things done in your project.

Common mistakes that people can make when influencing are approaching too aggressively, which can push people away. And remember, um, if we're if we fight people on something, are what are they likely to do? They're likely to fight back. Exactly. And so now all of a sudden we don't have a uh, a decision, but we do have a funny face with hair, which I've inadvertently drawn through my diagrams. Resisting compromise. Negotiation is key. Oh gosh, this is fun. Uh, focusing only on the idea and neglecting credibility, common ground, evidence, and emotional connection. Remember those four steps. Expecting to reach agreement in just one conversation. Again, this is very important. Sometimes it takes time to uh, to get the data, to have conversations, to make sure that people understand and work through any issues. Don't just do it in one conversation. Work through multiple conversations. Again, that's really, really good information to have.

We're also going to need to use our sources of power as a project manager. We've got organizational power, which is our role, any information we have, very important. Our network, the people that we know can get things done and our own reputation. And personal power is our knowledge and skills, our communication and emotional connection with the other party, our history or past interactions with the person. And our character, for example, qualities like honesty. Have we been honest in the past? Then people are more likely to understand and work with us uh with that view that we're going to be honest in the future. So very, very handy to know.

Now, project execution, communication, as we said, it's around 90% of project management uh skills that we're going to need to use. And there are lots of tools that we're going to use to communicate. It's our responsibility to coordinate incoming and outgoing communication and information, all the data, and get that information to the stakeholders so we can make good decisions. Define how documents are used and who can access them. For example, we don't always want everyone accessing the budget information if that's mostly for our steering committee or our project sponsor. Tools for effective communication, email, instant messaging, Slack and Google Chat, virtual meetings, Google Meet or Zoom, and work management like Google Drive or Asana or Jira. Many, many different wonderful tools that you'll come across in your project management career. And emails are a big part of that. So, we're going to need to know how to write effective emails. Here are the steps. State what you want clearly. What do you want, when, and how? Keep it concise. No one will read that long email. Try and keep it concise with bullet points, labels, um, paragraphs, and sections. Remove anything that doesn't support your goal. Structure writing properly, and check for grammar, punctuation, and spelling. Uh, just so that you know it keeps keeps it nice for our audience.

Uh, another way that we can communicate is facilitation and meetings. Effective meetings are structured, they're intentional, they're collaborative so everyone has a voice and they're inclusive so anyone can raise issues if they absolutely need to. Before the meeting, prepare and share a clear agenda so we know what we're doing. Invite only the essential participants. Cancel the meeting if it can be an email. Have you ever had that? This meeting could have been an email. So, don't let that be you. Uh, if uh, if you can just send an email, then do that. Keep it short where possible because people's time is valuable. During the meeting, start by clearly stating the team goals. Invite everyone to speak. Make sure that everyone has a voice and capture the key points and decisions and assign any actions to specific participants if you need to. So afterwards, we're going to send out a summary of those decisions and action items and schedule follow-up meetings with people if necessary. But usually you can just email and say um just following up on this one. Um, is it complete or are there any blockers? Can I assist? Uh, etc. So that's how we're helping our team. That's how we're tracking our tasks like Google project management certificate says which is pretty handy.

Common types of project management meetings are our project kickoff meeting marks the official start of the project aligns the team on project goals and processes. Status update meetings uh so shares status updates on progress or challenges or next steps. And we had our remember our status report that we could use as well. So that's that's pretty handy. We could use that in a status meeting. Stakeholder meetings to gain information or to gain stakeholder buy-in or support. Understand their challenges and communicate project information and project review or retrospectives or lessons learned to review what went well and what could be improved. So we're always improving as our project is going along.

Now lastly, as we execute our project, we are going to close the project at the end. Three criteria for closing a project is to ensure the work is all done. Now that might be a bit obvious but we do need to check all the boxes. Make sure no deliverable is overlooked. Ensure all project management processes are executed. For example, administrative tasks like uh finalizing the budget, signing any contracts or handing over any deliverables, making sure remember we're landing as well as we're launching if you remember that launching the product and landing making sure that it sticks once it reaches our users and our customers. Obtain formal recognition from stakeholders. So sign off from all our key stakeholders that the project is final and closed to prevent ongoing work. Otherwise, it's just going to yeah, we need to a specific final closing process. A formal closing process is essential to avoid incomplete contracts or scope and to ensure stakeholder needs are met. We want to verify the strategic goals and confirm completion. Did we meet the goals that we started out at the beginning trying to meet? Review any open documents and ensure all that work is done. Provide the training materials for the new product if we need to. Obtain formal stakeholder acceptance. So they give it the formal tick of approval. Uh, review and finalize contracts and payments. Hold a retrospective for lessons learned and send formal recognition of the phase or project completion to our stakeholders. And here is a new one. Uh, create and send the project impact report. Now this one is really good. In fact, we're going to talk a bit about this later. Um, but I I realized that I did this in a lot of my projects and it's such a wonderful way to close a project. You show uh the how you met the goals and what the goals were and what you aimed for and what you actually achieved and it's just such a great way for stakeholders to see the value that you actually delivered and you know it doesn't hurt your career path either. So I highly recommend that. We'll see more on that later. Dispense and thank the project team after project closure. And of course, have that celebration if you really want to.

Watch out for these things, never-ending projects where the scope is unclear and the tasks are never complete. It just goes on and on and on. We want to have a start and an end date because we're a project. Abandoned projects where deliverables are not properly handed off to the customer. So we we launch the the product but it never lands to use Google terminology there. Uh, so it never sticks. It's not properly handed off and then really we don't get the benefits that we wanted.

Closing documentation and communication. When closing a project here we are it's good practice to show the project's impact to our stakeholders. And again this is really good. This reinforces the value delivered by the project. We want to state clearly what the project aimed to achieve the problem and how the project resolved it. Use metrics to show your results. For example, time saved, revenue growth, return on investment, customer satisfaction improvements, reduced downtime for our systems, increased user adoption, and use lots of visuals if you can because usually we want to uh put this towards executives. Executives just don't have the time to read through wordy emails. So, use lots of beautiful visuals if you can, like charts or graphs to reinforce your idea. And like I said before, this really works. I highly recommend this at the end. Um, or even if you're delivering features along on your project, do it for each feature if it has a benefit.

We can also send a project closeout report which includes what was delivered and how it was done. So this is more of a report card on our project itself. It assesses the project performance in terms of budget and schedule. It might include these things. Executive summaries, a concise overview for our executives. Again, key accomplishments. So what did we achieve and the project impact? Lessons learned. What do we learn? What worked well? What didn't work well? Why did those things happen? Any open items, unfinished tasks or potential improvements for the future. Next steps, if there are follow-up projects or if there is uh ongoing change management or training that we need to perform, schedule and milestones, so timeline details, any setbacks and how do we go with our schedule? Do we meet it? Resources and team members for acknowledging our team. After all, they are the ones doing all of this wonderful work. Love and acknowledge our team and they will do great things for you. Resources and project archive. So, we want to archive all of these things and link to that information in the company repository if we need to.

Oh my goodness. And here we are. We've done four courses. Wow. Did you ever think you would do four courses today? Well, neither did I. So, that's quite a lot. And also we've gone from initiation to planning to execution and we've even closed the project at the end of execution. Now we're going to get into this wonderful thing called agile project management. One of my favorite things. In fact uh some of the best projects I've ever run have been with an agile way of working.

work. When it works, it really, really works. So, let's get into Agile and see what this holds in store for us.

First of all, the history of Agile. Agile emerged in the 1990s during the growth of the software industry, and it actually came from lots of different methods. So, uh, I haven't got all of the methods listed here, but you had XP, Scrum, uh, there were dynamic systems delivery methods, many different things. Software companies needed faster, more adaptive ways to develop their products.

So, in 2001, all these people who were working on these different methodologies for lightweight software development came together and created the Agile Manifesto. They came together in Snowbird, Utah, a wonderful place, the birth of Agile, 17 signatories. Here they are, to shift the focus from excessive planning upfront to instead delivering customer value, which is really what our ultimate aim is. And they came up with the Agile Manifesto, written in 2001, and here it is. It's four things.

Uh, we have individuals and interactions over processes and tools. Now, what this means is we prefer the things on the left, uh, over the things on the right. But it doesn't mean we get rid of these things altogether. It just means we prefer interactions, working together, and talking. And now, why do we talk? Because it's faster. We can get all of that feedback and information close, uh, close in person, in place, in time, instead of sending an email where it takes, uh, three days to get a response. So that's why it works.

Working software over comprehensive documentation. So, we deliver working software and we get that feedback instead of just delivering something and delivering a huge comp, uh, documentation to go along with it.

Customer collaboration over contract negotiation and responding to change over following a plan. In other words, things will evolve as the customer sees these features that we deliver, and so we expect that there are going to be changes. Uh, we can't know everything upfront. In fact, um, we'll see this soon, but it, uh, it works with VUCA. So, a volatile or complex environment.

Now, to go along with this are the 12 clarifying principles. These are a lot, so I'll just quickly go through them.

Our highest priority is to satisfy the customer through early and continuous development of valuable software. We want to welcome changing requirements, even late in development. We harness change for the customer's competitive advantage. Again, because we see it and then we say, "Hey, that's not actually what I had in mind. I need to change." We deliver working software frequently, instead of year by year. It's week by week or month by month, uh, with a preference to the shorter time scale.

Business people and developers work together, instead of, uh, instead of being separate. We actually work very close together daily in the project so that we can get that feedback quickly. Build projects around motivated individuals, so people have the motivation and give them the environment to succeed and trust them to get the job done. The most efficient and effective method of conveying information is face-to-face communication. And that's what we were saying before.

Working software is the primary measure of progress, not meeting a milestone. We're actually delivering real working software. Agile processes promote sustainable development. So, we want a sustainable pace. We don't want hurry up and wait because then people have sick days and, you know, things go bad.

Continuous attention to technical excellence and good design enhances quality. That means that we're always focusing on quality throughout the project. Simplicity is the art of maximizing the amount of work not done. Now, this trips up a few people, but, uh, we want to reduce the things that we're doing because that simplifies things. If we're adding lots of things, then it makes it more complex. So, that's essential and that's a really wonderful way to work.

The best architectures, requirements, and designs emerge from self-organizing teams. In other words, we decide how the work gets done. Uh, typically in a wonderful way, the Scrum way of work that we'll see coming up is a good way to do it. And at regular intervals, the team reflects on how to become more effective and then fine-tunes its behavior accordingly. What does that sound like? It sounds like a retrospective. Exactly.

So, all of these things, we've seen some of them already. And we've also seen this VUCA. Agile works well in VUCA environments. And I couldn't remember them all before, but here they are. Volatility, which is rapid change and instability. Uncertainty, with low predictability of the future. Lots of unknowns. Complexity, with many interconnected parts. Ambiguity, it's hard to interpret causes or conditions clearly.

And it works because we're delivering something and finding out with real data, and then we can adjust because we expect that change and we reprioritize the backlog for the next highest priority item based on what we've learned. And that's the power. That's why it's really helpful in a VUCA environment.

Now, Agile delivers in small increments, as we've seen. We go through all of these steps for each increment, and then we gather that feedback and adjust. So, requirements, analyze, design, build, test. But Waterfall does all of these things just for one big bang all the way at the end. And then what happens if we find defects over here? We have to go all the way back, maybe to design or analyze. Uh, and that's going to cost us. Remember the cost of quality. So, that cost goes up as it gets closer to the finish of our project. So, we really want to find those defects as soon as we can, in the requirements if possible.

We have other frameworks in Agile. Kanban is a very popular one, most known for the Kanban board. I think we saw a little bit of this before with our different columns and work moving across it. We've got "to-do," "in progress," and "done." We also want to limit the work in progress. For example, we've got four user stories here. Now, if we have, uh, three team members or four team members, then that might be perfect. Now, what happens if we've got 20 cards in analysis? Oh, now we're starting to, um, we're going to have to switch tasks and multitask, and we're going to have to work overtime. We don't have a sustainable pace. So, we want to limit the work in progress to match our team's output. Uh, we want it to be sustainable. We encourage the teams to finish their tasks before starting a new one. They pull tasks when they're ready. That's the concept of pull from Lean. I think we might see that soon.

Extreme Programming is also a large part of Agile. It's more around software development. There are four core activities. Designing. We want things to be as simple as possible. Uh, remember, executives may probably try to complicate things, and then, as developers, we may need to rein it back in and try and keep it as simple as possible. And, you know what? The simple approach is easier to use, is easier to program, all of these things. That's why XP says, "Keep it simple."

Coding with our customer close by. Testing. We write the tests first, then we code the solution, and then we run the tests, and hopefully they pass. And then we listen with our customer on the feedback, and we adjust.

There are some practices that we'll use in Extreme Programming. Uh, continuous integration, where we integrate, we, uh, take a copy of the system, and we write our change, then we merge it back into the overall test environment, and we run all of our tests at the same time. Hopefully, they're automated to see if it works and to see if we've broken anything in the overall system. That's continuous integration. We want to do that at least once a day if we can, once a week at the most.

Pair programming is where we've got two programmers side by side. This is to share knowledge quickly throughout the team. So, we might have a junior and a senior working together. One is doing the programming, and the other one is looking at the code standards and the overall solution. Is it the right solution? Making sure we're meeting the goals, uh, and any other things that they, uh, that they need to work on and just keep an eye on. And now we've got two people who understand this section of the code, and then they can move on to other pairs. And now, all of a sudden, this knowledge is being dispersed quickly throughout the team, which is really, really wonderful.

It also has regular refactoring. Remember that with our 5S, we're refactoring the code, making sure there's no duplication, uh, making sure it doesn't rely on other parts of the codebase, uh, if possible, avoiding big designs up front. So, do just enough to start, and then continuously improve and write tests, not requirements, because we want to test first and then code our solution. So, that's Extreme Programming. Some pretty cool stuff in there.

The Toyota Production System is also very cool. This one was all the way back from 1952 or approximately after World War II, when Japan had no money, but they wanted to have the best quality they possibly could. They formed this amazing process.

We want to define value from the customer's point of view, which is what we're doing on our project. We want to map the value stream. What are the steps we take to deliver that value? Create flow. That means reducing any non-value-added steps that don't add value to our customer. For example, too many sign-offs or, um, or any other activities that aren't directly creating our product. Establish pull. Remember, our team can pull work when they're ready. We're not, we're not just piling up work on them. We're going to let them pull it when they're ready and do all of these things continuously to pursue perfection over time. That is Lean. Great way to work. I actually wrote two books on Lean, so I'm partially familiar with it, and I've used it in a white-collar environment and manufacturing environment. Wonderful way to work.

Promotes, uh, this is the Spotify model last. And you'll see this, it's similar to SAFe, which is a Scaled Agile Framework, very similar. But where it basically is a culture thing, where we've got squads, so Scrum teams, self-organizing around a product. But then we've got tribes, so we've got multiple squads, uh, in related areas. And that is also like projects and programs, isn't it? So, very similar thing. But then we have chapters. This is where we've got individuals with similar skills. So, all of our testers might have a testing chapter, they get together and they learn from each other. Might have a business analysis chapter, might have a development chapter, might have an architecture chapter, or whatever that looks like. And lastly, guilds are cross-organizational groups sharing knowledge, tools, and practices. So, it's really more about coming together and sharing that knowledge.

Now, frameworks and Scrum in Agile. 72% of Agile teams use Scrum. So, when people say Agile, a lot of the time they're just referring to Scrum. But as we've seen, there's many different frameworks, and there's more than we mentioned here, even. But they all came together in 2001.

So, Scrum has clear roles, predictable routines, and structured practices, which makes it easy to adopt, which is why it's so popular. We have a few things. The backlog of work, which is a prioritized list of potential work, and we continuously update this work. Usually, the Product Owner will make sure that we're working on the highest priority item. We have the Sprint, which is our one to four-week time-boxed cycle of work. And at the end, we might have a retrospective, and we might also showcase our work to the customer. And then we have the Daily Scrum, which is a 15-minute meeting, a stand-up meeting, just to check progress and make sure there are no blockers so our team can do the work that they need to do.

The ideal Scrum team is a two-pizza team. Three to nine people. Small enough, small enough to stay nimble, big enough to have all of the necessary skills to create the product. They're also cross-functional teams. The team can handle all of the aspects of the work. So, anyone we need to develop the product, we bring them into the team if possible, uh, and hopefully keep it under nine people.

There are different roles in a Scrum team. The Scrum Master ensures that Agile principles are followed, facilitates the team's progress, and so the ceremonies, typically they'll run the stand-up or they'll run the retrospective. They'll help the team problem-solve when there are things. They'll escalate any blockers. The Product Owner owns and prioritizes that backlog. So, we want to make sure that we're delivering value. We want to show what that value is. Make sure we've got the right data. Make sure we've always got the highest value item at the top based on the effort and the value that we're delivering. And then we've got the team, who do this magical work and do everything needed to create the product. A cross-functional team with many different roles that decides how to build the product, and they do the actual work and make the magic happen.

So, Scrum 101. Scrum is based on empiricism, which is the idea that knowledge comes from real experience and data, not assumptions. Now, why is this important? Because of VUCA, if you remember, if things are ambiguous and complex and volatile, then we need to test and deliver something and from, from real experience, then we'll get that feedback and then we can adjust. It's empiricism. So, that's the idea behind in Scrum.

Each iteration and increment acts as a mini-experiment to learn and improve, which is a great way to work. Teams are cross-functional and they're self-organizing, so they decide how they do the work. The vision and mission align our team's efforts. The mission is a concise statement that gives a team a meaningful goal to work towards. The product vision describes the expected outcome and boundaries of the product, helping the team imagine the finished result. So, we know we have our Scrum Master, Product Owner, and the team.

In Agile, the Scrum Master's primary focus is facilitating and coaching the Scrum team, not budgeting or reporting or tracking progress like a traditional project manager. The three foundational pillars of Scrum, which support empiricism or real data, are transparency, making all of the work visible. And we can do that on our Kanban board, so we can see where we're up to. Inspection. We want to make sure our customer is viewing the real things that we've created to detect issues early. And adaptation, continuous adjustments to the product, the project, and our process with a retrospective to, uh, uh, to improve and avoid repeating mistakes in the future.

Scrum teams operate according to five core values. Commitment, where we're committing to the team's goals and we support each other to overcome challenges. Courage to speak up, to tackle difficult problems, to say when something doesn't make sense, to ask for help, and to address negative behaviors if we need to. Focus. Everyone concentrates on the work necessary to achieve those goals, and we want to minimize distractions. Openness. Teams and stakeholders share all relevant work information and challenges openly to enable problem-solving, so we all have the information we need. And lastly, respect. Members value each other's opinions, skills, and independence, fostering better communication and collaboration.

There are five key events in Scrum. The Sprint, which is our timebox of one to four weeks where the team delivers a usable increment from our Sprint goal. Sprint Planning, where the team adds enough user stories to the next Sprint based on our current velocity. If our average is 30 story points that we've, that we've, um, delivered in our Sprints, we're going to add 30 story points worth of cards into the next Sprint so that we're keeping a sustainable pace. The Daily Scrum, a 15-minute daily stand-up to report on any blockers, anything blocking us, make sure we've got the help that we need, and just update everyone where we're up to. And a Sprint Review, which is where we demonstrate the real product to our customer or the Product Owner for any additional feedback. And lastly, at the end of our Sprint, we want a retrospective to improve our work, to say what went well, what didn't go well, and take action items to improve for our next Sprint.

Here are some more Agile terms that you'll come across. The Definition of Ready and the Definition of Done. The Definition of Ready is the criteria that the team agrees on for when a user story can be worked on. For example, does it have everything that the developer needs? Does it have acceptance criteria? Is it estimated? Does it have sign-off from the Product Owner? Is there a prototype or a mockup? What do we need? And, uh, that's our Definition of Ready. The Definition of Done is the team's criteria for when a user story is complete. It's developed, the tests have passed, and it's been demonstrated to the Product Owner, or anything else that the team agrees on.

A Minimum Viable Product, or MVP, is the smallest set of released usable features to the customer that are going to bring value to the customer. Usually, we'll release an MVP, we'll get that feedback, and then we'll continue to release more features to continue adding the right forms of value according to the Product Owner.

As we build and manage a backlog of work, the product backlog is a living, prioritized list of features and requirements. It's owned by the Product Owner, as we know, and they use value versus effort estimates to prioritize those items. So, high value and low effort, ideally, is what we want to go for. Um, but then we're going to meet in the middle or whatever that looks like for the different variations of that. Items at the top of the backlog are well-defined and detailed, and items down the bottom are just a bit more vague. So, as they get closer, we break them down and we add more detail so that our team knows what they need to do.

Each backlog item includes important data fields. It might have a description of the work, the value that it's delivering, the estimate on the effort, and its priority, so top or bottom based on its value and its, uh, and its effort. The product backlog items are typically made up of things called Epics. And this is just our work breakdown structure. Again, our Epics are broken down into user stories. So, an Epic is a large body of work or a collection of related user stories. Epics are broken down into smaller user stories and placed in the Sprint backlog for our next Sprint that we'll complete. Again, the Sprint is one to four weeks. So, we complete that, demonstrate it to the customer, have a retrospective, then do Sprint Planning and do it all again.

User stories are short, simple descriptions of a feature from the customer's or the user's perspective. This acceptance criteria is a checklist to determine when a user story is considered done. The typical format is: "As a user role, I want this to happen so that I can get this particular outcome or benefit or goal." Good user stories also use INVEST, which means they're independent. They can be worked on without depending on other stories. So, that gets rid of our dependencies issue, which we had at the beginning of this, uh, of this course. If you remember, we want them to be negotiable. So, they can be open for changes. They can be moved in or out of the Sprint if they don't add value. But we do want them to be valuable. Delivers clear value, and we've got the data to prove it. We want them to be estimable. Clear enough to estimate the effort, so we know how long it's going to complete. And here's a key one: we want them to be small. Now, just as a side note, in the real world, if you're running into problems with your Agile team, I highly recommend looking at your user stories and your features and breaking them down into smaller pieces if you can. This will solve probably 80% of your problems. We want them to be small enough to fit in one Sprint. It helps us estimate the effort better. Um, it helps us define the value. It helps us show progress for our customers, so all of that noise starts to go away. So, if you can keep them very small. And lastly, we want them to be testable with acceptance criteria that can be tested by our users or our customers or our testers themselves.

Refining the backlog means breaking down the Epics into user stories, then adding acceptance criteria and estimates. So, that's refining the backlog. This is typically done with a Product Owner, a developer, and a tester. So, we come together, and we've got our user story. Now, we need to add this information to estimate the effort. Relative estimation is usually used with the smallest item used as a reference point. So, we've got our smallest user story, and then the other items are estimated based on that. Now, that can look like, uh, t-shirt sizing, where we've got small, medium, large, or extra large. Or it could be story points, which are usually based on the Fibonacci number sequence, which is 1, 2, 3, 5, 8, 13, and 21. And the way you do Fibonacci is this number is the sum of both of the other numbers. So, 1 + 1 equals 2, 2 + 1 equals 3, 5 + 3 equals 8, 8 + 5 equals 13, and so on. That's the Fibonacci number sequence.

Now, lastly, we've got applying Agile. Agile projects deliver valuable software or products, solutions early and often. How do we ensure value delivery? We can use the three Rs. We want to build the right thing. Make sure we're understanding the customer goals. Use prototypes to test and use conversations and feedback to check with our customers. We want to build the thing right. Develop only what's necessary and approved to avoid waste and complexity. And lastly, we want to run it right. Deliver with proper planning and keep improving our product and our process, uh, to improve the experience for our team and for our customer.

As we introduce Agile to an organization, we can create a value roadmap with a product vision. This is our team's North Star. It defines what the product is, who uses it, and how it supports the customer's business strategy. Again, this is similar to our, uh, feasibility study and our business case at the beginning, or our project charter. The product roadmap is similar to our Gantt chart. It's owned by the Product Owner, and it gives us a high-level view of the features that we're going to deliver and roughly when we're going to deliver them based on our velocity. The release plans are developed by the Product Owner and Project Manager together, and they deliver the basic working features iteratively. So, when are our features being released, and what's our plan? Do we have some post-verification testing? Do we have some change management strategies that we need with the business? And that's part of our release.

We'll need to influence other people on our journey. We want to clarify measurable results with our SMART goals. Remember, they need to be specific, measurable, um, time-bound, relevant, and achievable. And then we look for these things. Personal motivation to help individuals find their own internal reasons to engage in new behaviors. Personal ability, making sure that they have the knowledge and skills to perform those things. Social motivation, so making sure we've got peer pressure, in other words, peer encouragement and social networks. And social ability provides social resources and support within the team. You'll notice that all of the Agile ceremonies and frameworks do all of these things naturally, which is why Agile becomes so powerful. Structural motivation with rewards and incentives and structural ability to adjust the environment to make it easy to focus and, uh, the making sure that incorrect behaviors are harder to do.

Now, with Agile, there are scaling frameworks for large projects. For these, um, just keep this in mind, all of these frameworks usually recommend not to scale and just to keep it small if you can. Again, remember, the complexity will increase with larger projects. But if you have to, here are some frameworks that we can use. The Scaled Agile Framework. This is called SAFe. This organizes teams into release trains. So, we've got, uh, and this is based on value streams. So, with Lean, our value stream is where our customer orders, and then at the end, it's where our customer gets the item delivered. Along the way is the process to deliver that item, and we might have product teams, and all of these product teams are on a release train. Uh, so they come together, again, it's like projects and programs and portfolios, basically. We might have Scrum of Scrums, where multiple Scrum teams send a delegate, and now we've got lots of different teams down here, and they all meet in a Scrum of Scrums, and then all of those ones might meet in a Scrum of Scrum of Scrums. So, that can keep going, again, programs, portfolios, and projects. Basically, Large-Scale Scrum focuses more on the Lean principles. So, value and waste reduction. Remember downtime, our, our waste, defects, o, uh, overproduction, waiting, non-use of time and talent. Uh, Disciplined Agile Delivery is one from the Project Management Institute, using Kanban, Large-Scale Scrum, and Lean XP, Agile Modeling. All of those come together. And lastly, the Spotify model, which we saw with squads, tribes, chapters, and guilds.

Now, on an Agile team, we're a little bit different from a normal project manager. An Agile project manager typically coaches and empowers the team to find solutions instead of managing the team with delegation and organization. We design the plays with the team. We provide feedback. We problem-solve with the team, and we celebrate and learn and improve as we get feedback from our customer and feedback on our process with our retrospective. So, lots of words in there, and I hope you're following along. Um, but once you do get it, it's really all about that feedback.

There are challenges that our team might face, and we're going to coach the team and help problem-solve along the way. We might have missing delivery dates. We can use retrospectives, set work-in-progress limits, and reduce the user story size. Remember that. Frequent negative feedback after demonstrations. Ensure that our Product Owner is signing off on the acceptance criteria and review our Definition of Ready and Definition of Done to make sure we're doing everything correct and with the customer in mind. Low team morale or lack of raising issues. Provide training. Ensure psychological safety with our team, and we've been through all of these things now. So, again, it's all coming together. We problem-solve issues openly and again, reduce that user story size.

If we have an unstable product roadmap with lots of different items coming into our roadmap here, there, or everywhere, make sure our Product Owner knows how to handle new opportunities. They can say no. They, they have the ultimate say, and they should base that on value over effort. Remember that. Unclear responsibilities. We can look at our team charter with the team. What, uh, what are their agreed roles and responsibilities? We can use our RACI. Remember that one. And make sure that we're improving with retrospectives. And lastly, lack of team stability. Make sure we've got a good onboarding with our team. Use pair programming to share that knowledge. Remember that from XP. And consider shorter Sprints so we're not being overwhelmed. And also, not being overwhelmed is we are nearly at the end of all of these courses. Five courses you have been through. So, that's such a great achievement. Well done.

The last one is putting all of this wonderful stuff together into Project Management in the Real World. So, it's a little bit shorter, which is great, but it's also a bit more practical. Let's get straight into it. Let's see how much of this we remember as we go through this project.

Initiating a project with SMART goals: specific, measurable, attainable, relevant, time-bound. A vague goal is something like, "We want to improve customer experience with tablets." But a SMART goal is, "Reducing the average checkout time by 10% within six weeks of tablet implementation at pilot locations." It's specific, time-bound, relevant, all of those things. So, use those SMART goals.

Identify the scope and costs. Scope should be everything that contributes directly to our SMART goals. Include what we're doing, but also what we're not doing. Costs are what it takes to get there: the hardware, software, resources, training, and anything else. Then we put that together in a project charter. This aligns our stakeholders and initiates a project. Include the project summary, which is a brief overview of the project, what it is, and why we're doing it. The project goals, high-level results or outcomes that we're aiming to achieve, and the deliverables and scope. So, what are we delivering that makes our goals achievable? So, what's included and what's not included in our project scope.

Identify and negotiate with stakeholders. We may need to negotiate project scope, resources, or other things. We can list key stakeholders for the negotiation decision. Look for mutual benefits. Remember, if it benefits them, they're more likely to say yes. Advise on the trade-off between scope, schedule, and cost. Remember our triple constraint. If someone wants more scope, we can say, "Okay, we can do that, but it's going to increase or impact our budget or impact our schedule." It's the triple constraint. As we negotiate, listen first. Ask open-ended clarifying questions and offer creative options.

Once we've initiated a project, we want to build that project plan. Organize project milestones and tasks with our work breakdown structure, our high-level items, breaking them down into tasks to complete. We put those on a beautiful timeline with our Gantt chart. We look at the resources that we need to complete those items and who we need to assign them to. We brainstorm risks with our team, what's going to impact our product in the future. And then we figure out who we need to communicate to, and what we need to communicate, and how often. Because remember, communication is 90% of project management and the skills that we need. We might also need to research and brainstorm for more tasks or deliverables. And we can do that through our own domain knowledge, what that we gather along the way, or news, or case studies, or similar projects that we can look at across industries. We can brainstorm with our team, or we can use one-on-one conversations with subject matter experts.

We'll break down deliverables into tasks and complete them and estimate their duration and cost. We need to know how long they might take, and we do that with our team to estimate. We understand the task thoroughly. Make sure we've got all the information we need. We clarify any assumptions. So, we don't assume. And then we differentiate effort versus the total duration. Effort is hands-on work time, but the total duration might include weekdays or any waiting or handoffs or reviews. So, it's often longer. Make sure we keep that in mind. Leverage historical data. Have we done this in the past? Then we can use that information to estimate in the future.

We can also use three-point estimating. I don't know if we covered this yet, actually. This is where we take three points and we get the average. So, we just divide it by three. Uh, and it's the optimistic estimate, the most likely estimate, and a pessimistic estimate. So, for example, we might say we could get it done in five days is optimistic. Most likely is seven days. Oh, and I've done that the wrong way. Um, a pessimistic might be 10 days. So, add those all together, and we have, uh, 22. I hope my math is correct there. Um, and then we divide that by three. We've got roughly seven, seven and a third, something similar. So, then it comes back to around seven days to complete it. That's our three-point estimating. We can also ask for a confidence level. How confident is our team on their estimates? And we can base it on that as we go along on our project.

We're going to maintain quality, quality standards, and indicators. Remember those. Our quality management plan defines what quality means for our project. We'll include our standards. Who's responsible for quality assurance and quality activities, how and when we're going to manage and measure quality, how we're going to collect and act on feedback from our users and customers, and what tools or checklists we're going to use. Ask questions, use surveys, and perform a retrospective to check that the quality met our stakeholders' needs.

Remember the four types of quality activities. Quality planning, which is how we're going to meet our quality standards. Quality standards, which are the specifications that we're trying to meet. Quality assurance, which is the act of testing or checking the item. And quality control, which is once the item is delivered, we want to fix quality issues ongoing or during or after when that work is done. And lastly, for quality, we can facilitate that retrospective. We ask our team what went well, what didn't go well, and we want to improve. Remember, for any challenges, we take an action item and we follow up on that action item. So, we're always improving. And if we're the Scrum Master, we need to, we might need to help problem-solve or escalate that action item with our team. So, that's the power of having a Scrum Master.

And lastly, stakeholder communication. Problem-solving is the essence of project management. We're always problem-solving, problem-solving, and problem-solving. Whether it's the scope, the budget, the timeline, or resource issues, PMs exist to identify and solve problems. The key steps are: identify the real problem. So, the root cause, remember, with data. Use frameworks, tools, and methods to organize your approach. Maybe we might use DECI. Maybe we might use Plan-Do-Check-Act. Create a clear plan to get buy-in from stakeholders and implement it once we know what we need to do. Our job is to communicate these problems clearly to stakeholders, especially when we need to escalate or when decisions are needed.

And as we get to the end, we're developing that closeout report and the impact report. Uh, these are two great things. Remember, the project closeout report shows what our, how our project performed with a project summary, the methodology that we used, maybe it was Agile, a performance baseline, how we said we were going to achieve versus what we actually achieved, uh, and how our project went. Key accomplishments and outcomes, lessons learned, next steps and follow-up actions, and the project documentation archive. Remember, with links, uh, to the documentation as we archive all of our project information.

As we close our project, we'll use that impact report showing the value that we delivered, uh, and executive summary showing the vision and goals and what we accomplished and any lessons learned. Great for high-level executives to show them what we did. Personal closing report is for ourselves: the key accomplishments, the lessons that we learned, and the next steps for us and career advancement. So, this is a nice thing to do for our own resume.

And lastly, an elevator pitch. Who we are, what we do, and what we want. And we're going to use this to start preparing for job interviews. Uh, whether we have a project role at the moment, or whether we're moving on to our next project role. So, having an elevator pitch with who we are, what we do, and what we want is very, very handy.

But we can also use the STAR method with our interview. Uh, when we have interviews, there are three types of questions. Behavioral questions, for example, "Tell me a time when you did this or when you had to handle this." Hypothetical questions, which is a scenario they have and how you would handle that. And factual questions. So, "What does this process do or what does this tool do?" And we can respond with the STAR method, which is the situation, set the scene with the relevant context. The task, which was our role and the things that were required for us to do. The action, the steps that we took to solve the problem. And the result, which is the outcome and the impact, and the things that we learned along the way.

But mostly, the things that we did learn along the way are these six courses in the Google Project Management Certificate, which we've done in record time. We didn't need 240 hours after all. In fact, we got it done in this amazingly short amount of time, relatively. Anyway, I hope you've had an amazing journey along this course because I certainly have. It's been a whole bunch of fun, and also we've seen how Google will manage their projects and how they think about project management. I hope you take this and use it in your own career. Use it to improve and use it to do great things and deliver value for your own organization. I'll see you in the next video. Bye for now.