Project Management: Getting Started and Beyond

If you're looking to become a project manager, or you want to improve upon your project management practices, this is the course for you. This is not a course full of fluff and theory, but a real course on how to apply project management. We're not talking about passing an exam. We're talking about being a better project manager. About getting things done, leading your team, moving through the appropriate processes at the appropriate time.

Now, you might already know some of these topics, and I don't want to waste your time, so what I've done, there's a resource in this lecture that you can download, and in this resource you can look at the different topics, and see the exact section, and the exact lecture. So you don't have to follow the course in this order, you can go to the specific section and lecture that you want to go to, to learn about that specific topic. Or, once you're in a project and you want a little clarity, like on quality control, or team development, you can go and use that as a resource.

Maybe you're a new project manager, or you're moving into a project management career, and it's important to have just a real clear understanding about what is project management.

Let's talk about the fundamentals of project management, just so we're on the same page. First off, what is a project? Let's start there. Well, a project is anything that is temporary or it's unique from your day-to-day operations. So, if you were a architectural firm, you might have things like accounting and finance and sales and marketing, just the operational duties of that architectural firm.

Let's now take a look at projects and project management. I want to ask you some questions and talk about some facts here about projects versus project management.

First off, how are projects different from operations? Well, you probably already know that projects are temporary. Operations go on and on and on. But sometimes when I meet project managers, especially new project managers, they talk about oh, I've got this project. Well, it's not really a project. It hasn't really been launched officially. There's not really a charter. What they're really describing as they have an assignment.

The project management lifecycle is different than the project lifecycle. There's a lot of confusion between the two, so let's take a look at the project management and the project lifecycle now.

When we talk about project management, there are really two different approaches to project management. The traditional approach is predictive. In most of this course, I'll be talking about predictive.

The other approach we have is Agile. Predictive means we can predict everything that's going to happen in the project. So if we're building a house, we can pretty accurately say, "This is the structure of the home. This is the flooring. This is what the kitchen looks like." Even down to, "These are the handles on the different cabinets in the kitchen." So we can very clearly show what we're going to create, what our intent is. We can plan it out very precisely.

A term you've heard me use a few times is a stakeholder so what the heck is a stakeholder? Stakeholders are people. It's anyone who can affect your project. You have internal and you have external stakeholders so stakeholders are people like your project team; the project manager, the sponsor, if you're creating a piece of software your end users. You work with a central contracting office, those are stakeholders. You work with a PMO, they're stakeholders. If you're an environment where you have government regulations and inspectors, those are stakeholders.

Here's a quick quiz to test your comprehension so far.

Great job finishing this first section on the fundamentals of project management. Maybe you already knew a lot of the information in this section, and that's fine. Hopefully I filled in maybe some gaps for you that may be different than what you thought you knew and what you know now. In this section, we talked an awful lot about the fundamentals of project management and just what is a project. You know that a project is a temporary endeavor to create a unique product, service, condition or result. So every project in the world will be creating one of those things. Projects are also known to be a MACD project, meaning that you're moving, adding, changing or deleting. All projects are a MACD, but which one of those are you doing? So we talked a little bit about that. We looked at, a little bit, predictive versus agile, where predictive I could know everything in advance that we're going to create and agile is more change driven where I have a list of prioritized requirements, the backlog that we work from. So, depending on your environment, you might be doing predictive or agile or maybe a hybrid of the two, and that's fine.

In this section, we're going to talk about the core principles of project management. We're going to talk about your role and responsibility as a project manager, so, what's expected of you in most organizations.

Now, your organization is probably a little bit different than another colleague's organization, so you might have some specific requirements in your role as a project manager that others don't. It's really difficult for me to say this is exactly what you'll do, but I'm going to share with you the most common principles. I've consulted in a lot of different organizations on project management. Every organization had different expectations of the role of the project manager.

