PMI PMP Project Management Professional – Implementing Project Integration Management Part 2

7. Creating an Assumptions Log

The assumption log is a document that has a record of all of your assumptions, but also your constraints. Now, why we don’t call it the assumption constraint log, I don’t know. But for your exam, the assumption log has both assumptions and constraints. So let’s nail down the assumption log and talk talk about some different types of assumptions. Because this is a theme we’ll see throughout the project. The assumption is anything that you believe to be true, but you really haven’t proven it to be true. So you assume your project team is going to stay together for the duration of the project, or you assume the project won’t be canceled.

Or we have an assumption that the vendor will deliver on time. That’s all part of the assumption log. It’s updated throughout the project. So we’re going to see that as new assumptions are identified, we update the assumption log. Now, a constraint is anything that restricts your options. So you have to use a particular resource, a type of material you have to develop in a particular software package or code. You have to use a particular individual on your project, or you have a deadline where you have a budget. So that’s predefined for you. Those are constraints. So assumptions and constraints are documented in the assumption log. Some examples of assumptions, I just rattled off many of those. You assume your team can do the work.

You assume the vendor will be on time, and they’ll do a good job. And then there’s assumptions tied to how long and how much. So those are all examples of assumptions and then constraints. Also, policies and procedures. You have to follow these policies and procedures when you do this type of work. So OSHA or HIPAA, even if you’re in health care or whatever, regulations are unique to your application area. Those are constraints because you must do them. Predetermined budget or schedule. I get that question a lot. Is that a risk? What’s going on here? It’s a constraint.

It’s a predetermined budget or schedule. And then things like resource utilization requirements and the technological approach to doing the work, those are constraints. So really easy there. We have assumptions and we have constraints. Assumptions, assumptions, anything you believe to be true. A constraint is anything you must adhere to. Assumptions and constraints are documented in the assumption log. I know you said that out loud. So good. All right. Great job. Keep moving forward. I’ll see you in the next lecture.

8. Developing the Project Management Plan

Okay, we’re still hanging out in project integration management. We have completed initiation as far as this knowledge area goes. And now we’re going to go into planning. So we’re still in project integration management, moving into planning. Our process here is to develop the project management plan. One thing to be really clear about, about when it comes to developing the project management plan is this is an ongoing Iterative activity.

On day one, you won’t have a whole lot of information to plan from. But as you go out and talk to customers and stakeholders and you examine requirements and you work with your team, you get some clarity. This is part of progressive elaboration. Remember, I’m going to build a house for you. What kind of house? Tell me about the kitchen all the way down to what type of pools do you want of that cabinet door? So that’s progressive elaboration. As I know more information, I can plan in more detail. Let’s look at the edo’s to develop the project management plan. You have the project charter. You get outputs from other processes. That’s a great example. I was just talking about day one. We’re not going to have a lot of outputs from other processes. As I go out and I do more and more processes, that allows me to plan in more detail. And then EAF and OPA tools and techniques, expert judgment, data gathering. So things like brainstorming using checklist, focus groups and interviews. There’s our interpersonal and team skills.

Because you’re going to have conflict management. You have to do facilitation and meeting management. And of course we’re going to have meetings. The only output of developing the project management plan is the project management plan. So what goes into the plan or why do we have a plan? Well, the project management plan is a document that’s fluid, meaning it can be updated throughout the project. It defines how will the project be executed, how will you monitor and control the project, and then how will you close out the different phases and the end of the project. So it’s really a guide. It’s our prediction of what we’re going to do. As we move through the course, you’re going to see every knowledge area gets at least one plan. So those plans for each knowledge areas are part of this project management plan. They’re part of this master plan, if you will, but we just call it the project management plan.

They’re called subsidiary plans that are specific to that knowledge area. So for example, in the next chapter we’re going to see we have a scope management plan and then we have a schedule management plan and a cost management plan and so on. Those are subsidiary plans that are part of the project management plan. Once we have a plan created, once we have this project management plan created, what we want you to do is to create a baseline. A baseline is kind of a capture of our intent today. So this is what we say we’re going to do. This is locked in. We have approval and agreement on this plan. After we’ve got a baseline, if there are new changes or new additions to the project or any part of that plan wants to be changed, then we have to do change control. Very important. So we have a project plan.

