How to Make a Project Management Plan (Complete)

Have you ever wanted to create your own

project

management

plan

but aren't sure where to start? I know when I first finished the PMP there was so much information that could be included in your

project

management

plan

, but there just wasn't a real step by step or a nice way to do it step by step and also show you the wealth of information and tasks that we have to carry out as a project. leaders or project managers just as a brief overview before we start to give you an idea, we will go over the project management plan itself with all its information and then all the subsidiary plans, starting with the stakeholder management plan, how managing our stakeholders, our requirements management plan, how to collect the requirements, prioritize them and

make

sure they are delivered in the scope management plan, then how are we delivering these things that meet our customers' requirements, the schedule management plan we are taking. that scope and show when we are going to deliver it and how we are going to tie all this together our approach to managing our project schedule the cost management plan to manage the cost and budget making sure that all these costs are kept under control and we are delivering within budget What we said we would do.

There is a quality management plan that shows how we will meet the quality required by our customers and ensure that there are no defects. Make sure there are no problems. Management plan where we show how we are going to manage resources and these could be the people in our project or they could be materials or things that we are putting together to create physical products communicating and managing communications, so how are we communicating? with all those stakeholders and making sure that everyone gets the information they need to do their jobs and also to keep our stakeholders and our customers happy;

Then, when we get to the end of those subsidiary plans, we have risks. and the enormous amount of risk management that we will have to do as project managers all the time with risk breakdown structures, risk definitions, risk profiles and risk registers, making sure that we are managing those things and preventing things from happening. go wrong on our project and Lastly, if we have procurement, suppliers or third parties that we are working with on our project, then we will need to create a plan and a management plan for how we are going to deal with those things and

make

sure that they are delivering the product that we need them to deliver within their cost and within their timelines, so there we are, let's go through each one step by step, it's going to be absolutely fantastic, let's start with our overall project. management plan and I'll briefly show you how I set up a lot of these things and then we won't get into that in much more detail.

I'm going to assume that you have some basic PowerPoint skills and a lot of these things you can do with some basic PowerPoint skills, like creating lines and creating shapes. In this one, for example, we're going to insert any of the shapes and we have a nice hexagonal shape there and we can also insert icons, so if you're going to insert and icons in PowerPoint, these two things together if you select both by holding down the shift key and then you right click, you can group those two things together, it's as simple as that, the text I usually put in an aerial font, so something a little bit more. professional than standard PowerPoint fonts and the rest of these things you'll see are basically lines and shapes, so you have triangles, you have lines here above the title and shapes like squares to tie everything together, so with the project management plan The purpose of this document we are describing the project development approach the current status report we want to capture all the baselines of the project so hit schedule and cost and even quality if we want and then we want to capture all of those plans subsidiaries that we just reviewed, so here is a brief table of contents and I won't go over this because we will review these sections individually in more detail, but there is a brief overview so you can take a quick look. and the first thing we're going to start with in our project management plan is our roles and responsibilities, we want our names, project roles and what people are responsible for so we're really clear and on the same page. and you'll see this appear in every subsidiary project management plan, so the quality cost schedule, uh, all of those things, uh, we're always defining our roles and responsibilities for each part, the next thing we're going to do is just a brief project status report and this may be updated periodically as we progress our project.

You can display it in many different ways. We usually want to have an update on our schedule. this is just a high level milestone. this is just a high level milestone. update, so where are we? Is everything on track? Is it on track with green requiring attention or is it off track with red just a brief status? So we have that for schedule, we have that for cost, what? our planned cost versus actual cost, do we have any risks arising and what is their status? and do we have any issues we are currently dealing with in our project?

You can also add some wins, if you want to show the things that your project team has been doing well. Another way to do this is shown through feature-driven development, which is an agile technique. The project status report can be displayed as a feature status report, so present one, what is the deliverable we are delivering, who was it assigned to. How many work packages do you have? What is the red, green or amber status and what is the progress of this deliverable and when is the delivery date? So this is a really nice way to show those high-level deliverables and whether they're on track or off track.

