Project Management: Getting Started and Beyond

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.

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.

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.

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.

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.

One of the biggest request I received from people, as I was doing that survey to build this course, was, "Can you please provide some templates for some of the common project management forms or plans, or different components that we'll need?" This is really kind of tricky to do, because every organization uses a different approach and has different expectations. But often, we need just to start somewhere. So, what I've done in this section, I've gone back to different projects that I've worked on and I've taken forms from those projects and these different organizations that we use, and I modified them a little bit to what I think is best. I'm going to share those with you in this section. We have a lot of forms to go through, and these are in Microsoft Word format and you can download these and use them at your discretion. Let's hop in and check out all these different forms now.

If you're doing a project for an external customer. You're working with a vendor to do a project for you, or on a very large internal project, you'll likely need a statement of work document. The statement of work document defines why we're doing this, the scope of the work, what's our period and place of performance, what are the work requirement, big milestones, acceptance criteria and then there maybe some other requirements you want to include in your SOW. So, the introduction this is just some boilerplate text you can adapt for your project on why we're doing a particular projects, what's the scope of the work, the period of performance when this work will take place and where it will take place, what are the work requirements and you can adapt this for your project. These are pretty vendor neutral.

I've had lots of requests from people to see a sample charter. This is a sample charter with a dummy project and you can see it's really robust, so you can trim this down for what fits you organization.

We begin with an Executive summary. We'll do a justification of the project, our business case and objectives. What we're going to do in the project including our success criteria, requirements, constraints, assumptions and you may have a preliminary scope.

What are the high level risks, what will the project create, what's our summary milestone schedule, our budget, the approval requirements, who is the project manager and then an authorization.

Key performance indicators are objectives or goals in your project of how well the project is performing. It's typically time, cost, and scope but you could also do quality, very specific objectives about your scope. So this is what a KPI indicator would look like. This one is for funding. Are we having enough monies to get to the end result of the project? Our target is to use only 100% of the budget. It would be measured quarterly, and this would be point in time being quarterly. And then, are we red, yellow, green? What's the source? Is this a new or existing metric?

This template is a pretty robust project management plan. You can expound upon this or trim this down to what fits your project but here's what's included. We have our approach, the scope, the milestone list, the WBS, the change management plan, communications management plan, cost management plan, procurement management plan. We have a scope management plan, the schedule management plan, the quality management plan, our risk management plan, a risk register. We have a staffing management plan, you can call that your resource management plan if you wish. We have the resource calendar, a cost baseline, a quality baseline and our sponsor acceptance. So this was unique to an organization. This is the template we used there and this is just a dummy project here.

Another template you can use is the scope management plan. This is a subsidiary plan as part of your overall project management plan. This document, we have an overview. We get into our approach, the roles and responsibilities, the scope definition, the scope statement, the WBS, verification, control, and then we have a sign off. Let's take a look at this now.

Our introduction just tells why we have this plan, what it's used for, what's our management approach, primarily dealing with change requests and how the scope was created and then the scope statement, the WBS and WBS dictionary. So the approach here is how we create those things and then control change in this predictive project.

The project scope statement of work describes exactly what the project aims to accomplish. And then we get into the actual scope statement, what it is, how we're going to create it. Notice it's not the actual scope statement, but it's the approach to create the scope statement.

A milestone is a significant accomplishment in the project. It has no duration assigned to it, but it shows you've made progress leading up to that point.

You typically get the milestone at the end of a phase. And so in this example, the milestone list, we have the different numbers, what is the milestone ... This column, mandatory or optional, may be for some of the lower priority milestones. When was it completed and was it signed off on? So you had some acceptance to move forward.

So if you don't have Vizio, you can very easily create this from this template or go into Excel and create the numbering system and so on. But it's a way of showing the different components, the work packages being these items, the smallest item that's decomposed and it goes through every phase of this particular project. You can create more of a hierarchy structure like we have here in Excel. So it's not too difficult to create. And then you can see we have a more of a tabular view. I like this view in Excel the most, create some more formulas and do some concatenation to build out this level three. And if we go down, the tree structure of used more typical, it's a little bit more old school. On larger projects this can be really big because you'll have lots of these different levels, but it's a way of seeing the what's composed of each one of these levels. So it's a nice visual way to show your WBS.