You are the project manager, so you need to know your role as the project manager. You need to know your swim lane, as it were, what you are allowed to do and what you're not allowed to do. And this is going to vary from organization to organization. Now lots of people want to be a project manager. But to be a project manager you need to have some management abilities and some leadership abilities that we'll talk more about later in the course.

But just know that it's not unusual for people to become a project manager first en route to becoming a manager in an organization. As a project manager you need a clear idea of what you're going to accomplish. This just means you really have to understand two different things in the project. You first have to understand the current state, so where you are now. And then you have to understand the desired future state.

As a project manager in your discipline, whether that's IT or healthcare or manufacturing or whatever discipline or field that you're in, there will be some key skills that you'll need that are unique to that application area. There will also be some skills that are more general among all application areas that would map to any discipline. So first off, you need some key skills to do the work. You have to have relative knowledge. There's always a debate in project management communities. Could a project manager manage any project? I don't think so. I think you need to have relative knowledge of the area you're working in. I come from an IT background, as probably many of you do, and to put me into a construction project, I would really be somewhat lost. I understand a little bit about construction, but I don't understand the nuances of construction to be effective. So I have to have the skills to do the work and to speak the terminology and the nomenclature of the discipline I'm operating in.

In Project Management, there's a term called the project lifecycle. And a lot of project managers incorrectly think this means initiating, planning, executing, monitoring, controlling and closing. And they call that the phases of the project lifecycle. That's not true. The project life cycle is unique to each project. The project lifecycle describes your projects' phases. So if you're in construction, you might have permitting, the prep work, the foundation, the exterior walls and so on. The project lifecycle describes how your project, how each project moves from the very start to the very end. It's not IPECC, it's not initiating, planning, executing, monitoring, controlling, and closing. That's called the project management lifecycle. But the project lifecycle is your project.

It's not a good feeling when you make the realization that your project is going to fail. So maybe you know that about half way through, or as you're leading into those last chunks of your project, sometimes you might know even upfront, you can just see this train wreck coming. But why do projects fail? I'm going to talk about, in this lecture, some big reasons why projects fail, and what you can do about it.

We think about launching projects, we want to understand why are we initiating this project. Why is it being done? All projects, every project in the world, will fall into one of two categories as far as why it's initiated. You're looking to cut cost or you're looking to increase revenue.

Projects are really about getting things done. So, to complete a project, we have to do the work. So we're talking about the execution phase. The execution is what gets us to results. Not planning, not monitoring, and certainly not closing. We have to execute. So the execution phase, we're talking about the team actually doing the work, and then the team reporting, through meetings, on their progress. You, the project manager, will track expenditures. Expenditures means it's the actual allotment of money to materials and resources in your project. As a project manager, you also need to have resources available when needed. You don't want your project team waiting around for equipment or for materials in your project. That's wasted time that you're paying for.

Sometimes, as project managers, we have to be a sales person. We have to sell the idea of a project. Sometimes you'll just get a project that lands on your desk, and there you go, go to it.

Well, I like this quote from Tom Peters. That we, "Never, ever accept a project or assignment as it is given. Resist the status quo." I don't think Tom is telling us to buck that project, or to throw that project away, but how could we improve upon that project? How can we be certain to deliver quality, and business value, in the project?

We think about creating a vision for the project, we wanna create a shared vision of what we're creating. At project management we begin with our current state, where we are now. And then we wanna paint a picture, we wanna be very accurate to describe that desired future state that we both have the same vision. So what are the goals of a project manager? One of the key skills as a project manager is the ability to see the invisible, to see what's off in the future. And then we have to communicate that vision and get others to inherit that vision, to be successful in our project. When we think about selling a project, or any project that you're tasked with managing, we begin really with the vision, that desired future state. And then we have to do some critical thinking and really dig in and do some analysis.