In the project management plan we are going to show the phases of the project, so what are the phases of our project? It will be different depending on your industry, the product you are delivering, the company you are working for, but generally speaking we could go through things like ideation, creating a business case for example, going through Discovery, getting the costs and the benefits, then go through the project design, create and if it's physical, maybe it's plans or CAD designs, for example, if it's software, maybe we can are creating architecture diagrams and designing the overall system, then we build the item, we test the item, we make sure it's quality and we transition it back to operations or business as usual.

That's a good high level way to look at it, but you might have different phases in your project and we all want to be on the same page and outline that and we can put that in a timeline view as well if we want so we want to outline our development approach project if it is agile it is waterfall what are the ceremonies or what are the meetings that we are going to have and the timing of those things, how are we catching up as a project team in our project management plan. We want to put our change control plan and our configuration management plan so that change control is how we are going to make changes or how we are going to approve changes if they arise, for example, if we have delivered a large number of deliverables or scope and then the client says, well, I want to make the change I want.

To add something or I want to change something, now we have to see if that will affect our schedule, that will affect our budget, so we do that change analysis and we want to outline our process here, so who is going to do that analysis. who needs to approve those changes and how it is done. This is our process again so everyone is clear. Let's make our Change Control process very clear. Here is a way to show it another way step by step if you really want to. and here's another way, if you want to make it a little bit prettier again, boxes, rectangles, circles, text and triangles, all those things that you can put together to make it look really beautiful and, yeah, then you have that option.

We also want to put in our configuration management plan, which is Version Control. So what is subject to Version Control? How do we know we are working on the latest version? This could be the latest version of our software or the latest version of our plan. but what are those things that we are doing for version control and how do we know that we are working on the latest? How do we roll back to a previous version if necessary and what testing or approvals need to be done? moving forward to a newer more recent version, so this is our configuration management process again, let's make this clear now we want to put our performance management baseline, what is our scope.

Baseline, high-level deliverables, schedule. Baseline, our highest milestones and our cost. Baseline, which one. it's our high-level budget and we'll look at those in more detail in our individual subsidiary project management plans, which brings us to all of those plans, stakeholder requirements, scope schedule, as we saw before. Now is a good time to delve into them individually. One that we want to start with is our stakeholder engagement plan and the reason for this is that we are going to need all of these stakeholders and St people for our project to collect information for them to do the work on our project, so The purpose of this document is to describe our approach to stakeholder engagement.

Capture stakeholder details and communicate their communication needs. Capture stakeholder engagement levels to ensure they are engaged and working well. Describe other methods of stakeholder engagement, so we'll look at those at the end. Here is our table. of content for stakeholder engagement and this is what we are going to look at in more detail, but you can take a quick look at the overview here. The first thing we're going to start with is our stakeholder engagement process, so what is our process? creating the stakeholder engagement plan, who does it, how do we update it and what is the escalation process if things go wrong regarding stakeholders, the next thing we want is our stakeholder registry, which is who is involved in our project, what is his role and responsibility. everyone, not just for each slice but for all slices and we want the influence of the stakeholders and their impact and the reason why we want that, I'll actually show this, I'll show this part now, but we want to classify those stakeholders, so if they have a high influence on our project, then we will need to communicate very well with them and if we are impacting them quite a bit through our project, then we will probably also need to communicate very well with them, so this is a good way to look at it, if we have high impact and high influence, then we will need to communicate and engage a lot with those particular stakeholders, we will also need accountability.

The allocation matrix we can also show this as spicy, that is, who is responsible for a particular task, who is responsible, who needs, who must approve, who is consulted, from whom we get expert judgment or their experience and who is informed, who Do we need to provide the information or details once it has been created? This is a great way to show roles and responsibilities. We also want a resource breakdown structure. This is just for our project team and it's like a breakdown chart of organizational barriers which is a bit of a mouthful for me, but there you can see our different areas, we could have business analysts, developers, testers, product owners or businesses, people with subject matter expertise, and all these different people, we could have potential clients and we.