The requirements management plan is a subsidiary plan in your overall project plan. This gives an overview, our requirements management approach, we'll get into the configuration management, our prioritization, the metrics, and then we have an RTM, a requirements traceability matrix.

The configuration management plan controls changes to the features and functions of the product. And we had some rules on configuration management on this project. So we had roles and responsibilities, how we controlled configuration, our database describing all the elements our status accounting and we did some auditing. So let's take a look at this plant. So this is it's boilerplate. This is some generic text here for the project. Going to utilize this infrastructure and just kind of map out where we're going to be working, what we're looking to improve. I mean, this is all fictional. And then we get into the roles and responsibilities, the change control board, what they're doing, they're reviewing and rejecting, approving or rejecting. Making sure that all approved changes added to the CMDB, the configuration management database seeking clarification as needed from the, and the CI is a configuration item that we're talking about a feature or a function that's been changed.

A change management plan addresses how you will allow changes into your project. What's the flow of changes? In this plan, we have an introduction, our approach, what is a change, if you're working with the Change Control Board, the roles and responsibilities in your defines change control process.

The introduction here, the change management plan was created for ... And you just fill in the blank, your project name. It sets the expectations on how changes will be managed, what constitutes a change, and so on. Then again, you could have the fill-in-the-blank for your project. The change management approach for your project will ensure that all proposed changes are defined, reviewed, and agreed upon, so they're properly implemented and communicated to all stakeholders. I'm not going to read, of course, all of this to you. I'm just going to hit the headlines.

This is a change request form template. We know that changes are likely to happen in a project, so this template will help you standardize how people request changes. We have the project, who's asking for it, the date, what's the change number that will be completed by you, what's the category of change, and of course you could add more here. Notice we don't have things like communication ... We do have resources. Communication. We have a risk response that requires approval, so that could be a change if it's a cost or time. You could have stakeholders. You could also have procurement changes, contract changes.

This template is a change log, which is something you'll want to have in a predictive environment. You really would not use this in Agile or Scrum, because it's more for predictive where we are avoiding change. This is the change log. The name of the project, the identification number, the request, what's the type of change, because remember, changes can come typically from scope, schedule, cost, procurement. The description of the change, who's asked for it, when it was submitted or approved, and you might change this to add some columns where is it declined or deferred? Or just make the date for results. Have a status, and then any comments.

This is an Assumption Log. Recall that an assumption is anything that you believe to be true, but you've not yet proven it to be true.

This Assumption Log, again, we have just a very straightforward table. You could have your project name, you could have an identification for each assumption for tracking. The category of the assumption, you could have for example, technical, you could have hardware, software, resource, vendor. What the assumption is, the responsibility of the person that will manage that assumption. Do we have a due date for the resolution? What's the current status? What are the actions?

The communication management plan defines who communicate to whom, when the communication is needed, what modality, it really sets expectations for communication, so it's a really important plan in every project, but especially on larger projects. So in this project we have our approach, the constraints, our requirements, our roles, you'll have a team directory, might expand upon that to include your key stake holders, the methods, we have a matrix will look at, the flow chart, guidelines for meetings, what are the standards in your organization, how do you escalate, and then it's always a good idea to have a glossary if you work in a special environment where everyone may not know the terminology.

Depending on the size of your project, you may want to use this template, which is a Stakeholder Management Strategy, sometimes called a Stakeholder Engagement Strategy. It gives an introduction for the purpose of this plan, how we identify our stakeholders, the key stakeholders, and then our analysis. Let's take a look.

The introduction is why we're doing this plan, this is just a dummy project that you can update with your project information. The approach we use to identify stakeholders. Then we have some criteria here that can help us filter out, prioritize stakeholders to those stakeholders who might not be as important as others. Who are key stakeholders, what makes that determination? Then our analysis, so what do stakeholders want, what are their expectations, make sure they're engaged throughout the project.

All right. I know some of you will beat me up because this says human resource plan instead of just resource plan. But again, this is real world project management. And if you're missing the controversy there, the PMBOK guide six edition no longer has an HR plan, but just a resource plan. But this is real world project management. This is a real template that I've used at another organization.