All projects need goals. One of the approaches that I like to use when it comes to setting goals is this idea called SPIRIT. SPIRIT means it's specific, so be specific about what you do or don't want. Prizes, how will you reward yourself and your team when you reach the goal. Individual, the goal has to be something that you want to do. So for your team there has to be goals, but what are they going to get out of their commitment to the project? Then review, we periodically review our progress on these goals in the project. We want it to be inspiring, so you frame the goal positively. Then it's time-bound, so it's temporary. It's not going to last forever, just like your project won't last forever. Goals are really important and SPIRIT is an approach you could use.

Once you've established goals in your project, or you have key performance indicators, KPI, or you have objectives of how you know you're successful, you might create a target chart. It's just a real simple table where you list your objectives. You list the indicators of how you know you're successful, what's the priority level of the objective, what's the current level and the target level. For example, we might have first in the indicators for better customer service, we have less hotline traffic, less people calling with drastic situations about what we're supporting.

One of the most important meetings that you'll have in your project is your kickoff meeting. The kickoff meeting is an opportunity for your team members and your key stakeholders to all get together and to meet one another. It's where you, the project manager, lead this meeting and you review the high level project details, the vision, the plan. You're going to make certain that everyone agrees what success looks like. You're going to walk through your high level plan, like your different milestones.

Let's talk about planning and execution in your projects. You can't plan forever, right? It's so painful when I go into consult and I see project teams that have been planning for months but they haven't created anything. It's a waste of time. I'm not saying that the plan isn't important but you need to get out and do stuff. You can't plan forever. Planning is iterative.

Complete this quiz to test your memory of what you've learned in this section.

In this section, we talked a lot about launching a project, and selling a project, and creating a vision for your project. Really important. We also looked at some project goals. Using a target chart, having that kickoff meeting, doing some planning towards our milestones. So a lot of the things we talked about here are really core to project management.

These are things you should do in every project to create a good solid foundation, and to set goals like we did in that assignment to work towards. So really important for you to do as a project manager. One of the things I want to highlight that we talked about in this section was the role of the project manager.

In this section, we're talking about the mechanics of project management and what that means. We're talking about how projects operate, the things that you'll be expected to do in any project, so some really solid principles here that you can take from this and begin immediately applying. We're going to take a look at developing your charter. Every project should have a charter. That's really important. We're going to look at preparing and planning your project work. Planning is really important, especially in a predictive environment because we're predicting what's going to happen, but you still have planning even at an agile or iterative or incremental environment. So planning is important in both. Just our approach is slightly different.

Every project should have a project charter. Now you, the project manager may not be responsible for writing the charter, but you'll probably be involved with contributing to the charter. So what does the project charter do? Well that authorizes your project and you, the project manager. It means that your project has the authority to exist in the organization.

You're acting on behalf of a person that has the power to delegate power to you over the resources in the project. Now the project charter comes from someone who is external to the project. This just means that you can't write your own charter, it needs to come from someone with the authority above all of the resources utilized in your project.

Early in the project, you'll do some groundwork to really prepare your team, and the organization for the project. We begin by kind of setting some anticipation, some excitement about what we're creating, and what we're going to end up with. You'll define the location, so where will the work take place? Now this can mean a lot of different things. You might have a virtual team, so you've got people all over the world, you might have people that are on one campus, but not physically in the same space, or you might be co-located, where you have like a project office, sometimes called the war room, or your project headquarters.

Now let's drill a little bit deeper into planning the project work. A really good tool that you could use is a project planning worksheet that just gets us starting into planning, really helps us map out the big picture of our project. So you can just open up Excel then drop this in, or Word or what have you. But it's really just a document to kind of kick start our planning.

So we named the project and then give a brief description. Just one of the big benefits that we'll get out of this project. You might have a project number, not every organization numbers their projects, but you want to give it a name at least. What's the priority rating? Like we looked at that priority rating matrix early in this course. So what's the priority rating of the whole project compared to other projects in the organization? What's the request date? And then you can add other information as well. You might go ahead and add what's the deadline, what's the budget, what are concerns that we have, what our risk or assumptions or constraints. So it's just a way to kind of kick start the planning activities.