There may be people within your team depending on the size of the project, but we only want to show the structure of the project. This is our resource breakdown structure. There's a few different ways we can show that again, just beautiful shapes in PowerPoint, uh, without a nice circle with a shadow uh, really really nice ways to make it a little bit more beautiful if you really want to and here's another way of our res resource breakdown structure. We have already seen the stakeholder rankings. Stakeholder engagement. We want to mark our stakeholders on the left hand. they are here and they are not aware of our project, they are resistant, they are neutral or they support and lead C is what they currently are and D is what we want them to be, so basically, ultimately, we want all of our people to support us or leading if we can, but what are they currently and whatWhat should we do to move them to the right side? communication preferences how people prefer to get information and what information they need, we could have a communication schedule, so it is every week it is every month it is every day we have daily meetings and who is involved what we need there we can show it at a good time if we want or it could just be at a table, uh, which is another way to show now it's

complete

ly up to you, lastly, we have additional engagement approaches, we have team growth or training, rewards or recognition promotion opportunities, team outings or team meetings or anything else you want to put in place to help engage stakeholders in your project now once.

We've brought together those stakeholders and all that information, I see that's already a lot of information, right? And maybe there are some tips you've already gathered to include in your own project management plan, but once we have those, we can start Gathering and sourcing requirements from our clients and stakeholders So what do they need and how are we going to deliver it? ? With requirements we want to outline the requirements management approach. We want to capture all requirements and track them to their deliverables. We want to outline the requirements prioritization process. So how are we? prioritize which ones are delivered First and we want to outline any change control process for the requirements, so that if the requirements change, how do we go through that?

Who needs to approve it as we saw before? Here's a table of contents for our requirements management plan and typically this. it could be managed by a business analyst, or someone who deals specifically between the client and our, the people who deliver the actual deliverables, whether it's a developer or a construction manager, all that kind of stuff let's start with our functions and responsibilities. First, as always, you'll see who is responsible for managing requirements come up frequently and this is the process we're going to follow. Let's describe the process for gathering requirements, managing them, prioritizing requirements, and updating the requirements management plan as we go.

Making changes here is just another way to show that the process is pretty easy to put together, but a nice easy way to make it look more beautiful. The most important part of our requirements management plan will be our requirements traceability matrix or structure and in this we have the requirement, we have the priority, the scope or deliverable that is attached to it, so how are we meeting that requirement? , the scope ID, any acceptance criteria, and our test cases, so you'll see that it tracks you all the way. from idea and requirements to scope, delivery, testing and quality control and finally to being delivered to our client, so that we know that we are really meeting the things they need, the acceptance criteria structure So how are we describing? these requirements and there are a lot of different ways to do it, some really good recommendations here, we have behavior driven development, we have use case styles, which are having the actor and their goal and then the process happens in the middle, to get there, that's how we describe our requirements, many different ways of doing it, the requirements prioritization process, so how are we prioritizing which requirement goes first?

Here, many different ways to prioritize Moscow cost to benefit, cost of delay, graphs or multi-criteria decision analysis. Stakeholder voting could go another way, in many different ways, so we can simply choose or add another of our own if we really want to. Here is a Cost-Benefit Prioritization Matrix or a Value-Effort Prioritization Matrix. You have the Moscow Matrix here. We have Kano analysis which looks at the level of customer satisfaction over time, because customer satisfaction tends to decrease over time, it becomes more normalized, it might start out as a wonderful idea and over time people They just get used to it and wait. those things in your products, the cost of delay, you'll see the cost of delay quite a bit, where you got the features and, uh, the expected profit, the length of delivery and then we prioritize by the highest, once we divide those two things together, uh.