A piece of paper could be in Microsoft Project or Primavera or Microsoft Word, but somewhere you have the plan, you’ve got a document here. When management approves it and we’re all in agreement, this is what we are going to do. Any change to that plan requires a change request. Very important to know that. We’re going to see that throughout the course. We’re going to see that when the plan needs to be updated, you get a change request. So what’s the purpose of the plan? As I just mentioned, it communicates our intent. It says, why are we doing these activities? It serves as a guide for the project manager. It helps refresh memories, it helps to direct and steer, gives us some structure, it documents our intent and it gives us a baseline. We get baselines for the project. Remember, once you have a baseline, after that you have to do a change request if you want to change the plan.

Who contributes to the plan? Not just the project manager. We have a lot of different participants. Yes, the project manager, you have the project team because they’re the people closest to the work. They’re going to be able to help with the time, the estimating, the schedule, risk assessment, things like that. Customers can be involved because they set things like objectives and key requirements. They can also have a lot of influence on your budget and your schedule. Management is involved because they need approval. So they’re going to direct us on things like the budget, resources you can use, what’s your PM methodology, what’s the quality requirements. And then as I mentioned, they have approval on the plan. When it comes to planning, there is a skill set that we need to have as a PM. Be familiar with these for your exam. So we need to be able to tailor some processes and we’ll talk about tailoring in each knowledge area. I want to be able to develop additional components so those subsidiary plans and there’ll be some documents as well. I have to be able to determine which tools and techniques are most appropriate for the project.

What about technical and management details? So like my project team, subject matter experts, so I need to understand the technology and then the management of that technology. What resources and skills are needed, what level of configuration management is appropriate? Configuration management is all about documenting and controlling the features and functions of the product scope, what project documents have to go through, formal change control. So this is an important part as well. We talked about that baseline. So also in the project, we’ll create baselines for our scope, for our schedule, for our budget. But you might have some other things in there. So you might have like even the risk register, you might have the stakeholder register that are baselined, meaning that they’re kind of locked in. And if there’s going to change, there’s a process to change those you have to follow.

So we’ll see formal change, control. The big one, of course, is scope and schedule and cost. Some of those. Others may be a little bit more relaxed when it comes to change control and then prioritizing work, what’s most important down to least important. So what should you focus on when it comes to project success? In project planning? We’re going to do some data gathering. So brainstorming, we’re going to use some checklist. Remember those focus groups we talked about with the charter? So we can do focus groups here for data gathering, for planning and interviews. You got to get out and talk to people. You will have meetings. We do a lot of meetings and project management. So we want to discuss the project approach. How are we going to go about planning, so a methodology for planning or exactly what needs to be planned. And then we want to document things. So we’re thinking about writing this up on a whiteboard, taking photos of plans, making sure someone’s keeping the minutes. So document what happens in the meeting, and then, of course, we follow up with the minutes and action items.

Very important to do that a kickoff meeting. Kickoff meetings are a real signal that we’re done with planning and now we go into execution. Now, I know some of you out there do a kickoff meeting way back as soon as the charter is done. And I’ve been an organization that that’s just the way we do it. For your exam and in the pinbock guide, the kickoff meeting is after the project plan is approved. It’s not when the charter is approved. After the plan is approved, we do the kickoff meeting. The kickoff meeting is a way to get everyone together, kind of get them excited, get some buy in here and really communicate what we aim to do. And then we go around the room and we talk about the different stakeholders and what their roles and responsibilities are. That everybody’s clear.

Everybody hears the same message about roles and responsibilities and what we’re trying to do in this project. Kickoff meetings and project size. All right, so there is a little flex here when it comes to how formal this kickoff meeting needs to be. A small project. Planning and execution are overlap pretty quickly in a smaller project, so the kickoff could occur after initiation in planning. So I know I just said typically I’ve been in organizations where we have the charter, and then we go into initiation. But a smaller project, I may not have to be so formal.

So it could be in the planning process, we kick it off. Now let’s get to work. Larger projects. The project team does the planning and then the team is brought on when initial planning is complete. So what I’m saying here is you may have a project management team. So like the PMO or a group of executives and business analysts that they plan everything out. So I work with the project manager, I work with business analysts, I work with these executives and the PMO and we plan out the whole project. And then we bring on the project team and tell them this is our plan and how we’re going to do it.