As a project manager, one of the questions you have to ask in planning is, "What really needs to be done?" I've said it a few times. Project management's about getting stuff done, but what is stuff? We need to define stuff. What is the stuff that has to be done? That's what we're going to discuss in this lecture. What really needs to be done? It's important to define what needs to be done, and get to work. Planning's great, but you gotta get to work. We gotta get the team members out there creating results. Let's take a look at that now.

I think you and your team will find that one of your toughest challenges will be to identify all of the activities. Now a trick to really helping you find the activities is to go back to your work breakdown structure. The WBS will show all of the work packages, the smallest item that you decompose. When you're breaking down your project scope, a general rule is the last item, the last work package, the final component of the WBS, should relate to no more than eight hours in 80 hours of labor.

Let's consider that we're building a new home. There's lots of different stakeholders, lots of different resources that are involved in the construction project. We have Pete. He's the home builder and then we have Mark, he's our general contractor and then we have a couple of construction workers. We have Steve Smith and Sarah Anderson. We also have three additional construction workers and we have Omar who was our plumbing subcontractor, and then we could continue this list. We have things like the cement company and we have the electrical company both for your city utilities and the interior electric. We might have a pool, we have landscaping. There's a lot of people involved that were paying for their time and expertise. My point being that nobody works for free.

I have a secret weapon for you as a project manager. It's not really so secret, but a lot of PM's don't use this. And that's the work breakdown structure. The WBS is a decomposition of your project scope. We decompose the scope into smaller and smaller items. And that's what we're going to look at in this lecture.

A term I've mentioned a couple of times is the work breakdown structure, the WBS. The WBS is a decomposition of your project scope, that we take the project scope and identify milestones, so the different phases of your project, like the permits, the foundation, the framing, the electrical and the plumbing. At the end of those phases, we have some result. That result is a milestone. Within each phase, though, there are deliverables. So if we think about this house and we think about the finishing of the house, the interior, and we have the kitchen. Within the kitchen, we have the appliances. We have the cabinets and the countertops, the lighting, the plumbing. So we have all these different parts that we break those down into more and more detail.

There are lots of different ways to estimate time in your project. You want to choose the most appropriate way for your project, so depending on the priority of the project, if you have historical information like past projects, if you already have a preassigned deadline, and resource availability when people can actually work on your project. All of those factors will determine which approach you use to predict the duration of your project.

Regardless of which approach you take to predict the duration of your project and the activities in your project, there are some good rules, some good best practices to follow.

First off, you want everyone, I'm talking about your team members, everyone to participate in creating the schedule. This shouldn't be something you do alone and then give to your team. By having your team members there together, the scheduling conflicts can be immediately resolved. So you begin to estimate the duration and then you begin to put these in the order of which they should happen.

Often when I go into consult in different organization, and they are predicting how long the project takes, I find a really dangerous thing happens. Project team members will say, "This task should take me about 30 hours but why don't you put me down for 35, in case anything goes wrong." Everybody around the room is adding like 10 to 20 percent to their activities. I see project managers say, "Yep." They take the order for it and jot it down. Really dangerous.Couple reasons why.

In project management, you'll probably rely on some software to help you better manage the project. Now, I use a little bit of caution here when it comes to relying too heavily on a project management information system. I've met a lot of people who believe if they have Microsoft Project that they can manage the project. Well, that's like saying, I have Microsoft Word so I could write a novel. It's two different skillsets. It's important to understand the software that you choose to help you manage the project, but no software can take the place of the project manager. There are a lot of different software choices when it comes to project management. Oracle, Primavera and Microsoft Project, those are two biggies. I've worked with both of those. They both have pros and cons. And of course in this class we're not getting into the particulars of each software, but those are two really good choices.