So it's a good way to do it. The multi-criteria decision Matrix is ​​one of my favorites if you have a lot of complicated requirements or criteria that you're measuring against and then you have all your characteristics and you can measure them. 1 to five and then add them up and select the highest or average them and select the highest, so that's a great way to do it now. Control of requirements changes. We will have to have a process to know what happens if the requirements. change who needs to approve it uh and maybe it's simple maybe it's complicated maybe there's a lot of people involved maybe not, but we have to outline that and make sure everyone's on the same page in the reporting format so how do we report about our requirements and any organizational links we really need to know now once we have the requirements we need to look at the deliverables and the scope so how are we meeting those requirements?

The purpose of this plan is to outline our scope management approach, our process, capture the Scope Baseline which includes our scope statement work breakdown structure and the work packages we are going to deliver so that small pieces that people can work on as project teams or project individuals and describe scope reporting formats and their schedule, so here's a Table of Contents of all the things you can include in your scope management plan and we'll look at them in more detail and, as always, start with our roles and responsibilities, who is responsible for managing the scope staff and what they do.

We need to do as we go through our project, the process of creating the scope baseline, so what is our process of creating the scope baseline? Where does the information come from? Who needs to provide that information? What are the steps we are going to follow? We'll also look at the scope of the Change Control process, if something needs to change, how we look at who's responsible, and some different ways to show that again we can make it a little more beautiful with some different colors. and it frames and shapes that kind of thing. We also want to look at the definition of ready and the definition of done when we look at our scope management plan.

The definition of ready is when something is ready to work on, so maybe we need to have our acceptance criteria, maybe a prototype or a mockup, maybe it needs to be approved by the project sponsor or a senior user, whatever. Whatever those things are, let's describe them so that we are all clear that the definition of done is when something is

complete

and delivered and quality verified and ready to be delivered to our client and what are the steps, what are the things that we must mark for our own definition actually in our own project, the project scope statement, this is just a high level statement, a few paragraphs, what are we delivering and then the high level list of features or deliverables just the big high level things and then anything that's specifically out of scope and we start with the high level because then we go down to our work breakdown structure, actually, let's look at that now? because with that we basically break down those high level features into smaller tasks into work packages that someone can work on, so we make note of the process that we want to write down in our work breakdown structure, it could be a table or it could be a visible image.

So, there are a lot of different ways to display this and once we have that, we also want our d Ary work breakdown structure, which has all of those deliverables and the work packages, but then we add all this additional information like the resources we need the cost we need for that particular package the schedule or due date for that particular package and any quality or testing requirements for that particular package who it is assigned to and whether it has been approved or signed and completed now when we have those things, we can consider prioritizing the scope again, some different ways of prioritizing, we can use those same methods, choose the one that best suits your project and therefore the cost of delay, the cost over benefits, Moscow, for example, all those things, whatever suits and Whatever you agree on as a project team, now the lowest level in our work breakdown structure is often our work packages that we can assign to someone and he can work, complete and deliver, so we have our deliverable and the work packages underneath. that and who they are assigned to, is a good way to get everyone back on the same page.

We also want to show who we report to and how often, and then any organizational links we need to company-wide templates or procedures or other information, uh, sites we might need to link to, there you go. I mean, isn't that already a lot of information? So this is really good and we're almost halfway through, but now we have the schedule management plan. our scope our requirements now we can put them on a schedule, when do we need to deliver these things? So the purpose of this plan is to outline the process of creating the schedule, to outline the basis of our estimates, so how do we arrive at the duration estimates? level milestones and show our project schedule and any impacts to the schedule and again here's just our table of contents a good way to see what we're going to do in our schedule management plan and as always we'll start with our roles. and responsibilities who is responsible for managing the schedule, who should be involved, what should they do and we can also start with just a list of high level milestones, so just the big things, the big blocks, when are they coming up and there are a few different ways of showing this here is another good way to show the high level milestones of Schedule Master Stones again in a nice little roadmap here, so this is all very easy to create in PowerPoint with your shapes and again just squares and shapes and lines um, but that's a good way to look at it, what is our schedule planning process, how do we create our schedule baseline and how do we maintain it and also what is the change control process, so if things go over time or over schedule, we might need to ask for more resources or more money and we have to go back and go through that Change Control process.