So you could imagine you’re building a house and you’ve got framers. The framers don’t need to be there in the planning necessarily. So the project manager, the architect, the professional engineer and whomever they may create the plan while the framers are out working on another job right now. So we have the plan created, then we meet with the framers, we say, this is what we’re going to create, this is what you’re going to do. So in a larger project, the PM team, the project management team could do the planning. Now, multi phase project, a really large multi phase project, you could do a kick off at the start of each phase. So those are some things that could happen with kickoff meetings. Let’s look at what’s in a typical project management plan. We’ve got a lot of things here in the project management plan, the scope management plan. How will you define the scope and develop it, monitor and control it and do scope validation? We’ll see that plan in chapter five in the pmbok, the requirements management Plan how will you gather requirements? How will they be documented and managed? Also chapter five in the pmbok, schedule management Plan so how are you going to define and control the schedule?

So that’s chapter six in the pmbok guide. Cost Management Plan how will cost be planned, structured, estimated, controlled? That’s chapter seven in the Pinbox, the quality management plan. So how will this project adhere to our quality policies? What methodologies do you do for quality assurance and quality control then? How are you going to implement those? And of course, quality is chapter eight in the Pinbox, resource Management. So how will resources be categorized? How will you get them on your team? How will you manage them? How will you release resources? Remember, resources are people, materials, tools, equipment, things like that. Not only people, so we have physical resources. And that’s chapter nine in the Pinbox, communications chapter ten, our communications Management plan.

So how will you create information and distribute it? How will it be disseminated? Who has rights to it? So basically you’re saying who needs what information, when do they need it? What modality? How will you secure it? How will you archive and retrieve it? So that’s all in chapter ten of the pmbok. Risk chapter eleven. So how will you identify risk? How will you analyze risk? How will you create risk responses and track those risks? Procurement Management Plan chapter twelve in the Pinbox so how will you acquire goods and services? So what are you allowed to do? A lot of enterprise environmental factors here when it comes to procurement. And then also how will you do contract administration? And the last thing that we see here in chapter 13 as far as the Pinbox goes, is stakeholder engagement plan. So how will you engage stakeholders and then improve their engagement or maintain their engagement? So these are the typical parts of the project management plan. Your project plan will also include some baselines. Remember, a baseline is kind of a snapshot of where we are right now.

So some baselines that we need to know we have a scope baseline. A scope baseline is really three different documents. So we have the scope statement, the work breakdown structure, and the WBS dictionary. And we’ll really dive into that in the next section when we talk about scope management. Then we have the schedule baseline. The schedule baseline is just our schedule model. It’s where we say, this is how we get from the start all the way to the end. So this is the flow of the work and how we get all these activities done to hit this target end date. So that’s our schedule baseline. The cost baseline is a time phase project budget. So it’s basically saying here’s how much the project will cost to get from the start all the way to the end. But this is when you can expect to spend the monies to get to the end. So it’s not just $180,000. It would say this is how much you’re going to spend for phase one. This is how much you’ll spend for phase two. Phase three, all the way to the end, which will equal $180,000. That’s a cost baseline. Some other items that go into our project plan, we have a change management plan.

So how are changes allowed and controlled? The configuration management plan. How will we control, document, review and allow changes to the product scope? The features and functions of what we’re delivering in this project. The performance measurement baseline is really the three scope, schedule and cost to show overall project performance. The performance measurement baseline, you also have a description of the project lifecycle. Are you doing a predictive life cycle where upfront you plan everything and these are the known phases, or you’re doing an adaptive life cycle where you’re using iterative or Incremental or Scrum or XP.

So what’s the process look like for that type of a life cycle? The development approach. Again, so describe your development approach with predictive iterative agile or some hybrid method management reviews. At what point throughout the project will management look at and review progress project documents? Okay, I’m not going to read all these to you. That doesn’t do you any good. But you can see there are a lot of project documents. As we move through the course, we’re going to see all of these. So each knowledge area will create some project document.

So just go ahead and think of any knowledge area. Think of quality. Well, if you skim over this, you’re going to see, okay, there are some documents related to quality. Let’s think about resources. So if you look, there’s a resource breakdown structure and calendars and requirements. Every knowledge area, chapters four in the pmbok guide, all the way to chapter 13 in the pmbok guide. Create project documents. So you will need to know these, but it’s really not just memorization. You’re going to need to know how to apply them and what they’re used for. So they are part of the project management plan, but really it’s about using those at the right place and the right time. We’re going to see as we go into each knowledge area, those EDOs will be using different project documents. Often we’ll see as an output, we’ll see project document updates. So this is what we’re updating, the relevant project documents. All right, good job. That was all about the project plan. Keep moving forward. I’ll see you in the next lecture.

9. Directing and Managing the Project Work

We’re still in project integration management. We’ve done initiating, we’ve done planning. Now we’re going to talk about the processes to direct and manage project work. We know that project management is about getting things done. So this means executing.

