Comprehensive Project Management course with templates and documentation

1. Comprehensive Project Management course : Welcome to the introduction of this course. This course will show you all that you need to know about project management in theory and in real life. And also how to ace it as a project manager. The project manager for 20 years. I've also been a project management coach for ten years. Now. I've also worked with project managers myself, as a program manager, as a manager to really understand what is expected of project management to ensure that at the end of this course you are project management expert. I will be using role of diagrams, templates, example quizzes. Truly make sure that the concepts are really understood but at the same time, and we'll also highlight the differences between the theory and the real-life project manager. I will show you the challenges that a project manager can face on a daily basis and how to address them. I will show you how to simplify things as well too. We become more efficient. In other words, I will show you what is important, but it's hidden part of this course, I will provide you a clear step-by-step framework that if you use, you can really stand out as a project manager. You can really Ace project manager. Tell you if you stick to reach your manager, your team, the business, they would really love you for it when you have people on your side. He told on healing project. Now, in the third part, in part three, we will review on the high level some methodologies so you can see how this course relates to them and I will give you my opinion on how important they are. I've already put all my 20 years experience into this course. If you are interested in project management, if you are interested in getting into project management as a project manager. And maybe if you are already a project manager out there and you really want to step up your game. I think you will benefit from it. But also if you work with Project Manager, you can really understand where they're coming from. And maybe also you can give them a couple of tips. If you want to know more about this course, there's a 15-minute long overview. I know 15-minute is long, but I've created that for those of you who are unsure, they want to take this course or not. So you can really go into more detail in any case. Thank you very much for listening. 2. Let's get started!: Well, thank you so much for taking on this course. I really appreciate it and I hope it will be worth your while. So please don't hesitate any point in time if there's something that is unclear or if you want more, something added, as I will say, no conclusion as well if you want, if there's enough demand, I'm happy to add some topics. So if you haven't seen the course outline, the next video will provide you more detail on the overall course. But if you just want to dive straight into it, please go into the tips to review this course and there's some suggestion on some resources to print. And after you can go into the little story on the birth of project management. So thanks again and all the best to you and hope you get a lot from this. 3. Optional: Detailed course overview: So what follows is a course outline. It's a bit long because I want it to be very thorough. If you are still hesitating, if you're not sure if you want to purchase this course or not. I thought that would help even towards the end, there is a bit of a comparison table based on your level if fuel that will tell you if the course is suitable for you or not. Having said that if you have already committed to the program, to the course, this could be useful if you'd like to have a thorough understanding of what's ahead of you. But if not, feel free just to skip it and go straight to the next lecture. Welcome to the course overview. Before we get started in course content, I just wanted to have a quick overview of the philosophy. First, this five components, if you like, that, I have put together to ensure that the course is one, hopefully pleasant to follow, and two, that will increase retention. So there is a practical view on concepts, real-life scenarios. So that should make the course easier to learn. So there'll be a lot of examples for obvious reasons is always better. I've example or sometime we don't fully grasp the concept, but as soon as the example comes, yes, we see how it relates to real-life. We will also show as much as possible how to simplify. How can we can implement what we have learned quickly? And I think also they will make it easier to master. So at something simple, easier to understand, easier to master. And then you can take it from there in all of diagrams. And I think they are great way to communicate a concept sometimes, so there'll be a lot of those. And finally, for part one, which is a course, and part three, which is a standard, there will be quizzes. Now that we've put that behind us, course content, what will you learn? We start off with an introduction, some suggestions that I have for you to take the course. So for instance, there is a road-map here that what I call a roadmap. I know that some of you like to look ahead. We're what's in a course. So they like to have printed out or put that handy on your tablet so you can follow where we are at and the various functionalities. But some just prefer just to take it step-by-step. So it will be completely up to you. But I will suggest some resources that you could print. We will review what I have called the birth of project management. So it's something that is completely personal. Don't quote me on it. It's how I imagined that the project management was born. So I've done a little story around that. And that would be a good way to introduce you to project management and how the various phases of project management were born. So that will lead us to the phases of project management and the various activities to project management. And after briefly, we'll provide a definition of project management and the role of the project manager. And we will finish by a quiz already. So then we will move on to part one. Part one is the course of project management. So the structure is very simple. Project management is divided in phases. So during this course, we will just go through the phases more or less, will have an overview beforehand. And after we review the four phases, which are initiation, planning, execution, and closing. And after we'll do a review and a rapid within those phases, some concepts, topics, tools will be explained. And I just wanted to review those with you. So we won't go through the full course. I just wanted to highlight what we will cover amongst other things. So for each phase that we will review, will discuss the phase purpose. We will provide the key competence, what it means if the outcome sold on the very high level. After we review the project manager role for each one of those phases, review stakeholder management. That will be obviously like every all topics that I'm running you through. Now, it will come back for different phases. We will review who are the stakeholders, review how we can classify them. And we'll review an example on how to store this information and make a communication plan out of these, we will review our project structure. We'd have a few slides around this. This is just one structure, but I think it's important sometime when you're thrown into a project manager's role to understand the structure. So we'll have several examples of structure. We will review risk management. We will review risk severity, how to assess it, and we review a very precise example of risk register. So how to structure it properly and different types of outcome that we could have for each risk listed. We'll review scope. The importance of scope. Why does he choose for how to create it? We will review the change control process. So that's not the whole size of mentioning, but it's just to give you an idea of how the course is structured in a different type of slide you could have. So we'll talk about the scheduling. I will provide some suggestions how to build a schedule that has done this out. We'd also provide some suggested steps to build a schedule. Different representation of a schedule. How to monitor schedule using the MS Project software. What is a critical path? And now to quickly check it on the schedule. We'll review obviously cost and budget, which is also very important part of project management that we suggest a very easy way to split to start to get you started on a budget or real review with you. A few of those examples, very concrete, very clear. Hopefully. We will review a concept called Earned Value, which is which the project management methodology like to discuss. But as you've seen, I'm just gonna go back to that slide here. I'd just like to present it extremely simply, initially after we go into more complex examples. But always the example, always the concept of having something practical and an example to go, to go along with it. We will review quality management. This is when usually you start getting to sleep it up. I'm trying to make it as interesting as possible. It is quite important, but it's true that when you, it's quite heavy to learn when you go through all these project management courses. So hopefully have simplified it and at the same time kept, kept it very practical and complete a suppose. Provide a lot of information here, highlighting the ones that are really important. We will review also obviously issue management. We some slides around this and very clear example of issue register with a template. Project meetings. So we will review also that in part two where, where I give you my proper way on how to manage project. But we will review in part one. Here the, you know, the the by the book way and the different types of meetings that you can, you can have. So there is also obviously templates that we will review and discuss. We will also discuss project reporting, which is very important to perception of a project manager. So also we'll walk through a template. We'll review a closing activity. So I'll put closing a bit separate because it's something that is often rushed, but I'm hoping that have provided a clear way for you to know really the key components of these. And I'll explain why it's something that you can use as an opportunity to shine as a project manager for the very reason I was providing before, it's often rushed. So if you do it properly, then I think your stakeholders will be impressed. We'd provide some templates, or we've seen that. We've seen some of the templates. There will be more and examples. Once again, this is just to give you an example, there's a project management plan, which is a document a project manager creates. So I will give examples of this stuff exactly. Take a project as an example and exactly what you should put in and you can put more, but the starting point I think is very important. So that's it. So it's just that, that was just a quick overview of some of the topics at two, you will see the soul. Before you commit to this course, you know what, you'll get more or less hopefully with this. So that was for part one. B2 is the framework to really take part one and really take it to the next level to really ACT. In my view, there will be three components. The first component, we will review the project management context. What is the context of the project manager when he joined the company? Where does he or she has to deal with? And after we will go into the framework. So the framework is not something fluffy, something very concrete. I will tell you exactly what you need to do. Well, I will provide you with examples and the likes, but it's, it's very, it's very concrete. Sorry for laboring that point, but it's not something fluffy. That'd be nice if you could do these, but just do a, b, c, d. And finally, we will go into an interview tip. So I have interviewed a lot of project managers and I have been interviewed obviously as a project manager as well. And I have done the hard work and I know what works and what doesn't work. So we can review this. So that's it for part two. Part three, methodologies. So part three, I put it towards the end so that you can see how this course fits in with the existing methodologies if you like. Pnp and prints too, if you haven't heard of them, they are project management methodologies. You, they're obviously very long to take weeks to learn and they have very thorough examiner likes. So obviously, I am not going to give you a PNP and it prints two courses. So this is not the purpose of this course. But I wanted to give you some context to show you how this course relates to PNP and the prints too, more or less. The idea behind that was just to show you that it's more or less the same. Old project management methodologies are the same. So we'll review. So waterfall and agile, Waterfall being no by default method used for project management. I will just go to that very quickly and Agile, I will provide a little bit more information. I will show you an example. We'll also, towards the end, provide a comparison between Agile and Waterfall, the pros and cons. So if you're wondering what a fallen angel you can use both using the palate, one of the core. So it's just a different way to deliver the work if you like. That seat, we only left with one question. Is this course for you? This course is for you if you want to understand project management. If you want to become a project manager, or if you want to perfect your project management skills. Now, if we go into a little bit more detail, if you, if you're like, I don't know you, so I just just gonna go through different levels here and see if that, if that's too much for you. So let's say you are a beginner early man and you don't understand project management at all. This course is definitely for you. I mean, I'll take it really from the beginning as I was saying, I was just giving you a little story on how I imagined the project management was born too. I think that you will find that very useful. So there's three parts in this course. So if you are a beginner or lay man, I would suggest that you start obviously with part one and after you do PO2 and after you do part free. So this is for you if you are in this category, if you're intermediate, I really think you're going to learn from it as well. I'm putting all my experience in this as a coach and as a project manager. And you will I am sure you will get something for part one, part two, part three. If you don't, then I will gladly reimburse you. I think it's part of the of the terms of the course anyway. Now if you advanced, ma'am, Sure you could learn from this as well. I really put some effort into putting a framework together. So the part two, I would be surprised if you don't get anything from this. But you could also get something from part one and part three, I believe so actually, I'm quite interested if you want to have a look. This is how I would really suggest it potentially, potentially and years here. So that's it. So we went from the course philosophy, grams, examples, practical view, quizzes. To help you retain information and relax. I provide a precise description of the course content, which has three parts. The first part, the course itself, the second part, know how to really take it to the next level. And the third power to give more a bit of a context of this course amongst all the project management methodologies. And hopefully we finally answer the question, is this cause for you or not? 4. Understanding Project Management via illustrative story: So the next few slides is completely made up story. More targeted this time. Yeah, if you've never done project management and I think it will introduce you to project management from a different angle. What I found is in the project management methodologies that tell you, yes, this is a four phases and the likes and this is the purpose of each phase, but they don't tell you how they came to light and why create them to start with. Also, if you, if you a little bit familiar for project management, I recommend that you go through this. I don't think it's hard to watch. I think it's a little bit further, some photos and some diagrams in it. So hopefully you'll enjoy them. Then of course, as we progress through the course, you will get the form or by the type of meaning of each one of those phases. Having said that, let's go into each straightaway. Welcome to this part of the course. Okay, so don't quote me on this please. This is, this is probably not accurate. So these vertices, how I imagine as a bit of a learning tool, how project management could have been born. So imagine there is a queen, she has leaders. But they are always focusing only on the daily task, on the walls and stuff like that. So but she still has large project that she wants to implement. So the work is disorganized on those projects. Teams are tied. Money seems to be always running out. So she says, she's saying, I have leaders, but that's not sufficient if someone really focusing on this. So we were about to witness the birth of project management issue. This allowed endeavor lacking coordination, monitoring, and a solution. Provide a dedicated resource to manage methodically the work to completion. Project manager. Therefore, make your project manager to the Queen. Go and make sure things are running smoothly. Give me a call from time-to-time. So thanks. Suggests that we catch up after it's all done to close things off and see if we can improve things for next time we do this. Okay, so we have a project manager already and we have our business owner. So let's see how it worked on the first project they had. First project, trial one, the Queen get a project. And the project manager was doing role of monitoring was during the role of fixing. See what I mean. And communicating as well. And after the closure. So that's where it was mentioning before. Let's catch up at the end of the project is to check out things where we're going. And then the queen can have the benefits of a project. So at completion, the project manager reports back to the queen as agreed. Why did he say, okay, I think we can improve on this. I was not sure what I was monitoring against. When was this old you I didn't know. How much money did I have? I was not even sure how much money I had. It would have helped if I knew some of the stuff that could happen beforehand that nobody told me about this. Who was I supposed to communicate to and how the queen was too busy, she didn't return the core. What was this project all about anyway? What was the plan? Okay, Well, he's lucky. The queen is quite nice person say, okay, okay, I see your point. For our next project, let's stick the time to sit down and plan on how we will communicate, how will we do things? Then we can progress when we all agree on a plan. So let's have a plan first. We agree on a plan and then we progress. Let's do this. So those are the tasks that a project manager was doing before, but now it's added a couple of more tasks. Yeah, I did some planning and then there was a plan approval. So how did that go? You think trial number two? So gun project, Let's see. Took two months of planning and after the plan is presented for approval to the queen, okay, Planning is finished. It will cost you £51.6 of gold. And we should be able to complete it in 26 months or so. On a side note, we might lose 51.3 per cent of our Army in the process. I mean, this is obviously precise for one reason there you see where I'm at, where I'm getting at. So the queen immediately see where all this was a West. We do not have the money, we don't have these pounds of gold. And I can afford to wait two years because 26 months to finish. Really, they see the benefits is it's not worth it. I wouldn't approve this project if I had at least a rough idea of the cost and how long it would take. That'd been aware of that huge risk of losing half my army. So she was not aware of the risk. And she just heard about the incredibly high cost and how long the project while then the worst part is it has spent two moms, so two moms paying the project manager and all this team to come up with something that she knew she didn't want. Surely, there's a better way to do it. So now the project manager, it goes back to her and see, okay, I suggest we do quick assessment this time, not this two moms planning for most planning. We do a quick assessment and give you some basic information before starting planning on our projects. We can give you the higher level course timeframes brisk, who will participate. So this way you can decide if starting the project. Planning even is worthwhile. Okay, but I have to warn you, we won't be as precise, but at least you have, you have an idea and you can make a decision. So let's see. I went final trial. So before there was planning, plan approval, monitoring, fixing, communication, closure, all that was already happening. But what they have decided this time is to add two steps. So notice this is not project anymore. It's just an ID or a need. Okay. It's not a project yet. It's just some discussion that happened. Yeah, why don't we do this or we absolutely need to do that. There's an assessment and then there is an action here. Is a project approved. So after a couple of weeks, not know. Moms, your assessment is completed as agree. They say they'll do a quick assessment. Quick assessment completed costs you roughly £30, that this is all just so that you can keep up. This is a final project. This is a third project if you like this. So this is why it's not £50 anymore. It's only for £30 is a different project. Because you are a free £30 of gold. And we should be able to complete it. It's sinks moms, no loss of our mean of process. Would you like to go ahead. It's not a project yet. It's doing the assessment. And she said, Yeah, I like this process much better. No, I have some key information before I give the go ahead for potential projects. I realize it's not as detailed as during planning, but it is enough for me to approve or decline project proposals. Based on the information you gave me, we have a winner. Let's go ahead with this project and notice, now we have a project. This, we don't want to call it project yet, because in the previous example, there was just too long to, an endocrine decided we're not gonna do it, so it's not a project. So anyway, yeah, okay. Now this is what we have. We have all these activities that happen. The project not being a project here and all that productivities and after the queen can have the benefits. So what do we can do is we can group those activities in what we call phases in project management. Because we realize are those two could be grouped, the blue ones there could be crude. And let's say we call it the initiation phase. We, the second pallet we added, we call it the planning phase. So initiation planning. So this is how it was at the beginning. So what do we do for the other activities? We split them into two groups. We have the execution here, we have the closing that was agreed at very beginning. When they said, let's agree to catch up at the end to see if we improved or not. So this is why they've, they've improved their processes by catching up during the closure of the project. So what we have here, its phases. So we have outline if you like, four phases, initiation, planning, execution, and closing. And what we have on the left-hand side of this diagram is activities. And we have in this case, 12345678 activities. So some of those activities are just approvals, will see they are actually an important step. So they are, they are there. So that takes you from an ID to a project, to the benefits of the project. We could be you need something that absolutely has to do. We don't really want to have this policy implemented, but we are being asked to have this implemented, so it's a need. But we still go through this process in your way of assessing and project and benefits. So that's it. My take on project management. We can see why there is this different types of phases. By catching up after the project, you can do your next project better. The execution, It's all go, go, go. The planning is to give you a more precise idea of what the project will be like. An initiation is really to do. We even want to do this, but we will review all of these. I just thought I wanted to link back that story with the next with part one, which is really when we start to go into more detail on this. So that said, let's move on to the next part of the course. 5. Things to know for the course : So before we get started, just in case you don't know how how it works. Yes, it's the first time you take this top of course. For some lectures, there are some attachments to them. It can be PDFs where I put some of the slides there. There can be Templates, registers. When we go into scheduling, I will attach some schedules. So for every lecture, feel free to have a look at these attachments on time that can help you can have them handy if need be. But right now, there are two PDFs attached to this video, and I think they'll be quite useful for you to print or have handy during the life of the course. They are both roadmaps. The first one is just show you an overview of the phases and the key components of the phases. The second one is very similar, but it also shows you what are the outputs of a project manager. What at the end of the day, the project manager needs to create. So I suggest you print those. In the next video we'll talk about terminology and also suggests you print or you have handy the one on terminology. Another notice that you'll see on some of the slides, there is sometimes an advanced written on top right, top left. So this is just to tell you that if you are a bit overwhelmed, feel free to skip those. I know when you go through a long course like this, sometimes you just, your brain wants to have a break, so just skip them and maybe you can come back to them later on. They are a bit advanced. That means they are command in project management, but not as command as the, as the other components. So now let's have a look at some of the terminology. 6. Terminology used: So this is a terminology that I was referring to. So let's give some definitions. I promised I wouldn't be too long, but it will be worthwhile. Product. The product is the end goal for the project. If when you build a bridge, for instance, the end product or the deliverable, it's the breach, the project breach. So you'll hear me mentioned products. So that means what the project will give you deliverable. So there are components the project team will need to deliver at the end of the project. An example of the breach, it could be the breed itself, be also all the operation manuals for the bridge older here give the various document test results and arrive. So anything that the project team produces Morris BAU or to business as usual, if you're not familiar with this, it's part of the organization that runs our daily activities. And this is why project management was because everybody was so focusing on what they were doing every day and out of the sudden you have a large project coming in. And everybody is busy doing their own stuff, so they have dedicated resource. So business as usual, It's the part of the company that do daily activities and the project teams focusing more on project, the client, customer, business. So it's a stakeholder needing the project outcome. So it's more or less for who we are working. I will use those terms, will use business more often and client or customer. So upper management, executive team, as opposed to manager that we'll see later. Upper management for me, it's it's it's part of the business that are that are above you in a way that doesn't mean that they are involved in your project. But it's in a broader sense, not necessarily the working on the project, but it could be the CEO of the company. It could be an executive manager of another part of the company. And the manager, when I refer as a manager, also known as line manager, program manager for the project manager. It's your boss. If you're a project manager, is the guy who both views. So when I see you have to give these to your manager or you have to give the to your business. They are different entities. 7. What is project management: Next we are attempting to define project management. Please bear in mind two things. The first thing is that there are so many definition of project management. I'm attempting to give you one. I've created one that reflects well what project management is, but there are others out there. They usually include the word endeavor, which I really wanted to avoid at all cost. The second thing to bear in mind is they are always exceptions. And some companies use project management in a very flexible, flexible way. So this is no, nothing is set in stone. And in a way that's what's interesting about project management. But let's get into those definitions. What is project management? Project management is the practice of coordinating the work of a team to achieve a specific goal as at a specific time. So the reason why the team he is is you don't really need a team. I put it in brackets. Because in my view of project management, and not only in my view actually predict management can be one person. I mean, I'm sure you've heard of these guys running a project or on their own. But what is key here has a specific goal at a specific time. So if it's not very specific goal, it cannot really be called a project management is more business as usual. And at a specific time as well, when it becomes ongoing, when it becomes something recurring, that happens every three months or even every year. This shouldn't be called projects. There should be, they should be given another name. It's a once off project. Note that the specific ordinance to be loud enough or important enough to be a project. You have a business with your team, they have something smaller to do. Do they need to have a project team with the reporting process in place and with a budget and erotics, probably not. So it's not a project, it's just an activity that is on top. So to be called a projecting to be large enough. So this is just referring back to businesses, your project team and productivity as separate from the company's business. As usual, resources will see that sometimes it can be shared resources. But as entities, they are considered separate. 8. Role of the project manager: Challenge, I would say when you're a project manager is to ensure that the team understand your role. When you, especially when you're growing company, they've never had project managers or project management. They see you are robbing and they think, oh, there's a new admin guy there, Let's ask him or her to do this, to do that. So it's very important to set boundaries at the beginning. But for the companies that are more mature, they know what project management is. I think it'd be much easier, but still there, they're still be tempted to be the person who does what nobody else can do. So it's very easy to fall into the trap and do it all of things that you're not supposed to do. So let's discuss the role of the project manager now. So the role of the project manager, he or she owns the project, responsible for it. Doesn't always have all the authority. The treaty is responsible to get things over the line. Let's have a look at a few bullet points. So the PN, that's another, that's another acronym, project manager or project management. The project manager plans or activities, obviously with other resources, but he has the responsibility to plan. When all this is plan, coordination and prioritization of activities, reporting, communication, setting. You'll executive's how things are going. Issues. That's a big one during the execution phase, as we'll see, this is the key occupation of a project manager. I mean, you could argue there's no if there were no issues, who would need a project manager? So this is what we do and show some friends and budget are respected. That's also a big one. As we've seen in the beginning, the story of the Queen. She was having all these activities burning money. So someone needs to be accountable for it. Ensure sufficient quality has been applied. I mean, this is why we're seeing quality is not the most popular activities and project management. But in my view, if you, if you deliver something on time and on budget and it's not it's not good quality or he's not something that the business wanted, then it's, it's not better implement within constraints for me to good way to summarize the role of the project when I'm Manager, there is something to implement. He or she has to implement within all the constraints which are timeframes, budget, and the likes. So here we have our summary of what is project management and the role of the project manager. To conclude, we could draw the similarities between our live in a company's life, if you like. We all have our daily activities to do and this is what I'm doing live coaching now as well. Because of similarities with project management are so obvious. We all have things that we would like to do, but we never get around to them because we are focusing on our, on our daily lives. And companies are the same and this is why they bring in project managers. So they can really focus on that. And they have to do it. And they have to do all the coordination and the right are the words. Chances are it would, if it happens, it will happen at a much slower pace. Now, having said that, let's move on to part one. 9. Introduction to Part 1: The PM course: So welcome to part one of this course. So part one is a full-on project management course. All the theory, but at the same time he's a practical take on it. So during part one, we will review each one of those phases that we have defined, the ring, the introduction. We start with a high-level review and after we will drill down into more detail for each one of those phases. So let's get started. 10. Overview of Phases: Okay, so let's continue where we left it in the previous contradiction. So we have identified some activities that we grouped into phases, initiation, planning, execution, and closing. Those are phases. And we also had some activities. So just as a just to continue if you want us to put it a little bit differently in a way that will help us during this course is just a quick reminder. Initiation is why we're doing this and can we do it? So it's a quick assessment. Nothing too precise, but at least we can make a decision there if we go ahead or not. The planning, how will be managing the project? There will be also the execution were actually do work, action, monitoring, coordination, issue resolution, communication, happening and closing, and knows it all finished. Make sure that we have no loose ends and just reflect back. Did we do this correctly? If we put that under this, this representation here, and this is, this is how we'll have that for the course. So I still have this initiation in blue because in theory is not really part of project management. We saw previously the project manager was doing this assessment, but as we'll see, that's not always the project manager doing this. Those those were the key activities that we had before. Assessment, approval, planning, planning approval, monitoring, fixing, communication, enclosure. So this is this diagram that we'll be using in this course when we go through the various phases here. 11. Phase 1: Initiation - Overview of : Let's get started with phase one initiation. If all we do is have a quick overview of the section. We will discuss the purpose of this phase. We will discuss the project manager role. In this phase, we will review the creation of a key document, which is called the project charter and various components of this document. But more precisely, we will discuss the scope. Cost is stakeholder management who will review the risk management? We will review the structure of the project and then we will wrap up and provide some examples. 12. Purpose of the initiation phase: Welcome back. So next, we will be defining the purpose of the initiation phase. The first thing to bear in mind is this initiation phase does not always exist. Another project management methodologies out there tell you, yes, you need to have a nation faced. In real life. Sometimes it doesn't exist. So just as a quick reminder, the initiation phase is whether you decide if the project will go ahead or not. But there are some companies that don't care. They just want to do the job. Sometimes they have just a mandate. They have the budget, and they want to do it. And I don't want to have to go through all the initiation process. And sometimes they just don't have the choice. Sometimes it's just the government necessity, sometimes it's illegal change that is required. And therefore, no point discussing if we're going to do it or not because we know we have to do it. And also what happens sometimes is initiation phase happens behind closed doors. You are not involved and I think that makes sense. Why involve a project manager when the project is not really concrete yet. So there will be a group of executives discussing civil project IDs and decided after we do this and that, and then they can bring the team. They can say, Well, we want a project manager for this. We want to put a project charter together. We'll see what that means. But now let's assume that the initiation phase takes place. The purpose of this phase, in a few words, while we're doing these n, is it feasible? The key components that we need to make this decision is we need to have a look scope. The scope is, what is this about? What are we doing? The cost and schedule. So it could be a very good idea, but if he takes three years, it might not be a good idea by the end of it. And of course might be also prohibitive, might be just too expensive. We more or less put on a business case. Sometimes the business case is being done separately by the business, but sometimes the project manager, if he's part of this phase, would assist in creating some type of a business case who cut the cost benefits, strategy goals, they'll come out of it and see if yes or no, we can go ahead with this project. We'll have a look at the key risks. Sometimes there is a risk that is just so big that the business will make the decision straight off the bat not to go ahead with this project. So for that reason, it's important to highlight the risk. Now, we don't want to go to planning and execution. And after reality of this risk is just too big and it just hits us and it just can sell the project. Then when we are reasonably confident this project will go ahead, we can start putting a project team together. We'll have a look at the key resources. If the project manager is involved, they will assist with this. Or we will start and gather resources from the business teams to put a project team together. The key outcomes, Otis, yes, to get approval to start the project formerly, we need some type of sign off and we will see that we will use a document called the project charter that is sometimes used to put all these components, all these details on the project together in one document and we'll get this document sign-off and then we can say, yes, we covered this project has been approved and we can formally go into planning. Now let's review the role of the project manager. 13. PM role in the Initiation phase: The role of the project manager in initiation phase is optional. Sometimes, even when there is a formal initiation phase occurring, the project manager is not involved. I think that makes sense. There's no point in involving a project manager. If we're not confident the project, we go ahead. So in this case, the project manager will be brought in towards the end of the initiation when we are quite confident that the project would take place and then we can build a project team around the project manager. Another thing to bear in mind is that sometimes the project manager comes from a third-party, say, when a project is outsource, the role and the origin of the project manager depends, will depend on the type of project. And in the initiation phase, they will decide as a decided project team, they also decide who they want to protect. My pleasure to be with a project manager, GOP part of the company, or would they be part of the third party or maybe one project manager each? So we will review different scenario under the Projects Director component of this course. We've talked about the project charter and this is what we'll be reviewing next. I would say the key reason why the project manager is involved in this phase is the business would like someone to put all the paperwork for approval together. And this is where the project manager role starts with paperwork. So we bring all the components that we've seen before that form part of initiation into one document. 14. Project Charter: Now let's review the project charter. The project charter is a document the project manager puts together towards the end of initiation, really to summarize all the findings of the initiation phase or that has been discussed, put that in the next document. The schedule, the budget, and the big risks, as we'll see, and put all that in a document. Can you please sign up this document, everyone, so we all agree what we are doing. And then when they sign off, then you can go into the next phase. You can go into a more precise planning in a way. Next, we will review all the key components of the project charter. And then we will go into more detail and forth from all those components. So you have here listed the key component of this document. The project objectives and the business case are often included in these documents. So the business would stepped the outcome they want from the project and any benefits and why is it worth doing? We will review the scope in more detail in the following slides. The schedule that the state will be very simple. Some high-level timeframes with an end date will see this. We know we have some examples at the end of these slides. We will review this. The budget. We will also review which type of Richard is expected at this stage of the project. As mentioned, the risks are important early in the project, so we will need to list them as part of this document. Then the project team stakeholders, we discussed that already, but we will go into more detail on project structure and stakeholders list and rights. And if possible, we'd like to confirm early in the project who will be the approvers for these projects. So most of the components listed here will be refined during the next phase, during the planning phase. So this is a suppose what I had mentioned earlier in this course is that some components will be seen in initiation and then reviewed in planning and then monitored and managing execution. So that's something to bear in mind. Sometimes some of these components here can only be defined later on. Sometime the initiation goes so fast that the risk, for instance, is only in the budget, can only be fine-tuned during planning, but we stick to the theoretical view and hopefully we'll have all these components included. 15. Scope during Initiation: introduction: Welcome back to the course. So the first thing to define when we start a project is what are we doing? So this is what we call the scope. Sometimes is called requirements. You will see later on that you know, the scope and requirements could mean the same thing more or less. And we'll see this COP is more high level, it's more than the boundaries. And requirement is more detail what's inside requirements? The terminology that business analyst law like, like to youth. So what is important bearing in mind that we are only initiation and the project might not even go ahead. What we need to bear in mind is that we don't want to get bogged down into too much detail sometime we don't have a lot of time either. So the scope during initiation, it has to be very high level. We want to make sure that we have included all the big chunks, all the big components of the project. So this is, this is critical because if you forget one of the big chunks, then it's, the more you progress in a project of the more difficult it is to bring it back. If it's a small detail that then that that's easier. But what is as important as what is in scope is what is out of scope. It you have to make it very clear on the document that we do not do this. We do not do that. Imagine you're an executive and you have the assumption that something is included in the project only to realize halfway through the project that it was not included. So this is why you, you, you, you give them a chance. You say, well, this is out of scope. This to make it clear, we are not doing this. And then they Executive She has the opportunity there to say yes, but I want it in and then it's not too late because the budget hasn't been locked in yet. We can go back, increased the scope and Crito scheduled whatever. But at this stage, it's it's still okay. The more you progress, the more difficult it will be. So now when I suggest we do is we have a look at an example. 16. Cost during Initiation: Example: I'm just going to show you an example here that I think will show you the level of detail that is sufficient in a scope. Let's take the example of a website that needs to be stood up. A managing director wants to start selling its product on the website. He doesn't have a website, but he does have the resources to write the content. And it needs a project for someone outside his team to set up the infrastructure around the website. The project statement would look something like this. The project will include and that means that the project will have in scope is the sourcing and registration of the hostname, the infrastructure for hosting the website, design, build rollout, security testing, and setting up the ongoing maintenance we said with third party. So we can add more words to this. We can, I suppose at this stage to say as much as we can. But usually we don't have that luxury and we just yet, this is what we want. And this is on the high-level, what we would like the project that either out of scope as to avoid any misunderstanding with the project team when the business will engage a project team is This will be out of scope. We don't want you to write the content of the website. We will take care of the policy approval and the ongoing maintenance of the website. We really don't want you to do it. We just want you to organize the maintenance for it. So we doesn't have to be complicated. Just few bullet points like that. I usually enough. If you have someone from business who whoever say, oh, that's a bit vague and then you can drill down a little bit. But as I was saying, usually has to be done very quickly. Don't pay attention to this. Just to highlight that. We can sometimes make things very simple, very complicated. 17. Types of cost: So let's assume we have someone from the business who has a project idea. Sometimes they've done all the hard work for us and they've done their own investigation and they already have a cost and it just hand us the paperwork. But at other times, they are requesting the project team to pick the other cost for them. So obviously this is assuming that there's a project team that can assist regardless of who's doing the cost. It's usually done on a very high level. So before we get started, I just wanted to highlight a couple of ways that of course can be calculated. The first of course, estimate is the rough order of magnitude ROM estimate. You will hear that. So that can be done by a combination of expert judgment. Top-down estimating, an analogous estimating. The Rome estimate is perfect for an initiation. It's something that is very highly though, but still it gives them an ID if they can afford it or not. An expert just can be used sometimes is you have one of those gurus, for instance, to set up a website, as we said before, someone who says, Oh yeah, you want to set up a website, have all the infrastructure done that's going to cost you around 200 grand or the likes. So that's something that is sometime, sometime used. We want to kick off the project quickly. We free up the $200 thousand and then we will get started. Another method that is used is called the top-down estimating. And it's the high level estimate as well that is, but it's calculated by adding all the high level components of a project together. For instance, you for the website without the cost of the materials, the course of the of the contractors and the likes. And you would add all that up and I would give you a high level ID. So it's very similar to the next one, which is the analogous estimate. It's an estimating that is being done by using a previous example of something that has been done that is very similar. So this is more, this is what I was saying. This is perfect for initiation because it's high level at this stage, yes, The business is expecting a plus-minus and three-point estimating that we'll be seeing in the next slide. The second type of estimate, it's called detailed estimate. There's only one way to have a detailed estimate. It's just to the bottom. When we go into planning, we'll see how this is actually used. We can sometime also called this definitive, which is a bit scary in initiation to have a definitive budget when we know all the smaller components and we add them all up. We are usually pretty close to the final estimate. So this is more suited for the planning phase? Yes. 18. 3 points estimate: So I mentioned when we discussed the rom, the three-point estimation. I just find that to be a bit tricky because if you go to the business and you tell them this will cost you $200 thousand plus or minus the plus being the worst-case, minus being the best-case, then it doesn't usually fly. When you say, well, you could pay it, that will cost you 200 thousand, but it could go up to 300. Fascinated, usually a bit scared. So but they lacked the lag, the best-case. But they don't really like the worst-case. But it's sometimes with rum is to be expected. We are on a high level stuff. So please bear in mind that this is only a rough estimate and you could have some additional cost to read, but we could have also read Miranda and I reviewed this case. 19. Project cost example at Initiation: I want to give an example. So just to show you that once again, initiation phase doesn't have to be too granular. Following on the previous example, I'm just reminding being simple here quickly. The example of a website that is being setup. So the CIO of the company has estimated the cost of this website and you will be around 520 K. So infrastructure 200 k, design, build and test 200 K. Security testing, 100 K, ongoing maintenance, 20 K, you add all that up. You have 520 K. So the CIO, It's you will have an expert judgment even if the project is our tools, the CIO of the company needing the project, they will come to you and I will say, yep, you want to have that done? These guys can this company can do do it for you and it's usually around 520 K to be precise, because of this maintenance that comes at a 20 extra. So this is the example that you would have when you rely on expert judgment to do the estimate. So that's pretty much it for the cost. Once again, when we go to planning, we will be a bit more granular on how we can come up with the course. But initiation, It's all happening quickly. They want to know on a high level how much it will cause they're going to get approvals. They can add a little bit on top if they use the three-point estimating so as to make sure that they can cover some a little bit of contingency there. But that's all that is required. And in your project charter, you would add statement, project cost, and you would just list this. And that would be perfect. Once again, like for the scope, if you know more if you can be more granular, yes, by all means, go for it. But usually you don't have that luxury. 20. Stakeholder part 1: Introduction: Welcome to the stakeholder management part of the course. So in project management, there's a lot of stress on delivering on time and on budget. But for me, the project is not a success. If at the end of the project you have stakeholders that are unhappy, it doesn't matter who it is. For me, it's not a success. Just to give you an example. You could be on time and on budget. But what you deliver is not exactly what the business wants. It is what we agreed to do at the beginning of the project. For them. Everything has been signed off and the likes, but they're not fully satisfied. So why are they satisfied? Did did, did we really engage with them during the life of the project? Some project managers really don't like to engage too much with the business and ask them how they are and if they are happy with what we're doing because they are concerned that the business will come and say, Actually, I'm not really happy with that. And the project managers, we then have to do a lot of work to include this. But for me it is something I'd like to do. So I want to know I want to know how they feel about what we're doing. I want to know if they have maybe they changed their mind somehow. I want to know that. I need to know that in order to quote-unquote track of stakeholders, we need a tool. So there's a tool that is commonly used. It's called the stakeholder matrix or the stakeholder engagement metrics. So it's being done in two parts. The first part will be to come up with a list of all the stakeholders. And the second part would be to assess the stakeholders. We would assess how interested they are in a project, and we will also assess the influence that they could have on the project. So that's very important. So during part two, we'll review another way to track stakeholders. So it's not part of the formal project management methodology. So that's why I have it in part two. It's more my own stuff. It is part of the framework that I've created. It's actually a tool that, um, that have created and an amusing that has served me very well over the years. So I'd just like to suggest it as well as another way for you to quote unquote track stakeholders. But for the moment, we stick to the formal methodology and we start putting together a stakeholder matrix. 21. Stakeholder part 2 Stakeholder definition: First, let's have a look at the definition of a stakeholder. A stakeholder is anyone involved in the project are being impacted by it. Who are you working with? So that could be, That's the obvious ones that your team, your peers even influenced the project management. You are working with. Who we receive the benefits of the project that's more around the business. External customers to users be receiving some of the benefits who can enter up the project? I think this is something that is often forgotten. Yes. The business wants this, Yes, The protecting me super motivated, that if someone can come late field and out of the student, interrupt the budget to project that. That is something that needs to be done. I mean, in government for instance, you could be running on the project very happy. Everybody's happy, but there's a budget cut. And that's something that you need to keep an eye on, so they will be part of your project. It would be a stakeholder that we need to maintain the relationship with if we can, or at least be aware of their presence. Who provides the money that obviously your stakeholder as well, who will operate the end product that uses the contractors, suppliers. So we need to put a stakeholder list together. One way to go about it is to start on a stakeholder matrix where we put all the stakeholders and we categorize them based on their interests and their influence on the project. First of all, we have some stakeholders that don't have much influence, don't have much interest. So we will monitor all those so they're more or less, they cannot really impact the project and don't have a strong interest in a project. Now, if we move to the left, to the right, sorry, we have the stakeholders that have low influence. They have high interest in it. Top-left will have some stakeholders that are very high influence and they have a low interest, yet we need to keep them satisfied. But I'll come back to this one because this is my favorite. And then you have the high influence, high interest, and you need to manage those closely. Those are the guys that can have a lot of influence on the, on the project and are very interested in it. This is the girls are more or less you need to keep happy. Another way to manage closely, I would say keep happy that Martin, my favorite grouped to keep track on because they are the other one lurking is this group here, the high influence, low interest. It's more or less the stakeholders who sometime they are just against the project. So that's why they have low interest. But they could interrupt the project potentially because they do have high influence. This is the group that how would personally be very aware of? I mean, the one that have high interest. You could argue that as they have a high-interest, don't worry about getting in touch with them because they will get in touch with you because they are interested. So this is why for me, I think the top-left is as if not more important than this one. 22. Stakeholder part 3 Stakeholder Matrix example: So busy slide. But there's nothing like an example. So let's say we have a project, a software development project. Then we have managed to list all our stakeholders here. So if we look on the left-hand side, there's a Project Manager, Task Manager, Development Manager. We have the business analyst, we have the infrastructure team lead finance managers, senior user and etc. So for instance, a project manager who has high interest and I'm sorry to say he has medium influence. It doesn't have that at high-end influence on the project. Obviously, you can, you can make the he can influence the outcome of the project by speeding things up when he can. But at the end of the day, you cannot just say, stop this project. That's not the role either. Desk manager is being assembled. Someone is just testing. Of course they have high interests because they, they are the one that we'll be testing the thing. And, but an influence is medium. Once again, it can really stop it. So we'll have a look at the communication colon. At the end of this. Development manager, he's got all to high-interest, I would say medium influence business and that East High them even lower influence. That's just an example. I mean, obviously you would have situation where our interests and influence, excuse me, it's different infrastructure team lead. And then we go to the finance manager. So the finance manager would have a low interests sometimes in a high interference. So this is the scenario we're saying before, and that's why I say it's really for me a key one. You wouldn't show much of interest. But at the end of the day, you could say, sorry, we had to pull your budget and give it to another project if he's not really. So this is why it's very important to have a strategy to deal with this finance manager. The senior user. Same thing, low-interest, maybe something you didn't want to go with. Another new product. It doesn't add new software. But he's got a very high influence at the end of the day if we do all this work and he says, No, sorry, not happy with this, then that's something that we have the length of the project, try and influence him or her. Then you go down the list, operation manager, business representatives. The last one I want to mention is a senior executive is in a category obviously high-interest, higher interference. So those are also the one that you need to manage closely. But at least as I was saying, you would see them, it wouldn't be lurking in the dark as opposed to maybe some finance manager or the senior user. So don't, don't, don't take this as a, as a, as a truth for all projects is just it just one example of how things could could be, you could be on the project where, for instance, the finance manager has a very high interest in it because it's going to improve. This is bottom line at the end of the financial year. So it, but it's just an example. 23. Stakeholder part 4 communication plan example: Something that was said in a previous slide. Regarding this matrix that can be used as a basis for communication plan as part of the project. Sometimes you have communication plan. And what I think is the best way to do it is to use this stakeholder matrix here. And a stakeholder management plan. If you want, you can call it this way. Two, more or less put your communication plan together so you kill two birds with one stone. Here you have your matrix. By the way, this is not something that can always be published. For obvious reasons. You can tailor your communication based on the interest and influence factors. So if you take an example, the finance manager here, so I've already highlighted is high influence, but he has low interests. So I need to find some type of strategy to to to more or less raises interest and to make sure it doesn't come at the last minute to know to take some money off the project. So what I have here, for instance, I tend to communicate regularly, keep closely in the loop on any budget related matter matters. The senior user, you would have the part of the steering committee trying bringing in a steering committee or her and the attempt to communicate regularly outside the steering committee. So we will discuss the steering committee later on. But that's just to show the communication colon is used and how we will be communicating with resource stakeholders. And I want, just wanted to highlight the low and high, but we can very quickly go through the communication strategy. We would have reduced others. This manager will bring her to the productive meetings. We will send emails that way we will communicate with her. Development manager, will be part of Sam, part of the project team will be sent emails. The infrastructure team lead will be bringing to the project meetings to get his buying because sometimes they're working on so many projects, it's hard to get them interested. The operation manager in our communication we would have keeping in the loop by sending weekly reports will increase engagement and close to implementation date because the interests will grow as we get closer to the delivery date. The business representative will make her part of the weekly meetings and we will communicate with emails. The Senior Executive obviously it will be part of steering committee, will review the steering committee later on and then, and obviously, you can put some notes. And for instance, the senior user here denote is the reason why it's been put in a category as low-interest is E has not shown great interest in the project that's been focused on other more important projects. So there could be a reason. So it's been working on the very critical or the project and we roped him into this project and it's not fully with us, is not fully interested. So let's, it'd be dangerous because we could be as the user, the person using the product. And if he comes into play, then There could cause challenges to the project. So let's sit for stakeholder management. We have seen how to identify stakeholders of the project, or we can put them into a neat little list. And also in at least we can just more or less draft how communication plan. As it was mentioned earlier. I mean, we don't always want to publish this. This the way it is. We can probably remove the interests and appearance may be some stakeholders might not want to be seen in a category with low influence or the likes or something we have to be sensitive. It's more something we keep in our files. But the communication blend, obviously we we can tidy it up. We can remove the keeping a loop by sending weekly reports and comments like this. But we can say, well this, we will communicate with the steering committee of the email for a project meetings merges more, suppose, politically correct. So that's fit for stakeholder management. Next, we will look at the exciting risk-management part of a project. 24. Risk Management during Initiation: Welcome to the risk part of the initiation. So let's imagine we have a business person just got the informal approval to go ahead with the project. And she is quite excited and she wants to go for the initiation phase of the project quite quickly. She might be a little bit biased because she's so excited here and you want this to happen. So she might not be very open to someone telling her that there could be risks for the project. So it just a matter of during initiation, we wanna make sure that all the large risks are being naan by the executive team. We want to help her identifying some key risks that could potentially worst-case scenario mean that the project is being conserved or postponed. Remember, the scenario that I gave if you watched the video on the birth of project management, the queen said, well, if I know that I could have lost half my army, I would have gone to head with, with this project. So that's the same thing we need to make sure that the business, the executive team, everyone is aware of the key risk for this project. And we list them into the project charter and everybody sign that off. And then we are all aware of what's ahead of us more or less. So in order to, to track those risks, we use a tool is called a risk register. And the next video, we'll tell you how we can get started with that. 25. Defining Risk type: Welcome back to the course. To get started with putting together a list of risk where we can do is have a look at various risk types and see for each type, if we can identify Reesa, we can do that with a business or with the old project team actually, for that matter. To start with, we have the cost risks. That's an obvious one. What could go in the way of the project that will increase the cost of the project. And if this cost of the project as increased, what would be then the overall risk to the project. So there are some projects that have a very tight budget if you go over it more or less, this is a big risk. Models have more tolerance and in this case it's a little bit different. Schedule risks. If there is slippage in a schedule is at a big risk for the project. What could delay the project? What impact would the project have if there is a slippage in the schedule? For instance, you could have a date that is non negotiable at the end of it. All you could have data has been said, but if it moves, it's not a big deal. You could also have some reputational risks. If the project is not managed properly. Is there a reputation risks that could occur? Let's say you, you implement a website that has a lot of visibility towards external users. And if you more or less messy that up, that would be a big reputational risk for the company. Strategic risks. Is the project in line with the company's strategy? Or is there a big strategic change coming up? So if we know that there is a big strategy change coming out for the company in the next six months time is that there isn't going to pose a risk to the project at that point in time. That's something to think about. Then we have the legal risks, regulatory risks, contract risk. If we involved with both bodies, all these steps of risks. And finally, all risks associated with external factors or hazards are the rights. So in this category you could, you could, you could go nuts. You can put storms, floods, earthquakes, vandalism, labor strikes. So you could go completely nuts with these comments, hence, should prevail. Now, we have created a list of risks. The next step is to decide what we do with those risks. And this is the purpose of this next lecture, is to have a look at risk outcomes. What do we do with those risks when they occur? If they okay. 26. Risk outcome: Now we can have a look at what we do for a specific risk is five types of action that we could take. We could accept it, we could avoid it, we could transfer it, could mitigate it, or we could exploit it. So let's take them one by one quickly. But when we go into the risk register review, we will give an example of each one of those. So that would also add another layer to your understanding if I can put it this way. So what does that mean? We accept the risks, that mean that we are aware of it? Yes, we know that could happen. But if it happened, it happened. So be it. No problem. We are aware of it either. We don't want to do anything about it. There's nothing we can do about it, so we just accept it. We can also avoid it. Concerning the project is a bit of an extreme. But you can, what you can do is change the plan to avoid these risks. You can change the way you were planning to do things. Your project implementation strategy, for instance. Another thing you can do with arrays, you can transfer it to someone else. Say there is this risk. We don't really know what to do if it occur. So you can transfer it. And an example would be insurance. What you can do with the risk as well as to mitigate it or reduce it. So you take action to reduce the likelihood of the risk, or you have in place an action to take if the risk occurs. So if the risk occurs, you know what to do. Sometimes that will mean an increase in course of the project because we have to take some additional actions. But we'll see that as well. Risk can be exploited. So that only works for positive risks. Positive risks is a risk that if it occurs, That's good for the project Morris. An example, you could have caused the drop, for instance, and then that will mean more money in the budget. And if there's anything we can do to increase the chance of this, of this risk to occur, then we could take action. So it's a risk that we can exploit. So I know that the notion of positive risk is not easy to grasp. So that's it. So that wraps up the risk outcome. 27. Risk Severity: Welcome. In front of you is a table to assess risk severity. So the way it works is we need to know two components of a risk. We need to know the likelihood of the risk and we need to know the impact of the risk. And from that, we can detect by referring to the table the severity of the risk which could be low, medium, high, or extreme. So let's have a look at likelihood first. The likelihood can be almost certain, likely, possible, unlikely are rare, and the impact as significant, minor, moderate, major, or severe. So you will find some variations on this obviously from depending on where you work. If you know the likelihood of the risk, say, you know that a risk is rare if you know that the impact will be severe. So you know that you go there re or severe and they would put it high. Almost certainly. Could be someone being on sick leave, for instance, for the life of the project, yes, it's it's almost certain that someone will get sick at some stage. But the impact will be significant if it's one type of resource. But if it's another type of resource, the impact would be higher. And then you might want to do something in case that resources are sick. Just to give you an example. So as mentioned, the companies would have different criteria. This table would look different from depending on where you work. There is not one standard that's being used across the board. But I think that gives you a very good idea of how we can assess risk severity. It is not always done, but I think it's a good tool and I think if you do it, it would make you look good. That allows you also to put a little bit of perspective on the risk when someone comes to you and tell you, well, there's a very high risk that if this occurred. And then after you dig, you dig and you realize that the likelihood is unlikely and then the impact is only minor or moderate. And you can say, Yes, I understand your concern. The risk is in a risk register. But at the end of the day, the severities and the media. This is it for risk severity. Now we can go to the next part of the course. 28. Risk Register example: As part of the risk management process in initiation, we create what we call a risk register, which is a document Excel word order hikes that we list all the risks and the impact likelihood and severity, and the action that we take. So this is a register that has already pre-filled with a few examples. So I'll give you an example of each one of the outcomes that we discussed. So if we start with the first one, we put a risk number, we put a date raised, we put a debt. Risk cursory description here, a word on this red part, IF and then it's, it's good practice and it will make you look good if use this. I think it's a very good way to describe a risk using if, then otherwise it can become very fluffy. You can say, well what if this happens and the impact is not clear? So that really forces you to login risks in a very structured way. And it makes the impact very clear as well. So if the flight is canceled, then the budget will be impacted. So what is the impact? We have? Put the impact it has major. We have decided the likelihood is possible. We go back into our major and possible, possible major here. Possible here gives us a severity of high. Severity. He is high. We need to allocate an owner for each risk if it's if it's if he stays open. So who will be actively managing the risk? If the risk occurs, who will address, address it? So it's very important that if you are the project manager to avoid to have your name here, unless it's really a project management risks. But It's not always a project management is sometime you have to lag for the issue login. We will see later on, you need to make sure that someone actually owns the risk, monitors it for you, keeps an eye on it for you, and he's ready to action if the risk takes place. So that's that would be reviewed or so as part of the roles and responsibilities, it's very important to have a stakeholder responsible for each of the project component, the action. So we have decided that we will be transferring this risk. We took travel insurance for instance, I could be an option to transfer it. You pay a premium upfront. This way you avoid the risk. The risk is still open obviously because silica. But if he does occur, then you know what to do. You have an ad com, you have an action, you have someone to do it. So this is the first example, transferring the risk. If we go to the next line, if the IRS trend strikes in Paris, for instance, very unlikely, I know, but then we will not be able to travel to Madrid. The plan go on holidays. Your plan is to take the trend from, from Paris to Madrid. So the impact you rated as major, it's unlikely. But if you look in your matrix and you'll notice the severity is still marked as high, so the owner will be done. Here. You've decided to avoid the risk. Yeah, I don't want that risk to occur. I don't even want to be worried about it, so I want to avoid it. So forget about the trend. I will rent a car instead. Then you can close that risk. This is not a risk anymore. So you don't want to drag this risk along with the project with you because it's close. Someone raised it, you've avoided it so close, gone. Here is the next risk, the risk number three, say if it's running even in the ring heavily during the week, then the company will not be comfortable. Bit of an understatement, but just to give you a very simple holiday example. So the impact you see there's moderate, not the end of the world. And the likelihood is unlikely. And that gives you a severity only of medium. So it's not high, It's a severity of minium. The poor John is still responsible for this, responsible for everything. But you decide to accept this risk and you close at-risk. You say, yeah, it might rain. Yes. Well, thanks for raising it, but I accept it. You wouldn't have these two risk like this in a risk register because you would take one or 21 of the two oxygens. But just for this example, that's worth, I'm free a freebie. If you have the same risk here, same impact, likelihood severity, same owner. You will decide instead to mitigate it. So you plan some indoor activities just in case. So you would add an old bring some board games. You would just prepare yourself before the before the holiday projects start. You would prepare some activities to play. And also if this risk column, then you know what to do. And this risk stays open because you don't accept it. You mitigate difference with this one. Final example of a risk. If they are versus going to the beach, then we will not need to hire a car, and then we can save some money. That's an example of a positive risk. So the impact is moderate, the likelihood is possible. So the severity, quote and quote severity being positive, severity is, hi, John is still Yona. Action not come. You exploit this risk? Yes, we are aware this happen and if it happens, yeah, we can use the money saved to buy movie tickets, for instance, I think it shows, it shows, well what is a positive risks and how it can be exploited up. Think that the fact of having a positive risk is not very easy to understand. So I think with this example, hopefully that makes it slightly clearer. 29. Risk tips: To finish on risk with initiation, I just wanted to give a couple of tips. The first one is to include the key risks on your weekly reports, but also on meeting minutes. So that has a few advantage. First of all, for you as a project manager that reminds you of the key risks obviously. But that also allows your team member to be aware of the risks. Also allows your management to be aware of the risks and to be reminded of the risks. Yes, we're working on these, but we have those risks. Let's not lose sight of those. That allows everyone to check the status of the risks. So doesn't get lost into rich risk register. So not everybody. Actually, almost nobody would access the risk register apart from the Project Manager. So the risks have to be showing some way. And I think those two artifacts that are a good place for them. So you can, for instance, also use your weekly meetings to check if there are any new risks coming up. New team members would be happy to remind you of those. Also let you know if there's some that cannot occur anymore so we could close them. So it's a good practice. The second tip is to a formal risk review meetings. So what you will do is as early as you can in a project, ideally, in, during the initiation, you have a brainstorming session on risks. So what would this brainstorming slosh for more risk review meeting look like? So what you could do as a starting point when there's no risk there, you could use the risk type that we've seen before and then you would build your risk register. But ongoing in the project, what you can do is still try and bring everybody back and review the existing risks. Check if the severity as change. You can brainstorm in a new one. You can close the ones that are not valid. What is key for these types of meetings, attendance? You need to do your best to make sure that every part the business, every stakeholder attend these meetings. The reason is you don't want to have someone coming to you in the middle of the project and tell you, Well, what about that risk? Have you thought about that risk? But if that person has been invited for this early meetings, then they cannot say much because they have been there, they'd been involved. There have been given a chance to raise all the risks. So just a matter or so to cover yourself a little bit. Because there's always someone would come to you and say, What about that risk? So if you have your initial risk meeting and after you have regular risk meeting, you move the responsibility in a way from yourself to the, to the Broad spectrum of stakeholders. We have to take responsibility for these risks together. So it's not a project manager's concern only frequency. We mentioned one initial meeting when we start with a blank page or some gestures we put together all at the business knew that we knew and after every month or every quarter, depending on the length of the project. So that's pretty much it for the risk management. Thank you for your patients. So now we will be discussing the project structure. 30. Project Structure Introduction and basic structure: Welcome back to the course project structures. So towards the end of initiation, when is a good chance that the project will go ahead? We put together a team, project team. So when you section, we will review different scenario, internally managed outsourced project structures. And we will see how they relate with other parts of the business. Let's have a look at a basic project structure, internally managed. No contractors know Fed buys. You are sitting here as a project manager. You have a team working for you. Sometimes. You have several teams. Sometimes. And if you work on several projects, you would have some moral several projects team members here as well. You have peers, you can have other PMs, they're working alongside you. You usually reported to a program manager. Program manager is a manager who manages several projects. So it's called the program. The projects can be related or not. But at other times you could just report it to an executive. A program manager implies someone managing several projects, but sometimes you would report directly to business area and Executive Director or even to a line manager. And that would occur if there's no program manager, if it's a smallish project, smallish entity, smallish company. So you would have all these types of reporting possibilities. If you're like an a you, you would have some times team leads, the team needs would have their own team members. Or you'd have some times team members working for you with a direct reporting line. One thing of note is you could have resources working for you 100% of the time, which is called a fully dedicated resource. Or you could have shared resource. You have a team member here, peter is actually a shared resource between yourself. And the other project manager here is working on two projects. So this PID of a red flag, you need to make sure that is worth litigation is as agreed. So if you can, in an ideal world, try to only have dedicated resource, but not always possible. Another scenario highlighted here, it's Mary. She shared it with BAU. That's even worse in a way because she is working for the business as usual team and the business which is your workload, is not linear. So they would have periods where they would work intensely and there'll be some other periods which little bit quieter. So definitely maybe another warning signal here to make sure that Mary works are allocated share for on this project. So as a bit of a risk mitigation, what you could do is when you have shared resource, you could put that on as you risk. A risk here, It's likely that the memory will be dragged along some BAU activities, especially if they do production support under the IT environment and the likes. To finish just a quick note, just to mention that this is called the matrix environment when the project manager takes resources from other teams. There. Just to give you an example of a basic project structure when the project is internally managed and there is no project office. And we will see the project trophies in the next slide. 31. Project Structure: Project Office: Welcome back to the course, the exciting world of project office. A project of fees. And I'll give you a bit of a few acronyms here. Apologies called a pill or a PMO, is more or less a pool of mainly project managers and project coordinators. They are usually managed by your project office manager. Their main role being to allocate project manager and project admin resource, but there will be also managing them. So you could have a heart reporting line if you like, between the project manager and the project coordinator to the project office manager, they set standards and policies for all projects. So you join a company. They insisted that, you know, prints two or PMP or anything else. But when you join them, you realize that they follow some standards, dark, quite different. And you have to work with our standards. And for me, this is just another argument that learning one of those prints two or PMP certifications is more to look good on your resume and to attract potential hiring companies. But the real-world that it's rare that you would have to work to work with those methodologies. You will just use the company's standards and policies and the likes and other role of the project or feces. They would sometime consolidate all the reports provided by the project managers and they would, of course, verifier you on report and they will chase you down. If you haven't provided them on time. They would regroup all those reports from all the project managers and consolidate them and provide them to the executive teams. We then show the process are being followed, of course. So they give you Standards and the likes. So they want to make sure that the processes are being followed. And if you're lucky, they can provide you with some training, I suppose, like any type of management team would. So that's a quick overview of the project office. Now we can have a look how that fits in within the org chart that we saw before. So this is same as before. So we are sitting here as a project manager, you're reporting to the program manager here. But at the same time you have some type of dotted line to a project office. You can be working alongside a project coordinator. You see, sorry, I'm too busy with this project and I need to project coordinators who the project coordinator would assist you. Project coordinator could help you with things like organising meetings, writing minutes, could also help you with schedule and the Reich's. And based on the experience of the project coordinator, that, that can be more or less useful. But as mentioned, this is a good way into project management as I, as I will mention in part three, I think this is an excellent way. Sometimes I don't need to know any any other project management methodology. So you would go in here and then you would end up here probably. But let's leave it as is for the project office. And let's have a look at another type of chart that you could have. 32. Project Structure: Project outsourced: So let's have a look at another project structure in a scenario where the project is being outsourced to contractors to a third party. On the yellowish here, we would have the usual internal structure with Programming agile business around them and protect managers there. And then in greenish, we would have the contractor. They would have their own structure usually for large project, they would have a project manager and the company would have an in-house project manager as well. So the flow of information, if you like, would be from the team here to the project manager, contracting, and up to the project manager in-house. And after the reporting flow will go up to the program manager. So that's just one scenario. If you like. Sometimes the project manager, he could report directly to the program manager or the business area sometime when it's very small, they don't need project managers. So therefore, the team lead could report directly to the in-house project manager. But for large projects to project managers, one on each side. 33. Project Structure: Steering committee : Welcome back. So to finish on project structure. When we discuss communication, we mentioned the steering committee we as a group that needs to be kept in the loop and we need to have a structured way to communicate to these group. So the steering committee is a temporary structure that is being set up for the project so they can oversee the project and provide some key decision. And I was going to say advice, but it's more than advisor really supposed to release, tear the project. This structure more or less is made of high-level stakeholders in, but sometime they bring experts to this meeting to enable them to make a decision. They're usually the sign offs for the key decisions. So they are very important group. So let's have a look of what typically the Steering Committee is made of. So they have what we call a senior user, which is a Senior User is the end user of the product, if you like. They are the one that we'll be using, what the project delivers. There's also a senior supplier which is not always present, but when the project is that source or when there is someone supplying the good or service than they would at hand here. And then the senior executive, or so-called the business owner. So this is the person really responsible for the project. The project is for him or her. In a category of stakeholders, they will be high interest and high influence. So as, as the project is made for them, then they have the, they make the code more or less. If at some stage I decide the project's not worthwhile anymore, they just make the call. So very important. So what's interesting is the steering committees. You would assume that the project manager is a mandatory attendee, but but sometimes it's a Project Manager doesn't attend. Sometime it's the project manager's manager attending. So they raised the bar a little bit. They they want to get a bit of an independent view on the project. So if it's not always your decision, but it's best if the project manager attend. So that's all I wanted to mention really on a steering committee, group of hi, influence people meeting to discuss the project. And when there's are some key issues they would they would make the call. They can also be used as the escalation point. This is what I said is good as a project manager that you attend because you can raise your key issues. And that's it for project structure. So next, we will wrap up the initiation phase and we will start by checking some examples before wrapping up the faith. 34. Optional: Project Charter example : So earlier in an initiation, I mentioned the project charter document, which is a document the project manager creates to regroup all the findings of the initiation phase. And this is being used as a way to get the business to sign off on the project and we can go ahead with the project. I just wanted to give you an example. The initiation phase up, because I think it always helps. I think, as I've mentioned, the project charter can be a bit scary. Sometimes we see these huge template with all this information that needs to be in. But it doesn't have to be. If we start with something very simple and we just add a few words around it, it can be actually quite short exercise, especially taking into consideration that most of the content of this document is taken from other stakeholders. From the stakeholders, you are not writing much of the content. Let's take another project for a chance, building a bridge. So one of the section, our suggesting we have in the project charter document is a project objectives. So very simply, the project concerns the building of a bridge on the soft side of the city. Something very simple like this for the project objectives. When they had some business case paperwork and the likes, you would take things from the document and you will put them in there. Same for the next section here, benefits and business case. That's something that you would often take from the business. I have here. The current traffic on the center of the city has become unsustainable and it's causing delays. And therefore we need this breach. You will then go into the high level scope, what is in scope, and what is out of scope. So I have really simplified it. I think earlier in scope, I had several bullet points here. Just really simplified it. Obviously you would have more words than nice, but it's just to highlight the structure of the document. In scope, the building and testing of the breach. This is what we want the project to do. We want the project to build a bridge and to make sure that it worked, you would have more subcomponents. I would think that two bit value tells, you would say where it needs to be done and the likes. This is more or less to give you an idea of in and out of scope. Out of scope, you would have communication to road users and all the roads in it serialization, for instance, you don't want the project team to take care of this. You'll take this yourself. This is out of scope. The high level schedule will be just key milestones. You will just say by John, I would like to finish the planning phase. 2021, March. The company will be engaged. June. This has to happen and you would you would wander the completion by 2023 implementation budget the same. We had quick look on budget. We talked about the rough order of magnitude and one of the weight get to these rough order of magnitude. Whereas expert opinion, and then we have an expert can building a bridge. You just don't want to improvise to match. So you really need someone, you hired someone, an expert. It knows how it's done, is a specialist is done that many times. So any kind of preserved with 120 million to build a bridge. And the budget as the Council, sorry, as a budget of 150 million. So it looks like it could work. Next part, the key risks. But whether we'll delay construction. So you would worry that if there is bad weather, then the construction will be delayed. And then you will put that into your risk register. And you would then decide what do we do with this. We will just accept it. You want to avoid it? There'll be more difficult. You probably could mitigate it. Maybe do some indoor work world while it's raining. I don't know, but that's a starting point. You would refer usually to your risk register. You would, you could attach your risk register to the project charter to really help everyone make a, make a sound decision. Another risk that have listed here, obviously I'm not a bridge-building specialists, but I like this example. So road authorities dependency it could delay implementation date so that you would imagine you would have few loops to go through to build a bridge. And one of those being the policies, the standards and the likes. So that's something that would cause delays. So as part of the risk mitigation, we'll try and speed up that process or at least very understand what are the steps involved. You would give also the project stricter another view of the productive. So you've decided to go to outsource the project. Obviously you didn't have handy specialist team to build a bridge. So you would have a team metal of the following. You would have an internal project manager. You would put Mary Smith, part of the council should be your internal project manager. You would have Project Manager from two different companies. So you would have the company XYZ for doing the construction itself and ABC to do something else. So you will have a team made of free project managers because this project would be so, so big that the third party would have project managers. You would set up a steering committee and part of the stakeholder list. I suppose a steering committee will be made of the senior user, which is the road authority representatives. So the senior user will be representing everyone using the bridge. So obviously you cannot have all users, but you would be the one representing all the uses. The senior malaria would be the company XYZ. They are the key guys, are the key guys building the bridge, so they will be the senior supplier. You would also have the senior executive and that's a boss that I would assume it's mayor of the city. So he or she will be the one making, making the key decisions on the project. Then you would have a stakeholder list. I have here just duplicated the steering committee. You would obviously have project manager. You would have Marion nice. You would have the project managers of these two companies and you would have anyone you can think of list of approvers required? Yes, that's important. You would have the senior executive would be sending off the document after review from the management team. So you've you know that the key approval for this project would be the male, the city. So that's a bit of a wrap-up of the project charter. I hope it makes sense. We were not done with example. We still have a couple of examples after this one, but I think that hopefully it's just the ceiling, all the information that you've had in his face for the phase initiation phase. And you have also a template in your resources. Once again, the template, every company would have a different type of template. So if you join a project manager somewhere, that would give you a template. But I just wanted to put a template in the resources just to show you that it doesn't have to be too complicated. Let's have a look at another example. But this time on some specific components of the project charter. 35. Optional: Additional Examples: So I've just focusing here on a few components of the project charter, which are the cost, schedule, the business case, and the team. So first example, you would have a software delivery. The highly high-level cost. You would have the service provider X, Y, Z, that's provided an estimate of 150 K and 50 key ongoing. So it is outsource environment. And this is usually the best way to get misdemeanor because, you know that service providers are doing this day now, as I was mentioning, they have teams. They will be able to give you very precise precise cost, high level schedule. So the provider as estimated for moms deliver. So then based on that and based on when the project can start, you should be able to give the business an implementation, implementation date up to you if you want to add some contingency or not. The business case, we need an accounting system to avoid manual input and human heroes costing us 75 thousand per year. So they are telling you that one of course would be 15050 doing. But you are telling them that I would set a 75. Yeah. So is that worth it? So they would say, well, 50 K cost for 75 saving, yes, it's 25 K per year. But is that really worth the hassle taking into account that you need to recoup your initial cost. So you put all that up to them and they can make an informed decision. The team bring a team together, the service provider provides us with a project manager. Steering Committee will be setup with these project manager and senior resource from x, y, z, which is, which is the service provider here. Next project. As an example, you develop a website. So the high level cost, you have an SME or subject matter expert or other word for a guru estimated at $30 thousand. You have your liberal scale. You'd say that we need these before Christmas. That's small business imperative. So you get the estimate from the SMA and you'll see that if that could work. The business case is we want an online facility to reduce the amount of phone calls and there's some numbers there. So once again, you would put all these numbers together for the business to decide. Cost savings. Is it worth it? And the team, an internal team can do the work. So we won't be an outsource project like the previous one. It will be an Italian manage project. Will use Mary as a project manager. And the rest of their team has already been set up. So you can rest easy that we can run this project not problem. Another example that I've just actually given an expert estimated 120 million, the high level schedule they expect mentioned for years, breach is required to avoid congestion. And to put the team together. We know this Pm specialize in breach constriction, so we will hire him as a contractor. Instead of having another scenario in the previous one, I had someone internally from the console. But you realize that to be more convenient maybe to have a specialist project manager and you would hire him or her. Final example, just just just to keep these agreeing on holidays such as I like to give a various range of examples. So high-level cost, well, we have 5 thousand broad span, the Oliver schedule, you have two weeks business case. We really need a break in the team, the two of us and the kids. So as part of the bearing in mind, we are in the initiation phase. The project has not started yet. So in other words, if you stay with, uh, going on holidays, projects, you have $5 thousand to spend and you have two weeks available. And then you can model is decide well, is the business case worthwhile? Do does it hold water? Do I have? Can we start planning on this? And this is the advantage of asking yourself this question before, before we go into planning. Because if you go into planning and if you start investigating and erotics and after you realize, well, we don't even have the money for it or we don't even have to leave for it. So I wanted to finish with this example just to highlight the importance of getting, the key thing is writing a thesis and face, because after it is too late, you don't want to go into all this planning. Only to realize that, well, the other day that that's not viable project and that's the purpose of the initiation phase. 36. Phase 1: Initiation wrap up : Welcome back. To wrap up our project initiation. So I started off this phase by stating that the project initiation doesn't always occur. At very least doesn't OKRs formerly was a bit of a reality check as opposed to what you'll be learning in some project management standards, methodology analytics. You will have a scenario with someone that management and executive. They would just come to you and let you know. Yes, you have a project. We already worked out the budget and this needs to be implemented by such a date and it's usually quite aggressive. So this happens is, it's important for you when you get involved at this stage to be very active at trying to find any potential gaps. Because anything that is missed out at this phase, it'd be very, very difficult to fix later on. Need to challenge very tactfully the resources that came up with this quote, You need to try and find out how did they come to that quote. You need to check if they have forgotten anything to include it. That quote, quote, sometimes they come up with quote, but they don't think about all the overheads and the like. So as a project manager, you really need to make sure that everything is included. And to avoid that as you do the planning era as well, but they didn't include this. I didn't include that. So Challenge tactfully, that would be my recommendation. If you hide involved in initiation to make sure that the full cost provided early impossible because once the budget is allocated, then it will get harder, if not impossible as you progress in the project to Amanda and change. So we see the, the initiation phase as analogy. If you want to start a painting, the initiation phase is when you outlined the large shapes on your canvas. If you forget one or if you don't do one right, then it doesn't have to be precise, broad-brush. But if you forget a large chunk, then it'd be very difficult to rectify. So we have a quiz to wrap things up and we'll be continuing with the next phase, which is project planning. 37. Phase 2: Planning section overview: Welcome back to the course, face to planning section overview. In this section, we'll review the purpose of the planning phase. We will also discuss the project manager role. In this phase, we will review an important document the project manager has to create during this phase, it's called the Project Management Plan. Usually, the key components of this phase that we will discuss will be the scoping requirements, scheduling, cost, budget, and quality planning. We will finish as usual with an example of the document created by the project manager. And then we will have a wrap-up and some quiz as well. 38. Phase 2: Planning purpose: We have now completed initiation, congratulation. The project is approved. Now we are starting planning. Planning is planning for the execution, which is planning for the next phase, more or less. Blending is how will we be delivering this? And what exactly do we need to do? Because initiation, it was all a bit high-level, high-level chunks. Now it's time to know the small chunks, so we need to go back to the business and ask them what exactly and put that on paper and we can all sign off and agree. But now let's review in detail what's involved in the planning phase. So what is the purpose of planning? It's more or less, how would we be doing this project? I will be performing the activities of this project. It's Southern look at the key components that are involved in planning. We go back to requirements, get more granular. You a bit of the lower level. What exactly do we want to achieve? What is included, what is excluded? We set the boundaries a bit more in a more refined way. We have a closer look at our schedule now we're not in to the broad brush anymore, so we are really looking at each step that is required. The dependency is the duration of the steps, and that should give us a final delivery date. We have a look at the budget and cost into much more detail. We have a look, another look at stakeholders if they are still okay, more closely or so in the roles and responsibilities. This is the key document that will be delivering at the end of this phase, we had the project charter in initiation. And in this phase, we will call the document that is created by the project manager, the project management plan. And then planning all other activities more or less. Depending on the project, you will have more or less activities here I've listed a few. We planning on how we will be reporting on a project. Do we need to keep anyone in the loop on quality control? We talk about quality. Can we check what we are doing is right? The communication? Talked about that to stakeholder. How are we going to communicate and with who and how? Have a look at planning for procurement. Do we need to buy anything and if yes, how we'll be doing it. And we'll have also, of course, we'll have a look at the risks. So the overall outcome sought from planning is to know how it's project activity will be contacting, conducted, sorry. 39. Role of PM during Planning: Welcome back to the course. Let's have a look at the project manager role in planning. During initiation, the project manager created a project charter. And during planning, the project manager create a project management plan that will encompass all the findings of the planning and will submit this for sign-off. He or she has another document to create some paperwork to do. On top of that, the two key activities that the project manager needs to do is to finalize the schedule and the budget. Those are those are key and they are very important. And it needs to be done with a lot of detail. On top of this. Of course, the project manager needs to ensure that all the planning is done correctly. I've just listed a few here. The PM needs to ensure that the planning of activities is historical, that the requirements are clear. Scope is defined, that the team structure is finalized, full list of stakeholders is created, that resources are available. That's very important obviously for the planning and the schedule. That everybody is on board. We could have a list of stakeholders, but here are not engaged. And if the resources are not available, then we won't go very fast. So usually what we do is we have a kickoff meeting where we engage all the stakeholders, all the project resource, and see if anyone has something to say, say it now. Otherwise, we are going we need to ensure that the reporting is defined. As mentioned earlier. All the steps are taken to deliver a good product which is planning for quality. And that'll communication is clear. On top of that. Let's have a look at the risk register also we added. So that's a lot of things to do during planning. It's very active phase for the project manager. 40. Project Management Plan Definition: Once again, that's what your project management plan could look like. I have taken some of the components that were in my first slide on the project planning, but I've added a few here. The critical success factors, which be, how will we decide if the project is a success or not? That's something that we could include in the project management plan. We could list all the deliverables. If you remember from terminology, that's everything that the project will be handing over at the end of the project. The work breakdown structure, that's something that is way too. List requirements are what is required from the project. And I have an example of this later on. You could also have some constraints that haven't mentioned before. A project approach, which is, how will we be doing this project sometime, sometime it's not required because the way to do the project is quite standard. But if we do something a little bit different, I suppose it's always good to list it. So that's another document that we need to create. And next, we will start to review the first component, which is going back to scoping requirements. 41. Requirements: Introduction: Welcome back to the course. Now it's time to go into more detail in our scope. So on one side, we have the business. They need to tell us what exactly we need to do. On the other side, the project team would be business analysts and architecting whoever really need to make sure that they understand what the business want. This is a critical step because all that we do in execution will be based on these requirements that the business is providing us. And we will see in next slide how important this requirement is and how important is it to get it right? So how do we create a requirements documents? There's usually some type of business analyst involved on behalf of the business to put all the business wanting in one document. It could be called the business requirements document. It could be called the detailed requirements document, but it can also be a requirement matrix at a high level. And the advantage of the requirement matrix, it's quite quick. To go back to requirements. You would have a requirement here and has a number associated to it. I'm just giving you an example here. That's quite useful as we'll see, if it's not a requirement matrix, there will be some type of other document anyway, where the requirements are clearly articulated. Just to stress the fact that this exercise is quite important for the project. We will use the requirement matrix or any type of requirement document during the execution to design and build the product. It will also be used to check the scope of the business here. Have you thought about that halfway through the project and if it's not in the list, we said, sorry, that was not in this list. So we need to do a change control. It will be used to check the quality. When we have a test team, they will go through all this requirement and they will confirm that the build has been done properly and then include all these requirements. And the final acceptance. When the product is completed, the business will go back with this list and will ensure that, yes, they have these years, they have that tick, tick, tick, and it's all done. It's especially important in, in a vendor environment when a company is contracted to do a work just to before you sign off and free of free up the money. You would usually have some discussions around the requirement. The requirement here, for instance, they can have here some category. It could be a compliance requirement, could be a security requirement, it could be just a design requirement. Then you would have some type of description. Could be a good starting point. For instance, serial security requirement or transactions on the website must be encrypted. And then you could have something more detailed. Underneath. 42. Work Breakdown Structure: WBS definition: Before we move on to the next part of planning, I just wanted to briefly mention a tool as we are in requirements that business analyst use sometimes too. Visualize the requirements that are required by the business on the project. So it's called a WBS or the work breakdown structure. And it's just a fancy way to decompose deliverables into smaller chunks. So it can be used, it's used mostly by business analysts, but it can also be used by project manager. For instance, here actually I have the example of a project that I have decomposed using the WBS chart. So the way it works is it goes from the more complex to the more detailed component, and it works with sub-categories. So if you have, for instance, I have the higher component, which is my project is to go on holidays. I decompose this project into the key activities that I feel are required to deliver this project. And then under each key activity, I have smaller activity and the reach. So if I just take one example, decide destination. So my project would be similarly days. And my sub project, if you like, my sub component would be decided on destination. Endo, decide on destination. I would have brainstorm ideas. Check the way. The next sub-component is, how am I going to decide on each unary? Another look at the timing. I'll have a look at the stokes I wanted to have and ascites that I want to visit. So in other words, it's when you go from top to bottom you get more and more granular. I need to good way not to forget anything. It's called WBS work breakdown structure. Just wanted to mention it just in case you hear about it and you can see yep. I've heard of that. I know what it is. 43. Scheduling: Introduction: Welcome to the scheduling part of the program. As we've seen with scope, scheduling during planning has to be more thorough. It has to be complete. During initiation, we were just happy with some key milestones, but they were in planning. We have to do a full plan, a full schedule. When we build a schedule. During planning, we are mostly concerned about the activities that will take place during the execution phase. Nobody's really interested what's happening in the closing phase, maybe your project of his so they can properly rail kit some of the project management resources and the Reich's. But a business your project teams and the Ragsdale are mostly interested in the execution. So this is where we will spend most of our time planning the execution. So the scheduling obviously is important for the coordination of resources. It's important to know you cannot just take in resource and let them go whenever you want. So you probably wouldn't be working with other managers. You need to tell them when a resource will become available or when you need to have access scoring quarter and other resource. Obviously the coordination of activities. So you can tell the teams this activity we finished on that debt. Then the other team, if they have a dependency on this activity, then they can start. So they can put all that in I or the team leader can put that into the plannings. Obviously the implementation let the tricky one, but also the final costing because some costs will be dependent on the length of your project. For instance, project management is the obvious one. The longer the project, the more time you will need to spend on the project. It doesn't mean you'd need to spend 100% of your time. But the longer the project, the more the project management cost will be. The same for some are contained in some admin, some overhead activities would be in the same category. 44. Scheduling: Breaking down Execution : Welcome back to planning and scheduling part of planning. After the introduction, I wanted to show you some typical components that fall under the execution part. So it's always a good idea when you plan for a project to check if you fall under this scenario here. So at the end of planning, you move into execution. So in other words, in planning, you need to plan for the execution, as we mentioned earlier, you have to look forward or what's the execution would entail. So they are instances where the execution will be decomposed as follows. So you would have the design, build, test and then the implementation. So that's typical for an IT project. You would have the requirements would occur before and during the execution will, you will do the design, you will do the build, you will do the test, the implementation, and after the execution component will end. During planning, you will do the requirements gathering. So the business will come with requirement matrix or business requirement document. And that will tell you what needs to be done in detail. And then during the execution, you will go into design and how we will do it. So sometimes there's some confusion. The design is not part of planning, although it will be tempting to put it there. But it's not. What isn't planning is you gather the requirements and then design is part of the execution. These and we will tell you how you will lose it. This is the requirements, will tell you what you will do and the design you, how you will do it. The requirements on the high-level business here I want a website that has this data has doubt and the likes and the business analyst as part of the design, will tell you how they will convert this requirement into something concrete, how the webpage will exactly be designed. And after we move on to build, the developers build or construction, they will use the design document produced here, and they will use it to build the product. When the build is completed. Hopefully you will have a test step here where you will check if the work is appropriately done. And as per requirements. This is what we were seeing before. The requirement document is used for design, for built, and for taste. Final step after testing is you do the implementation. So as you can see, that can be very useful to put a draft schedule together. You would have a heading with a design or hitting with build, test implementation. And under each heading you would have the more detailed tasks. 45. Execution planning examples : Welcome back to the course. Now what we can do is we've seen this model before where we can go from design, build, test implementation. Where we can do is have a look at projects and see when, when to do the planning if they fit within that model. So here I have five projects and let's just go through them quickly and check for each one of those components here if it fits the model. So the first one is a software delivery. So what would be the requirements for this? That will be the business telling us what they want the software to do. So that works. So we can really relate to a requirement here. Design will be usually use software specification of some kind, and it will be done by the business analyst. The build will be all the coding configuration and relax done by the developer. There is no surprise there because software delivery is actually the one that it's actually an IT development project and render this model fits IT development project. So to come back here, test test of software VS requirements. Yes, so it tastes analysis would be involved in implementation. There will be a go-live where the users can access the system. That works. I'll develop your website are also kind of IT project. The requirement would come from the business will tell us what type of width side they want and which functionality that they want to have. The design that will be the same. There will be a designer website design here that being done to build, creating quarter-on-quarter website, which is more configuration these days. As far as this is concerned. Yet specialized team does the website and on top of that, obviously the the business will come and do the UAT implementation. Yes, we go live as well, provide full access to the website. So that works tick, building a bridge. The requirements. I think we've seen building a bridge before. So the requirements, the government or whoever wants these bridge, outlines what types of rays they want. The design would be done, I would think by an architect will have the plant and the likes. The bill will be done by the construction team. Test we will be testing the breach solidity. So that's an interesting one. I assume they also taste components before, but I don't know if you've seen those on the internet, but they put 50 big trucks on the bridge and they more or less tested. I don't want to know what happens if it doesn't work, but I think they do that. Quite convenient that the taste is quite solid and the implementation, yes, on one day they say that's it. The bridge is quote unquote live and the cars are allowed on the road. Now if we take the encode project of going on holidays, the requirements, whatever that is, this, we all need holy days, I suppose at some stage, design will be preparing the scenery and the build will be to make the bookings test. You can't really test the holiday. I mean, I wish I could test my holy days, but I suppose you could do a dry run with all the bookings. And the implementation is when they only they start landing on the moon. Let's say we want to go to the moon. So this, this is a requirements. I would imagine they would provide more detail than that. But the design, we have a rocket being designed and we build the rocket taste. I assume they do a lot of tests, but they can't really test going to the moon once, twice and after. Okay, that's, that's, that's the right one. Let, let go now live. So they would do some type of tasting. So it's debatable if this model works for this, we think maybe yes. And the implementation, That's it, 321 go here, you have it all the components. Very useful when you want to create a plan. 46. Building a Schedule: Steps and example : Let's continue with project planning, scheduling. I have some suggested steps to build a schedule here. Step 123, obviously, I think that building a schedule is quite intuitive. I think we all know about project duration dependencies. We've all planned something somehow. It's not funny the holidays as well. I'd like to give this example. It's everybody. Hopefully you started that at some stage. Step one, we list all the tasks required alongside with the effort required. It is a mode of time that would be actually spent on doing the work. The duration will be the time spent from start to finish. So you could have some delays, some width times in-between. So that will be taken into account during the duration. Is a quick example here for you. Take the builders two hours to fix my roof. But if you take into account all the green back and forth, it will take them two weeks, the duration, but there will be actually working on my roof for just two hours. So if we go back to our example here, it's building a fence with a gate. So you would list all, all the tasks that, and please don't comment on those. Just assumption that what is required so 0.5 days to build the material free days to install the post, one week to put a fence up in todays to build in installed the gate. So we start off with listing all the tasks. Step two, we list the dependencies between the tasks. We reviewed a task that cannot start before another one as complete. So for instance, we cannot start building the fence prior to getting the material. We cannot put defensive without reading the material. So we can start putting the fence without the post. So we cannot do this without the post. We list all the, all the, all the dependency between a task like this. Document here has advanced. Sometime the relation to be between tasks can be more complex. For instance, some tasks that can start a few days after another one is started. Or sometimes I need to finish at the same time. An example is we need to finish the fact that the same time as our neighbors finished his. Because we want to make sure they're exactly on the same height, for instance. So that's more bit of a complex dependency the that we can have. So this is where I'll put us advance. If you're a beginner, you don't really have to worry about this scenario. The stage. Step three, we put it all together. We review the resourcing and a constraint for those tasks. Who is doing those and how many resources do we have available? And this is where I was mentioning before, effort and duration as two terms that are often used in project management for those scheduling, effort is actually the time to actually do the work and duration. It's a time that it will take, taking into account all the, all the dependencies, the constraints, and the knife. So for instance, what I have here, let's have one week to biomaterial is we need to find the proper wooed. The shops might not be open and the likes. So this is to show you that 0.5 days task can turn into a one-week task. And this is what would happen in project management as well. Sometime could, some task could have one day if it's on the plane, you would put five days because the resource is not often valuable, works part-time or the length in, we'll take two weeks to put the fence that fence IP as a contractor is working part-time. So when we effort, but the duration will be two weeks. Resource might not be available. So that's more constraint if you like, until a certain date. So you list your constraint. Shops are closed during the Easter break, contractors away or me. So you can list them enough to mine will be your program. You might finish the project before the project might stop. After. Two resource available with the same skills could work on the same task. So that's more positive situation. Something to bear in mind when you put your schedule is a secondary source will be available from the 10th of May. And then you list all other constraints. The fence needs needs to be paid by the 12th of June. There could be a type of constraint. So that's it. Step one. Step two, dependencies between those dependencies required. Because when you have a look at the resource and constraints, then you will need to take those dependency into account. So that's just an example on how you could go about building a schedule. And how would you represent this? You can just represent this this way to the business. I've taken all the effort and duration into account and assuming process start of March. I've put all that together and I'll give me a completion date. It's a small scheduled, but just to illustrate the three steps that I had before, We will see other ways, obviously to present a schedule. But this type of schedulers would see it's quite good to present on them, very valuable to the business. 47. Schedule Types part 1 Milestone and Timeline views: Hello again. So let's review some scheduled tabs that you could come across. So I ever presented here to schedule tabs that are quite common. They focus on milestones. For the first one that is called milestone view, we just list the tasks and then we put the completion date here on the right-hand side. So usually you'd have all your key important project tasks. And when they will complete that gives stakeholders and idea of when some key milestone will be completed. The second one is a project timeline. It's a little bit similar in focus also on milestones, but it's a little bit more visually, if you like. So there's the completion that he 30th of December and the name of the task is here. It's quite user-friendly. I've done this one in Microsoft Excel. I think it can also be done in Visio. So let's review the advantages of this type of schedules. So they are great for management of Steering Committee reporting. Obviously, they are very easy to read and they focus on a key component. They are easy to include in reports. So you can just copy this and put it at the end of your report. That gives you a everyone an update on the schedule. And also with the project team, they are better. I feel to get people motivated and focused on the tasks at hand. So the Gantt chart that we will see on the next slide, It's more complete, more detail, but I found that your project team sometimes struggle to be twisted. They don't have the time to go into the more detailed task, so that's perfect to get everyone focused. Okay, So the software development here needs to finish on the second of February. And that gives everyone a bit of a goal and a clear view on what needs to be achieved. 48. Schedule Types part 2 Gantt Charts and attachments: So the other type of schedule that you will come across definitely is a Gantt chart. Again, chart is the gold standard. As opposed for project management scheduling. It allows for complex dependencies and even you can even do your budgeting with it. So this is what it looks like. So on the left-hand side, you have a project tasks. And on the right-hand side, it's a bit of a more visual way. Going back to the left-hand side, you would list your tasks. Here. You can group them. For instance, you could have the planning grouping and you would have all the tasks for planning execution, all the tasks for execution. You would have the effort they discussed earlier. You could put the duration instead of the effort. You can put resource names. You can now allocate a resource for this task and for that task. And the software will let you know if a resource is double booked, if he is allocated to more than 100 per cent. So it's quite a good tool for the project manager. We look at the pros, yeah, it's great for complex project. Calculates the completion dates based on dependency, so you don't have to do to do it all manually. It all. I told calculated. On the downside, it can look a bit overwhelming as I mentioned in the previous slide. So which business in project teams? So if you want to use it as a tool for communication, I would strongly recommend to keep it to one or two pages because I've just represented one page. Here are more or less here I have one project on one page, but sometimes there would be 1011 pages. So It's a bit unreasonable to ask a project team member to review it. And for you it's a bit becomes a bit of a maintenance nightmare. So the tool that we use for this type of schedule is Microsoft tool called, called MS Project and Microsoft Project. But you can also do it with Microsoft Excel and actually show you an example in the resources, talking of resources, here we are. So I have included one of these Gantt chart in a resource done with Microsoft Project. So obviously if you don't have Microsoft Project, you won't be able to access it. So for that reason, I've also put it in PDF format. And I've also provided an example of a Gantt chart that has been done with Excel. So if you go into Excel, if you want to create a new workbook and you go into the templates and you scan for gunshot, you will be able to find some Gantt charts are templates that you can use. So if you're really keen that if you really want to play around with whiskey and charts, but obviously Excel doesn't have the same calculation advantageous that Microsoft project would have. So that's it for project scheduling. Next, let's go into planning for our project cost. 49. Costing during Planning: Introduction: Welcome back to the course. So I'm sure you've guessed it. During planning, we get more detailed, Whereas which was the case for scope as it was at careful schedule. Now, for budget, we get more and more detailed. We need to have everything ready. As we'll see. As you've probably, the more your progress in the project, the more difficult it is to change a budget. So we do a complete budget. During initiation, the high-level coast was estimated, and we call it the order of magnitude. Now we are in planning and it's time to go more granular. So we do a bottom-up estimate, which means that we add all the smaller component that we would have found when we did our schedule and our design. So we've caused attached to each one of those components. So we do this after the schedule is completed because some costs will be dependent on the length of the project. For instance, the project management cost. And it's usually more expensive if the project is longer because it's based on the model of days that the project manager will be involved in, wants this project cost are finalized. We refer to these budget as our baseline. And during the life of the project, we will be always referring back to that baseline to check if we are still within the budget boundaries. 50. Costing: fixed Price and Time and Material: So when we get started to putting our costing together, one way to go about it is to make it clearer, is we would split our costs into time and material and fixed price. So just to give a quick explanation on each one of those determined materials, of course, calculated is depending on how long the project or the task is going to take. So we're not really sure. It could take ten days, protect 20 days. So we would have to make an estimate on how long it would take to finish the task. But if it takes longer, it will be more expensive. If you take less time, it will be cheaper. So we don't really know, so we say, it depends. This is why in this example here, you would have the contractors. You bring someone in for one day. If you finish the task in four days is 4 thousand, but if he finishes it in six days, it would be 6%. Obviously, you will have some type of estimate, but it's not really fixed. The price the same as we discussed for the project management cost. It depends on how long the project is. Functional managers, it could depend on how involved they get. If the projects get more complex, maybe they would get more involved. And you could require some adult consulting as well. In the middle of the project, you might realize you need something and then you would bring him or her as Stan and material and also the purchase. You don't truly know. Sometimes then vents how procurement activities will take place. It's totally been vague here, but you would always come up with some types of estimates. The fixed price, it's more concrete, you know exactly how much you want to have to pay upfront. If we look at examples, your hardware, purchase it. So that's one that we know. We will be needing. We know in advance how much it would cost. You can have a fixed price on traveling if you know you need to travel for the project, you can calculate it exactly in advance. You can have also some type of service that it's fixed price. Someone comes to fix something. It doesn't matter if it takes them five days or ten days, you would pay only the same price. And for, for some goods as well. Here are only examples. It's just some examples of that put here, but obviously, you could have a bigger list. So maybe just to wrap up with a very quick example is that let's say you go on holidays. Before you go on holidays, you know, some costs will be fixed. You would have paid for your hotel, say you would have paid for your flight. That's fixed price, but some will be more time and material. If you want to call it this way. For instance, the middle, you don't know exactly how much will be spending at every meal. You don't know how much petrol exactly you will spend, but you would have an ID, you would make an estimate. You would say, well, $50 a day for males, for instance, it's still considered a time and material because you don't know exactly in advance, but you would have some type of estimates to give you an ID. So this is obviously the cost to keep an eye on. If you look in a vendor client environment. The common material is obviously preferred when you are the vendor. Because if it takes you longer than you get paid enough for you, you're covered in a way. On the other hand, the fixed price would be the one preferred by the client because they know exactly how much they're going to pay in advance. 51. Costing: FP and T&M Example: So to reiterate a bit regarding this fixed price and time and material concepts and wanted to give you an example. So if those concepts are clear to you, feel free to skip that video. But I always like to provide an example. So if we go back to the fence, building a fence example, you could have potentially two options or combination of the two. Let's go for option one. Option one, you decide to go fixed price, or the contractor gives you a fixed price. So the total budget is clear. Price for all the wood nails and post sold fixed, and the labor also is fixed. It will not cost you more than this. So as a client, you know that the price will not go above this amount. I mean, there's always exceptions, but this is the idea of the fixed prices. In theory, you stick to these price. So other contractor, you could potentially have a greater margin if you if, if this was a bit of an estimate and you have a dream run and then you have a little bit of money left. But if, if it takes you much longer than you could potentially lose money. So you could go also with option two. And it was a time in material. So either they could tell you, Look, I have no idea, but our labor is $50 per hour. But usually, as I was mentioning, that would give you an estimated we see all around $2 thousand, but it will be time and material anyway. So rest assured that you will not pay more than, than than is required. So as a client, you are unsure how much it will cost in the end, exactly. That you have more confidence that you will pay the right price. As a contractor, you do not have the same pressure to potentially losing money. So if there is a problem in a job takes longer than still pay on an hourly rate. So this is how the two options that you could potentially have, there's a third option. You could decide to have some fixed price and some time and material. Like for instance, the contractor could tell you, we give you all the materials, fixed price, So that's $750. You know how much exactly you're going to pay for those. But we will have the labor as as time and materials will give you $50 payout. For that, we will charge you 5% or pay off. 52. Budget example: Welcome back to the course. Let's have a look at a project budget example. So what I have here is a bit of an example of a simple project where you would have and project management coordinator and a developer and tester. There's obviously it would be more resource involved, but I just wanted to give you a very simple example. And I wanted to split it between talent material and also in a fixed price, you would have the time and material. You would have the estimate of how long the project is. You would have the 50 days here. So that would be the length of the projects multiply by the rate. And you would have a cost here for time and material. As I was saying, this is just an estimate. If the project takes longer than your cost will increase here. Terminal arteriole. Again, if the estimate is wrong, then this would could increase if it was underestimated. All those resources, the number of days. And now you have the red per day and that gives you a total cost. That cost hopefully will not change. But if they are, if they are, if they are events that goes into way of the project, the eye issues than these, these costs could change. In a fixed price scenario, then that's your more convenient although the purchaser, so it's going to cost you $20 thousand. You know IT security testing is going to cost you $10 thousand and you're doing. So this is how you would put your budget together. You would add the older talent material and you would add all the fixed price. And that would give you the tutorial estimation, the danger zone term and my tail. So that's the one that you need to keep an eye on. Could potentially be an opportunity if things sticks, take less time than plan. But that's your starting point. 53. Schedule based budget: That's another example that I wanted to give. I've put this, put it under the advanced category. Feel free to skip it. It's called the scheduled based budget. Instead of giving your finance department a bulk cost at the end of the project, you actually split it on a monthly basis. This would look something like this. Let's assume we have time and material here. You would have every mumps here. You would have an estimate for you need to build. You have 75 units and you have an estimate of $1 thousand per unit that you build. Obviously being time and material, this is just an estimate, so it could cost more to build ten units. So how does this work? You would tell your finance department or whoever your management you would see at the end of January, I would have spent 10 thousand and February 21st of March 31st and etc, till the 75 thousand total or the end of the project. Sometimes the finance department only free up the money on a monthly basis, so that will be handy for them. Instead of handing you the 75 thousand, they will just drip feed you every month. So here we have production is planned to increase for April. Therefore, your total cost for a pro will increase and then you would reflect that on your monthly payment there. And that's the overall project budget. So the difference with this budget example and the one I provided earlier is that we provide a monthly estimate of an Agile project will spend. And as you'll see, it's quite convenient when we are tracking our budget. So in other words, end of February, you can check how much you have spent and compare with this amount. And I will be more accurate instead of only comparing with the final cost of the project at the end. During execution, we will review how we can track these types of budget. 54. Budget contingency: To finish on costing a quick slide on contingency. Sometimes when you put your budget together, you can put for some contingency funds to be added to your budget. You might be okay to do it, but they don't always allow you to do it. So they are mainly two types of contingency. Money that you could get. One is a risk contingency. The other one is estimate contingency. In your overall budget, you would have your base budget plus the risk contingency and plus the estimate contingency. So the only thing is you cannot access those under certain conditions. The contingency for risk, you will only be allowed to access it if the risk realize and you had some action that actually cost money to fix the risk. And the contingency for estimate. So that's more contingency if you are not very confident with your estimate, let's say you are, it's a technical project and your technical team has provided you with an estimate, but they are not extremely confident with it because it's a a bit of a greenfield for them. They have never done it before. So you could go and say, Well, this is my budget, but I would like to have ten per cent of top because of these component here that is a little bit scary and we are not fully, fully confident. I think sometimes too good way just to reduce your budget instead of going the full monty and having these two together as your baseline, you say, Well, I will go for this budget, but just as a heads up, there is some contingency here that might need. So that's it for the contingency. 55. Quality planning introduction: So welcome to the quality part of the course. I'm sure you've been waiting for that one. So it's my job to make sure that I don't lose you at this point in the course. When I was learning project management, as soon as we got into the quality part, I was just anyway, but I think that quality doesn't have to be so excruciating. It's just a matter of for the project manager to ensure that the quality is being applied. You have the responsibility of quality on your own processes. And you have the responsibility to ensure that the quality is applied on the overall project. Doesn't mean that you have to measure things yourself and check things yourself, but you have to make sure that whoever is the best placed to do these measurements is actually doing them. Let's have a look at quality in a little bit more detail now. So most of the time steams know where they have to do to ensure the quality. But the challenge is that quality can be quite subjective. Therefore, we need some way to measure if what we are doing, all what would be delivering is of quality. So we need to ensure that the final product and also the delivery process will be of quality. So the replanning we state what we will do to ensure that the quality across the project, what actions we will be taking. The outcome can go either inequality plan, as mentioned, or we can go just as a section in the project management plan, which is, which is more common. 56. Quality planning - How do we do it?: Planning for quality, how will we achieve it? So the way I see there are two key components involved in planning. We need to ensure that the process and the controls are in place. Even as a project manager, I need to ensure that are following my own process. So that will ensure quality to the project. And at the end, hopefully, that can reflect back to the quality of the final product. In order to check if processing controls are in place, we could ask ourselves the following questions. You could ask ourselves which processor and contract will be using. So we could list those. And that will make everyone feel more confident that the quality will be applied. And we could also ask ourselves, are there sufficient or do we need to set up additional processes and controls? So for instance, we could say the change control process will be used to avoid scope creep. Make sure that we don't go out of scope. And if we want to go out of scope, we'll just have the change control process to keep us in track. And we could say the budget will be reviewed monthly. We could say we would review all the process at one mom's into the project to ensure that they are still valid and they are efficient. So that's we don't want to reinvent the wheel here. We have usually usual procedures that we, we want to use, but it's always good to have a fresh look at those and to confirm they are, they are still valid. And other parts of the planning for qualities is testing the final product. So it's good to have all your processing controls in place, but to find that product needs to be of quality as well. That's this. This is what the stakeholders want at the end of the day. So what questions do you ask yourself? How will we test the final product? So usually you would have test team and they know what they have to do. But it's always good to save those different type of strategy. Or if external teams will be involved for this. What are the criteria that will satisfy us? The final product is of good quality. So at the end of the project, we need a way to say, Yes, this is exactly the final product that the client or the business or whoever wants. So we need to have some type of acceptance criteria. So here we stipulate which test team will take place. What do we do if the test failed? Probably process if testing is not good, we send that back to the build team analog so we can specify all that. So here in our project management plan, we could have the testing will be outsourced to company X, Y Zed. We could say x, y, z will provide a weekly report on testing. We could say they will provide us with a test plan that we will be reviewing. And here we could say that the acceptance criteria would be that all the testing has been completed as anomaly, minor issues lift. So once you released all that everything, everybody, Sorry, Is more confident that you will have a quality product towards the end. So having a quality product doesn't mean that having a solid product, but it also means that it's actually the product that the business wanted. So the final word on quality, if you like, is, in theory, the project manager role in quality is not to perform quality. So you don't go to the team and tell them, you know, show me show me what you have done so I can check it. You would be more asking questions. What have you done to ensure quality? Have you followed your, your testing processes and the likes? So if you see something by all means go sometimes to website development that has actually happened to me. Check the work that guys have done, and realized that I saw a few defects already. So I just I just mentioned it to them. So if there's something really obvious, glaring yes, of course do it, especially if you have time. But if not, you just need to ensure that the quality is being applied. 57. Quality: Types of Testing: Here on this slide, I have listed all the, not, not all the men types of testing that you could come across. Just wanted to, just to give you an ID that way to test the final product. They are sometimes a lot of testing that, that can occur. So this way, if you, if you hear about those words, terminology, you should be familiar with them. Starting from the top. And I've put some green stars here to highlight the key ones. You would hear the system integration testing or seat. So that's usually done for software development projects. And you could develop a software, it could work perfectly, but if he doesn't integrate well with other internal, external software components, then that's not good. So an example, if you test a new accounting software, if you don't take risks properly with legacy applications, don't get too concerned with this app. I've put it under the advanced slide, it suddenly for your information at this stage. Now the next type of testing, which is more comment, I suppose it's called either the, the functional testing, the system testing, or sometimes just called testing. So it's usually done by a specialist team, a test analyst, and they check the financial product works properly before turning over to the business. But they have a test scripts. And it's, it's more formal testing that what a business would do at the end. They are a team of specialists. In other words, it's very good to have that done before the business comes into play. As an example, you know, the, the test team could check the navigation of a website is working as designed. And we could check all the links one-by-one are working properly. So all the functionality will be working. So the user acceptance testing. So that's when the final testing takes place before we can release most of the time. So the business would come in. We would give them for the scenario for website, for instance, we will give them access to our test environment. And they would come with a test scripts and they will check if the software is they actually what they required. They check that the product meets the expectations and requirements before we go in implementation. So an example, there could check if the coracoid process be calculated on the products sold on the website. Next? I mean, those are slightly different, but I put them all into the categories. More resilience, stress testing, performance testing, or check the final product is robust enough under extreme condition. For the website, you would simulate a lot of people using the website. For the breach example here, you would bring, I don't know if you've seen these 50 huge trucks on the breed to ensure the British solely Jennifer, I don't know what would happen if if it's not if it's not enough. So I think they probably know what they're doing. So that's another type of testing that you could have. There's also the product verification testing called PVT or production testing or post implementation testing. Let's take the example of the website that no, Let's say you go live on one day, in the morning when you're alive, their users come in as a, as an external user and it will check that the website is working properly. The system is live, but still the final testing before everyone, everyone gets in. So take the implementation of a software live, works as it did in test. Website going live but on your users can access it. So that's the scenario was just referring to. So as mentioned, there's plenty of type of testing that you could come across. This unit testing. So this is usually done by software developers and when they do they on their own testing prior to giving it to the specialists teams. So you might hear that, but it's more or less with developers doing their own work. You could also have penetration or pen testing, which is quite popular at the moment. It's to ensure that the website cannot be hacked. So it stimulates cyber attack and check if that, no, we cannot be attacked, that the website is safe. Release testing also you might hear that. So that's more to find our testing that we do before software is released. If you'd been overwhelmed. Just bear in mind is to you, we'll just call them the testing itself. And a user acceptance testing. 58. Quality: Example of Testing for Soft development projects: I just wanted to show you as well what it would look like on the software development project that you will have. So here you have all the planning. Here you have the execution, so which is a design development. And then you would have all the testing. And I just wanted to show you where that would fit in. The first testing that you would have would be here. So the team would be doing this development at this stage. And then after you would have a system testing. And after these you would have the business. They would come and do their user acceptance testing, which is here. This one is nine. Here you'd have the penetration testing. Usually it's being done at the very end when there's no more software chance being done. So they went to check that the website is safe. And then just before going live, you will do the post-implementation testing, PVT or production testing. So you see that quality in the project can occur several times. Not only you have your recurring process and control quality to be put in place, but also you have some key milestone here around each type of testing. 59. Optional: Project Management Plan Example: So next we have an example of the project management plan. But I have put it as optional. But it's a good way for you to understand what happens in planning and how the final document looks like. So having put all the word for word, what you should have in a project management plan. It's actually quite succinct in a way, but I'll walk you through every part of the project management plan so you really understand what this document is all about. Let's have a look. Welcome back to the course. Project planning comes to an end. So we'll have a look at the project management plan example. I'll have that on two slides. It's more or less to review all that we've seen during that phase. And just to give you a bit of an idea as we did at the end of initiation. So the project is building a breach. So we would have a scope statement bit similar that when we had an initiation, but we'll go into more detail. I just have he built a bridge. The job includes all elements of the breach, but exclude or traffic lights. We'll be done separately. So you would go into more granular and you would have more bullet points in his in his high level scope. But obviously, at the end of planning, you would also have all the business requirements. So the business requirements don't come from this document here. They will be provided separately. So you can refer to like Indiana sculpted men saying the scope is all the business requirements that we have produced separately for this project to be a success we want to breach to be ready by the 1st of February 2022 or the second of January, 2022. If you read the dates the other way, with little disruption to traffic around the building size. So this is clear as to be done at that date. And we don't want any disruption to the project team. Know where they have to do the project approach. The work would be probably a source, would be hiring a company XYZ to do the work, consult. Pm will be coordinating the work testing would be outsourced to company ABC. So that's giving you the high level approach or on the how will be progressing with this, with this project and these document, if you give it to executive, they would know how we will be doing it. This is useful for them. If we have some constraints, we can release them as well. The construction should not interrupt the current traffic. That was also mentioned in a scope statement. The breach must be operational by 1st of February. So that's also part of the critique cosx x photos. So if you have any constraint, things that are preventing you from going as smoothly as you would like to. You. You would list them here. Deliverables, that breach. But we go a little bit more granular will also want as part of a deliverable or the operational restrictions, we want a maintenance schedule to use after the bridge is completed and you can list them all. You can go crazy. You, if you are business, you want to list here of all that the project would give you at the end of the project schedule. You can insert the milestone view here. What I will do is I would put the milestone view here. And depending on where you work, sometime they are interested in a more detailed schedule so you could attach your Gantt chart. Towards the end. This will have to be signed by the business. So the business wants some confidence that we'll be meeting your timeframes. And the best way to provide them with confidence is to give them a breakdown or the tasks and by which data will be completed. Continuing on the project management plan, the budget. So here you have a very detailed budget, so you can provide them the detailed budget, but in this document, you can give a summary. You can see the total cost search and across two years and then you refer to the budget breakdown and timeframes. If if it's a budget based on the schedule, the quality, you can make some statement here, or you can refer to the company's quality management plan. But you could say things like the company ABC, which is the company we have hired to do the testing. Ebc will be entering the breach, would be tested to best practices and it will present a testing strategy for approval. You could also say that ABC will be testing to give us the green light for when the breach is ready to go? That's clear. When the businesses out there today. Okay. That's okay. It looks like this has been taken care of stakeholder list. So you could, you could duplicate the stakeholders that you had in your project charter or you could be more granular if there are any changes and the rocks. You could list them here. Communication. Communication and you would have your communication plan. Or if not, then you can just let them know when the project of this would be will be sent. You can mention if there's a steering committee and you can also mentioned that the outsourced company will be providing their weekly report to your project manager. And the project manager will escalate anything significant issues. Risk register. So we already have a risk register from the initiation phase. So we can refer to the risk register here and we can say, well, we have noted another risk, the contingency Monet for this risk, as I've been a bit included in the budget, if that's the case. So you can provide a few sentences here on the risk. And then you can mention any other planning document, procurement, communication, human resource, anything that can. The way I see this document is anything that can make the person will be signing this document. Feel better. You listed listed here, existing procedure would be followed nor the planning document would be required at this stage, but the project. So if required. So that's it for the example of the project management plan, you can have a look in resources. There is also a draft template just to show you that the project management plan can stay very simple. Obviously, depending on where you work, if you want to go into project management, you will not come up with your own template. Usually they would have their own templates and you would have to use them. But it's always good to have an example of some ways. So there you go. 60. Phase 2: Planning wrap up: So that's it. We finished with project planning. So to summarize, project planning, be as thorough as possible to avoid any surprises during the execution of the project. Initiation, we needed to have the big chunks, right? In planning, we need to be very granular, very meticulous. We need to make sure we have everything planned very thoroughly. So the more thorough we are, in theory, the easier the execution will be. Nls surprises we will have, we will always have surprised and execution, but the idea is to reduce the amount of surprises that we could have, ensure that the requirements are as precise as can be. So that's something that sometimes it's difficult to get control of because the requirements come from the business, in a way, comes from outside the project team. This is why you have to be a bit thorough with us. And when they give you a requirements, you check with your, with your team. Is that good enough for us to get started in execution? So get everything sign off before you get into the next phase. The requirements, you project management plan, make sure it's signed off by, by everyone. So there's often pushes to start execution as soon as possible. So use your, your common sense there. You don't want to sound too and all and say, No, I'm not going to start execution until everything has been signed off and I don't think you will come across as someone very flexible if you do that. But use common sense and stress that sign offs are really critical. So now there's only one thing left, more or less is to do the work and do the execution. But before we do, don't forget the quiz. And I'll see you at the other side of this. 61. Phase 3: Execution section overview: Welcome to face free execution section overview. So as usual, we will start off by providing the purpose of the execution phase and also the project manager role in that phase. Then we will discuss the following activities. Scheduled management, scope management, issue management. We will have a closer look on meetings reporting. We will also have a look at cost tracking and a very specific component of cost tracking, which is n value, which I have flagged as advanced because it's not always present in project management. But I suppose it's something good to know. And finally, we will wrap up on this phase and there is a quiz as well. 62. Execution intro: Welcome back to the course. So now planning is completed. Planning is completely that means we have our sign offs and our plan on our project management plan on the requirements from the various documents that we have. So it means that now we are okay to proceed to the execution of the project based on the plan that we have provided and that has been accepted. Now let's have a look in more detail. What we need to do during the execution. Planning has been done. This phase is more about monitoring, controlling, fixing issues, and reporting progress. Let's have a look at the key components. Of course, we'll have to do some coordination. So that depends on the maturity of the teams. Sometimes it can be very easy as it seems I used to work together so they coordinate between themselves. But sometimes a more hands-on approach has to be done for the project manager. Reporting, very important to report. So that has to be done usually on a weekly basis, but sometimes a fortnightly. So it depends on where you work. If you project manager, quality control, making sure this is taking place, have a look at your processes. Communication. Make sure that everybody, all the stakeholders are being communicated to on how the project is going. If there are some purchase, reviewing the risks as well. This has to occur. Managing issues. Of course, we'll talk a bit about that later on. Monitoring the schedule and cost. So that's one of the key component. We will review the three key components in just a minute. And review. Project management is not just about rolling tasks. If you feel that the trend is going in the wrong direction or if there's some tragedy, strategic changes, this is where you really make a difference and say, Well, hang on a minute. Is it still worth doing this? And then at the end of all that, you do some implementation. So this is just a snapshot of the key component. It all depends on the type of project, the amount of work you will have. But this is a good summary. But if you are still daunted by this list, Let's review the three key components that I believe you'll be involved in as a project manager. The first one is reporting non-negotiable. This has two. Apparently there's only one thing you do during the week is to do your reporting. If you don't report on time, your management team, business, project or fees, or whoever would think that you are not on top of your project. So this is my advice. Reporting goes first. It's temp. Say, well if I do reporting, I don't have time to do anything else and I hear a lot of that from project managers, but put that aside, trust me, reporting goes first. Second thing is managing issues. You might have a lot of issues, you might have less issues or you might have issues. I don't need management because the team is mature and they know how to fix it. And they, and they have processes in place and the likes, and they are quite self-sufficient. But sometimes this is where you spend most of your time. And finally, haven't listed coordination but monitoring the schedule and the cost. It's something that obviously you have to do. So you have some, either you use your Gantt chart or I prefer to have a more granular task list so I can really tick them off as I progress. But those HR activities should keep you busy during execution. 63. PM role in the Execution phase: Let's review quickly, the role of the project manager in execution will be a bit of a repeat of the previous slide, and this is what I want to go through this one quickly. We saw the key components of execution, the project manager being involved in all components, then that will be very easy to guess. What is the role of the project manager and execution. But before we start, I just wanted to mention that sometimes execution is a bit of a smoother ride for project managers when there's no issues and the likes. But regardless, this is the phase of the project where the project manager is the most in view. So when anything that happens on the project closely or from a distance, the project manager will always be the first of contact. Actually, if something happens in your node, first of contact, point of contact area is they could mean that there is something wrong in the project. You should really be the first of contact. Having said that, let's go for the role. Coordinate work between teams, we saw that monitor the schedule and budget are layered. Let people know this slippage, report on it and fix it. Ensure quality is performed, communicate project progress, facilitate purchases, manage issues, and monitor risks. So as you can see, it's more or less a repeat of what we had before, but we've reviewed that and now we can move on to Schedule, which is, as mentioned, that one of the three key activities we are monitoring the schedule. 64. Scheduling in the Execution phase: introduction: Let's review schedule tracking as part of project execution. During planning, we created a schedule with detailed milestones and dependencies and the likes. Now during execution, we just a matter of entering those tasks are done. And we just monitor the progress and we address any slippage even better if you can anticipate slippage and prevent them that there'll be very appreciated by your management team. So how do we do this? So I'd like just to mention quickly part three of this course. Part three of this course, we'll discuss briefly the difference between two methodology which has waterfall and a jar. So for this part here I want to stress that this is more addressing the waterfall component. Waterfall is more or less when you do just everything once you only have one planning implementation and likes. If you are working in an agile environment, you have a different looking schedule. So how do we track this? We use usually a software called MS Project. And again, chart that we've discussed in planning. 65. Critical path definition: On this slide we have the Gantt chart representation. The one I mentioned in planning using the MS Project software. I just wanted to mention get us started the critical path and what it is. So critical path is the part of the schedule which infant impacted the world schedule will be impacted. So that's the way I like to see it. In other words, it is quite intuitive really that you know, that if a task is delayed, they will protect, will be delayed. And we would call, we would see that that task is on a critical path. Let's review these quickly. So what we had was we were doing the design, the design, which was these were doing the development. Which was this an after we were doing the testing. So if the design is delayed, as this task here comes after and is dependent on the design, then this task will be delayed. And if this task is delayed, then the war project will be delayed. Nfo the implementation date will be delayed. In other words, we say this task is on a critical path. This task is on the critical path and likes. Now if there is a task that is not on the critical path, for instance, this one here that is not under critical path because there's plenty of time for these tasks to complete. Let's say the training documentation, the writer of the training documentation is not here or is she is sick or the likes, and he or she is not gonna be able to start until that point in time here this tenders work without delay the project. Nope. Because there's plenty of time in more or less has until the 26th of July two to complete this task, which is the beginning of the next task because it is a training requires is training documentation. So I have just one task here that he's not an a critical path. All the other task, if they are delayed, that would delay the implementation. And this one if the, if, if delayed will not delay the implementation. So that's what a critical path is. 66. Schedule monitoring : Let's continue. We scheduled monitoring. So I just wanted to show you how in theory, the project manager can check if a project is ahead of schedule or is behind schedule. So I have a screenshot here of MS. Project gunshot on the right-hand side and our tasks on the left and side. So we have the task names, we have the duration, and we have the percentage complete and all these updates to start and finish dates. In order to check if we are on schedule or not. We are having a look at the task here and the percentage completion here. So for each task, we allocate a percentage completion. So here we have this task here a 100% complete and the percent complete. So all the planning tasks are complete. So that means the planning is completed. If you go and execution, we have the design document 100% complete to it's done. And development tasks. Those two tasks are 20 per cent complete. All the others have not started yet. On the right-hand side on again, to help part of the screenshot, we can check if we are ahead of schedule using today's date. So today's date is this vertical red line here. This inside line that is within the bar shows us the completion of that bar. So here a 100 per cent. So you see your line fruit that all these other alone through here, only 20 per cent of the task has been completed. So the inside line is 20 per cent of the bar. So it takes you here only when in theory, if you will, in time, it should take you just write bang here. If you were ahead of schedule, this inside line should be in the future. So we would meet that. So that would mean that we're ahead of time. So obviously that's all very theoretical. And those tasks being largely would have on this MS Project or on the spreadsheet, or somewhere. The developer would have all these task listed and the rocks so you could have a more granular and precise way to track, but the ID is on his high level, if possible, to have a percentage completion. So if the team can, they will tell you, Well, we are around 20% completed, twenty-five percent completed. You will put that in and that would give you a very quick visual way to check if you're on time or not. So here you would be concerned because we've seen that those tasks on a critical path. In other words, if they are late or project implementation will be behind. This task here is not on a critical path, so it hasn't started, should have started while back. But you're not concerned because it's not on a critical path. So you see you have all this time here to have it completed. That just a brief overview of scheduled monitoring, how he's done. This way. Keep this simple. Let's hit one or two pages if you can do the rest outside. So this schedule nevertheless is very important because it is a central point if you want for the project to have a view on where we add, it's good for yourself, but it's also good for the project team members, for the management team, for the steering committee is it gives them a level of comfort knowing that there is the central scheduling in place. 67. Scope Management : Welcome back to the course. Let's review scope management. So during planning, we have precisely defined our scope. We have business requirements. We have a business requirement document or requirement matrix, or whatever process we used. Now our job during execution it to make sure that we stick to those requirements, when to make sure that we do not perform activities that are out of scope. Because that would most certainly increase project costs and timeframes. So we have to apply a little bit of project quality control is a process that we use and that is called Tange control for that purpose. So this is an I will discuss this in part to the interview part of part two. It is a question that you will probably hear when you go and interview says Project Manager. It will be around along the lines. What do you do if the business come to you with additional requirements? Here's the answer. So let's have a look a bit more closely at what the change control. 68. Change control: So if there is a change in the requirement, regardless of where it comes from and the reason for it. The project team really needs to assess the impact. And potentially what we call a change request needs to be raised and that we need to get approval from the steering committee so I can walk you through the process here. This process is really dependent on the company itself, but I will show you the, the vanilla version if you like. The starting point. We have an additional requirement from the business for whatever reason. The first question we ask ourselves is, is a requirement small enough? Sometime it's just so small that the business forgot to mention that they needed this. But we discussed with the team and SEO, this is fine. We just can, we can just slip it in and we can just do it. So then what you do, you just you just include the requirement in the scope. This additional requirement is very small and your credit is in scope. But what I have here is a shortcut is not always accepted by your management, by your project of v. So now they, this is small, I don't care that they didn't want it. They're going to keep coming with small requirement or the y's. So that depends a lot on where you work. It's good. I think it's a good way for as a project manager is to show that you're flexible. Yes, it's a small requirement, but we can slip it in so it's good for your relationship with a business. But at the same time, if your management doesn't want to, then you just as opposed to undo it. So what happens if the requirement is not small? So the business, we ask them to raise a change request for approval to the change request is a document, Word document, or whatever that the business will write to formally say, yes, we need this new requirement to be assessed. Sometime it's not the business. Sometime it's a project manager actually doing it on behalf of the business, but that's not really important at this stage. So in order to do this, yes, so this is a change request that we will see how we can fill it in simply. At the next slide. That is smallest document where you input some information on the change that you want. There is the comity somewhere. It could be sometime just a steering committee or sometime it's just an agreed approver somewhere that have a look at a distance request and it will have the impact on schedule some time the impact on cost is going to require more money. And the rocks are they have a look and either approve or decline it. Let's have a look what happens when they approve it. So when our prove it, there are two things that occur. The first thing is we include this requirement in scope. So yes, we will be doing this requirement. What do we do is we change our budget. Let's say there was more money attached to these requirements, but it has been approved. So now we're good. We can we can put more money in our budget and we can rebase line to schedule if that applies as well. So we're squeaky clean. We had a baseline that we do, a new baseline because everything has been approved. Now, if the change request is it's turned on. You just log the change requests somewhere. You just file it, and then you don't do anything on this new requirements are that this has been turned down. So that's a quick overview of what happens. A new requirement could be found for many reasons the business realized I forgot something or as part of the more precise work they realize there is another piece of work that needs to be done. So if it's small and if you can include included in a scope and just keep working on it. But if it's not more than you have to have a keep keep keep a track of it, and have a bit of a log. So you put a change request. If it's approved, you do the change. Your baseline if it's not, stays out of scope. So this is what a change request looks like. Simplification. Again, this is all you need. Unfortunately, you have to use templates that you are, you are being provided with. So you don't always have to you don't always have it so simple. But this is the minimum I would recommend. So you have an ID so that that allows you to keep track of it. You have the name of the requester, you have a description. And let's go with this example of the bridge. Again. The business say that the bridge needs to have an additional set of lights or the self and trends. And you have reference to more precise requirements or which type of light where they wanted to exactly and the likes. So this is linking your back to the requirements. As a project manager, you have to assess the impact of this change. So that's your role. The business is not going to do it for you. So you have to check, especially if there is a change in the schedule and the budget, if you have the resources for it, etc. So here in this example, additional costs and extended time parameters below. In fact, schedule the project. We need another free mumps that either the chat, you need another $20 thousand. So when that goes for approval, they know how much extra money they would have and I know that it will take longer to deliver. So when I assess yes or no for the change request, they know all the they have all the elements in hand to make that decision. It's always good to have options. Now here the options are a bit black and white. It's like either you do it, either you don't. So the option one is do not make the change and postpone the additional required after project implementation. That can be an option. Don't do it at all. Be another option. Or you accept the new delivery date and you accept the expenditure. Then you say the change approved and obviously which option you have chosen, and then it's signed off. So it's always good as project manager is to try and find several options here. Now here they could have. Here they said suggestion is to have done after the project implementation instead of saying, we don't do it at all. But sometime they are civil, civil options. You can find ways to implement this change. We may be at a lesser cost or faster. If you can bring in maybe more resources, all the rights to do the work. So be lateral thinking for option is always good. 69. Issue Management: part 1 Introduction: Welcome back to the course issue management, the fun part. So there is kind of a process to manage issues which is more or less logging the issue into an issue register and manage it to resolution. But there is no really a magic formula on how really to fix those issues. When the issue is logged, it's more or less up to the project manager to work with the teams, the various teams to fix the issue. So there's a lot of brainstorming, lateral thinking, and influencing that needs to occur for the issue to be resolved. I will show you in a couple of slides the most common type of issue that we have. But before we do that, let's have a look at this tool that we have the issue register. 70. Issue Management part 2: Issue Register: Once again, this is AC register in its simplest of forms. I don't believe that needs to be more complicated than this. And once I've introduced you to all the columns, I can, I will show you the two most important ones. So first of all, it is sometimes called Issue log. I think I mentioned that already, or issue register. There is a template in the resources if you're interested, which is more or less a carbon copy of this. We have the issue number so we can reference to eat quickly that raised. We have a description as precise as possible and we have the impact. What is in this impact of the issue on the project? And usually it's a delay in implementation due date. When is this issue due to be resolved so that it doesn't impact the project? Sometime we have an issue. Yes. But either the task is not on the critical path or is not immediate concern, we need to know by when it will become a concern. So this isn't due date for resolution for the issue. The owner very important. We need to allocate someone to resolve this issue. And if at all possible, not the project manager. Why not the project manager? Because the project manager role is to coordinate all activities of the issues and to manage the issue to resolution. But most of the time, the issue itself cannot be fixed, quote unquote, by the project manager. It comes from a technical team, has come from it, from another team. If it's a resource not available, then it's a resource manager needs to fix the issue. So the project manager needs to avoid being being the owner of the issue. The status open or closed. The latest update. It's good to put dates on these dead this occurred and after you put all the subsequent date and related risk number, when a risk occurs, it becomes an issue. So for instance, this here as non applicable. So this issue here doesn't come from it, from a risk. But this was highlighted as a risk initially, and now the risk has occurred and therefore it, it'll issue. So this is just a couple of example. The first of John, securities testing resource won't be available until the 1st of FEB. The issue is it will dip, delay implementation as it takes testing is on a critical path. The test procedure is required by 15 foot job, so we can still fix it without it impacting the project implementation date. We have managed to get an owner here. So the test manager, in his situation, the manager of the testing results, is the one that is owning this issue. And provide an update here the test managers have been T2 attempting, sorry, to free up resources. We provide an update by the end of the week. That's good. So again, one foot body to provide ongoing maintenance of the website. Still not selected. Guys, we want you during the risk. Now the risk has occurred. So measure because we cannot go live with ongoing maintenance. The due date selection is required by the completed by the 29th of John are the ones that will delay the implementation. We managed to find that an owner, Natalie, procurement manager, need to solve this one out. It's not just a matter of putting the order and wait for her here to fix the issue. Obviously, we need to be managed actively by the project manager. And naturally provided an update is looking good, company has been earmark and you deletions is in progress or do the 14th of John? Let's have a look at the two key colon. I'm sure you've guessed them already. So the owner, they need to be reminded that they are issued owners for this and that they have a date, the due date, which is good most important column. Once you have an issue and you manage to have an owner and your due date, then things are under control. They are not you're not cleft here as the owner to try and chase everybody up to fix the issue has been clearly established that there is an owner and there is a due date. 71. Common Issues: So let's review the most common issue, which tasks are behind schedule? So this is more or less an outcome. There's potentially an infinite number of causes for these, but I just wanted to highlight the key one and see if we can address them. So common cause for a delay and how to reduce the likelihood. If we take them one by one. The first really cause is to know the estimate is wrong. So we try and use contingency as much as possible. When we provide our estimates. N2, we pushed the teams to be as detailed as possible, so that would allow them to uncover any subtasks that might not have thought of. So you are more likely to find at that point early all the tasks that are required. But that would, oh, shoot. Okay. Already in planning during execution, it's too late. The resource not available. That's quite common in when resources are shared. So how to reduce his avoid shared resource? I mean, have you alarm bells as soon as someone tells you where you can have this resource, but he or she is being shared with another project or another business as usual team. Avoid if you can put that as a risk. I have a shared resource. Also, a way to reduce the likelihood is looking resource early and formerly. Get it in writing that you can have that resource from that date, from that point in time. Another cause for delay is the resource nodes killed for the job. That's quite tricky sometimes, but at the end of the day that will impact the project. So try and discreetly tech credential. Hi, this resourced resource worked on these type of activities before. And as soon as you notice it during execution, it as early as possible. And put that down as a, as a big risk. The cost for delay additional work found. So that's what happens when the detail estimate and the distal breakdown of the task on your occurs during execution. When that occurs during planning week still good because we can attempt to change the timeframes and the budget, but during execution it's too late. So there are two causes that's for the that was addressing. The first one, detailed estimating planning that would reduce the likelihood. Same as this one. But additional work phone is detailed scope. Tedmed would address this issue as well. Well, it would reduce the likelihood as well. In a scope in planning, we mentioned the need to be as detailed as possible, and this is where they would pay dividends. And other scenario. Your design team or your development team would say, Well, I realize I need to do this as well. I was discussing with a business and they say that needs to be included. And then you're difficult situation that if you don't really include these, the business will not be happy. And so therefore, you need to be able to push them towards change control, towards raising your tent request. But in order to do that, you need to demonstrate to them that what they are asking you now is out of scope and well-stated out of scope in a document that you have provided them? Of course, not in those words, but you would be tactful and you would just highlight that to them. To more things. Use contingency if you can. During planning. I mentioned that the estimates could change and try and get some controversy, money or hero, if you notice the resource is not killed. Use that as an excuse to get a contingency. Whenever you can, obviously, preferably in planning. But even if you do that in execution, it's good because it allows you to anticipate potential Dealy and try and fix it before the delay is impacting the overall project. Brainstorm the team on the risks that could cause delays. At the end of your meetings, Guys, did you think about any risks that could cause delays? And some resource will be more than happy to come with tons of them. Take note of them and just try and sort out the potential dangerous ones. So this is it for issue management. Managing issues is really where you can show off your skills, show off your lateral thinking. Good things happening, anticipate problems and when there is an issue, stay on it until resolution. Let's go to the next part. 72. Project Meetings: introduction and types: Welcome back to the course. Project meetings. Not always very popular with team members, but very useful for project manager. So in part two, I will show you how I feel you can get the most out of these meetings. But for this part here right now, I will show you more how it is done, the more traditional way of managing meetings. So project meetings can be used to coordinate work, influencing the project team and escalate issues, or get assistance from the management team. So coordinate work and influence and motivate the project team. That will be more for your project team meetings. And this will be more for the steering committee if you attend them or management team meetings. So as I mentioned already, There's two types of meetings. The project team meetings that you have with your team. This is the one that you are cheering. You invite all your team members and your chair the meeting, and you have the agenda, and you will have minutes. And Steering Committee or any management executive meetings, these ones, you don't really share them. Usually you are just a participant to this meeting. So let's take them one by one. So productive meetings. The traditional way what you do is you, the project manager gets updates from team members who go around the table and what did you do this week? Yes, that sounds good. Then you take all this into account. After the meeting, you you go to your schedule and you update your schedule and your issue register if if if if any, and you write your minutes and you're sending it across. So it's also the opportunity for team members to discuss issues that don't always meet outside team meetings. So that's a good opportunity for them to discuss. You can of course, coordinate the work. When one finished the task, the other one can start in two to three days. So you have to coordinate this. And this is where you do your issue resolution. The steering committee, the project manager, is there to provide updates, not to get updates anymore, to provide high level updates. And I will show you on the next slide the difference between the two types of meeting, the difference of detail that you need to give for each one of those. So now this is your opportunity to escalate major issues. I don't like putting big issues on the table during meetings, so I would usually go and have one-on-one chat or phone call to give everyone a heads up. And if possible, have an issue resolution strategy ahead before I drop a big issue on the table. So that's something that I think is very important to do. So this is usually not true by the project manager, is chaired by the steering committee member or the business owner or the likes. So two types of meetings. One way when you have your outcome, what you want to get from the team. And another one when you are a participant and where you're the chair would have her outcome that she wants from the meeting. So this is your outcome and this is the steering committee outcome that is to bear in mind. 73. Meetings and Reports: What to discuss: Welcome back. So we'll review reports a bit later on. But this slide here works for both for meetings and reports. Trying to highlight the difference of content that you would have in meetings and reports depending on which type of projects. So I mentioned this to key meetings that you would attend. This one that you will chair the productive meeting, and these are the one that will be a participant. Obviously, there are tons of other meetings that you will be involved with, usually ad hoc. But this is really the two key ones. If I take the component here one-by-one, we can trick to which meeting it applies. For. For instance, this one here, high-level update, status, update on key milestones. So that can be done for both types. Doesn't hurt to give your team and a bit on a high level schedule. And for the steering committee? Yes. The more detailed update on progress in the past week, what's happening next week? What have you done? Exactly? How did you go? Yes, that goes for the project team meeting. The steering committee. Don't need to know that. Finances, budget update, how we're doing. It's really not needed for the project team meeting. Unless you have some resource that are really switched on with budget and the Reich's. But they don't, they don't come across very often. So I would say, don't bother them with this. And sometime it's quite confidential. They're not even aware of the of the budget of the project steering committee yes. Management meeting? Yes. That's a key thing they want from you at this stage. Small technical issues. Small project team, yes. Steering committee, management team know they don't want to know about it. They wouldn't know if they have to worry about them or not. So don't mention them. Qi project issues, yes, the one that will potentially delay the project, increase the cost. And the one that they can influence? Yes. Give, give give these to both predicting meetings so they can work on them. Steering committee potentially so that they can escalate and assist. Action items? Yes. Project team meeting? Yes. They need to know they need to know what they have to do for the next meeting. The impact if they don't do it. Action items. Well, as mentioned, the project manager is not really chairing this one, but it's very important for you to overlook if you have any action items that you needed to do to report back to the steering committee. And if you manage to do that not to obviously, you can also give them action items during the steering committee. So if you're very subtle with that, that's something that you can do. 74. Meeting minutes and template: Welcome back to the course. We've had our meetings always good form to send meeting minutes if only bullet points. But usually you'll be provided with a template. So you can send the outcome of the meeting after the meeting to order meeting attendees. What I'd do is initially, if the template is too complex, always try to remove some headings. Always like to simplify because the more headings you have, the more parts you have in your meeting minutes, the more open you are too. More or less putting incorrect information and that's provide you a lot of overhead as well. So I've provided you here a list of things that could go into a meeting, minutes, the attendees, and apologies. That's quite important. If someone was not present when we when we made a decision or someone never turns up it's good to have them on this list. Decision mentoring meeting, that's very important. So we all agreed on something. It has to be logged somewhere. A quick summary of discussion. So we don't want this person say this and then this other person replied this. I don't think we do this anymore, It's not very useful. What is the plan for the following period? That's something that we can do to get everyone focused. The action items that also important. If we come across a discussion point that needs resolution, then we locate in your action items. What are the key milestones ahead? Once again, to get everybody focused if there's any concerns raised. So concern is not yet an issue, but it's good to put that down. First of all, they make them feel better because I know it's on a piece of paper. And then for you It's a bit of a heads-up. Something could turn into an issue. You can also go crazy and put all the change requests. One of the outstanding are approved, so that gives a team the heads-up. If there is some work that is going to come their way that was not originally included. The key issues, it's always good form to review all the key issues. So you can double this with the issue register review. Or you can just list the key issues here so you can get your updates on issues by the issue owners. The key risks, I like to have the key risks as well doesn't hurt and that's open to discussion. They can have a look at the risks and say, well. 75. Project Reporting: Introduction and what to include : Welcome back to the course. Let's review project reporting. So we saw that sometimes with meeting's minutes, you can tweak them to your own preferences. With project reporting, it's more unlikely that you will be able to just create your own reports. You might be lucky and you can do it. But most of the time you have the ARM templates. Having said that, even if you use their own templates, you can still tell her what's within each heading. And this is where I suppose you need to tell her the report to the audience. I mentioned that already delivered a report on time would make you look very efficient. Even if there's problems on the project. If you deliver it on time, it's always good practice. The number or n type of reports will vary depending on where the project manager works. Most of the time, you would have the usual weekly reports that's more detailed for your management team and the likes. And but sometime the project office would put all the project manager's reports in one bucket for the monthly report. Sometime you would have to report to your steering committee maybe on a monthly basis. How many reports you'll have to deal with if you're a project manager is really an unknown quantity. Having said that, I just wanted to also to show you what can be included in a report. Just to reiterate, the reporting content can be tailored to the audience, but not really the heading. So here what I have is an overall rack status that we will see on the next slide. What it is. The rack set has four components. We'll see on the next slide. We'll have an executive summary. This is more for monthly or executive type of reporting. The project status. Obviously, how you're tracking against the schedule. You will have the progress down in the previous period. That's usually something that they like, is to show that you've actually done something. What is the plan for the following period? So the period could be a week or month depending on type of report, least your achievements. So even if this is not something that they ask, I think it's good to give achievement, to give the project team will boost the key milestone the head, just to have everyone focused and a change request. That's something that you could have in a report, think it's always good to keep track of those are ones that are being outstanding that were approved or the one declined. The checkup date as well. Tracking against the budget baseline executive, that's something that'll be very interested in. The key issues. Also, if you need to escalate to a project reports are usually for someone higher up diet and yourself. So it's always good to put them here, the high-level ones, so you can get help for escalation. Same with the risks. 76. RAG Status introduction: Welcome back to project execution reporting. When we saw the project reports, I mentioned rag. So sometimes in your project reporting you need to provide a rack status. So what is a rag? So RAG stands for red, amber, and green. It's color-coded way for you to provide a high level visual on how you project. He's going. Sometime executives have to go through 2030 projects and AC this project, green, green, green, green, green. I can just add on even have to review them. This one MBA, start to have a look at and read. So you probably guessed that green is good and red is not good. So there's no clear standard. And sometimes when you come in a company, they already have their own standards. They will say green means that you have this. Amber means that you have that. Red means something else. So green obviously is always well. Ember. The way I see it is some issue on the horizon that could impact the project. So things are starting to fall apart more or less. Read the project is currently being impacted. Another way to look at it is how much do you want your executive to pay attention to your project right now? Use it for yourself. If my, if my project has some issues and I'm on top of them, they don't really need to know. So I just put the project green. If I know I'm going to need their help and I don't want to tell them at the last minute, I give them a bit of a heads-up and I put it Ember. And if I need help, right now, I put it red. Let's have a look. Project prayer components can be visually tract using the rag. Components that can be tracked. So I said this is a way to track your overall project status. But you can also use it for your scheduled. For instance, you can say my project is going okay, Green, that the schedule is starting to have a bit of MBA to it. The budget also could be the same. You could be on drag. Your project would be green value, your budget is starting to fall apart. Anything else can ever ask status, communication, sculpt stakeholders, happiness, resourcing, risks, issues. Some companies also have a bit of a formula. If you have two of those Ember, then the project should be Ember. For instance. If you have one read, the project has to be at least if you have all greens and one red, it's still okay. So as you can see, many ways to use it, but it can be a very powerful communication tool. So now let's move on to the next part. 77. RAG Status with tolerance: To finish off with this rack status, sometimes there is a mechanical way for you to calculate your rack status. And this is an instance where your project had been provided with levels of tolerance are on schedule and cost. So they would have, for instance, the first-level of three rent is ten per cent. The second level of tolerance is minus 20 per cent. So for a schedule, it's, it's if your project is ten month, so you would have is still okay if we deliver between 1011 month or 1012 months for the second level of tolerance. So if we take this example for a budget, you have the budget of $100 thousand. If you realize halfway through your project that the cost to complete, which is a budget estimate at completion ESC, is between ninety thousand, one hundred and ten thousand. You are good. It is green. If on the other hand, you realize that your budget at the end of the project will be smaller than 90 thousand or bigger than 110 thousand, then you should put yourself and be honest. Unless it's even worse and your estimate will be under 80 thousand or above 110 thousand. So that sounds a bit crazy. But most of the time, even if you're doing very well and you will be ending your project well below your budget allowance. Then you have to report it as red and you have to explain, Why didn't you spend more money? They think the thinking behind this is that why are we so far off the mark? Why do did we just overestimate? And they're like, so they want to really understand why. But some don't, don't bother with this and just interested if we are going over budget or not. That's it. That wraps it up for the rack status. 78. Project Report example: To finish on project reporting as I did with project meeting minutes, I have included in the resources a template of a report that you could have. So feel free to go and have a look. In these instances are just feel the few bits and pieces so you can check out how it looks in real life. So you have the rack satis here, you have the project summary, you have the key reporting stakeholders involved here. You're right, a quick status completed this week, planned for next week. You provide a schedule of debt. So this is a milestone view. And you can even have the rack status, not only for the overall schedule for each task. I like this visual way. So you can, It's very quick for them to see your status for a scheduled green. Green, green. Oh, there's a red here. Let's have a look where it is as opposed to just words. But it'll tell you the same. So here green, green, green, OK, and server, more expensive than estimate. So they can have a quick look. Key issues are to one that we want them to have a look at. And usually it froze onto escalation. So that's pretty much it. 79. Budget tracking: intro and Actuals Definition: Let's continue this budget tracking. So this is obviously a very important part of project execution. On a regular basis, we need to review what has been spent and calculate what is left to be done. So we can add the two and check if at the end of the project will be, will be good. So first, how do we calculate what has been spent? So what has been spent? We call that Actually let you know. So I'll be talking about actual from now. During planning, we split our costs into two categories. So there was time and material was fixed price. So how do we track our tools on those? So for time and materials, you will need to use a term sheets and the hourly rates if you have human resources working on it. And you would calculate the total amount of hours and Holly red, so that will give you the human resource cost. You would add invoices for contractors as well. So that could be also for time and material or there could be a fixed price invoice. So there will be no surprise. There. Usually would work with the finance department and they would have located a project called your project. So you should be able to go to them and ask them how much have I spent so far. So they would extract actually all the actual from the code for your project. So that's just some ways that you can keep track of what has been spent. 80. Tracking budget month by month: Let's continue this project execution tracking budget. So during planning, you've put a project, project together. With this example here, it could be something like 100 days at this daily rate that gives you a budget. 50 days at these red gives you a budget. Fixed price, 20 laptops give you the, so your budget at the beginning of the project is 300 thousand. So I wanted to introduce you to a couple of terms if you like. So estimate to complete is your estimate at 1 in time of our much money you need to complete the project. The actual rows, we just talk about those. That's actually the money spent overall until now. And the estimated completion will be your estimate. Now, taking into account the actual goals and estimate to complete. So that's your estimate at completion. That means how much do you think you would spend at the end of the project? That will become clearer with some examples. And that's a variation. So that's, that will tell you if you overspent or understand. So estimate at completion is to be compared with a project budget. Is the magic formula. Estimate to complete plus actually estimate at completion. So beginning of the project, no problem. 300 thousand to complete, estimate at completion friend and fuzzer. So now let's move to January. Step one. We are reassessed. All are sending work. So that will be our estimate to complete. We asked the guys, How much time do you need to finish your task? And they said, I only need 90 days. Only 90 days. And it looks like these guy then started. So they said this the December month, 50 days. So that gives you an estimate to complete 176 pheasants. Step two, we go in our time sheets, we go into our contents, finance person, we check our invoices and we gather only $18 thousand. So we're estimated over cost. So we add this to this. What's left to be done? And what we spend in that gives us this amount here, 294 thousand. So initially we told our steering committee it will cost for ended for them to complete. The project would cost us 400 thousand and now it's only 294 thousand. So we are at the moment $6 thousand head. If we were taking only this value, it'd be, it'd be very difficult for us to assess. If we're gonna be meeting these $300 thousand or nodes that we need to both. Okay, let's move forward to February. Sam, we just ask the guys how long, how long. But oops, this guy realize there's something more to do. And it's the estimates that stemmed. So the overall estimate to complete is 276. It's the same. It's just a coincidence. The actual is 35 thousand. The estimate at completion is now friend and inhale even further. And so this causes problems. And now we are overspent. But it looks like in March we had a better run. These are sending 60 days, 60 days, and 60 days. So that gives us 192 thousand. So the actual 78 thousand estimator competition, 270 thousand. So the variation from the budget is 31st until we're back on track. So it's a bit of a roller coaster. It was more to show you that if you track without these two components, then it's, it's, it's, it's meaningless in a way. It's good to have both of those as factors for you to take into account. So this is it, this is how we track budget. It's important to do it in a structural way on a monthly basis. Sometimes we're being asked to do it on weekly basis, but I suppose your best judgment to start with, and then depending on those standards that are where you work. So this is it for tracking budget. 81. Earned Value simple example: Welcome back. Project execution, budget tracking. Now I have an advanced categories. So as mentioned, if you're a bit overwhelmed at this stage, feel free to skip this. We will be discussing earned value. Value is part of all the project management methodologies out there. It's a tool that you can use to track how is your project going. It's often explained in a very convoluted way. And this is where I really wanted to bring it down to its simplest form with two examples. The first one extremely simple, the second one a little bit more realistic. So let's do this. So n value, It's the value of what you have already done. It's a value of the work that the project has already produced. So when we had a look at the tracking previously, what we did was we calculated the estimate to complete and we added actual center gave us the estimated completion. So that's, that was in a way looking forward. What is left to be done in value? It's more looking back. How have we been doing. But at the end of the day that should give you the same result. Example. We have five houses to paint. This is our project. We have a contractor. We pay him $10 thousand per week. Any or she tells us is one week to paint one house. So you have five hours just to paint. Your total estimate is 50 thousand. So what's important here? It sets an estimate one week to paint a house. You said. Eoc tells you, well, it takes me one week dependent house and it's five hours to pen. So your estimate will be 50 thousand. It seems quite straightforward. You come back three weeks later and you have chores actually 30 thousand because you are paying this company 10 thousand per week. So after three weeks, you are spent 30 thousand. But when you check, you notice only two houses have been pinned, and the third one has not even started. So the earned value, which is the value of what we have built so far, is 20 thousand. Because we were expecting 10 thousand expense. They house, but now we only have two houses painted. And we already paid 31st and so it's not looking good moving forward. So you go, so this is your first example. 82. Earned value formula and Example : Let's continue with earned value and value. Value of what we have built so far. If it's greater than the actual rules, then you're under budget. But as we've seen an example just before with a house is to be pent. When your n value is smaller than your actual stain, your over-budget. You didn't get what what you've paid for in a way. So as mentioned, I wanted to give you another maybe more real-life example. Let's say we have a project to build 75 units without going into more detail. So very simple project. You just need 75 units of something built. So it's time and material. You are told it cost you to build one unit. So building material, this is where you will be doing your your budget is a scheduled base budget, orangey color. And you have plan to build 1010151515. And then the end, you should have your 75 units. So here we track the arterioles, the money spent at the end of each month. So here we have in the genres, spent 8 thousand, we have been 10 thousand weapons, 70 thousand. So at the end of March, we are spent 25 thousand. So here what we do is we calculate our earned value. We go and check how many units have actually been built. At the end of January, we see that you need to have been built already. Alarm bells because we're supposed to have ten and February and other ten, end of March, only five. Okay. So let's have a look. So end of March situation. We're planning to have built 30. We have only build 23. And the end of budget figure that we have now gives a project team false sense of security. So you'll be checking your budget. You would say, we cool, after three months, I only spend twenty-five thousand dollars and that's ahead of my schedule budget. I'm doing very well. But you have only spent 24 units. So I think the n value is a good tool so you don't get too comfortable. So obviously this is a simple example in a way that it's very easy to, to check the n value because you just referring to units. So it's very easy to count how many units have been done. But I suppose, and this is where the theory sometimes doesn't work in practice, it's not always as easy to check the value of something. When you work with several teams and they all have their own products to create an axis, it's not always easy to check how much they have produced. So let's have a closer look On nice what that would look like on a chart. So this is how you could represent it. Bearing in mind, you're still in the advanced section here. So we are in March here. Some example that we have spent only 25 thousand when we should have. The planned value was 30 thousand. But we've only created this. So if you do that, put that on a chart with this being the planned value, the actual cost being there, and n-value being there. So the value in green, this is what you have done end of March. In blue, actual cost and the planned value, it's there. So that's really a good visual way. If this goes high and this doesn't go as high, that means that you are spending more than, than what you have produced. Quickly. Final example on earned value. This time, just, it's just to show you that the actual cost could be above the planned value. So it's more or less the same project. But the actual change. So plan you need to be build three. We have only build 23. But this time you are chores even above the planned value. So you in even worse situation than before. So that's just to show you the actual cost here is above the planned value. So right from the start, you know there's something wrong. So let's hit F4 and value on budget. So it's quite a very good tool if you can do it. I think it's a very good way to look back and check how, how efficient the teammates. 83. Earned value for Scheduling: We have finished with budget and we also have finished rescheduling bird before we finished execution that I wanted to show you that the n value can also be used to assess the schedule performance. I don't know if you've noticed that on the previous slides. So when we reviewed the budget, we compare the earned value with actuals to see if we are doing well with our budget. So if the p-value is less than what we have spent, we know we are behind budget that will be having an overspent. We can do the same rescheduling, but this time, instead of comparing the n value, is actually, we compare the value with the planned value. If the value is greater than the planned value, we have built more than what was planned to build by this point in time, we are ahead of schedule and the other way around. So let's have a look at the example. I think it will make it clearer. So for budget, we calculate, we compare the actuals and the earned value. So here the actors was bigger, the end value. So when you were not doing well with whispered yet, if we want to use these tools for schedule tracking, we compare this time the n value is a planned value. So the n value here is smaller than the planned value, so we are behind schedule. So it's quite an intuitive tool, maybe a fancy terminology to do something that we could do otherwise quite intuitively. But it's always a good tool, as I was mentioning earlier, to know. 84. Phase 3: Execution - wrap up: Welcome to project execution wrap-up. So we've completed our execution. As part of the execution, we still have the implementation. So that obviously depends on what type of projects you're working on. It could be just flipping a switch and doing some post implementation testing or something that will require a fool and implementation that we take place over a weekend or the likes. So they are just too many scenario here to list them all, but that's the final step of execution. And the next step will be closing the project. So the execution is the most intuitive of all phases. This is where your lateral thinking really constant most. This is where sometimes there's no rules, there's no processes to follow and you just have to fix issues using your best judgment and your communication skills and all the tools that you can think of. So the key component of this phase are the schedule, the cost, issue management, and the reporting. So when implementation is done, they usually a type of what is called the warranty period where the project team is still involved if there's any challenges with the project, just to make sure that the project team doesn't run away as soon as it's implemented. So there could be some issues and the project team will be the best killed to fix them. So there's a warranty period of several weeks, or sometimes it can go to several months. But in parallel, you can start the last phase which is closing. But before we do, forget the quiz, and I'll see you at the other side of this. 85. Phase 4: Closing - section overview: Welcome to face for closing section of a view. In this section, we will not go through the usual role of the project manager because the project manager's role is quite succinct and also I believe quite obvious in Israel. In this phase, we will discuss the purpose of the closing phase and the closure of completed activities. The handle, there are four incomplete activities. And we will also review the lessons learned documentation, and we will also review celebrations at the end of the project. So let's get right into it. 86. Closure purpose: Welcome to the final phase of the project, project closure. Towards the end of execution, we implement our product, our deliverables. Sometimes, as mentioned earlier, we have a warranty period where the project team needs to support what we have delivered as they have the knowledge at this stage. But feeling that we're just focusing on closing all activities. So the purpose of this phase is to tidy up Morris key components we close or endothelial activities. So what it means is we don't want to leave any loose ends. There's also listened, learned. What have we learned? What have, what have we learned that we will always do it better next time. The key outcome that we're seeking is closure sine of one. Once the executive, the steering committee, or whoever signs off on a document, then we can formally say the project is closed. But sometime it doesn't happen quickly at all. So as mentioned, sometime after implementation or resources disappear, they are busy working on the project. So for the project manager is sometimes a bit of a challenge to keep everyone involved. The business don't get much value out of project closure. And now they have, they have their product. So everybody is a little bit focusing already on other topics. And sometime even the Project Manager doesn't get a chance to tidying things properly. So I will be presenting here that the theoretical closure of a project. 87. Project Closure activities part 1: I mentioned that the closing of a project is very much project dependent in a way that depending on type of project you're working on, the closing and handover activities could be quite different. But I just wanted to give you an example to give you an idea of on a typical project, but the type of work you would have to do during the closure of a project. So a split them into two categories. So those activities here, we just closing and those activities here we handing them over to business as usual teams usually example of closing activities. So we have several categories of try and put that into categories. So Reports, resources, and listened learned. So reports. The key document here is a project closure document. So that's a project manager role to put this document together. So that will encompass all the closure activities. So part of this document would have the stakeholders sign off. Then we file an archive or the reports. Obviously sometime this on project folder is where you just fight all these the resources. So there could be various type of resources. That could be obviously you release all the resources, human resources, they're still working on the project. But that also could be that you are paying for the final invoices and your published a final budget figures and your work with your finance team and to make sure that the numbers are all in sync. The final category of how these lists and learn, listen learned. We'll have a look at this on the next slide, but it's more or less when the whole team discuss what has been going okay during the meeting and what could have gone better. And then at the end of this meeting or sometime you just have a document that is being created with at this meeting. But usually it's better to have a meeting and then you create this document. So the head of the activities on the other hand, that's something that we need to ensure that we are handing over to the appropriate team. So I've put that into two categories. Deliverables and the risk and issues. Deliverables. When we handle the final product or breach our website, our software, we need to make sure that the stakeholders are happy with it, that the business owner is okay. So we need some, some type of sign off implementation, sign-off, maybe project closure document. They need to say that they are fully satisfied and that we can move on. Operations documentation to the business as usual, team say you build a bridge. I need to give all the operations. You have all the knowledge. So you need to give all the operations documentation to the team will be maintaining this breach website, the same thing, software, this emptying. So training is some type of trend or trainer. So you need to ensure that as the knowledge is within the team, that you hand over that knowledge to training team or to individuals. And also your project team needs to still be involved if, if there is a warranty. So they probably shared with another project. You might not want to have the resource still working full-time on your projects as just to support. So they probably need to be shared with other projects at each stage. And risk and issues. So in our issue logo or issue register, we might have some issues that we didn't get a chance to complete. The obviously we're not critical because we still managed to implement the project or the project. So they're probably minor issues. But the team that will be running with a product business, does your team need to be aware of those and they need to fix them. So we need to give them this issue register somehow. And risk is not as obvious, but sometime they are some risks that are still valid at the end of the project. Usually in a risk register, you have risks that would come and cause issues to the project, but sometime they are just risk that are there and that ongoing and therefore, it'd be useful to give them to the businesses use your team does not mandatory so that just a nice-to-have might not apply all the time. So I wanted to highlight how we could simplify this. We don't want to be the project manager who left without being of invoices. So I highlight this one as an important activity. We wouldn't have a sign off. This is key. We have delivered something. We were really hard. We want to make sure that at the end of the day, stakeholders are happy with it and we have provided them with what they wanted. And then you know that you've done your job as a project manager. That is also required, otherwise that's going to come back and haunt you in a way so you need to make sure that the product can be supported moving forward. This seems to be quite critical document, but it does not always get done. Obviously, if you go through all the methodology standards in their lives that tell you this is absolutely mandatory that has to happen. But with my 20 plus years experience, it does not happen that often. You are implemented good on you go to work on another project. So this is why I would really recommend that you have these three things done. On the next slide. We'll have a look at those two here. 88. Project Closure activities part 2: PIR : Post-implementation review. So I'm really strongly recommending to other post-implementation review. In order to get some Listen, Learn. It's a meeting that you would have with all stakeholders. Sometimes you don't want to have managers of resources because you want to resources to be able to talk freely. But it's good to other meeting because you get, you get everybody. Everybody's point of view. Other words, if you'd rather listen, learn on your own, then that might be a little bit biased. I would strongly recommend to have a meeting. So during the meeting, you review what has done, right? What could have been done better? What was not planned for me to highlight it so that someone in the company doing a similar project, they can take that into account in their planning. So there's different structure that you can apply to this meeting. You can say, okay, what was done right in planning, for instance, what was done, Ryan in execution? How worst tasting done? Or how was a stakeholder communication done? You can ask the stakeholders at the end or the steering committee, how how was as a project manager, how was my communication to you? That's something that can be done. And then you can after the meeting, you go back, you write all the orderly simpler and then you have a document. Recognition and celebration should be planned in advance. So that adds an extra motivation to the team. So it needs to be planned. It shows that you value what they're doing. You value their work. And it's not an afterthought that UK the project went well. It's all implemented. Let's go and celebrate. But it shows that that was in your plan all the time. That is project closure. 89. Phase 4: Closure wrap up: So this is it wrapping up the project closure. So closing a project is a low-risk phase for the project manager. The project has been implemented. And if it has been implemented without any challenges, then everybody can relax. So if you can manage to put a project closure document together and indeed have all the older lose and being addressed. All that you've done to really close the project. I think that would be very beneficial for you as a project manager, you would leave the project on a very good note, on the very positive note. That would leave a trace if you want of professionalism. So I strongly recommend it if you can. If you want a desktop, a project closure documents somewhere. As usual, simplifies and then circulated. And if nobody respond, if nobody approve, if nobody provide feedback, then so be it. But at least you've done your part. Now we do for a wrap-up of part one next. But before we do, don't forget the quiz. 90. Part 1 Recap - overview of phase activities : Welcome back to the course. Let's wrap up part one. Let's review the key concepts, tools, activities that we have seen, and how they can overlap over each phase. So I wanted to show you that processes are recurring during the project life cycle. So we don't see them just in one phase most of the time. You see them across all phases. So we'll be starting with the concept that haven't really discussed so far. I didn't want to muddy the water. I didn't want to overload you with information as we're going through the phases to remind you each time, don't forget the approvals, make sure this is sign off and relax. I mean, I think it has been evidenced in a way, but now is the time to see really what are the key approvals that we move across the lifecycle of the project. So you can see a provider sign your sign-off, smaller, less. So during initiation, It's easy if we have a project charter. So this is signed off and that means that the business is good to go. So this is done by the business. But we've seen also that the initiation doesn't always occur very formally. So in this case, some type of generic approval would be provided by the business or by the project office? It's not always the project charter. During planning. There are two documents that are very important and that needs to be signed off. The first one is a project management plan, which is a document produced by the project manager. And that includes all the planning information that's usually signed off by the steering committee or by the business directly. And requirements as well, if applies. So if we're on a project that has requirements, then none needs to be sign-off and this document is to be as thorough as possible. So during execution there's a few documents that need to be signed off. So we don't always have this scenario where we mentioned the ring executes shown. You don't always have design testing and likes, but you need some approval to go live. So that's definitely a given. When applies to design needs to be signed off to the business needs to say, Yep, this is is designed agrees with my requirements. Testing. Also before the business test, we need to make sure that they are happy with the way we have tested prior to their testing. Also, the business need to do their testing and they need to sign off on the overall tasty. So closing we do a project closure document, if we're lucky, and that will be signed off by the business or steering committee and I will definitely close the business that we've seen that doesn't always occur. And maybe just a final approval from the business or steering committee saying, yes, we good with what you've delivered now, you can wrap things up and move on to the next project. So that's the one for approval that I wanted to mention initially. The others, we've seen them. The budget during initiation, an order of magnitude is sufficient, which is another level budget. In planning, we go more detailed. We go as detailed as we can to avoid any surprises during execution. Then the written during execution we just monitor weekly, monthly for very long project. You don't want to do these weekly. But sometime you not given a choice of how often you do that? And doing closing if applies some time you return the unused funds and sometime you didn't get the funds to start with, so you don't have anything to return. The schedule very similar to budget high-level implementation deaths during initiation. You don't have the detailed gan chart at this stage. But here you do get your organ chart more granular and you get it signed off as well as part of the project management plan. During execution of beauty that will keep you busy. If, even if it's not an MS Project Scheduler, just all the tasks or the monitoring of everything that is progressing needs to be progressing within the agreed time frames. There enclosing There's not much action in one's really interested when exactly the project will be closing. Usually the sign-off of the good life is more or less the end of it. But there are exceptions, of course, risks. During initiation, we create the risk register in which we highlight the key risks to make sure the business know what they're getting themselves into. And then if we can, we get more friends for the risk mitigation. We found some risk that they'll be good to have some money to take action if the risk occurs. During planning. Same thing we updated. If we find new risks. Still last chance to get more money. During execution, we monitor and we updated regularly. I like to have monthly meetings on risks and the ring closing. Same as budget. We return the risk contingency firms, if not used. Issues during initiation, unless you're very unlucky, there's no issues, but if they are creature is log little bit earlier, try to address them as early as possible or at least plan for them to be at rest. During planning, you definitely create your HLog and you start addressing issues. So the issue resolution exercise is starting there. During execution, you continue to update your issue log and monitor you issue Look, you have owners and timeframes and you keep a close eye on on those. And then you address issues if you can. There enclosing you would have two types of issues in your issue register. You'd have the closed one that you don't need to worry about anymore. And you would have the open ones with the open ones will have to decide. What do I do with those. You discuss with the project team, you discuss with a BAU and you decide for each issue. Can we close it because the project is finished or do we hand them over to the BAU team? Scope? During initiation, we don't show the key component. The big champs are listed. They need to be clearly stated, although they are big, trends need to be clearly stated. Make sure that we don't forget any big chunks that will cost us later on. During planning back to the granular as possible. Requirements and scope to ensure no misunderstanding during execution. We have our overall scope, but we also have our detailed requirements from the business. And if we feel the requirements are not detailed enough, we have to go back to them. Otherwise, we'll be managing scope during the full execution. So during execution is only one thing to do. Either business, ask for a new requirement. We need to go through the change request process. Sometime we have a little bit of leeway if you like. We can decide if the change is small, then we can slip it through. But it depends on which environment you urine. During closing. What we do is we make sure that all original requirements documents are updated with change of scope. So here we created our requirements document at the end of planning that was sign-off. But on top of these original requirements, we might have some change request here. So we need to make sure that we update this document here with all the changes. So sometimes it's done on a case-by-case basis, but sometime it says over a rapid opinion. So if someone comes to the business as your team and say you had a project, what are the requirements of the project? Then you can show them the full the full document. And to finish the project manager paperwork. During initiation. There's just a project charter, the ring planning, This project management plane. So obviously these are all the paperwork around the project approach cost schedule. The project management plan should be a summary of all that has been decided and that will include cost schedule approach in their life. So during execution, there are two types of documents that the project manager needs to work on. Minutes and reports. The reports, bought it. And during closing. If you can put a project closure document together and listen to those document even better. So that's it. Another way to look at this table is if you want to refresh your memory during initiation, where it needs to be done. During planning, what needs to be done and you go down this list, execution and closing what needs to be done. Another point of note is that during initiation, paperwork for the project managers is called project charter. The rink planning is called project management plan. But you will see in part three when we review project management standards that they can have different names. So I believe those are the most common names. So that's why I've noted in this way. But you might come across, especially for prints two, which is a project management method, that they can have different, different names as well. Berkshire nor definitely they are part of initiation or planning. 91. PM adaptation for each phase: Welcome back to the course. We continue the part one recap. I just wanted to have a quick review on how the project manager can adapt to each phase. So during initiation, it is the point in time in a project where it is the easiest to make any schedule or better changes. It's not always possible. Some sometime there's an amount of money on a table and you have to take it. But it's much easier to do it now than to do it in the middle of the execution. So for that reason, the project manager needs to be able to anticipate. When you look at across the four phases in initiation, this is when I feel the project manager needs to have the foresight. It needs to be able to have a look with little information and little time that he has or she has. Planning the execution, the closing n, the benefits realization. The project manager needs to be able to have a look at all these future phases, the benefit, realization and check that or maybe a piece of paper with 20 lines sometimes as he tore to take care of all these components. You could argue benefits realization is not really your problem. It's a business. If they do it, they know what they're doing. But I think it's very good practice to challenge things if you can very tactfully. So here, foresight anticipate. And if you can, if you see something that is a miss, then try and change it. Try and get more money for it. Try and buy more time. Planning, thoroughness, the ring planning. We are meticulous. We look at everything in more detail. We want to make sure we don't discover things today. During planning, we only look at execution really, although initiation, you have to look at the all that during planning, we know where it needs to be done. We've had sign-off. So we need to focus on the execution phase. We need to make sure that this goes as smoothly as possible. So we are very thorough. During execution. We just have to do it. We need to be extremely productive. I've also mentioned this is where we need to use our lateral thinking the most sometime there's no processes to help us that we need to be proactive to anticipate and control. So there is really at this stage no need for extreme thoroughness. That's too late for it in a way that was during planning. Now let us just do it. During closing. Time for reflection really. Obviously you want to leave something behind you, so clean things up as much as possible that you've been working with a team for some time as mumps. And it's time to reflect on the quality of the work. And it's time to give kudos to people. Say well done, and thank you for the work. So as a project manager, you don't always get team members come to you and see you. Thank you for what you've done. But as a project manager, assisted really as my role to go and thank them for the hard work that they've done. And also if you had the post-implementation review, you can ensure that the next time a similar project is being done. They can learn they can learn from you from what you have done. So closing well, it's a good important T2 to leave a good impression of yourself. If you thank people and if you close cleanly. So then people maybe we'll, we'll ask you to do another project for them. So all those qualities of focused activities have to occur at each point of each phase, of course. But I think that this is where foresight is most needed, thoroughness, most needed productivity, it's most needed, reflection, most needed. Okay, we're almost there. 92. Part 1 - conclusion: Thank you very much for attending part one of this course. I hope you enjoyed it. I know that I really enjoyed doing it myself. Before we move on to part two, I wanted to leave you with a quote from Jack Dorsey that I think represent the philosophy of part one. As part of my commitment to this course, I wanted to try as much as possible and be practical and to simplify some project management components which sometimes are being shown as very complex. So when you simplify, it doesn't mean that you are not doing a good job, doesn't mean that you're living things aside. But simplification in a way it's very difficult because you have to bring things down to fewer elements, to fewer components. I was mentioning, for instance, to the project charter and the project management plan that can be extremely complex. You try and simplify them. If you have a simple report, simpler minutes, simple of everything, ensuring that the key stuff are in there, then you're more likely to have something of good-quality and easier to maintain. So here you go. Thank you. I see you in part two. 93. 155 PMP and Prince2 Introduction: So let's provide a quick overview of the two main project management methodologies. So they are called prints two and p and p. So when you look for a job and you look at the job description and job or job requirements. It's usually they'll usually if they are looking for certificates, it will usually be one of those two. So I think this is a key reason why it's good to know about those methodologies. So if we take them quickly one by one for a quick introduction, the PNP stands for project management professionals. You will often see that associated with Pembroke, which is a book of knowledge, which is more or less the manual, if you like, of PMP. And it's provided by a company called PMI, which is Project Management Institute. So it's based on the standards manuals. So it's referred more as a standard than the methodology, but in my book, you can perfectly use it as a stand-alone to run your project is a good to have a good reference manual on, on the role of tools that you can use to manage a project. The other methodology is prints two. It means projects in controlled environments, which had never heard of and it doesn't really mean much. But it's methodology as opposed to PMP. It has processed models, even provide you templates and the likes. And it has two levels of certificate. So if you wanna do it, you should really aim to the practitioner. Sometime. They asked you which type of certificate you have and it's good to have the practitioner. So those two exams, if you like, are quiet. They are very long to learn. And it takes time, it's very time consuming. And I suppose once you've learned whether or not you have a chance to use it, I don't find it that obvious. Sometime you go for interview and then systole you, you know, PMDD P or prints two. And when you go there you realize it has not much to do with what you've learned in, in PAP and, or prints to wherever you go, they have their own templates, they own process anyway. So this is a little bit the concern that I have is some some, you know, someone wanting to go into project management labia bit scared because they don't know the PMP to the detail and the likes. But you never have a job when you get in an essay, okay, Here we run projects as PMP. You can get started whenever they always have their own processes. They have it tailored if you like. You having a certificate is a good way for them to know that, you know about project management. You know about the theory, even if you don't fully applied, they is good for them. Give them a good level of confidence. Diverging flow to manage a project for both. Taps of methodology is extremely similar. As far as I know. They, they, they don't start with closing and do the execution and the beginning. So it's all very logical in a way. So you're not gonna have any big surprises with either of this methodology, but we'll see that, we'll see that in the next few slides. How how, how do my part one, if you like, relates to PMP and prints too. 94. 158 PMP vs course: So let's start with P and P. Let's have a look and see how PMP is different or similar to what we have seen in part one. So at the beginning of part one and at the end of part one, we introduced the idea of activities. So part one, the theory was met her on four main phases. And on top of that, one way to look at it is to see activities under each one of those phases. So those are activities and the reason why I went with activities, I liked the way that it's really concrete. And you can go sequentially from one to the other. And you understand that you have something to do. But obviously you, as you go through those activities, there are processes and they are rules, and there are things that you need to do. And you can have a look at the same thing several times as we've seen with scope and schedule. Now having said that, when you look at PNP, the philosophy is a little bit different, but the overall process is very similar. So that's p and p in a nutshell. So PNP has also four phases. Or project management method that I know of are these four phases. Initiating, planning, executing, and closing, that that will not change. We're seeing you don't usually start with closing and planning, so you always have the pre project phase, the planning phase executing, enclosing. So that's a, that's a similarity between the two methods, if you like. Now the difference is, I was going through processes and techniques if you like. As we went PMP, they have bundle all that into a monitoring and controlling, which is not a phase, which is more a set of rules, set of processes, if you like. So I wanted to learn from mine prints two and PMP certification process and inject that into this course. What I've found liter be Tejas with both BMP and prints two, is this. Because you learn this technique, all these rules. And you don't really know how they really relate in the lifecycle of the project and their eyes. So it's all a bit fluffy. This is why I like the idea of activities. So you start here right from the start. We got started with something concrete. That the very beginning we learn about the scope. And then we, we, we made our way through to closure. Now it has, we have quantum concepts like for instance, budget. We had discussed budget here. We discuss budget a little bit more here. We'll discuss it as we, as we want here. Then on my large cross-reference map that I have, you can see exactly four scope of our schedule for budget. What do you do in each one of those phases? To learn my method, it's more sequential. And for PNP, if you'd like, it's more academic. But in the end, sem, four phases and both methods will get you there. So sculpt Control, cost controls, skeletal performance, just to give you an idea of the type of things they would, they would put in there to monitor and control the overall project. So just to finish on PNP, in the course, I called the initiating document project charter. And I've called the planning document project management plan, and it's the width colon PNP. So I didn't I didn't call those document this way because this is the way they are called in PNP. But because I think from my experience, those are the most common names. So it's easy to transition if you like. If you want to learn PNP, you would be familiar already with those those names. But that's it for PNP. Next, let's have a look at prints too. 95. 160 Prince2 vs course: Welcome back. Prints two. Prints two, as you can see, has the same generic flow here, but the wording is a little bit different. And we can talk about the, the orange part later on. So if we focus just on the central spine here, if you like, what we call the initiation and initiating in PMP, it's now called setting up, but it has the same goal is just it's a pre project to check if we go ahead with the project and do some, some initial work on it, then initiating the project. And this is where it gets a little bit confusing, nice for them. Initiating a project is, is planning for my method and for PNP. So it's not here. They execution is called controlling a stage. And this is what is really specific with prints too, is that there are low for several stages to be part of a project. So obviously, you can also do that with other methods like this PNP. And you can entering execution as well here. But for them it's a little bit more standardized, if you like. It's that cater for it. So that's why it's easier for them to do some ajar. There's not a big difference with a prince to a jar and the red prints two because a gel is based on status, as we'll see. After closing a project is closing a project. So Sam spine, little confusion with name which starting up is initiation. Initiating is actually planning. Not hundred percent but very close. And then execution, they call it controlling a stage because they want the flexibility to have several stages. Now if we have a look at the other components. So directing the project, what is that? So it's more or less a project oversight. So it's more or less there Steering Committee. I mean, they don't call it Steering Committee, but they call it project board. It's more or less the project board as an overview of the project during all day. So he told the interaction, all the approvals, analytics. So we obviously have those as well in nice. But once again, as for PNP, They like to describe this process in a separate entity and they call it directing a project. Same thing. But the description of the event is done in a separate part of the course if you're sick, one thing to note on on the other processes that the prints two has is the approvals to proceed, which they call managing stage boundaries. It's also separated. The process for these is also separated. So IF2 here, because it's used at the end of each stage and at the end of each initiation. But they would have only intercourse. It would have only one component called Managing stage boundaries. Give you all the rules if you like, the heart and how we can go from one stage to the other. In my view, it's approval to proceed. So all the approvals older, older, going back and forth or how does it work? So it's very important for them because they are method is based on the stages. So they want to make sure that when you go from stage one to stage two, when you go from the execution stage to the closing stage, they want to make sure that everything is squeaky clean and you have all the processes in place. Finally, managing product delivery. That's also something very specific to Prince tube, but we do also in order that method, but we don't we don't formalize it in a separate part of the documentation, if you like. So it's more or less describing the handover of work between the PM and the project team. So they have a very formal way. In theory, once again, prints to shops, can't always do it this way, but in theory, they have a very formal way for the project manager, one to request work from the project teams and to, to receive back work from the project team. And it works the same with a project in, let's say you have a technical area. They would want some very specific way to get the work from, from the Project Manager here. So it works both ways, if you like. It's it's how the work is headed over between the PM and, uh, and, uh, various teams working on the project. Once again, this is done implicitly in all other methods. So it's interesting. So if we have a look here, for instance, I just wanted to really mentioned a soda. The point of confusion, if you like, that. The starting up, they call that the project brief. In PNP, we call that the project charter. And here, initiation, initiating a project document is called project initiation document, PDD. So this, this, this could be confusing because in PMP we call it project management plan because it's part of the planning. But once you get over it, you realize that all those methods are pretty quite similar. Another thing of not imprints to Steering Committee is referred to as a project board. I suppose this is, this is what I see us. One of the key interesting thing, if you like you, they are formal rules on how the project manager receives project work. I could have had here in theory. 96. 162 PMP and Prince2 wrap up: Welcome back for a wrap-up on those two methodologies. Very popular ones. Here on this slide, I've put more or less the three methods that we've seen. So this is the, this was my part one. So my part one, my method there has in part one was including all those components in orange. But I chose to invent them if you like, in every one of those phases. Prints two and P and P being some very thorough methodologies that you will need weeks to learn. They have a little more detailed explanation of each phase and how things go from one phase to the older. As I was saying, I don't think it's necessary to learn all this to be a good project manager. You fought me. When you need something, you just go and get it on the spot. You don't need to know it or from, from day one. But at the end of the day, project is a project. I've seen project managers being very good and they're coming from a different environment. Because more or less you just, you just follow the logical way of implementing things. So here, the part in blue here is pre project. Whether you call it initiating, starting up or initiation, it's pre project. You get your your business case together, you get some high-level cost and milestones. And that's it. Then you go into planning phase. So you go in planning phase, which is initiating a project in prints two and which is also called the planning in PMP. And what do you do? There's no surprise. You do very precise planning. So obviously, you need some type of approval. So prints two would call that directing a project. Pnp would be would be that would be under monitoring and controlling. So you would have the same things down but presented differently. Execution, no surprises. I mean, you have several stages, yes. But nothing prevents me from having several stages here. We can have several implementation during a project. It's not forbidden. Bird to close it. Then you need all the stages completed. Now prints to make it look a little bit more, four more if you like. And he had this SM. You can have as many stages as you like. So managing product delivery here, it's what I find interesting. It's, it's a more formal way. But once again, when you ask a team to do something as a project manager, you just just send him an email and let's go ahead and do it. It is already quite formal. You have some If it's an IT project, you have the business requirements that are being signed off. I think prints to, for instance, it's good for very large companies. So they would have some maybe extremely complex requirements. And they would, they would have a lot of them. So therefore they need to have a process around this. But most of the project, this is the existing proce procedures, if you like, would be sufficient to manage these. If you are a very thorough project manager, you should be able to, to get some precise instructions for the team to do the work and a precise way to get to work back from them. Some some type of sign off center like so it, it, it all can be done. That doesn't mean, you know, PNP cannot do one type of project and prints to do so, it can all be down. So you might be wondering which one to choose if you want or have to. So as I was saying, the key reason for me to get certificate is because when you look for a job that they want you to have a certificate to be certified? Not always. If you want to go to a project management role internally. It's also possible. I think if you look in your, in your company and you have a look at that, okay, there's a project of fees there. I would really recommend if you're really keen on becoming a project manager, instead of having to go through the certificate, applying and all these, I would recommend that you try and get them get there through the project office. And you say, Oh, I wouldn't mind being a project coordinator there just for a few weeks. And before you know it, you'll be running projects. And I've seen that so many times in terms running projects after a few weeks. So they arrive other as an admin and after they do some coordination and after a PM gold leaves, they take their place and end up printing a project. So go for it. If you work in a large company and they have a project of his tray and use the back door. I prefer PNP. Pnp, there's a stronger focus on managing teams and the relationship. The communication side, if you like, this, is what I really like this PNP. The learning process for both is heavier, not always applicable birthday provider or an asset allocation. That's a way to wrap it up if you like. So, yeah, So here you go. Pmp prints to your choice. If you want to. If you don't want to instill, want to go into project management. There are other ways. 97. 163 Waterfall and Agile intro: Welcome back to the waterfall and agile part of this course. So we have seen prints two and PMP, which are methodology or standards, ways to manage projects. Now waterfall and agile and more approaches if you'd like to deliver the work of a project. So both approach can be done with either prints two and p and p as the overarching method. But as you go down actually delivering the work, there are two ways we can do it is waterfall energy. Let's have a look. 98. 164 Waterfall: Let's have a look at waterfall. So we've seen that a gel and what four different approaches to deliver the work of the project. Which in other words, mean different approaches to execute the project. The way we have seen in part one. In part one we saw that fall all of projects, especially IT projects, the execution is, is quite standard. So the execution needs the requirement gathering, which is done in planning. And then the execution is more or less design something, you build something and you test it and after you implement it. So Agile and Waterfall are two different ways to go through this cycle here. What we've seen in part one was Waterfall. Waterfall, It's usually the way the project management method is being taught. Because once you know what a fall, then it's just a matter of switching things around to go into a giant waterfall. And agile, you would have the same initiation here. Sometime you would have the same planning. You would have definitely the same closing, but it's, it's more or less the execution and the end of planning when you do the requirements gathering, that will change a little bit. So when I say part one, what we've done with waterfall is that we've assumed that there's only one implementation. We said we do this once, we do this, once, we do this once and after we implement once. So that's why I said part one, we were using waterfall. So let's have a look for what to fall. During planning, we ask the business to provide us all the requirements. Where do you want exactly, right. This big document. Put all your requirements in there. You sign them off and hand them to us. And we have a look. And then we go into execution. And then we designed based on these big document there. And then we build based on these large document. And then we test based on these large document. If they want something different, if they want to change. Here, we've seen we just call under change control card. We said, Sorry guys, you need to go through the change request process and it needs to be signed off before we even have a closer look at it. So we do that once and after. We do all at once. And then we implement once. Now, once it's implemented as as, you know, as we do that only once we usually go into closing. Now, they are they are times and this is why prints to as stages. When you would have several large stages. So you could have two free largest stages. But most of the time it's all only 111 big document here. Do all that wants and after we implement. So you will understand when we go through a javelin, how a child is different. But for waterfall, this is the process. Now let's have a look at a giant so we can really see what were the differences. 99. 165 Agile part 1: Let's review Agile. Agile is an iterative process to deliver the project work is not only wanted iterative, and we can change and fine tune as we go. If we go through the loop, if you like. When the execution starts, we already obviously have a good idea of what we'll be doing. So it's usually a very large chunk of work that we've agreed to work on. So we've had we went for our initiation. So we had to go head or the project let's say is to deliver software. And then we know that we need to deliver the software. But we want to give ourselves the opportunity to be able to fine tune how the software will be implemented, for instance. So in other words, is more of recurring activities until we get it right more or less. So in planning, we have to go head. We have the high-level requirements on what we want, the type of software or the tap or a website or anything that we want. And after we get caught into that loop. So initially, there's several requirements gathering during execution, but we might keep that one. Usually we might go directly into design because we haven't started the loop yet. So we might go into design directly and we do a first build and we do a test internally. So this is a technical resource during the test. And after we demo it to the client. And the client, client has a look at it. Maybe do their own test as well. And then we implement the first draft we've really implemented into the production, so it's live. So we've done the first loop and the product is already live. So this is live. But there are also instances when we could just be in a test environment somewhere and then we keep working with a business in this test environment until, you know, until they are happy. And there are several loops have occurred and then we can put it live. But if we just keep it to the scenario where we go live at every loop, I think it'd be easier to understand. So let's say we arrive in a second loop here. And the business wants to change something, or they have something else in mind and they want to add it. So we will do another bit of design and we do another build, and we do another test them all. And then we implement again. The rule book says every two to four weeks, but it can be any any any length of time if you like, which usually quite close to each other. So they call that sprint. So every two to four week, a piece of code, it will be a repeat of a website. A small component is added based on the latest requirement gathering here. Go through the loop and you implement it, go through the loop and you implement. Now the ring designed, built and also taste. The teams meet very frequently. They call a daily stand up. So they call that cramps to review progress and get feedback. So the whole idea, it's very interactive between the business, between the business analyst, between the developer and between the tester. So they all go in front of a whiteboard and they say, Well, what do we do for the next implementation here? Obviously had a backlog and they decide what they will do for this time and they're review what happened in the previous day. They're planning to do the next day. So it's very interactive if you like. So when you compare that with waterfall where you have just these big bang requirements and after these big bank design. And so it's, it's, it's much more interactive. We see much more of the business and the teams interact much more. So this is where if you also take a jar by the book, the business representative, the business analyst, the developer, and attest that there should be the same physical area. So this is just as opposed for Biden cases which may know don't, don't always occur. 100. 167 Agile part 2 and example: So if we went to go little bit deeper in our understanding of a child, just wanted to mention the terminology here. And I'll put that under the advanced because hopefully it was a previous slide. You You have a good understanding of a trial, but if to go little bit deeper, so you would have a project and you will break down your project into larger chunks that are called epics. Epics are broken down once again in building blocks. That's something concrete that a developer can build. I'm using the terms build and development. Because a gel is mostly done for IT project where you actually have to develop slash build something. So I think it's easier to use that type of IT if you want a terminology. So you have a big chunk here, here you have thinks something concrete that can be implemented. So when you go to your daily Scrum or daily meetings, you, what you can do is have the whiteboard broken down into five parts. One part where you have all your stories. You have one part where you have your older to do so. It could be some work for a business analyst, for a developer, or a tester. You have another part where you put in progress so that that shows what what is currently being done, what is to be tested so that the development has been completed and now it's ready to be tested and what he's done. And these should go into the implementation. As an exponent. I think we should have a look at an example or maybe take a look at an example. So let's say I work on a project. It's to develop a website to sell some mountain gear, say. So I could have one API could be ability to view the catalog items. So I don't, I don't want to right from the start create carts so they can put products in card. I want them to be able to visualize only because I want to go on the market quickly. And that's the key advantage of a jellies. You, instead of having ticking all the boxes and having everything done perfectly, I want to go on the market quickly and then I will build on that. So what I do is I have this first APK ability to view catalog items enough to create another API, which is ability to purchase items. I really want that, but first week on the market. And also as a client, I want to have a look at it. I want to visualize it because it's hard some time for a client visualize the final product without having a look at the, the other website, the field and alike. So once they see that, they say, Okay, I would like the car to be built this way on the right, so it's quite flexible. And this is a user story, what they call story. What we've seen in the previous slide is it's often worded this way as search and search. I want to be able to search and search. As a website user, I want to be able to add items to my car. So this is a story that will go here. And the story here will be, you know, Mr. Builder, please create a piece of code that will allow items to be added to the cart. And then when they're done, they look, they will, you know, the team lead or whoever, or even the project manager could say, Okay down and that's going to be on my next to-do list. And after you would go into Progress tests, then don't put a story there. And then you have this as a task. So they have a different terminology because obviously each are working on smaller components. They need to be able to break down the activities and also the requirements into smaller, smaller pieces. So this is where they have all these different terminology. Suppose that seat for an, a general overview. I think that this example makes it quite clear. Now what we haven't seen yet is what are the advantage of a Giles? Although I'm sure you've already spotted some. What are the advantage of waterfall? So I suggest as to wrap things up, we have a look at the key pros and cons of Agile and Waterfall. 101. 168 Waterfall and Agile pros and cons: So let's have a look at Waterfall, Agile and see who wins. Well, the answer depends what you have to do really. You have, you're working for government and you have an important legislative tends to do. And you know, it's not going to change and it's going to something for the next five years. So in this case, you know, okay, I'll go ago is waterfall, no problem. M&a even going with Agile is not even an option. But on the other hand, as we've seen in the previous example, if if you're a client and you want to have a fill first before fully committing to the to all your requirements. You know what you want, your end game, you know you want a website. But for the final detail, you're not, you're not completely sure yet. And then you would like to try it first because if it's a complete failure, then you could always top. So that's another advantage. You don't have to go all the way. But let's review those pros and cons one by one. So the proof waterfall is easier to assess schedule and budget requirements. So for a project manager in theory, it's good, it's easier. That gives you a clear protests code from the start. So you know all the requirements before you go into execution. So before you go there, you have all your requirements. Another advantage is project plan can be repeatable for similar projects. You've done it for once in another project, you very similar, you can just reuse it. Now. The cons. So there's a long time between drinks more or less. So you have your requirement here. The implementation is all the way here. All the things that could happen during this. This is why I was giving the example of government change for instance, that's a very good example to go in waterfall because you know that nothing will happen in this. But you could be, you could be in a scenario when you do your requirement here and it's a two-year project, and chances are things will change in these two years. So this is a suppose the disadvantage of a waterfall is, is you would have to use the very heavy change request process here, change control process. This is a bit tied up with this way you cannot react quickly to changes because you've done all the work he already, if you get a new requirement that contradicts a little bit, then you need to go back there and it's a bit of a long process. And this ties in with this one as well. The change control processes is heavy in a way. So if they want something different, your project office mart might have a feet and the cell than on the need to go through all this, all this process again. So it's very heavy in this way. Let's have a look, a giant pros and cons. So what is great with a jar? You get a lot of customer feedback in water for. In theory, hopefully, you do it a bit differently, but in theory, they cannot see is that if they've done their requirements in 2020, they don't see the screen until they do the testing. It could be 2022 on very large project. So there's not a lot of interaction if you like. There will be some during the design, they would see look at the design and the documentation, but actually seeing it that there will be, there will be much interaction with the customer. But here, very often, you implement something quick initially and after you have constant customer feedback. So you know, they will not be a big surprise when, when implementation comes. Another advantage of the project can deliver some business benefits quickly, as we've seen with the example of the mountain gear, a website. So you can, you know, even if you don't have the full, the full functionality of the website, you can already provide some very good benefits to the business and you can show your product to the client. And this is obviously a good one. You know that there's collaboration and not only collaboration with the customer, but it is constant collaboration with all the team members. What are the disadvantages? The disadvantages are more driven by the type of project you work on, I suppose so more uncertainty are on schedule and costs. The budget could be allocated some time. So you have six months of a designer, a developer, and tester. And in six months, after six months, the money stops. But sometime it's very, it's very difficult to assess because let's say you work on this website, mountain gear and there is one small change from the business and other small change from the business. And you realize that the business really is not really sure. So there's older. So the project takes longer, so it means more cost. So it's not, it's not as easy. Disadvantage. So it can get out of hand without strong oversight. So it's very important that, for instance, if you have a business person involved here, that he or she has the authority and doesn't worked too much in isolation. Because other words, it's gonna be bombarding with a lot of different types of requirements. And if the business analyst or the developer are not strong enough to say, well, this is a bit contradictory, contradicting what we agreed on the last sprint and the lexicon. It can easily get, get out of control. So strong oversight is really important for a giant. So it's not. You can do whatever you like. We will let you play with software for six months. But you know, some very stronger oversight and we want to have a clear a clear path to what the final delivery would be. The disadvantage in a client service provider scenario that can make the claim nervous and that's something that I have experienced, especially for the requirement here. So a client can be concerned that this this, this would be an ongoing process because they sometimes they do have a clear idea in mind and they don't want to go into uncertainty of the requirements being refined in a design changing and potentially in a cost is changing. So you are a service provider, you, you, you're used to working this way, but sometimes the client, I've seen client that they just they just unwanted did this. They see this disk, just too much uncertainty on these. The contract usually a bit scary because obviously the service provider wants, wants to protect themselves. So to summarize, I suppose, you know otherwise saying, what a four best suited for project with a strict budget, clear vision from the client, and likely to change. So a jar is best suited for when some competence can bring business benefits early. And I think as we've seen, and when there is frequent client feedback, it's best to have them under a giant model than just the ringer waterfall model. 102. 169 Standards and Methodologies wrap up: So as a wrap-up, I suppose we've seen prints to PMP, waterfall and agile as well. So as you've seen, footprints to end PMP, don't be intimidated. It's just the same way to manage projects. Just sometimes with different terminology, but not always and not often. As usual. There are always things that you can learn once you are on a, on a, on a client side or on the company side, or if you're working internally, there's always things there that you will need to learn any way. So don't be intimidated by, by those, those standards. But get them if you really keen to get into project management because it's often asked. Also talk about backdoor that you could use are going through as a project coordinator initially, where they don't really require a lot of certificate and the right, and that's an excellent way to go into project management. As far as Waterfall, Agile, it's depends on the type of project. Don't go with a jar just for the sake of going with a jar because it's trendy and that's a big thing at the moment. We know has been a big thing for, for a few years, I know. But what I would say regarding the waterfall and agile is you can be a child in a certain way, even when you work on waterfall. Don't always wait for the final, final, final sign-off. You can always get things started in parallel. Beer gel in a way you interact with others, try and have it. We saw one of the advantage of a gel is the interaction. Nothing prevents you from having strong interaction with the customer. If you're working on Waterfall project print, bring them back often. Even if it's not formally through these prints every two to four weeks, bring them in early. If you have a twelv month waterfall project dot, dot, dot, let them wet 12 months until they can actually see whether we get, bring them early. So be agile as much as you can even if you work on a waterfall project that will pay dividends. So that's it for part three. There is a crease for pathways, so please don't forget the quiz. 103. Conclusion and Next Steps: Did you go? Did you like it? Please don't hesitate. If there's any queries, any questions, I'm more than happy to answer them. I think there's a Q and A section, but also if you want to get in touch, just let me know if there's a topic that you really want more information on. If there's something else that you would like me to do. I've been thinking, for instance, doing an MS project demonstration. Maybe if there's anything and if there's enough demand, I suppose I'll be more than happy to add it to the course. If you want to leave a review that's always helpful as well. And it will be appreciated in case, if you want to go into project management, it has its challenges. I was not hiding them, and I think I provided you a lot of information to really make it easier for you to cover yourself if you like. But also it's a very rewarding job. And on top of that, the salary is not too bad. All the best. Whatever you want to do next, stay in touch.