As a project manager working in scheduling, there are some terms you'll likely encounter that you should be familiar with. The first term that's often misunderstood is the critical path. In a project network diagram, the critical path is simply the longest path, the longest string of activities from start to finish.

The critical path shows which activities, if these activities are delayed, your project is going to be delayed. Other activities that are not on the critical path still have to be completed. But there's an opportunity to delay those up to an amount without affecting the project completion date, and that opportunity for delay is called float. You might see that called slack. That's a little old school. We call it float now. Let's take a look at a project network diagram.

Lead time is also known as negative time. It brings activities closer together and even allows them to overlap.

Here's the scenario for lead time, we have a huge hotel that we have to paint. Before we can actually put the paint on the wall we have to do some prep work, we have to clean the walls and we have to prime the walls to accept the paint. Well, that primer takes about 24 hours to cure for the painting, before the painters can begin.

Being the project manager, you'll likely be responsible for the project budget, so you have to predict the budget. You're going to have to control the budget, determine when you're going to spend things or when you're not based on what's happening in the project. Most projects run on a tight budget. You don't have a lot of range of variances. You don't have a lot of plus or minus 20% when it comes to money. It's typically more easy to get time than to get more money, but yet, time is money because you're paying for labor. When we think about the budget, you're talking about the actual allotment of monies to a project, how much you can spend in the project.

In project management, people often talk about quality, but they've not really defined quality.

Quality is really meeting scope. When it comes to a thing you're creating though, one of your deliverables, quality is the totality of that entity to satisfy stated or implied needs. That's my favorite quote when it comes to quality. Quality is all about it's a conformance to requirements and a fitness for use.

What does quality mean to you? It may not mean the same thing to me. In a project, we have to know what quality means. Good, fast, those are subjective terms. We need definitive terms. What is good? What does fast mean? What does up time or reliable mean? So we need metrics to build our project against. So we really want some caution when it comes to any subjective in our project and then once we know what constitutes quality we have to do quality control. We have to go inspect the work and that's what we're talking about in this lecture. Let's check it out now.

A quick quiz to test what you've learned in this section.

Great job on finishing this section with the mechanics of project management. We talked about a lot of information in this section. We looked at developing your project charter. If you have your checklist, we looked at developing the project charter. We talked about preparing and planning your work, about what really needs to be done, doing some assignment estimating with our durations. We talked about management reserve. Remember Parkinson's law. We looked at some scheduling approaches and different tactics, and how you can develop your schedule with your team and for your stakeholders to answer some of those big questions. We looked at budgeting. We talked about quality management and controlling quality, so a lot of information we covered in this section. You're making great progress. You're on your way to becoming a better project manager. Keep moving forward. I'll see you in the next section.

Project managers often say the most difficult part of managing a project is not managing the time or quality or the budget. It's managing people. Managing people probably is, in my opinion, the hardest thing that you'll do as a project manager, especially if you've never worked with those individuals before. So when we manage people, people bring a lot of stuff to the project table. They bring their emotions, their opinions, their experience, a lot of baggage, misconceptions about what we're trying to do.

If you have the luxury of choosing your project team, it's a lot of things that you want to consider when it comes to who you'll place on your team.

First off is accountability. You want people that hold themselves accountable, people that when they have an assignment, they'll get it done. So based on your knowledge of that individual, your experience with the individual, that should influence people that you choose on the team.

This can also mean that you want people that they want to be on the team, that they're aware of the project, and they're asking to be on the team. And then you're gonna talk to them about accountability.

Two terms that I mentioned earlier in our time together was "effort-driven activities" and "fixed-duration activities" when we talked about crashing and fast-tracking. Effort-driven activities are just that: they're effort-driven. They require labor, like painting 100 hotel rooms or installing 1,000 fixtures. The more labor you can apply, generally, the quicker you can get done.