It could be agile or waterfall. Maybe in Agile we are just approving a scope change to reduce the scope, for example, as a product. owner, but in a waterfall project maybe we have a change control board and all those steps need to be followed, so whatever your process is, we just need to outline it and make sure everyone is clear and on the same page. We're going to want to look at the basis of the estimates, so how do we come to estimate the durations of these particular elements? What are the roles and responsibilities here? What is the process?

Are we using different methods? Analog Delay Estimation Parametric Broadband Delay Estimates and you'll be familiar with these if you've been through the PMP or if you've been through some project management training, but here I just want to describe what your process is, so how do you we are meeting and what? The assumptions we have made to make those durations correct. We also want our list of project activities, our deliverable or our work package, what the activities are, what the activities are that we need to perform, and what their available durations, dependencies, and delays are. that we might have, so this is a good way to start putting this together for your project schedule and then we also want to do things like do the sequencing of the activities, so do we have a deliverable here?

This is one way. to show it, but you can show it in many different ways, it could be just circles or squares, it could again be a table, it's up to you, but we want to show the order that things should be in, so which one should go before the another and this is a network diagram of the schedule, so that's one way to show it. Once we have all of those things, we can put together the schedule for the project itself, so it usually looks like a Gant chart on a calendar. There are a few different ways to show this again, but generally you have the deliverable, who assigned the start and end date to it, and then it shows on the calendar where things will be delivered with our schedule management plan.

We want the calendarcommunication from our stakeholders and, if you're a little smart, you might have noticed that some of this overlaps with our stakeholder document, right? So those two things can sometimes be put together if you really want, just to simplify it a little bit, but otherwise we'll mention it separately so that I want to show the flow of communication information, where it comes from, where it should go and describe common project terms so everyone is on the same page. Here is our table of contents for the communications management plan. Can you guess? What could we be starting with, that's right, you're already clear, the roles and responsibilities are who is responsible for managing communications and what they should do.

Here's a glossary of common terms, so if we have acronyms or industry terms, put them in the document so everyone is on the same page and what the flow of information is, where it's coming from, we can put it in a flow document of the project or in a flowchart, it's up to you or you can just put it in a table. if you really want it, but where does it come from and where should the communication management process end? How do we create this plan? How do we do it? Who should we escalate if things go wrong?

Are there any restrictions? our communication, are there any legal restrictions? Can't we tell people certain things? Maybe different departments can't actually know certain things, so let's put that out there and make sure people are clear so there are no mistakes. We have our Stakeholder Matrix that we looked at earlier and that is the biggest impact and influence. We really want to work with those stakeholders making sure they're in the right place and getting the right information. Joint Communication Styles M this is good, so we can talk to our stakeholders or our project team or we can send an assessment so we can ask them how, what information they need and what the preferred communication style is.

They prefer email. They prefer. a working group, they simply prefer a report or an update, they prefer a daily face-to-face meeting, or picking up the phone, what would it really be like for them if they had their ideal situation so that we can then put their communication needs to the parties? stakeholders are there and what needs to be communicated how often who is going to receive it or we can look at it another way what the stakeholder is, their area, their expectations and the communication approach they prefer. So that's a great way to summarize the communication and now we move on to the last two big jobs, guys, incredible work, the big ones, the two big ones, actually, they risk, there are always, there are always risks within our project and we have to know how we are going. to manage it, so the purpose of our risk management plan is to outline the risk management approach, show the current and delivered risk profiles, so do our stakeholders accept the risk that we are delivering?

Outline the project risks and their impacts and their likelihood of occurring and then show any risk financing or stakeholder risk acceptance at the end, so here again is the index of our risk management plan, an idea of high level of what you could include in your own risk management plan and look, I don't even need to do that. I'll tell you now because you know we're going to start with our roles and responsibilities, so who is responsible for managing risk? Isn't it great when everything starts the same way every time? It makes it nice and easy but who is responsible and what should they do when managing the risk management process so describe the risk approach if it is qualitative if it is quantitative we need additional data we need to do simulations who is involved who provides the information?