Our process for executing is to direct and manage the project work. We want the project team to go out and get things done. So this process is about satisfying project objectives, doing the work, spending the money. This is done throughout the project lifecycle. So each phase we’re doing the work right? So we’re directing and managing the project work. It’s also about managing risk and allowing approved changes to come into the project. Some other things that you’ll do in directing and managing the work, we have to manage communications.

So follow that communications management plan, collecting project data that we’re not just doing the work, we also need some data about the work. So things about actual cost versus what was planned, actual duration of task, what’s the overall project progress, and that allows us to report on that business. So we’ll talk about data in a little bit more detail. Coming up completing Lessons Learned we do this throughout the project and managing stakeholder engagement. We want stakeholders engaged and then we also want to increase their engagement or maintain their engagement. Let’s look at the edo’s for direct and manage project work.

So our inputs here the PM plan. Any part of the PM plan can be used with direct and managing work. The different project documents, well, specifically the change log, our lessons learned milestone list, our communications, the schedule,

a new term requirements traceability matrix. This is a table where we just track requirements through the project. We’re really going to see that in chapter five on scope management and requirements. The risk register, a risk report. So those are all project documents. The approved change requests, we have to get those into the project to actually create them. And then we have EEF and OPA tools and techniques. You need expert judgment. You’ll be using a project management information system, a PMIs. So, like Microsoft Project or Primavera. That’s a PMIs.

And of course you’ll have meetings with your project team outputs. What do you create as a result of directing and managing the work? We have your deliverables. You’ll create data that raw data, issue log, change, request updates to your plan and to project documents. Look at all these documents that are updated here. Your activity list could be updated, your assumptions log, obviously lessons learned. You do that throughout the project. Your requirements could be updated, your risk register and your stakeholder register. These all mean that it could be updated, doesn’t mean they have to be. And then you have OPA organizational process assets updates. So that’s directing and manage, managing the project work. Remember, we’re in project integration management. So this is the big process and execution about getting things done.

10. Deliverables

Throughout your project, you’ll be creating things. The things that your projects create are called deliverables. So projects create deliverables. It’s basically anything that’s unique. It’s verifiable. It gives us a product, a result or a capability. It’s an output of the work you do. So your team creates blueprints. That’s a deliverable. Your project creates a physical device that’s a deliverable. So it’s typically anything out of the project. In addition, it’s any component of the project management plan. So in planning, we create a quality management plan that is a deliverable. Doesn’t mean the customer gets it, we keep it. Another type of deliverable could be a piece of equipment you purchase for the project. The customer doesn’t get it, but we keep it.

So a deliverable is anything that the project creates or as a result of the project work. When we have deliverables, we also have change control. As soon as we have the first version, any changes beyond that is change control. So as soon as we have the blueprints created, if there’s a change to the blueprint, that’s a deliverable. So we need change control. The control of multiple versions of a deliverable is configuration management. So on these blueprints, when we have to make changes, we want to change the size of a room or where the HVAC is or the mechanicals are. Those are changes. So configuration management would say this is version one, this is version one one or version two, whatever the case may be. Version 1314, every time there’s a change to those blueprints, because we want consistency.

We know when we have a document or blueprints that’s going to be distributed to all these different people, is to always make sure you have the most recent version. That’s configuration management. That if you’re changing the features and functions of even a document, it should go through configuration management. Once we go through scope validation, any change to the deliverable is going to require a formal change request. So let’s talk about this when the project team creates, let’s say the house.

All right, so we’re building a house. So they create the house and we’ve got it all framed out. And the customer comes out and they’re walking into the garage and the kitchen. Remember, it’s just the studs, it’s just the frame here. And they go in the kitchen and they say, you know what? I’ve got this antique table. This isn’t big enough. It needs to be another 2ft. This room has to be 2ft larger. We’ve already got it framed out. So when we’re doing scope validation, if there’s a change, then it requires a change request. So you could even take it one step further. The customer comes in and said looks at the frame and they sign off and they say, it’s great, it’s perfect, exactly what I wanted. And so then we begin putting up the sheet rock or the drywall, whatever you call it. The walls, actual walls of the kitchen and then they come back in and they’re like, oh, now I can really see it. I need more space in my kitchen here.