Fixed duration means regardless of the amount of labor you apply, it really doesn't affect how long the activity takes, like software testing. You may test that software for two weeks or a piece of equipment can only operate so quickly. You can't put two engineers in front of a server and think the software's going to install faster.

So we've talked about creating a winning team and choosing people to be on your team. Let's drill down to this a little bit deeper out here to the real world. When you want someone specific on your team because they have a great skill set or you've worked with them in the past, you want to go to that staff member and the staff member's supervisor to talk about your project and how it's going to benefit the organization.

Have you ever found yourself on a project and there's a lot of chaos that you and others don't really know what they're supposed to be doing?

Roles and responsibilities are what we need. Everyone needs to know what is their role and what does that entail, what does that mean to be an application developer or to be an engineer on this project or whatever the role might be, so what are the responsibilities.

As a project manager, you really have two different roles. You have the role of being the manager, but you also have the role of being the leader. Management is about getting things done. Leadership is about aligning, and motivating, and directing, and inspiring the people to want to go get things done. So, in this lecture, we're going to talk about how can you lead team development. How can you get that team to be a better team, a more cohesive team? And what are some natural steps that all teams go through? So, let's hop in and do this lecture now.

At the beginning of this course, I told you that I don't want to waste your time and I know that you don't want to waste other people's time, so when it comes to managing team meetings, we want to be cognizant of the team member's time. Here is a really important thing to think about when it comes to having a team meeting. When you're having a team meeting, those people are meeting about the project, they're not doing the work in the project. So you have to really time box your meetings so you don't waste time away from your project, away from getting things done. Just think if you have 10 people on your team and you have a one hour meeting, and you come in, and you chit chat for 15 minutes, and then you get to work, and then you still have 15 minutes left, so you chit chat some more, or things get kind of rowdy, it's a lot of time for 10 people. In fact, that's 10 hours a way from your project. That's like more than a whole day. So managing time in meetings is really important and that's what we're going to look at in this lecture.

If you want people to perform in your project, they need to feel valued. They also need to feel that they're working towards something that's good for them, the individual. Here are some easy ways to reward your team, to keep them excited about your project and invested in your project.

First off, giving people a sincere compliment is so valuable. Often what I do is a handwritten thank you note. When someone has really been hustling or going above or beyond, I give that person a handwritten thank you note. It was funny, I was working in a project years ago and I gave an individual a thank you note, something that I do often for my team members. Well, the project was done, I went away, and then a few years passed so they had me back to consult on another project. So I just went by to see my old friend, this team member. I went in to talk with here and there on the bulletin board behind the desk was that thank you note that I had written years ago. I asked her about it and she said, "You know, it's the only time a manager has given me a thank you note, and that really meant a lot to me." She kept it, and that meant a lot to me as well. So it's important to show people that you appreciate their work and how they're helping the project be successful.

Complete the quick quiz on leading the project team.

I once had a project manager tell me, "If it weren't for all these people, my project would be so much better." Well, probably, but you need all those people for the project to exist. It was a little bit of frustration there.

This individual really needed some emotional intelligence, really needed some insight how to work with people and how to better manage the team, and that comes with time and having a little bit of finesse, but there's also some logical things, like we talked about here, to better manage our human resources for that team to go out and do the project work.

I call this section advanced project management. What I've discovered in my years as a consultant is there's kind of a funnel or a cone when it comes to the skillsets of project managers. I find that the topics we've talked about so far go from that very broad portion of the funnel and they get narrower and narrower because fewer and fewer people have mastered these skills.

What we're going to talk about in this section, things like risk management, about putting together that final plan, about getting stuff done and execution, about controlling change. I find that a lot of project managers kind of shy away from this stuff and they just let it kind of sit there in the background or they do it half-heartedly because they might be a little afraid of it or they might be afraid of making a mistake. Don't let that be you.