Who approves it? Are we using impact or probability or are we using additional information such as proximity detectability or strategic impact of the risk? Do we have certain meetings or activities that are risky or Cadence? Do we meet every week? Do we meet once a month? we have a certain special risk person or it is management by the project manager or it is managed by the client. How are we describing this? Just make sure everyone is clear about the risk. We also want risk categories. Now it is possible that you have them in your or in your organization they already have a control and see if they have them, if not, it is better if you create them yourself, so we are going to have, basically, like a risk breakdown structure , so we describe all the high-level ideas. where the risk might come from, so what are all the technical risks, what are all the risks with the materials, what are all the risks with the brand and then we break them down in more detail, the specific risks themselves and then we can use them as a brainstorming list and just pick those particular risks when we put them into our risk register, so it's a pretty good way to do it and then actually the organization can use it in the future because it's a excellent standard approach, very good.

We also want our definitions of risk, so when we say a risk has a high probability, probability here, what does that really mean? Or when we say it has a high impact, what does that really mean? Now it will be different for your organization, but here. It's an example, for example, a high impact could be a time cost for us of 6 months on our project or it could be a money cost of $1 to 5 million. Again, different for your industry, different for your product, different for your organization, different for your team, but make sure everyone's on the same page and let's outline those risk definitions, then we want to put in our existing risk profile, so What is the current risk profile of our product?

Are there already risks in our product that we are trying to eliminate? or there are already risks that we need to be aware of that we can't resolve through our project, so let's put in the current U risk profile for the product we're delivering and then we want our risk register to really be the main part. What are the risks? Let's brainstorm about them with our team and with the company and with the customer and with the product owners and with whoever we need. What is their probability of happening and what is the impact if they happen and once we have what we want?

To put together the risk score, as you can see, we can score those risks if it has a medium probability but a high impact, then it's going to be a severe risk, so that's a good way to do it, so we want a risk. answer so how are we going to mitigate that risk? either we just accept it or we need to transfer it by purchasing insurance. How are we going to manage that risk? And then, once we have done that management, what is left? What is the residual risk? uh hopefully we've reduced that risk through your management.

Do we need additional quantitative data, like simulations or other things, like financial data, multi-criteria decisions about our answers, do we have different answers, um, and how do we actually decide which one? The answer is the best, we can use a multi-criteria decision analysis if we really want to and once all that is done, what is the residual risk or the risk generated if we start as a sustainable product, but when we deliver our product maybe we have added a There are few risks and now it is serious. We need to ask our client if they accept that risk or, hopefully, we've kept it similar to what it was before risk financing, so the risk and contingency reserves and what the process is to access those risk reserves. risk when we really need them, so when a risk arises that we don't have money for through our project, what is the process to get access to that reserve fund for contingencies, risk reports, who needs to know about the risks and how often we should communicate with them. and approval and risk acceptance at the end once we deliver our product, what are the remaining risks and who needs to approve them and accept the risk that we are delivering and now we are down to the wire? part which is procurement and we could do this at any stage of the project, but it's just the last part here, because with procurement we have an external supplier or someone who hands over part of the project to us for the purpose of procurement management.

The plan will outline our procurement strategy and process selection criteria for our suppliers and any pre-qualified vendors we may have in our organization. Let's outline the statement of work for the project. What does our supplier need to deliver and display the supplier tender documents among many other things, as you can see there is a lot involved with our procurement management plan so here is all the information we will need to review and this is a great way not to do it. Let's not forget any of these things and as always, we'll start with those roles and responsibilities for procurement.