They’ve already validated the scope. They’ve already approved that deliverable the framing. So now we have an even bigger change because there’s going to be a lot more time and expense to make that change. So once approved as part of scope validation, now you need a formal change request. And then of course, in that instance, like the last bullet point, changes to the deliverables mean more time and cost. So even if they made the change when we had the frames up, it would be time and cost because we’ve already paid for that labor to frame it. So if you change it now, you got to pay for the labor to fix it. You already pay for the labor to do it the original way. I’m not saying it was wrong, but you have to move it over 2ft. So now we have more time and more money that’s going to be in vested in the project. So that’s some things to know with deliverables and change control. All right, keep moving forward.

11. Work Performance Data

Throughout your project, you’ll be creating work performance data. Work performance data is just raw data. It’s not necessarily very useful, but it’s just kind of facts and figures. So it’s data that is based on the observation, the measurements, any type of an output or fact act about your processes or activities, like how much did it actually cost, how long did it cost, how many defects. Just raw data. It’s not very useful. Data is analyzed, and it becomes information. Information is usable now.

Once I have information, then I can create reports, so it’s communicatable. So remember, we had data information reports. So work performance information helps you make decisions. Let’s look at some work performance data samples here. So some different things you might have data on from the scope. You might have compliance or nonconformities.

How many change requests, and what are the factors there in the schedule you could have, how many activities are in motion, how many are done, what’s the current status of those activities cost. You can get a lot of data. What’s our cost, our cumulative cost? How much money do we have left? What type of variances quality? You’ll have technical performance data, different quality metrics that are unique to your project, your discipline.

How many defects did you have? What about the rejection rate? So when you went out and inspected it, how much was wrong and how much was rejected? You had to do it all over. In communication, you could have what are you communicating? What type of feedback? In risk? We track a lot of things in risk, so you get a lot of data and risk.

So the different events, did they actually happen? Are there unidentified events that came into play? How many risks are you identifying each week or each month or each quarter? How effective are your responses? How much money do you have left in the contingency reserve to offset risk? And then procurement, you could have some with the sellers. How long are they working, what’s their cost? So that’s all work performance data. You can get data. These are just samples. You can get data from all over your project on anything that you want. If you track it, if you have metrics to track it. But remember, data is just raw data. It’s the information that’s used useful and reports or how we communicate it. All right, good job. I’ll see you in the next lecture.

12. Issue Log

One way of describing an issue is to say that it’s a risk event that has occurred. Issues are kind of disruptions in your project, things that have to be resolved. You have to do some analysis. You have to work with people. So we need a place to document issues. Well, this document is the issue log. The issue log is a way of identifying the issue type. Who raised the issue and when was it identified. Tell us about the issue. You have a little narrative or description. How important is this issue? We know some issues are kind of petty and some are very serious. Who is assigned? So you need what’s called an issue owner that they are tasked with finding a resolution for that issue. And then you have a date for the resolution. What’s its current status? You can track it.

And then what’s the outcome of the issue? So the issue logs. So, for example, if we look at this little piece of trash here, we’re at a construction site, and the neighbors around this construction site are saying, hey, your crew is throwing the trash out here on the street. And I know it’s minor, but I don’t want to look at it. So that’s the issue type. So who raised it was a stakeholder and when that was on November 1, we have a description, crew stowing the trash on the street. The issue priority, I want to say it’s moderate to high. We don’t want our neighbors or other construction site to be mad at us or to be mad at the homeowners or to have a negative connotation. So who’s assigned to it? We’re putting the team lead that’s going to be assigned to it, and we need a resolution by this.

Hey, I’ve given you one week. Pick up the trash and don’t let it happen anymore. So we’re going to have on November 8, it better be resolved. So the issue status, is it’s in motion or pending? And then on the 8th, the outcome is the team lead report says, hey, we didn’t have a good trash can out there by the curb. We’ve taken care of that. I spoke to the team. Everyone agrees. They apologize. We picked it up. And so the outcome is it’s resolved that it won’t be an issue any longer.

All right, so it’s kind of a pretty silly little issue, but those are the types of things that you have to deal with in a project. So here’s an issue log sample where we have a numbering system for our issues. This could follow your project numbering the different types of issues. I’ve got environment, hardware, vendors, resources, and so on the date it was identified, who identified it, what’s the description? And then the priority level. And I’m using from very high to very low here. So just a quick way to capture the priority level. Who’s the owner? Who’s going to figure it out and resolve it and then the different statuses, including to be determined. I give a deadline, and then what’s the outcome here? So that’s the issue log. It’s a way of identifying and tracking and getting the issue resolved. So an issue log is something we’ll be updating throughout the project. All right, good job. No issues here. Keep moving forward.