[MUSIC] Welcome back. [SOUND] Good to see you. Just as you carefully consider and plan for how to manage your stakeholders, you also plan your project. Now we wanna take a look at some of the tools and techniques you're going to use to accomplish this. It is so important that everyone understand and agree upon what your project is supposed to accomplish. When I say everyone, I mean your key stakeholders. When do you develop this understanding? From the very beginning. Remember, when we discuss the PMI or Project Management Institute, and also the PMBOK or the Project Management Body of Knowledge, well, after a project is selected and approved, the first project document to be created is the Project Charter. What is the charter? This is the document that formally announces the project and grants the project manager the authority to use organizational resources to meet project objectives. Technically, the PMI does state that the charter should be created by the sponsor. The PMBOK guide says sponsoring entity, to be clear. What you need to know is that you may be called upon to write the charter. This might be one of the first things you do as the project manager. The charter will help you and your stakeholders gain an understanding of what the project looks like. By looks like, I mean what will be accomplished. What does it mean to say the project is successful? Is there a predetermined deadline? What about the budget? What risks have been identified? The charter is the place to gather up what is known and then agreed upon. The charter helps you because it includes a discussion of your responsibility and authority. It serves as an announcement which states that the project has been approved and you have been authorized to run the project and it describes what authorization you have. Perhaps you can hire team members, perhaps not. Maybe you can sign purchase orders up to a specific amount. Maybe you will have input into team members' performance appraisals. A well written charter helps position you for success. Where do you get your information for the charter? Well, that's a good question. If a business case or a project proposal was created, ask for it. This is your first source of information. This also helps you to identify your stakes holder because it's gonna show you who wrote the business case and who approved it. You can use the initial information you received to create a draft. And, of course, you really want to involve your stakeholders. In fact, when we were discussing stakeholders and interviewing them at the start of the project to learn about their needs, you can also use this time to gather information for the project charter. Your charter becomes the basis for your project plan. Best practices really point out that we should invest time at the start of the project to plan out the rest of the project. You are going to encounter people who are gonna say things to you like, what is all this talking about it and writing about it? Why don't we just go do it? When you take the time upfront to map out what it is you're doing, it's so much more likely to go smoothly. And it's gonna be easier and cheaper to change your approach at the beginning while you're discussing the work, than it is when you're in the middle of doing the work. And that's why we don't just get started. What is it you should plan? Well, if you make a checklist of all the things you were worried about as your project was beginning, that checklist could be the basis of the plan. Now, the way the Project Management Institute does this is in the PMBOK guide. They have what they call knowledge areas. And that's why the PMBOK guide is called the Project Management Body of Knowledge. In many ways, each body of knowledge represents each of the areas you should consider. Throughout this course, we are looking at these bodies of knowledge. Let's consider some examples. Scope Management. How will you and the team determine what that project is accomplishing and what the project is not accomplishing? Who has to approve this? Once this is approved, can anybody suggest changes? What happens if they do? How will this be handled? Schedule Management. Are there guidelines for how schedules are to be created? What software is going to be used? How often is the schedule to be maintained? And who can make changes to it? What types of scheduling information will you report? You might even note known work shifts and holiday information. Cost Management. Are there guidelines for how estimates are to be created and documented? Who approves the budget? What do you do if you are over or under the budget? Can you ask for more money? Who do you ask? What type of budget reporting will you do? Another way to look at your project management plan, is that it is your Rules of Engagement. I've also heard others call it your Project Recipe Book or even Cookbook. This is beginning to sound like a lot of documentation. Let's just step back for a moment and consider the spirit of that documentation. Now some of you work in an industry or foreign organization where there is plenty of required documentation. When that is not the case, create the documentation which supports your project. The spirit of the documentation we are discussing in this class is that it should all support clear communications about the project. Everything you create should help others successfully meet project objectives. Another key piece of your plan is your Project Scope Statement. The Scope Statement describes what the project is creating. This is your product scope description. It defines the conditions that must be met for your product or service to be accepted. And it defines the deliverables to be created along the way. Great. What's a deliverable? A deliverable is something you create on the way to completing your projects. It is a piece of the product or service that you are creating. Let's say that your project is to help your human resources department redesign their recruiting, interviewing, and hiring processes. A deliverable, or a piece of work, that you would probably complete along the way would be to document the existing processes. Including deliverables in your scope statement helps you express exactly what it will take to create your project's product or service. Another important part of the scope statement is Project Exclusions. What is not part of the project? I get that this sounds odd, but it's important to insure that your stakeholders understand what they are not getting. So sticking with the example of redesigning the recruiting, interviewing and hiring processes, you might wanna note that the project will not include the redesign of the 90-day performance interview that is given to new hires. You might want to note that the project does not include the actual interviewing and hiring of new employees. Known Project Constraints are another piece of information that is included in your project scope statement. Remember that constraints can be limitations or special restrictions which are imposed on the project. Perhaps the project must be completed by a certain date. Or the product being completed by the team must provide certain types of functionality. And let's not forget about assumptions, the important facts we think we know are true and that are driving our plans. Perhaps you assume all team members will give at least 50% of their time to the project. What if you're wrong, and you have created a schedule based on this? If team members give you more time, you will finish earlier, but if they give you less time, your date is going to extend. Your scope statement is driven by the information in your project charter. You're gonna take this information and expand it. You accomplish this through interviews of those who will use the product or service, through learning what is really required of the product or service. We are not spending time on requirements management in this course, but know that your scope statement hinges upon a clear definition of what the product or service is required to provide. You should also know that we are discussing as the scope statement could actually really be a large scope document, especially for a large, complex or lengthy project. The recommended next step is to take your project scope and conduct what we call Decomposition, resulting in a Work Breakdown Structure. A Work Breakdown Structure depicts the work that is necessary to meet the project objectives. If we really were redesigning those human resources hiring processes, our Work Breakdown Structure, or WBS, would show the work required to complete that project. Although the WBS can be created as an indented list of activities, it could be more powerful when it is depicted as a graphic. A good WBS takes the work and divides it into smaller and more manageable pieces. This can be used to help create your schedule, and your estimates, and to become more clear about your resource needs. The WBS really is a foundational planning tool for your project. In fact, the WBS should so completely depict the scope of your project that if something is not in the WBS, it is because it is absolutely not part of the project. The WBS is hierarchical. Each level is a higher level and/or perhaps a summary of the level below it. The very top level is the completed project. The very lowest level, no matter how many levels down you go, is called a work package. And although you will find that many project management professionals really favor a WBS based on deliverables, it is possible to divide the work into phases. The key is that each phase should not represent a period of time, for example, a three-month planning cycle. Each phase should represent and depict some specific deliverable being created. So during that planning cycle, something needs to come out of it. Projects are completed when the work is completed. And the WBS is all about showing that work. Using deliverables really helps to show what has to be completed in order for the project to be completed. And that's why, to many, it is a preferred approach. Sounds good, but how? First, don't think that this is something you should do by yourself. You definitely want to involve your team. You start with your scope and your deliverables. The very top level is your completed project. For our Human Resources Hiring Process Redesign, the top level is our project name or outcome. Now our next level are the major deliverable we need to complete in order to say, we did, in fact, redesign the HR hiring processes. If we had created a complete scope statement, we would already have these. Ours could be something like define current processes, define to-be processes, complete gap analysis, create updated processes, create process training, implement new processes. Now what? Now with your team, look at each major deliverable, and discuss what makes it true for that item to be completed. For example, what makes it true that define current processes is completed? By the way, you might want to say the current processes defined. I try to use action words to name each deliverable because it helps to show what is being done. You do not want your descriptions to be too long nor too short. Current processes, what does that mean? Define current processes show that this is where we're doing the work to make sure we understand the current processes. So what makes it true that define current processes is completed? Well, we need to define each of the processes. Perhaps you would create a next level which showed the processes involved. Okay. Let's say those would be defined job requisition process, define job posting process, define applicant review process, define candidate interview process, define candidate selection process, and define candidate job offer process. And now you ask what makes it true for each of these items to be completed? How do we know that we have defined the current job requisition process? What work would need to be completed? Probably now you're asking well, how low do I go? Here are some guidelines to consider. First is the 8-80 Rule. This means that your lowest level should be between 8 and 80 hours of effort. Now we haven't estimated yet, but your team probably has an idea of how much effort specific pieces of work will take. And the reason behind the 8-80 rule is that if it's less than 8 hours, you could be micromanaging. If it goes beyond 80, it might be too easy to lose track of the work. Another guideline is the distance between status points rule. Try not to let something be more than two status points without showing some type of completed work. The idea is to create manageable work that can be easily kept track of. Then there's the if it makes sense rule or guideline and this states that if and when it makes sense to violate the 8-80 Rule or the distance between status point rule, you should do so. For example, if there's a part of work that's less than eight hours but it's so critical that if we overlooked it, the project would fail, then break it down. Take your time and create a WBS that provides you the detail you need to manage the project. Creating the WBS can be a good team building activity. It helps to gain buy-in from those who are doing the work. It also allows you and the team to discuss how the work will be completed, the type of risks you face, and even initial estimates and resource needs. This is why the WBS is such an important part of your planning. [SOUND]