We may have people who make the contracts, maybe someone who chooses the seller or creates the seller criteria or the supplier criteria, many different roles. of different responsibilities, uh, let's describe them all here, the procurement management process, so what is the process that we are going to go through for procurement from start to finish? Now there's a lot of information that we're going to put in here and we might want to leave this until we've completed our management plan because there are a few different ways that we can display it, so starting off, what are we doing here with the seller lists?

Getting estimates from commercial databases, so we are planning to create this statement. of the work being done, who approves that statement of work, the contract types and the reasons for using them, so this is a really good way to show this from start to finish and the steps we might need to take with suppliers and acquisitions. Let's describe our process for creating the acquisition management plan. So how are we creating the acquisition? How do we prepare the statement of work? How do we prepare high-level estimates? How do we advertise the opportunity? And again, this is a beautiful bullet point list.

You can add something to this or remove it from this list, but this is a great message to always be up to date and know that you have these aspects covered through procurement, identifying the list of qualified vendors who issue the bidding documents review of proposals many things different here the procurement management process uh as we are actually managing our supplier once we have selected them so this is another phase again do we have periodic product reviews do we have a product acceptance process do we have an escalation process, what do we do with the knowledge, training or knowledge transfer once the item is completed?

There's a lot of things here that are a great message for you and you can add or remove this again and we can show it as a process flowchart if you really wanted to know. The first thing we are going to do in procurement before anything else is to do a make or buy analysis. We want to know if it is really better for us to make the item ourselves or if it is better to buy it. and we have to look at ongoing costs as well as initial costs, so something might cost $11.4 million to make and $1.7 million to buy, so it's more expensive to buy, but over time, as You can see in this graph the manufacturing cost.

Keeping it in-house is actually more expensive, but this is just an example - you need to do the analysis yourself and make sure it's right now that we have our supplier Source Selection Criteria, what are we using to choose our suppliers? Does it have to be delivered by a certain date? Does it have to have a certain presence in the market? Do you have to be able to include particular parts of the scope? You have to have a budget less than x amount of dollars and then we have? our list of pre-qualified sellers, so in our organization we may already have a list of sellers or we may need to go out in the market and advertise and get more details of more sellers so that we can put them and be able to choose. those vendors once we're making that selection, we also want independent estimates, so with independent estimates we want to make sure that we're in the ballpark for the right cost for our suppliers, it gives us something to compare it to. look at a timeline of acquisition activities and again we can put this into a visible way to do it or a way to do it with a milestone.

The statement of work is what our supplier is going to deliver, so what are they responsible for delivering and who is going to do it? deliver it, eh, and even when we want themterms of reference include all the things the supplier is going to provide, it's a shipping schedule, so what is your list of approval times for any data or services that need to be provided? Bidding documents are our requests for information, request for proposal or request for quotation, quotation is simply a monetary matter, so how much are you going to quote for this proposal? If we have a complicated situation where we need them to propose a solution and a request for information is just more information about their services, perhaps we could use that when we are collecting more information for a list of qualified sellers, for example, so that everything this starts to take shape and then once we have everything.

Before your information comes back, we need to make a decision about who to go with and we can use our source selection criteria and suppliers and put them together in a multi-criteria decision box as we have seen on different occasions before, in a very useful way to make procurement metrics decisions how we measure our supplier whether the features delivered whether it is delivered on time delivers within budget and at the end of this what is the complaints management process if we cannot reach an agreement if something has not been delivered as per the specifications but the supplier does not agree that is the case, then what is the dispute resolution process and lastly, here are the names of the third parties if we have alternative dispute resolution and we want to include this in the document just to be clear and We are sincere that this exists and that this will happen if we cannot reach an agreement and that is the end of our acquisition management plan.

There's a lot of information in that one, and generally, that's all the information in our project management plan. Now you, as a project manager, understand why. things can seem so complicated and so complex and why we really need to be very good at outlining all those things so that everyone is on the same page and we have our plan and our way of working really nice and crisp and that's what a good project management plan can do for you. I hope you enjoyed this video. It's been a lot of fun for me and I'll see you in the next video, bye for now.