Risk management is an activity that you'll do throughout the project. You'll do it over, and over, and over. There are three things to know when it comes to risk management as some general rules. First off risk is uncertain. Risk has a probability and an impact, it's the uncertainty that we have to worry about. We have to look at the chance of the risk happening, and that's probability.

There are two categories of risk events, positive and negative. Positive risk are things that are going to work in your favor, like if you get done early your company will receive a bonus, so you have some incentive, or a cost or time savings. Negative risk is anything that hurts your project from reaching its objectives. Negative risks are time and cost. We generally think of cost, but negative risk can be time as well, anything that hurts your business objectives and your project. As a project manager your general focus will be on negative risk, that's just where we tend to go. But that doesn't mean that you should ignore the positive risk. With your team you'll be assessing project risk. So you'll be looking at that probability and the impact.

Two terms that I've mentioned in the previous lecture was qualitative and quantitative risk analysis. Qualitative means you're qualifying the risk for more study, for more analysis. Quantitative means you're quantifying it. You're looking for facts and data about the probability and the impact. Let's take a little bit more in depth look at this now.

Qualitative is very quick and subjective, it's not always reliable, but it's the most common approach to risk analysis. When you do qualitative risk analysis, you'll likely create this probability impact matrix. And you'll have the risks identified in the first column, the probability and the impact, and then you'll have a subjective risk score. So you'll do this with your project team. So you've identified all of your risk, and then you'll have a conversation about each risk, "What's the probability that's going to happen?" So based on experience, kind of a gut check, based on their confidence with managing that risk event, you have the probability. If it does happen, what's the impact on the project? So again, a gut check based on experience and so on. And then from that you'll create a risk score from low to high.

Sometimes when I meet project managers, I'll ask to see their project plan and then they open their desk drawer and they pull out this big binder and they say, 'Here it is, here's my final plan.' All right, that's cool. Nice to have a big thick plan, but does anybody read this thing? Does anybody know what's in here? All the little binders and the little tabs and different sections, that's great. Well here's some news. The project plan is not a museum piece. It's not a document you create and then it goes onto display with a glass dome over it.

The project plan you use all the time. If you've got a great big, thick plan, you better have a massive project to go with it. While it's nice to have all those templates and forms that we'll talk about later. Really, the project plan is usable, it's fluid, you're updating it, you're using it to communicate and to really guide what you doin the project.

You've heard me say GSD, get stuff done, an awful lot, it's one of my mantras when we go into projects. When I meet with my project team it's become kind of a joke sometimes that people will say, "GSD," because it's a get stuff done, it's what I talk about the time. That's fine people want to joke about that but really it's that mentality and it's exciting to get stuff done. I always tell my team, "GSD," at the end of our project meetings and then they'll often tell me that too because I have stuff to do.

Changes are likely to happen in your project. In a predictive project, we become change resistant. In an agile project, we are change driven.

In a predictive project, where the bulk of our conversation is, we want to prevent changes from entering the project by having a really solid scope up front. Having said that, changes could still happen.

So when we first meet, our kickoff meeting with all the stakeholders and the team members, we want to communicate what the change management process is like, so what are the rules for change. So you want to have a process in play, and I'm going to show you an ideal process for change control coming up.

As you know, communication is so important in project management. Because of its importance, we want to dedicate some time to planning for accurate and good communication. There are really four factors when it comes to planning communication we have to consider.

We know communication is paramount in project management, so we need a project communications management plan that shows our intent and gives us a schedule to follow of when we communicate into whom we communicate. This plan will define how communication will be managed and controlled. The control part is really important because there will be some pieces of information not everyone needs to know and you may not even be privy to some of that information. So really understanding how you're going to manage it, how it will be controlled also includes securing the communication. The Communications Management Plan is linked to stakeholder management and stakeholder engagement because that's who you're communicating with.