So the HR plan, what it does, it defines how human resources are managed throughout the project. So it's part of this software upgrade project, which is fictional and it helps the PM identify the different HR activities. Now, this may not be your responsibility at all in your organization. It might be through an HR department or your manager or the individuals managers. But in this project, the PM was over the resources.

This it the activity list template in Microsoft Word. It's very straight forward. You can just change this information to match what's appropriate for your project. The project name and activity ID number if you want to do that, each activity has its own identification, its own number. The name of the activity, a quick description of the work, and who was responsible for that work.

This document tracks your issues you've identified in your project. An issue is when you have a problem in the project. It's a risk that has happened. It's a very simple plan here, just explains what issues are, what's the purpose of this. Then I'll show you the actual table that we use to track issues that you can use.

You may be required to create a performance report weekly or monthly. It's not unlike a status report.

A performance report gives a summary of your past performance and how the project is doing, what trends may be emerging. It can use earned value management, something we really didn't talk about at all this course, but EVM is a way of showing performance on time and cost and if you've taken some of my other courses, I go through this and there's an earned value worksheet and you can create it in Excel.

I recommend that every week, you update and distribute a project status report. This is one that I have used that gives a RAG rating, red, amber, green, or red, yellow, green, based on different objectives in the project. These are the five I always recommend: scope, schedule, cost, risk, and quality. It just tells a quick story, a little summary of how we're doing in the project, the work we did last month, what we completed, what's planned for next week, and then we get into any issues or risks that are pending, our status on different milestones and deliverables. We may have some open change requests and what that status is, and then how are we doing on our KPIs? Our schedule, our cost, and then you could have other objectives here as well.

One of our subsidiary plans is the quality management plan. This plan gives an overview of our approach, the actual quality management approach, requirements and standards and what constitutes quality. Then we get into your organization's QA program, such as Six Sigma or Lean, and then we have quality control and our measurements for quality control. Let's take a look at this now.

A quality checklist is a way of making sure you do all of your quality requirements. So you have some preplanned questions. Do you have a quality management plan? Has it been reviewed? Do stakeholders have access to the plan? So the quality checklist is just a way of ensuring you've met your requirements as far as quality goes. And we can scroll through here, all of these different questions. And of course, you can tailor this for your project, making certain that you ask the right types of questions. Depending on what field you're in, you may have some quality questions in IT or healthcare, manufacturing, or construction.

The Risk Management Plan is a subsidiary plan to your overall project plan. In this document we have an introduction. We've identified our top three risks. You could make it your top five risks or risks above a certain threshold. We talk about our approach, how would we do risk identification throughout the project. Then we do qualitative and quantitative, which we called qualification and prioritization in this project. Monitoring and then how you do risk mitigation and avoidance. Those are the only two risk responses in this plan. Of course you could also include the escalate, enhance, sharing. You can do transference. Avoidance of course is here and acceptance. So you can add other responses as needed that fits your project.

In larger projects, or projects that you do for an external customer, you may need a formal project acceptance form. This form details the deliverables and that it's been transferred to the customer or to operations, and what happened there. Close out all the things that have been done with the review, the lessons learned. The project team released all the procurement, any other documentation. Then we get into the acceptance where the customer or the sponsor would sign and date it. This officially closes the project. Generally, you do this on projects that are more formal in nature or for an external client.

If you're working on a medium- to large-size project, you'll definitely need an operational transfer plan or a transition out plan. This plan defines how will you hand off what you create to operations so the project can end, because projects are temporary. So we have a quick summary, our approach, our team for transition, even the workforce transition, how we're going to work during the transition, maybe some dual support, subcontracting, property transition, so there's some particulars that might be unique to your organization, knowledge transfer, the schedule, and then the actual handover and acceptance as part of closing.

Great job. You did it. You reached the end of this course on real-world project management. My hope for you is that you have completed the course and that you have learned new information, how to be a better project manager, how to grow in your career and to really shine as a project manager. We talked about everything in the generally accepted practices of project management. We talked about the project lifecycle, how that's unique to your organization, the project management lifecycle, how that's universal to all projects. We looked at all of the different knowledge areas of project management. So we talked about scope and all the things you should be doing with scope. We talked about your duration for your scheduling and some different factors there. We looked at cost management. We talked a bit about quality management, quality assurance and quality control.