okay this process developed project management plan is the beginning of the planning processes and what I would like you to imagine is that the project management plan is a huge plan with sub component plans inside of it so the project management plan is not what people think most people when you say project management plan they’re thinking this schedule that’s not what we mean here what we mean is the overall project management plan and it includes the schedule that includes the budget it includes the communication the quality requirements the procurement or contracting plan the quality requirements or plan the risk assessment the resource management plan and the stakeholder engagement plan don’t know and the scope management plan so all of these plans consider them to be folders inside a big drawer which is the project management plan inside of it are these folders one for each of these areas initially when you start your project management plan you’re not going to have everything in it you have the basic information that you’ve gotten from the project Charter and if you were starting the project because there was a contract initially then the details of the contract are your starting point and it highlights the scope of what is expected okay so typically what goes into preparing a project management plan is a lot of data gathering that needs to happen so you will brainstorm with some of the experts and here I just want to clarify it is not just one step the first thing that you do in developing a project management and management plan is to collect requirements so you don’t really see it here all it says is develop project management plan and so in general when we develop a project management plan we collect information we assimilate we organize the information so brainstorming can be expected interviews workshop focus groups maybe even looking at checklist from that would you know or prompt us from previous projects that we worked on addressing any conflicts or disagreements that the team may have or management may have about what is expected from the project run a few meetings facilitate these workshops and so on and at the end what you want to have is a plan that details what should be done on this project here it’s very important to note that you will have a project you’ll have a project management plan that includes several plans beneath that and as you can see here there are 18 different subsets 18 different plans that could be identified and also along with these there will be project documents that will be prepared and you can see here there’s about 33 different documents that could be used so for example we might look at this the scheduled baseline right the scheduled baseline is one of the key deliverables that we are looking to get and this includes the schedule data it looks at let’s see here we will have the project schedule the project schedule network diagram the project calendars the milestones list the resource calendars the schedule data the scheduled forecasts and so on so you see there’s a lot of documents that are being used for you to have the scheduled baseline right so we have the plans 18 different plans we also have 33 different documents then there could be even more out there this is just a small example a small list and so as we go through this project we will be updating both the plans and the accompanying documents that go along with it so there is a requirements management plan but there’s also a requirements document that will need to be updated there’s a stakeholder engagement plan but there’s also a stakeholder register right so there are documents that pertain to specific plans and we will need to update both as we execute on this project the three key baselines that we can expect out of manage out of developing the project management the scope baseline the schedule baseline and the cost baseline these are the three key baselines and we will develop them later on as we go through the different knowledge areas all right this takes us to the next process in integration management and it is direct and managed project work what we can say about direct and managed project work is this is where all the work happens all the deliverables get executed and completed here teams get assigned work changes me happy communications start to go back and forth to management and and the team status data is updated and shared risks are risks are being assessed right you would have identified them in the plan but here in execution as the risks not to happen you’ll execute on your contingency plan vendors will have to be managed lessons learned will be collected as we go along in direct and manage project work is where we spend the most amount of money and use the most number of resources the key areas to look at when we look at direct and managed project work would be the outputs that you can expect and the key outputs here would be the deliverables work performance data and change requests all right so what happens here is that work is being done right and you’re tracking these into your project management information system like Microsoft Project or even if you want Excel or Primavera you’re having this you’re having these different meetings you’re collaborating with different experts on trouble areas along the way or changes or risks that pop up and at some point some pieces of the project will be completed so we call these deliverables and that’s one of the key things that you see there in the outputs the first one deliverables these are the small pieces of the project that have been completed and they represent just one bit of the whole and when all of these deliverables that have been outlined for the whole project are completed that’s when the project is closed so little by little these deliverables will start to be completed what happens when a deliverable is completed we send someone to go and validate that so that usually is done as of the monitor and control but for now we’re looking at direct and managed project work so we can expect some deliverables to be completed we can expect some work to be in progress so you see the next output there is work performance data and this tells you that some work is partially done quarter done fold on three quarters have been started has not been started this is the counter data the raw data that we’re gonna get from the team as they execute on the project if there are issues that are made known to us then we document them into an issue log and if there are changes that are required which we will uncover as we start executing on the project then we will submit necessary change requests so that they can be evaluated for approval this takes us to the next process which is manage project knowledge and here this is more about contributing to organization learning learning via the process of lessons learned when we use previous information that we have gained as lessons learned were able to improve and enhance the way we manage the project going forward and that makes it easier and less costly to execute on our project now knowledge is commonly split into two different areas there is explicit knowledge and tacit knowledge right explicit knowledge is one that is easy to explain document that’s that’s what they mean by explicit so you can explain it you can document it you can show someone and they should be able to pick up whatever it is that you’re telling them and be able to use that information tacit knowledge on the other hand is harder to share so you know if you if you’re a good chef and you know how to cook a specific let’s say soup you know how to make it you know exactly the amount of salt you know what flavor it needs to be and what herbs you need to add and you can judge by the smell or you know you can time it accordingly when you notice certain aspects of that soup right these are not things that that are easy to explain to somebody else these are more based on feelings senses that you have and so we consider these to be tacit knowledge and tacit knowledge is not that easy to document then even if we document them they don’t tend to be complete right so the easiest way to share tacit knowledge is to have somebody shadow you and learn from seeing you doing the work or maybe you run some workshops and you explain it to them so what you have to do here is come up with a plan for you to be able to share both explicit and tacit knowledge within the organization tools and techniques here depend on the nature of the project when we share knowledge it could be face to face it could be documented in a you know a portal or file-sharing server where people can access that but face-to-face interaction is typically the best way for us to be able to build trusting relationships that would be needed for us to be able to manage knowledge once we have these relationships established then we can go and do virtual connections afterwards to maintain that relationship so along with knowledge management we expect that information is also being managed and that means we have to have ways for us to be able to code this information that we have documented save it somewhere some library services and make sure that it is accessible for others when they need it a lot of times if you have an up-to-date mature project management information system you can expect to find knowledge and information management capabilities in it it is recommended when you are sharing information to add an element of interaction something that helps people and supports them when they try to find any relevant information so a search feature would be beneficial or something that says click here for this click here for that you know add elements of engagement in your knowledge sharing don’t just pile everything into one folder and expect people to just you know look through all of this information to try and find what they want this is one of the main reasons why lessons learned typically fail in organizations that people just dump everything into one place no labels no nothing very hard for anyone to find anything all right so in knowledge sharing you’ll find that interpersonal and team skills will become very relevant so things like you know being able to actively listen to what someone is trying to relate to you being able to facilitate successful workshops having leadership attributes where you listen really well where your delegate where you clearly teach what needs to be taught and you relay information accordingly being aware of the politics and dynamics of the office or the project team and being well connected this is going to help you in being able to obtain and share information within the organization one of the outputs that you’ll see here is the lessons learned register and the lessons learned register can be in a database could be an excel sheet but you want to be able to document what you have learned from every phase so that we can benefit from that on the next upcoming phases so you could use Excel to track these things you could put videos if you want pictures audios any means that others would be able to tap into to learn from this brings us to our next process which is monitor and control project work this process is focused on making sure that what we are executing is matching what was planned and so it’s a comparison it’s looking for variances in performance and if there are variances we are trying to control so there is a monitor component and there’s also a control aspect to it we’re also watching for any risks that may happen and we’re producing status reports and forecasts and we’re monitoring the execution of any changes that have been approved what you’ll notice here is that the plan comes in as an input and we are using that plan for us to analyze whether there’s been any variances so one of the tools and techniques that you will see there in there analysis and if you look at the bottom there it’s variance analysis okay variance analysis compares the original plan with what you have executed if there was a plan that says something some activity will complete by March 15 and you have not completed it by March 15 then there’s variance there right especially if you’re late that’s the variance what you want is positive variance negative variance obviously is bad you also want to monitor for trends sometimes we take an interim reading and it looks good but then over time you see that it starts to slide down so you have to watch out for these things root cause analysis is used in this instance where we try where we notice that things are things are problematic and repeating in a specific fashion and we want to get down to what the root cause is so we do a root cause analysis at that point sometimes fixing the root cause will address many problems out there there is also earned value analysis that we will cover later on when we talk about cost management but it’s a it’s a it’s a number way so we will have metrics a ratio or negative or positive cost variance that we will use to assess how the project is doing sometimes we use cost-benefit analysis where we try to analyze what would be the corrective action that we should take in terms of the cost right that we might incur if there are any variations so we evaluate if this is the impact to us then what should we spend and to fix this and what would be the benefit if we do so that’s typically the decision making components of changes when we’re trying to propose any changes but before we propose any change we typically look at alternatives we try to analyze if there are different ways that we can address this one problem we evaluate them we look at how much each will cost what would be the benefit of each and we choose one of these and we propose it to a management so decision-making can be considered one of the tools and techniques that would apply in this instance outputs would include work performance reports that we will produce on a frequent basis that we will share with management and will be used as a basis for us to take action if we have to and changes changes will be the other output when we make changes there are three different types of changes that we make corrective action preventive action and defect repair we use corrective action when the problem has already happened the issue is already there we’ve already missed it and therefore we need to correct it and therefore this is not really going to be preferred to management they would rather that you do the second one which is preventive action before the problem happens when the indicator is there that’s the time to act on it before the metric is missed so you know the schedule is going to be missed if you continue as you are and so you decide to take action adding more resources so you don’t miss the schedule that’s called preventive action defect repair modifies anything that is non-conforming with regards to quality specs and we try to bring it back on track okay this takes us to the sixth process which is any graded change control and integrated change control is focused on the process of the process of change management within a project mind you in the world of I tell people see change people see all initiatives as changes when we talk about change in projects we mean we have a plan and as we deviate from this one plan in a way in a manner that we’re not happy with and we try to bring it back on track then we request a change and if that change is approved we go and change our project plan so that we can execute that and fix things and bring them back on track to where they need to be so this would be change control within the project to fix it when it starts to deviate from its original plan okay so for this you’ll see that the project management plan is your key input coming into this the scope baseline the scheduled baseline the cost baseline all expectations essentially everything that has been planned is an input into the change management process as well as the change request that came in and says that we need to modify our plan in this fashion right the change request that comes in typically comes in with some sort of a status of where we are what we were where we’re supposed to be this is where we are right now we are varying in a negative way and we need to take some corrective action and so we go and submit a change request for that so typically if your organization is mature as an organizational process asset at this point you will have some change control procedures in place or maybe procedures for how we review and approve change requests and issue the the recommendation from analyzing the change requests and sometimes we have a configuration management knowledge base where we save all of the technical aspects or components or specs of the products that we use so that we can be so that we can tap into these and search through them to make informed decision when technical changes are required okay so change control tools will be beneficial at this point and these are tools that help you in identifying change documenting the change submitting the change deciding on the change and tracking that change all throughout the project we will need to consider as part of the change decision different alternatives and evaluate them for cost-benefit before we make decisions on specific changes there are times when we get stuck and we have to go through a voiding process where senior managers will vote on what they feel is the best option to go with this is when when the team is disagreeing other times you will find that because there’s so much disagreement the autocratic or let’s say dictatorship style may work best where the manager just calls this the shot and says you know we’re going to go with the change like this and I’m not opening to any additional discussions we could also go with the multi-criteria decision analysis where we list down all the different criteria that we care about and we compare the options that are being evaluated and we see how these options score against the criteria that we care about the one does course the highest is the one that we will go with the outcome here will be the approved change request and that will be documented and we will update the plan accordingly the project management plan and we would let people know that this change has been approved so they can execute on it finally and this brings us to the end of integration management the last process is closed project or phase closed project or phase is the process of finalizing all the activities for the project phase or contract the project or phase information is archived the plan work is completed and organizational team resources are released to pursue some other projects here in closed project or phase we’ll focus on the completion or exit criteria we need to make sure that all the criteria have been met and if it’s a contract then all the contractual agreements have been satisfied we collect all of the project records or documents if we have to do some auditing we do it if auditing was dumped we collect any of the audit reports that have been produced we make sure that knowledge that needs to be shared is documented in a way that can be shared as a lessons learned on future project we transfer the product services or results to the receiving party maybe operations and we collect any suggestions for how to improve or update the policies of procedures or to make all the ways that we can ensure that the customer or the stakeholders assets are satisfied with the output of this one project well sometimes the project will be terminated early and in those instances we need to assess how much of the work has been done basically take inventory of the work that has been done save all of the information and archive it because in some instances we might need to reference it in the future for legal or for other purposes the key input here would be accepted deliverables these are the deliverables from the project from the execution side remember in execution we said we will have some small deliverables completed these are the deliverables that would have been completed and then evaluated for the scope of work and would have been accepted by us so slowly we will be accepting all of these deliverables and so they make up the key input into the closed phase or close project process right so as we complete these deliverables we are slowly closing out the phase and once all the deliverables for Phase are completed then that phase is evaluated for closure once all the deliverables for the whole project have been completed then we evaluate the project for closure so procurement documentation if any would need to be collected indexed and file any information on contract schedule scope quality costs all related information will need to be catalogued and saved so that we can access it later as built drawings will need to be saved manuals training manuals troubleshooting data any technical documentation will need to be saved and this will be useful as lesson later on you could tap into expert judgment in the closing process people were familiar with you know management processes for document control or for legal aspects of how we save information or lessons learned or auditing you may want to ask them what things need to be done as part of the closing process some of the techniques that you will see here will be document analysis this is where you’re reviewing all available documentation to make sure we have all of it ready to be used on future project you could do regression analysis to go back and analyze what may have caused some variations along the way by backtracking you could review trends you could look at variances that have happened on the project and update all of your project documentation the final product will be handed over as part of this one process and that usually will go to the receiving party which could be operations or it could be your client and we’re expecting at this stage that some document will be signed that says that all has been delivered and handed over and you are clear of any liability at that point typically organizations prepare a final report that talks about successes and failures on in executing that one project lessons learned and maybe final cost maybe reconciling the cost of this project and looking at the scope quality cost schedule objectives and what were the actual results versus the plan any reason for variation we track these things because these will be beneficial in the future if we ever need to go back and look at the details of that project okay if the project is intended to be part of a program then we document where maybe when the benefits will be realized so any notes pertaining to this any risks that the receiving party needs to be aware of needs to be documented any issues that we are aware of we need to track these so that the receiving party is made aware of that and that takes us to the very end of integration management I hope you enjoy the session and I look forward to seeing you on the next knowledge area which will be scope management please don’t forget to subscribe so you’ll be notified when scope management has been issued thank you and hope to see you on the next video bye bye