Now that you have the communications management plan created, you're ready to start communication with your stakeholders. However, before you actually jump into really put out a lot of communication, you wanna think about just a few more things when it comes to how you communicate. Think about the culture. If you're working on a project that spans different countries, then you probably have cultural issues that you want to address, so cultural differences. You wanna talk about the differences in communication styles, how people work, what's expected of them in their culture may not be the same in yours. Different age groups, the nationality, who will you be communicating with in a professional discipline and what are the communication styles they're used to receiving.

Sometimes in a project, you have bad news. Things are going to break, people are going to quit. People are going to make mistakes. You're going to be over on your budget, or you're going to be lagging behind on your schedule, so you have to go communicate bad news. Not always fun, but it's part of project management. We never want to hide bad news. Think about it in your life. Do you want bad news delayed and delayed. You want to know what's going on. So does the sponsor and your stakeholders. Let's talk about a little finesse when it comes to communicating bad news.

Because communication is so important, it's really the heart of what you do as a project manager, it's vital that you manage communication.

Rumors can be your worst enemy. So you want to head off rumors as quickly as possible. Squelch those rumors and keep the project moving forward.

Ask trusted people to be on the lookout, to keep an ear to the ground so to speak, to be aware of any rumors or misinformation that's getting out.

You've developed your communications plan, so use it. Don't just create it and tuck it away, it's a guide, it's your intent.

Project managers sometimes get a bit nervous, a little bit of anxiety when they have to take any news, or have any meeting or update with executives or your sponsor. So in this lecture, we're going to talk about how to calm yourself, and how to go in and be confident to present information. How to avoid being kind of breathy when it comes to meeting with executives and sponsors. The truth of the matter is, executives and sponsors have confidence in you, or they wouldn't have placed you in the position of being the project manager. So if they already have confidence in you, you should have confidence as well. Let's take a look at this information now.

A real quick lecture here on meeting management. Meetings require an agenda, so you create the agenda if you're hosting the meeting and then stick to it. Be concise. We don't need people to ramble or give eulogies in a meeting. So be concise, don't waste people's time. Talk about solutions rather than problems. What I mean by that, sometimes it's easy in a meeting to talk about a problem and just to really groan about it and to keep going on and on and on, and it becomes just this gripe fest of the problem. But you have to talk about the problem, but you don't have to get out of control, so also talk about the solution to the problem.

I've mentioned status reports several times throughout this course. If you're creating a status report from scratch, there are five pieces of information you should address. What's the cumulative cost? That means, how much money have you spent so far against your budget? What's the scope, and what have you created thus far against the scope? Then, what's the schedule? Where are you now in the schedule? Maybe your milestone chart. I hopped over RAG rating. For each of these, you can do a RAG rating or a RAG rating for the whole project. Red, amber, green.

I've talked about Agile projects, or said Agile projects frequently throughout this course. Agile was really gaining in popularity, but what is agile? Agile is really kind of an umbrella term for lots of different flavors for methodologies or philosophies for project management. Scrum is one of the largest methodologies under the Agile umbrella in the world today. So we talk about Scrum, we're talking about having that prioritize backlog and getting all the way to the end of a sprint. Let's dig in a little bit deeper and take a look at all the moving parts of Scrum.

One of the happiest days in a project is the day you get to close out the project. Let's take a look at some key facts you want to have as you go into closing. You should already have a good plan as part of your project management plan for how you're going to close out the project, how you'll release resources, how you'll transfer deliverables over to your operations, or to another group, or to the customer. That's sometimes called the operational transfer plan.

Complete this quiz to test what you've learned in this section.

Great job finishing this advanced project management section. I hope that you've picked up some real nuggets here, some real good information that you can begin applying in your projects to make your projects really shine and to stand out. It isn't just though to shine, or to stand out. It's also about being successful, that if I have the right tools, and I know what to do, and I do it, it's going to help my project. It's going to help my project team. In this section, we talked about risk management. One of the biggest things you need to do in a project is to manage your risk, to identify and respond to risk.