Project Management fundamentals: A practical approach | Ben Moreau | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Project Management fundamentals: A practical approach

teacher avatar Ben Moreau, All about Life and Projects!

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

    • 1.

      Project Management Essentials - Course intro


    • 2.

      How to make the most out of this course


    • 3.

      What is a project?


    • 4.

      What is project management


    • 5.

      Introducing the 4 phases of Project Management


    • 6.

      9 areas you need to know


    • 7.

      9 areas: High level explanation


    • 8.

      Initiation phase introduction


    • 9.

      Initiation phase description


    • 10.

      Quick intro on scheduling


    • 11.

      Quick intro on budget


    • 12.

      Introducing Stakeholders Management


    • 13.

      OPTIONAL: Stakeholders matrixStakeholder matrix


    • 14.

      Initiation phase Exceptions


    • 15.

      Initiation phase - what happens after approval?


    • 16.

      Team structure: Program example


    • 17.

      Team structure: Steering committee example


    • 18.

      Initiation phase: What is the great challenge?


    • 19.

      What's with the Olympics being always over budget?


    • 20.

      Multi phased projects


    • 21.

      Project example: Initiation


    • 22.

      Planning phase introduction


    • 23.

      Planning phase description


    • 24.

      Planning phase description phase 2


    • 25.

      Project example: Planning


    • 26.

      Execution phase introduction


    • 27.

      Execution phase description part 1


    • 28.

      Execution phase description part 2


    • 29.

      What type of issues do we face during Execution?


    • 30.

      What's with Risk and Issues being 2 lists?


    • 31.

      Project example: Execution phase


    • 32.

      Closing phase introduction


    • 33.

      Closing phase: examples of activities


    • 34.

      Project example: Closing phase


    • 35.

      Introducing the roadmap


    • 36.

      Roadmap walkthrough


    • 37.

      7 key documents in Project Management


    • 38.

      Project Charter


    • 39.



    • 40.



    • 41.

      Issue list


    • 42.

      Risk register


    • 43.

      Budget document: What to look for


    • 44.

      PMP = Project Management Plan


    • 45.

      How to talk to a PM to get what you want


    • 46.

      Project Management always the answer?


    • 47.



    • 48.

      Next steps


  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class


It would be useful for anyone to learn the basics of project management to allow them to:

- Understand what is going on in a project

- Influence a project

- Become part of one

- Sound knowledgeable and get respected in the corporate world. "Yes I know what you're saying"

- Maybe start a Project Manager career. (This course is not sufficient, if you know you want to become a PM now, check out my other course)

- Check how you could use a project structure for your own life projects.


This course is a 90mn introduction to Project Management, but is also providing lots of useful information around Projects, Project Management and Project Managers (PM).

You will understand exactly:

  • What is a Project

  • What is Project Management

  • What is the most basic Project Management process used on most projects

  • What are the 9 key things to look into when dealing with or managing a project

You will also get an introduction on:

  • Program Structure (Project Manager team)

  • Steering committee structure

  • Risk Management

  • Issue Management

  • Budgeting

  • Stakeholder management, the unloved child yet so important in Project Management

  • Project Charter and Project Management Plan (2 very important project management document)


I will provide you with most slides of this course to allow you to review the basics wherever you are without having to watch the videos.

I am also provide a small booklet with the 7 key artefacts of Project Management.


Part 1: Definitions and Process overview

This will provide you with a framework, basic knowledge on how a Project Management works. Useful for Part 2 too.

  • Introduction & Definitions

  • 4 Phases

  • 9 areas to watch

Part 2: Walking through the process

Here I take you step by step through a Project lifecycle, from start to finish

  • Lifecycle: 4 phases in detail

  • Example for each phase

Part 3: Knowledge reinforcement

This part will really nail down the concept of Project Management. You will review some topics seen from a different angle.

  • Roadmap walkthrough

  • 7 key Documents

  • How to talk to a PM

My bio:

My name is Ben, I have been a Project Manager for more than 20 years working for amongst others IBM, HP, large Financial companies and also Government agencies. I have also been coaching Project Managers for more than 10 years.

I have all the most respected Project Management certifications (PMP, Prince2, MSP, Agile Project Management) - and you know when I was doing those courses - I did not really enjoy them because when I did them I was already a PM and what I was hearing was not usable and so remote from what happens out in the field... and I thought I can do better maybe - to bring this knowledge to people interested in Project Management.

Meet Your Teacher

Teacher Profile Image

Ben Moreau

All about Life and Projects!


Hello, I'm Ben. I am a certified Project Manager, Project Manager coach and a certified Life coach 


If you would like free tutorials on Project Management subscribe to my Youtube channel.


Tutorials include:

- How to build a GANT Chart in EXCEL without MS Project

- How to create an awesome Task list in Excel. 

- How to become a Project Manager using the Back door.

- Productivity tips and;

- Plenty more 


 You can subscribe to my Youtube Channel here for up to date learnings:

You can visit me at


My bio: ... See full profile

Level: Beginner

Class Ratings

Expectations Met?
  • 0%
  • Yes
  • 0%
  • Somewhat
  • 0%
  • Not really
  • 0%

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Project Management Essentials - Course intro: Hi there, My name is Ben. Thank you for checking. If you go for this course and you review the material, then by the end of this course, we will know more than most of the executives in the corporate world I've been working with. This course is for everyone, whether you are the business, whether you want to be government project manager, whether you are a technical resource, often working on projects. This is for you. I hope you can join us. So if you want to have a taste of project management and at the same time, some very useful sites of project management. And I think that you would like. 2. How to make the most out of this course: Thank you for taking this course. Now a couple of tips. Now you must sum to abuse, but I think the best way to go for this course is to go through a sequential way. Part one, part two, part three, because it's part based on the knowledge of the previous path. And when you go through the course in part two, I go through the life cycle of a project if you want from initiation to closing, which is the last phase of the project. So you might be tempted at the end of part 2 to say, okay, I've seen it and understand, I can move on. Don't need to go part three. But you would be missing on a lot. Because part three is really what brings it all together. In a way. There is a roadmap and there are some, you know, some videos where I review all the documents and the communication with the project manager that will really reinforce the knowledge. And at the same time that will give you some additional insights. Or the TPP is I put some videos optional. If you feel that the topics sounds familiar, then you can skip them. At the same time. My suggestion is go through everything. Is there the videos are usually not long. Another tip is, I go through some videos quite fast because I don't really know you, I don't really know what you know. So if you feel this is too fast than the best advice is to watch that video again before moving onto the next video. For some of you already know the concepts, then that would be perfect. You can just go through them quickly. Now another tip which is more suggestion. Don't look at the resources yet as you go through the course, I usually put the slides or the diagrams on the video itself so you don't need to attain them might be a bit distracting, but that's just a suggestion. You might really want to have them in your hand as well. The only exception is the road-map at the end. The font is quite small because I wanted everything on one page. So for that one actually suggests that, yes, you have the printout in front of you while you go through the roadmap. 3. What is a project?: Hello everyone and welcome to this course. Now before we define project management, I think it's important that we define what is a project. So what is a project then? So in order to have a project, we need something that needs to be done, something to do. And I thought I will attach some criteria to this, you know, as, as I will say, down the track, it's all open to interpretation. So there is not a rigid definition of what a project can be, but I'll try and define it as much as I can for you. So I came up with four criteria that I think are required for, quote unquote something to be called a project. The first one is, this thing that we have to do needs to be specific, can not be vague. For instance, I'll be talking about walking as an example a lot. The ring during this course, if you say, I want to walk more, for instance, that is not really a project. It's not specific enough. It's the same with being healthy. I want to be healthier. It's a goal probably, but it's not really a project until you really define exactly in specifically what you want to achieve. So that's the first thing. The thing that we want to do cannot be ongoing. It has to be a one-off with a start to finish and after it's completed, we move on, we do something else. I'll come back to this one. The two other criteria I think would make sense to you to be a project is something usually that requires planning. If you just do something without any plan and if you can do it anytime, then that's not really a project. And the last Carter, Yeah, it's a little bit unintuitive as well, and it's a bit related to the one before, but requiring planning, it has to be large enough. Just want to elaborate just a tiny bit on the one of, because as I mentioned, is something that people struggle with sometimes. Let's say you part of the Olympic Committee, review your review beads from different cities and those cities submit bids to you to host the next Olympics. So that's your job. You doing this day in, day out. They come and go and it can be beat for the radio team, it could be for the Tokyo team and the Paris team. So you're doing this more or less an ongoing basis is our project for you? I don't think so. This is what is being called a business as usual or BAU activity. On the other hand, each one of those teams, like the Rio team or the Tokyo team, they have a project because they, it's something new for them that requires planning. It's very specific and it's one. So once it's finished, then they move on, they have a start to finish. So I think that explains a little bit more if you like, the difference between ongoing and project activities. Another example very quickly is there'll be, let's say you're part of an IT team and your job is to make hardware maintenance and you do that all your hunger as soon as there's a problem, fix it, or if a certain needs upgrade, then you upgraded. So for me, this is business as usual, this is not a project. That doesn't mean it's easy that you do that day in, day out. On the other hand, if your company decides to a bread oldest servers on site and they will allocate a project manager usually if it's, if it's very big to ensure that all the tasks are coordinated. It is not because an activity is complex, that it has to be a project can be very complex, but it's ongoing. It doesn't fit the criteria of being a project. 4. What is project management: Now we know what the project is. We just need to define project management. So let's have a look. This arrow here. That is project management is all we need to do to get things over the Rhine. And the project management, the way I have it here is the management of all activities required to implement the project. Now that doesn't mean that we have to check every single activity on the project. But we need to ensure that actually someone is on top of all these activities. And more often than not, you need to implement on time, on budget, and it has to be of good quality. Now the definition of a project manager is very simple. Responsible for managing this process. The project manager needs to ensure that this something is being implemented. So in order to implement project, we usually follow a process. And this is what we see in the next class. 5. Introducing the 4 phases of Project Management: Now let's have a look at the process usually used to manage projects. So projects are usually managed around four phases. There are some methodologies, they have some slight variations around those. But at the end of the day, it's more or less the same. Now let's go through each one of these phases one by one. The first phase is the initiation phase. So during this phase, we decide if we formally go ahead with the project or not. Are we really doing this there? So this is why I said potential projects before, is that in theory, we are not in a project yet. Say one executive for instance, you might other great initiative or project. But if the company doesn't have the money to do it, or if the initiatives would have too much of a big risk, then the company is not going to put money on this. And before we go too far into planning and spending money towards that initiative, we regroup in a way. And we ask ourselves, is it worth putting our money in today's time? We just need the tick. We just need a formal approval. Yes, that's a great idea. Let's do it. And then we can put aside the cost for it. Now, if the project is approved, then we can proceed to the next phase which is planning. So during planning, we plan for things that will happen during the next phase. How are we doing this? Obviously, I'll go into more detail in each one of those phases moving forward. But for a quick overview, that's all you need to know. Planning is how we will be running this project marvellous. What activities do we need to run this project? Then, when we all agree on the plan, We can move to the next phase, which is the execution phase. During the execution phase, we are actually doing the work. So the question that we need to ask ourselves as a project manager or the team member is all going well, is ongoing. Okay? What can I do to help? How can I fix stuff? Towards the end of execution, there is sometimes something to implement, and then we would implement a project, but it is not finished yet. We still have another phase to go through, which is the closing of the project. During the closing, we ask ourselves two questions. Is everything done? And how well did we go? How did we go? So we wrap things that we close properly and we reflect on how we've done it. So as a heads up, obviously in part 2, we will see those phases in a little bit more detail. But for the moment, I think that gives you just a very high-level overview of the process for project management. 6. 9 areas you need to know : Now we've just seen the four phases of project management. So the challenge I find with project management methodologies is from that point it all becomes very complicated very quickly. For that reason, I wanted to give you something simpler. I wanted to give you a simplified view of project management. And at the same time, I wanted it to be a very thorough view, a very complete view. So I thought it'd be good if I could give you a list of things that you could refer to as you progress through this course maybe. Or if you are involved in the project. I came up with a list of nine things that you need to monitor. You need to assess in E2 to keep on top of. You need to really keep an eye on all the time. According them, the nine things didn't sound very professional, so I've been calling them the nine areas. The nine areas of project management that you need to monitor while you go through the four phases. Here's the list of these nine areas. We have scope, schedule, cost, risks, quality issues, amine, stakeholders, and approvals. Now in part three, I will show you how you can combine the four phases of project management with this list of nine areas. Together, they will combine to form project management roadmap that I have created with. Now, let's have a look at these nine areas in a little bit more detail. 7. 9 areas: High level explanation: Let's define this nine areas then that we need to assess and monitor. Scope. The scope is one needs to be done. Usually when you need to do something, there is someone there who knows exactly what they want. Let's say you being asked as a project manager to implement a website. So you would have someone from the business who would tell you, I want my website to be like this and I want my website to be able to do that. That's what we call business requirements. They will write a document and they will give it to you. And that will be the scope of your project. But it's not always the case. You don't always have business requirements. Let's see to go back maybe to the hardware upgrade across, across the board. It's not the business. They're going to tell you, I want you to upgrade all these. It's more or less military, you have to do it. And therefore, you have to put all that in your scope. You scope is to upgrade all the oldest servers of the company. Next, we move on to the schedule. So the schedule, it's, it's quite intuitive. How long will it take? And when can we have this? The cost? How much will it cost is quite simple as well. Risks, risks. It's any future threats to the project. And we usually truck that in a risk register. We will go through the risk register later on in the course. The quality. How will we check the project quality and how will we check the end product quality is not only a matter of checking the quality of what we deliver, but also making sure that we're doing this properly, that we are following the process properly. Issues as opposed to risks, actually a potential problem. Issues, it's happening now. We have an issue now, project admin. So it's quite broad. So you have the reporting, you have the meetings, you have communication is or the governance of the project is the meetings. All that you need to do? You chair meetings, you would, you would write minutes. You would update everyone by communicating with them. And you would buy stuff if you are in charge of buying stuff. Stakeholders. So we will go into this in a little bit more detail later on. But in a nutshell, is, who are we working with? Who will be impacted by the project at the end of the day and how we keep them happy. It's called a stakeholder assessment. And finally, approvals. An approval. It is often forgotten as a really something to check all the time. And I liked it. This is what I like about this setup is if you manage a project, you have to bear all of those in mind all the time. In part three, I will show you how you can combine the four phases of the project management process with the nine areas that have just mentioned and that will give you the roadmap. My students usually best to walk you through this roadmap free after the path tool, which is explaining the process a little bit more detail. But for the moment, just knowing these nine areas would be very useful. 8. Initiation phase introduction : Welcome to the project initiation phase. So when we introduced the phases earlier on, we talked about productive session and we gave this example of going for a walk. So at some stage, we have to decide if yes or no we go for a walk so we could see that as the initiation. And once we have agreed that we're going it becomes a project. So where we are in Project landmark. For business, obviously, the decision can be a bit more complex, but it's the same principle. So in a nutshell, key question that we want to answer during initiation is, are we really doing this every really committing to this? And this is what's tricky. But initiation phase, it's, it's half, not a project. And towards the end, if we go ahead with the project, and I'll explain why it has to become a project halfway through. And a key reason is that we need a project manager to do the paperwork in the end. So in theory, it's not a project until after the initiation, but still be good to have a PM to do the paperwork. Now I think we can get started. Let's have a look into more detail of what is, what is required for us to make a decision. Let's go ahead with this as a project. 9. Initiation phase description: Just as a repeat, if you like, the end game is to get approval to proceed as a project. So we have to ask ourselves what would be required for all these guys in the room to say with confidence, this is a good investment. Makes sense, Let's do it, let's go for it. So one of the question is, the first, actually I would say question is what do we want to do? Which in project management talks called the scope. So we need to define the scope. Also. We need to say, can we actually do it? I mean, if you want to go for a track, for instance, for three to four weeks, can, can we actually do E? Do we have time to do it? How much will it cost? And what the stage is, its early stage. So we just an order of magnitude I suppose, but, uh, but that's very important to decide if we're going to go ahead with the project or not. And it's called a budget as opposed. How long will it take? Project manager talk, schedule? We want to know when that can be implemented because that will influence if we want to go ahead with the project or not. If we say, if everybody thinks that's a great idea, but you cannot have it until three or four years time. So maybe it's not as good an idea as we thought. Maybe we can have some lower hanging fruits and we can have some maybe a quick wins earlier instead of willing for that, for that big thing there. A very important thing, it's the risks, any risks we need to be aware of. And if we find risks, how are we going to address them? Are their initial stoppers. You come up with with an ID. Let's say you're the guy wanted to go for this work and you don't want to hear about the risky because you really focused. And if someone tell you, oh, you know, there's some heavy rains planner or what? This lesson bushfires writers and we will check before. So the person who would bring the project idea usually would have blinkers on. It won't really be interested in bringing all the risks that come with his ID. So you say, Oh, no, that's okay. Lets us so it's your role if you involve as a project manager, if you're not, it's role of the executives, of everyone around to really highlight the risk is not that we are being negative here, but it's query. We want to, to give this information before it's too late, before we are running the project and we start spending the money. So risk is very important. And based on all that, you make a decision, is it worth doing? So? If you're lucky you have an executive and she has the business case 3D and she brings it to you and as all of the numbers in this, everything. So it's perfect. Maybe just have a look at the risks. But it's not always the case. So sometimes you have to do a bit of the groundwork and you have to start from scratch. This was just a row ID if you like, and you have to do all the all the packaging. 10. Quick intro on scheduling: Now a quick overview on scheduling. I'm going to talk about the basics here. Fundamentals course. I wanted to show you first the impact of dependencies and then I won't show you an example of a Gantt chart. So you might hear that gunshots. So I wanted to show this to you. Let's have a look. So the importance of dependencies and that will have an impact on cost. After we'll get to this, say you manage a project and you have three tasks. I told you it would be simple, very simple. First task is to design the product. The second task is to build the product. And the third task is to test the product. Have a look at those tasks. They all had been estimated to be two months long. If you didn't take the dependencies into account. So you would come and say, my project is going to last two mumps and it will be implemented into months. Now obviously this is not the reality. In reality, have to take into account the dependency. You cannot start say, building something until it's being designed. And you can start test until the build is completed. So you schedule taking into account dependencies would look like that. And then you would have a six month duration instead of a two months duration. And then you can implement. So that's simple and it was just in case you ever came across dependencies. And that would help you understand what a Gantt chart is. Our Gantt chart looks like this. On the left-hand side, you have some tasks with duration when it starts, when it finishes, and the dependency on the task, if we look a bit closer. So dependencies, you have one task here, for instance, and the task after depends on this task to be finished. And this is how it is visualized in a Gantt chart. And this is why the gunshot is very popular. And it's the standard for project management to actually create a schedule. So the Gantt chart is a standard to create a scheduler. Know you can do it in Excel and the life, but people usually used a Microsoft product called Microsoft Project. 11. Quick intro on budget : A budget obviously can be very complex, but I just wanted to give you something to get you started if you've never done that. And if you're interested. Super simplified budget process. So this is the way I like to show it. There are three components. The one of fixed cost, the one of activities, and then the ongoing activities. So the one of fixed cost, for instance, the hardware fees, fixed services, you know, you need to buy a server and is $2 thousand that's fixed or you can put that in your budget. Total, goes into your budget. Then you assess the duration of all activities and you calculate the cost for one of activities. So you calculate how many days it's going to take them to design the product of many days to build a product and how many days to test the product. And then you have a total, one of course, Any goes into your budget. To expand the third component, I'll go back to the example that I gave on unscheduled before. The third component is for ongoing activities. It's for support costs. During the life of the project. Step 1, you assess the dependencies between one-off activities, and then you assess the duration required for this ongoing activities. And then you have a total ongoing costs or the total support costs. And you put that in your budget and actually offer component if that doesn't make sense. The third thing yet, let me show you the diagram that we have done for the schedule. So this is the first diagram. I don't know if you remember, we have ongoing activities, which is project management. You need a project manager for the life of the project. So if the project is to mumps, you need a PM for two months. If a project is two years, you need a PM for two years. The longer the project, the more expensive it will be for those ongoing activities, including the project management activities. Say in the example given below, if we didn't check the dependencies, then we would have thought all these projects are going to finish in two months. Therefore, there's only two months of project management cost. So that would be wrong. What you need to do is you need to wait for the schedule to finish. And you would have something like this. You would have the design for two months, the bill for two months, test for two month, and the total activity will be six months. So the price or the cost of the tasks below will not change. But is it coasts of these that will change? The cost of the ongoing activity will change. So by going back to the slide, you can see that this is a variable and this depends on the life of the project. So that's it for a very brief overview of budget. Obviously, this is Fundamentals course. We're gonna go into too much detail, but I think that will get you started. 12. Introducing Stakeholders Management: Were collected, of course, stakeholders management. I wanted to walk you through this because part that is not as intuitive for some stakeholders management. It is something that is not always obvious to people. What is a stakeholder is that the team up and width, there is this misunderstanding of 10 that stakeholders are the business guys. They're giving you the job and they are very important. But stakeholders actually not that, it's actually much broader than that. So don't quote me on this just to give you an example of people who could be involved in your project. The questions that you need to ask yourself. If you're a project manager and you won't really understand who's involved in the project. Who is a stakeholder is, know who you're working with on this project, that your team and the likes who will receive the benefits. So this is interesting one because it's an end-user. So you might not be working with them during the life of the project. But it's the people who might be using your products on down the track. It's a, you build a website. The users of the website, our stakeholders, you need to take them into account. Who can interrupt the project. That's something also that you need to bear in mind. So you need to understand who are the decision-makers who could stop the project? Who provides the money. If they don't give you the money anymore, your project is, is dead. So you need to understand what will impact budget, which will impact your receiving the ammonia or not for your project? And who will operate the end product? This is more the operation side. The gas will take over from you when you finish with the project, will take over the product maintenance. You finished, you build your bridge, you've tested it. Now the users are using it. But when there's problems down the track, who will be taking care of the maintenance? You need to bear them in mind to give them the proper documentation so they can maintain the product that you have created if you like. Then an official definition is who could cause problems during the projects and when the project is implemented. For this reason, when I manage a project, I like to keep asking myself, who else could it could be, should be involved in this project? Who needs to know about this project because they are people who could impact this project negatively. I want to hear about it now, not later. Give me the bad news and I'll try and deal with it. Instead of them being dominant. And when the project is implemented, they come out of the woodwork and they create challenges. 13. OPTIONAL: Stakeholders matrixStakeholder matrix: To finish on stakeholders very quickly, there is a tool that is being used. So if you hear about it, then you'll know what it is. It's called a stakeholder matrix. I'm just going to walk you through it very quickly. It sounds terrible, but it's a way to categorize your, your stakeholders. You assess the influence of the stakeholder, and you assess the interest of the stakeholder. And based on this, you know, how to deal with them more or less. Then you have the low end, freelance, low-interest. And what you need to do with them is monitor. So they are not really interested, but they cannot really influence it. So that's fine. They could be low influence and high interest. So they're very interested in your project, but they don't have a lot of influence. So what you do with those, you keep them in form. In my experience, it can be a bit of time wasted. They can, they are super keen the country all the time, but at the end of the day, they have little influence. So keep an eye on them. But the official thing for low influence and I interest is keeping form. The high influence and low interest. Keep satisfied. For me, this is a danger zone. It's the guys that don't they don't they're not interested, but they could derail the project at any time. I know this is the one that they say, just keep satisfied. But for me it's a challenge. I need to go and dig them out. I will really want to know about those. Other guys are seated, meeting, don't say with and when the project is implemented or getting close to the end, they come to you and say, What are we doing here? So keep an eye on those the managed closely. Those guys, personally, I am less concerned because they have high interest. So there'll be in your face. But according to the rule, it's high influence, high interest in it to be managed closely. That's it. Quick summary stakeholder matrix. Now you know what it is. 14. Initiation phase Exceptions: In this session is not always required. Sometimes we, there's no need to debate if we going ahead with the project or not. We know it has to happen. So for instance, if there's a new regulation that requires you to do the work and it could be a beak work. So it's a project, it's not debatable, but you still need to go through a bit of a super-fast initiates and just to, just to kick it off and make it formal. And just to give you a bit of a brutal example, is the CEO of a company wants to do it. And I'll tell you you have to be very courageous project manager. The CEO comes to your desk, puts a big fall and say, Ben, this is a project. And you say are now sorry, I have to go through the initiation phase. I need to make sure this is solely so it is not always occurring and sometimes it doesn't have to be, to be very long. As, as mentioned, if if the if the executive comes to you and have done all the all the work, all the paperwork. It's an idea that's been around for a while. It could even happen in one day. I mean, during a steering committee type of meeting, it's decided and off you go. 15. Initiation phase - what happens after approval?: Now the decision has been made during a meeting or formally by email. And this is going to be a project. We are still in initiation. We just need to do a few things before we close initiation and we get formal approval for this. In theory, there's not a project manager, this because it's not a project, but the reason why we would want to project manager is to do the paperwork more or less. If the activity is approved, progresses a project, we have to decide who will be doing it and we have to do some paperwork. We'll be doing it. That's a project team more or less. We have to decide if we do it internally in house or 0 if we associate, we have to decide who will be the business representative. So the business representative. Sorry, but it represents the business. So he or she will be signing off on everything because usually the people who initiated the projects, they are very, very busy and they cannot just do the daily or weekly work on the project. So they will delegate that to someone who will be the technical team. We usually put together a steering committee which is an entity that regroups all the, all the project member and the executive and the business owners and life and the project manager. The second part that needs to be done is to do some paperwork to other formal sign-off. So we more or less we put all the findings of the initiation into this document. We get it signed off and off. We go off. We go to the next phase which is planning, if you remember. 16. Team structure: Program example: Welcome back to the course. Let's have a look at a couple of team structures. Starting off with a project manager team. When frequency now oh, that a project manager is part of a program where a team of project managers are working on different projects. To a program is a group of projects. I give you a very simple example. We have a program manager on top managing the program. And we have the first project manager with the steam underneath for the project or projects he's working on. Now as it is a program, we expect to see another project manager hearing is if every PN. So working on my project. I had this lady. She looks similar because because she is working already on my mates project. So we are sharing the resource. So this is an example of shared resource. Also have a team lead working for me. She has a team, but I usually only deal with it. Before I close on this, I wanted to mention a couple of things. The first one is, obviously a program can have many PMs. Many PMs can have mini-projects. So program can be quite big as far as projects is concerned. Now some quick notes. The project manager can belong to a pool of project managers. It's called the project office or project management office. And also another note is that the project manager can be assisted by a project coordinator. I would say mainly on admin type of tasks, helping with minutes and writing reports. And lets it very simple structure that I think that helps you understand project management within the context of a program. 17. Team structure: Steering committee example: Now let's have a look at the structure of the steering committee. Once again, there are many variations, but I just wanted to give you a simple example. So Steering Committee is temporary structure and its purpose is to provide direction to a project. Remember that when we define a project, we said the project has to be temporary, not ongoing, a one-off activity. So a steering committee starts at the beginning of the project and is being more or less dismantled at the end of the project. So the role of the steering committee, they make all the important decisions they can discuss at a very high level the issues of the project and when there is a decision to be made, they make it. So let's have a look at a very simple example. On top, we have the steering committee chair, usually someone higher up the chain with a vested interest in the project, so there would be making the ultimate decisions. Then we usually have the business owner. The business owner is also sometimes the chair of the steering committee. The business owner is usually the person who initiated the project, but he represents the business, championed the project. And it's not always the case, but usually they focus is more on cells. Then we have our familiar face. The project manager, you know what the project manager does, runs the project that you know that. And we can also have a Senior User. A Senior User represent all users of the product. So in this example, we have a product that is being created by the project. So let's see. The project was to implement a software for a call center. So this lady, she will be representing the call center staff. So she would be very interested in the software being very easy to use. Because the focus is on the productivity. More than sales. She would have KPIs that he needs to meet analytics. We don't want to implement something that she doesn't like. So finally, we have a senior supplier. The supplier is supplying the service or the product. In the software. For the call center example, it would be building the product. It will be building the software. In a scenario where the building would have been outsourced to a vendor. The vendor would be sitting in a chair of the senior supplier though the vendor would be the senior supplier. So his focus is usually not really on sales or productivity. I think especially in an outdoor scenario, the focus will be more on cost and quality of the product, which are a bit interleaved. Usually they have a fixed price, So they will want to make sure that they implement these quickly and it doesn't drag on too long. And you would keep an eye on the senior user requesting changes that were not in scope. And right now, just, just the last remarks obviously is that at the beginning of the course I see the Steering Committee. You'd have project team members could be included in a steering committee in a scenario where there is a very technical projects and you would have an architect or subject matter expert and SME that would also be part of the steering committee because the goal of the steering committee is to make some very important decisions. So they would want to have the advice of some very key team members of the project. So that's it for an example of a simple steering committee. 18. Initiation phase: What is the great challenge? : Now the challenge with initiation, as mentioned before, it often happens very quickly. So it's great when you, everything has been very thoroughly researched initially. But more often than not, it hasn't been. So you'll find yourself in a situation where the decision has been made, you go head of the project. And as you don't really have time to spend on it, because everybody is really keen to turn this into a project. The schedule and the cost I usually put together very, very quickly. And we talked about, earlier, we talked about order of magnitude only for cost. So that will be good if we were at all. Okay, don't worry, this is just six months estimate TMI AND or OR this is just a rough ID. Do your planning and after you come back to us and give us the new cost for the new budget, usually the cost has been decided during initiation, stays with you forever, and then it's not very good, very well received. When you say you're sorry, the budget's going to be twice as much unless you can really, really, really, really demonstrated and even though usually have to stick to the initial budget and schedule. So that's one of the talent, I believe, of initiation. 19. What's with the Olympics being always over budget?: Just to highlight the challenge with initiation, I wanted to give you a concrete example. I'm going to speculate a little bit. We have a slide here showing the over-emphasis of the Olympic Games over n, meaning how much money was spent above what was allocated. We notice that most of the Olympics have actually had overland. The why is that? We could speculate and say maybe, if we are cynical, say that maybe they've put some beads bit lower. And they said that they don't need that much money to organize the Olympics to increase their chance to win the bid. But that, that would be a bit, be a bit cynical. Another reason is that during execution of the project and we'll touch on data on the next part of the course is during execution. They are all things that are being discovered that we can anticipate even with the best intentions. But that is temperatures want to allot. One reason that I'm sure plays a role in those projects being over budget. So during initiation, we have a limited amount of time to assess the cost. Each city has probably a budget allocated. And I said, refresh sense you have 20 million to assess the cost of the Olympics. You cannot go into too much detail because you haven't wonder bead yet. You are not a project yet. You are still in initiation. It will be extremely risky to spend 100 million just to assess the course when you're not even sure that you will win the bid on the next stage of those projects. Once they have won the bead, then I will go into more precise planning and the bad news we start to show up. 20. Multi phased projects: Hello again. Let's review a multi-phase project because this is something that can be a little confusing, especially when you learn project management. And also, I wanted to show you two ways a multi-phase project can take place. So what we just saw before was the project management phases, initiation, planning, execution, and closing. Now you know those. But what we can also call phase is future implementation of the project. Something else to be implemented. For instance, you could have phase 1, we build a simple website to showcase our product. And phase two will allow for the client to purchase those products online. So phase one, we want the client to be able to see our products only to see the product and maybe the price, but they cannot purchase it yet. And this is actually the example I will have in the example that comes next example on the initiation phase. Those will be called the two phases of the project, phase one and phase two. So we have two ways to have a multi-phased project. The first way, which is the scenario one, is we approve it all at the start of the project. We know that we want to have the two phases. We know that, we know that down the track. We want the possibility to purchase the products online, but we want to have early benefits. And therefore we want to implement into two phases. So this is quite similar to the Agile methodology. The difference with a journalist, a gel applies a lot of phases. You approve the full project at the beginning and after you keep rotating between planning, execution and implementation. This is a jar, but here the chunks to implement would be much bigger. So let's have a look at this scenario. One, in initiation, we would approve everything, the budget for the two phases, and also the schedule for the two phases. So when you look at the project manager schedule, you should be able to have a look at the phase 2 as well, maybe not in as much detail, but you should be able to see the two phases. So you have the initiation approved after you go into planning and after you go into execution where you implement. And after, when you go into the face to work, you don't have to do the closing of phase 1. You don't have to do the initiation of S2. You can go straight into planning, but he doesn't have to be sequential. You can, you can start the planning office to, while you are doing the execution. Phase one. This is the advantage of benefits as you know, to prove to you can start work earlier. This is the general model as well. You don't wait for the end of the implementation to get started on planning. And after you implement V2, and you close the two phases of the project at once. So this is one way of doing it. This is the scenario one. You have two phases under the same project. So the second way to go about implementing a project in phases leaves the possibility that potentially we will not be doing festoon, or at least not in the near future. It is like having two projects in a way that we have to go through the full for project management phases. For each phase of the project, you need to get approval for phase 2 as well as you did for phase one. And sometimes this can occur when no phase two is a bit too vague to have it approved. I think that one of the key reason we would have it this way is it's a way to push some work for later when you really cannot do it. Now, It's like having two projects in where we have to go through the full for project management phases for each phase of the project. So you hear that a lot in a project, we will do this in phase 2, which is a polite way to say, no way we are doing this now. We pay what you want, but it will be too big to do it. Now, this is what I have in my example. Next, at the beginning of the project, someone wants to implement something too big, That's care people are in a bit and SEO we'll do part in phase two. So this way, first one is a bit more achievable and we know what we're doing. And after we can stop and reflect and see if we can get the money for phase two. So the scenario 2, same as having two projects. When fest 2, we will not show we want to do it at all, or at least not in the near future. So we say let's do that. Invest to create ID. It has moved it to fess 2. So that's it. Oh, that was a quick summary on walking and multi-phase project and, uh, different ways to go about it. So in my example next, there is some mentioned about, we'll do that in phase two. So don't be confused with the phases of the project management. Phase 2 means we'll do this later on. 21. Project example: Initiation : Just wanted to give you an idea of the things that can be done during the initiation for, for one specific project. Now I've decided to go with the example of hardware store, say that they want to go online. They only have shops around the country, but they would have to have an online website. To have a website where people can just purchase the products and have it sent to them. So this is the project ID credit WIP sell to customers to purchase items online. So an example of activities that could, that could occur. And I put the risks first here. One of the executives may be resi idea that we are not ready for the logistics. You know, it's good to have a website that can be done quickly maybe, but we're not really, I mean, delivering stuff to clients. It's it's usually we might have to subcontract with that, have to do all this end and go through all the legal stuff. And it's gonna it's gonna take us too long. So after, after discussion, it has been agreed to remove this risk. There was, this was just too big to deliver. So we will be doing this in another phase. We will be doing this in phase two. Another research has highlighted a bit less important. So that could be addressed by shadowing told Martin from projects start to John Martin is a business owner so they will have someone to help him. So just to give you an idea of the type of risks that can be discussed during the initiation? The scope would to be to the high level scope was described as is create a website for product display, only new online ordering that has been removed already. The high level cost. There has been some discussion and it was maybe originally 12 million, including the delivery and the rise, but now it's only to be able to see the product cost has been reduced to $10 million. And the high-level deadline just to do the website and everything around the website obviously is a six months. The project team, we have allocated Ben as a project manager. It will create the project charter. And then Ben will get this to get sign-off by the business owner and all the people involved in approvals for this project. 22. Planning phase introduction : And now we are into planning in a one way to summarize planning in one question is, how will we be doing this project? What are the project activities in which order will we be for performing them more precise cause more precise schedule. And another key thing coming from the planning phases are we really sure we understand what we need to do and then we can do the planning for the project execution. The only thing about planning that sometimes it's misunderstood is that we're actually planning for the project activities. We are not actually designing anything. We are just planning for the design to happen. For instance, in the example we have about the website during planning when we look at the business analyst to do the design, but during the execution phase. So the design will be done during the execution phase. So we planning for the project activity family here. 23. Planning phase description: Welcome to the theoretical side of the planning phase. Let's talk a little bit about what's happening in planning. So we are getting more granular on null, the initiation phase activities. All that we've done, we became more precise, more detailed if there was something that was completely miss estimated or wrongly estimated or wrongly understood during initiation. Now is the time to raise it. So we confirm what needs to be done exactly. The business requirements document will be created if that applies. Sometimes there is no business requirements. So just to go back to the example of, of the initiation, when we said sometimes a project has to happen because as a new tax system or that is being implemented or there's a new regulation. So we would have everything already chewed up for us where we know exactly what we need to do. So we don't need any business requirement. We can plan the activities without the business requirements. When can we have this more precisely? What are all the activities required to perform the work? We do a breakdown of the work. So this is when to go back to the example of the Olympics. This is when you start to see all the little things that has to be done that you didn't really think before. When you break everything into smaller parts, then you can have a better idea of work to be done. And any, and you're starting to have a look at dependencies between activities and that will drive the Tammy will take to perform everything. The longer it is, the more time it will take to support and afford the cost will increase as well. You have a look at at staff availability, for instance, and that will dictate when you can deliver this posting more precise as your schedule and you list of activities more precise, therefore, you're coasting will become more precise. We also have a look and how we will be doing this work. So I think that when you plan, it's very intuitive that we want to understand exactly what needs to be done. We want to extend a more precise schedule and we want to understand a more precise costing. But the how we will be doing the project is something that is not always understood or ought to be honest, that is not always being done very well in project management. This is your schedule, this is your cost of Hugo. But I think it's very important to discuss how we will be doing this, how we will be doing this sometimes to a certain extent that can change the coast. So let's have a look at some bullet point. How will we be doing it? Which system we'll be using? Which tools, which resource would be using? How will we check quality? That's very important and the quality of the work and the quality of the final product as well. I think it's also intuitive the quality of the final product. We're going to make sure that this product is, is suitable to the business and also that the product is resilient, it's solid and the likes. But the quality of the work, I mean, as a project manager for instance, you need to provide a quality report. You need to communicate properly. So everything that has to do with quality, I think you can put it there. And this is also related to quality, or as I was mentioning already, is then show the final product is in line with what the business want. The requirement, we understand it has to be solid, resilient, good-quality part. If it's not what the business wanted, then that's not much use to then. We need a way to keep track of this. How will we ensure as we progress in the project that the product is exactly what the business are expecting, seems so obvious. But sometimes even a good willing business and I do proper business requirements in my things progress, they might realize that it's not exactly what they wanted and it will be useless at the end of the day. And I suppose if you've heard of a jar and this is a big advantage of a journalist as you progress you selling to show the product to the client. And they can say, oh, look, I know this is what I wanted, but this is, this is not really going to be useful for me at the end of the day. I mean, having a project that is on time, on budget is great. But for me, if he doesn't give the business what they wanted, even if they change their mind. It's for me, it's a little bit useless. 24. Planning phase description phase 2: Some activities that we do during planning. Are there any new risks that have been uncovered? But now with that, we are more precise. There's a good chance that we kind of find risks that we didn't think of before. And then we put them in a, in a risk register in this document. We can also check if the risk is a show stopper on what is it? Is it big enough that we can stop the project as we progress into planning when we're probably going to have any issue. So this is where we create the initial list or issue register where we put all the issues. I think the most important part of this list is who is responsible for fixing the issue? And as much as possible, the project manager shouldn't be fixing any issues unless it's a governance issue. But there's a tendency sometimes to put a project manager against that and it's not a very good idea if, if they don't have the knowledge or the expertise. So we need to find who from the stakeholders can manage this issue. Towards the end of planning, like we did in during the ionization, we create a document that outlines all the findings of the face. A more detailed schedule. We provide a more detailed cost governance model, testing principles, reporting method, and usually this document is called project management plan. I think this is most commonly used name. And as part of the approval process, the project manager should get this sine of Pi over 2 progressing to the next phase. Remember that initiation, we had a rough cost. During planning, we might find a different type of cost. So it is important that things get, get signed off again. And because this coming out of this, we will have the budget for the project and we will have the formal timeline and schedule for the project and we will be tracking against those. So it's very important if there are discrepancies between what we found in planning and initiation that we adjust numbers in this document and we get it signed off by Bye everyone. 25. Project example: Planning : Back to our example. We are now in planning phase scope. Just to give you an example of activity, the business of providing business requirements. These requirements have been reviewed by a business analyst. The business requirement was formally signed off and is insufficient detail to Louis to design and build the website. So that's fine. So we managed to get the business requirement sign-off. I mentioned the business analyst here because usually a business analyst would be the person designing according to the requirements. So therefore, it's very important that they understand and that everything is clear and detailed in this document. So the business analyst obviously would sign off, but also the business owner and whoever can assign that off from the business side would would have to give a big tick schedule. The schedule has been revised from six to eight month and that needs to be approved. We haven't signed the planning document yet. The cost as the schedulers extended, as we mentioned, the budget would have to be increased to 12 million. It was 10 million before now we want to we want to bring it back to 12 million. And once again, this needs to be approved. They will probably be a bit of going back and forth. As mentioned, the schedule and the cost that is mentioned during the initiation stays with you forever. So you probably any scenario there, you will probably have to put a bit of a fight. In my experience, what happens of 2006? They say, oh, thank you Ben, Very good work there. We're going to stick to six months and we're going to stick to the 10 millions. So you're going to have to run with that. But you can still try. The key risk. No additional risk was uncovered at this stage. Project approach. As I was mentioning, the product or process is how we will be really doing this project. So the company will perform the development of the website in house, but we will be outsourcing the testing to another company, will hire security expert for the site safety. So we have a stake holders least, we have identified exactly who is interested in the project and who can influence it as, as we've seen in the diagram in the introduction of this course. And then all light is done is good. We becoming more precise with the stakeholders, at least project governance activities. We have now a full-on project team. We find all the technical team we have. We have identified the testers. We have identified everybody that we need to run this project and the project managers as put all that into his PMP project management plan. And now we're going to seek approval. And that's it for the planning phase. 26. Execution phase introduction: The project management plan has been signed off. We're good to go. Usually what is good practice? What I like to do is to have a big kickoff meeting as a project manager, it's good that also you'd see fo for the business or for every team member, it's very important to attend. We are formally in bringing everyone together and say guys that said we have a approval, we can go ahead and do it. So it's an opportunity if you're the project manager to set down some ground rules, set your expectations. If you are a team member, it's important for you to understand how this project is going to work, who is involved. Sometimes you don't really know who's, who the businesses, who the tester will be if you're a developer. So you have a good chance here to get introduced to everyone. If you are the business, it's very important as well for you to attend because you would know the players if you're right, you would know who you are, who you will be working with. Obviously, you will be working mainly with the project manager, but you know, you probably have if the business analyst working on your business requirement, you probably spent a lot of time with him or her. You will need to understand how the project works, how the reporting is being done in arrives. So it's very important if you're the business to attend this. And after the kick-off meeting, we can clarify a few things and put that into minutes and then everybody's happy. I like to summarize each phase with a question. And the question I would have for that phase is, how are we going? So the project manager report on progress and manage its risks, issues, and scope. Obviously there there are other things, but I just wanted to keep it simple here. But more or less the project manager job is to ensure that everything is going according to plan. 27. Execution phase description part 1: Welcome back to the execution phase. I want to show you a list of things that a project manager can do to one and show the project stays on track and to communicate effectively on whether a project is that. So one of the things is monitoring or project activities. I mean, this is, this is a little bit obvious. Reporting on a project progress that's for the communication as well as the next bullet point which is communicate effectively to all project stakeholders. We've seen that we've identified different types of stakeholders. And each type might require a different way to communicate to them. Fixing issue. That's also a bit of a catch-all, updating the schedule and the budget as we progress. So this is obviously very important. We don't want to be late. And unlike the Olympics, we don't want to have an overrun. So we want to make sure that by the end of the project, we are still within our budget allocation, reassessing the risks. So for me, that is a very important one. When I work with my team every week, I will review the risk list and I will ask them, does it still make sense? Do we have any new ones or some that I should remove? On top of that, I'd like to have more formal monthly or quarterly meetings on the big projects, quarterly meetings where we are, I invite as many types of stakeholders as I can, especially the business. And I go through this process quite thoroughly. I go for the list and I say, does anyone has any more risk they would like to put on the table. Because what we don't want to happen is in the middle of the project, someone who comes to you if you're the project manager or comes to you as a business person and say, Why haven't you thought of that? And then you can say, Well, you were part of this meeting. You could have brought it as well. I'm really sorry that we missed that. So it's a way to want to cover yourself, to cover the business, make sure that we have these meetings and people really try to dig out any possible risks and trying we are doing no more or less than what was approved in scope. If the business comes to you and say, then, I wanted to add this on the website. Let's say the example that we gave earlier, but the website and I've changed my mind, I wanted to have that instead, and I want to have that on top. So it's not just a matter of using okay. No problem. You need to raise a change request, which is a formal document where you highlight the impact of this change, the intact as far as schedule and as far as cost. So it's going to cost more. The change request needs to be approved. And then you can add the monitor your budget. He said, For instance, I went to chance, I will require one extra month for you to do the work and an extra million say. So you need to have this change request to prove and then you can change your timeframe to add one mumps and had the the million to your budget. 28. Execution phase description part 2: Let's have a quick look at what the end of the execution phase looks like. So usually we have something to implement. So what we need to do is we need to ask the authorisation to implement. So there has to be to come from the business obviously, but also from the technical teams. Everybody needs to be in agreement that we are going live, that this is really happening. So we can have sometimes a meeting with that will be called a go or no-go meeting where we decide if Rico or if we don't go. Sorry for the repetition. So the implementation of the project can take several forms. It could be just a migration of a digital product into the production environment. For IT project. They usually have different environmental, usually have the development environment, the test environment, and the production environment. So the migration of the software into production, that would mean that the end users will be able to access it, to use it. And therefore, you can say this is an implementation on Monday the 23rd, I will implement this project into production. And then this is a big bang implementation and everybody can access it. Another type of implementation is to allow everyone to access the final product. The product was there dormant if you like, not being used by the full public and then it becomes available for everyone to use. That could be the case also for website. But the example I have just here is a breed. For instance, the bridge is finished. It's all squeaky clean. But nobody is really using it because they are still finishing the painting, so or whatever. But on one day and say, okay, we're going live and then everyone can then use the bridge. Another type of implementation is just noting that all project activities are completed. If we go back to our going for a walk project that we talked to his feels like a long time ago. Now, at the beginning of this, if we go back to this example, you've done your work and you're going back home. When you go back home, you say that this project is implemented, it's finished. It's just taking note that all the activities are completed. The last point is that usually when we implement something, there is what we call a warranty period. When the project is still active to fix any issues post implementation. During that period, it's still the project team that would be fixing any issues. The main benefit is that the problem will be fixed faster because the project team still has the knowledge. And in parallel, the project team can handle the older knowledge to any production team. 29. What type of issues do we face during Execution?: Now let's review some of the issues that could be faced during the life of a project. Now the first issue would be that the task take longer than planned to execute. And that could be due to various things. It could be technical issue and controlled. It could be skills issue, it could be poor planning. This is usually the main issue that you have as a project manager and that has a flow on effect on the budget if things take longer than it would cost more. Another issue that would come up is that there are some tasks that had to be done that we haven't planned for. It's a bit unexpected, if you like, that would happen, especially for very large projects. I'm just going to mention the Olympics again. It's very difficult to plan every small task when the project is just so big. And also when it's, when it's a very technical project, when it's a Greenfield projects, things that we've never done before with all the best intentions in the world, you cannot just anticipate every small tasks that you will have to do. You cannot be that granular other during planning. Another challenge that you could have as a team members working on other activities. I don't know if you've heard of metrics, environmental metrics. Environment means that, you know, you have people working for you on the project if you are the project manager, but they're also working for someone else and you are not actually the manager. You have what we call a dotted line to them. So in this case, it's very difficult that say they would be located 50 percent to your project. So you need to make sure that they work does 50 percent and they have allocated to your project. If they if they workplace, then obviously we will have problems. You could get delays. And sometimes if they work more, you need to keep an eye on it as well because that would mean they would tell you more and that will cause more money at the end of the project. So this is one of the challenges that you would face. Another challenge that I would put down is the stakeholders not, not engaged at all, not interested? Let seems to be quite brutal type of statement if you like, but it happens. It's very difficult for someone who's not actually working on the project all the time. And I'm not talking about technical teams now, I'm talking about even, even the business of stakeholders. It's very difficult for them to stay focused during the life of the project. And the challenge you would have is they lose interest a little bit. And then they come back two or three months later when you lead your, your project to a certain point where they don't lie. And then in this case it's, it's difficult to bring them back. It's very important to keep them engaged to make sure that they are all on board. So they are, they don't come later down the track and say, or this is not the way I wanted this to happen. And then all types of issues that you can imagine. At the end of the day, I think this is why we have project managers obviously, is that things never go really according to plan otherwise, why would you have a project manager, a project coordinator type, just to do the administration would be sufficient. 30. What's with Risk and Issues being 2 lists?: Welcome back to the course. We'll talk about the risk register bit later in the course in part three. But I just wanted to show you the dependency between risk and an issue that that's another thing that can be obvious for some, but I thought I will, I will throw that in here. So you have a risk register with all the risks. So if the risk has not occurred yet, it stays open. Is this active until it occurs? So you have it in your risk register. You manage it in here, you review it from time to time. Now, if the risk occurs, let's say it runs now and it's delaying things. So therefore the risk has occurred. So what you do is you close the risk because it's not a risk anymore. It's happening. It's real-life, It's now. But what you do, you open an issue instead of having the risk it could rain, instead you have an issue. Training. Sorry if it seems obvious, but that project management tok, if you like, you sometime is not intuitive that you have to remove it from the risk register. And then you manage it as a, as an issue. So obviously, sometimes when risk occurs, there's a plan and you act on this plan. So therefore, it may not even reach the issue stage. But this is the most common flow if you like. You need to manage it until completion there just to give you a quick overview because sometimes people ask me, Well, why do we have to register 14 risk for issues? That's why I wanted to clarify this. 31. Project example: Execution phase: Let's go back to this example. So how is everyone? I hope everyone is still with me. I hope you are still enjoying this. And we're getting close to the end of the phases is still another important window. I want to go back to the example of the website, and I want to show you some example of activities that would happen during execution. Let's have a look. Scope. So the change request presented by the business include store selection too low for availability status of the project. So the business came to us and they say, you have the products, that's very nice. Now what, what I would really like to do is for our clients, by putting their postcode suburb. They can check if the store next door they have the product that they want. If you remember initially we said, Oh, we don't want to deliver, but I think this information would still be very useful for them. So the business put that as a request. So the revise coast from 12 to 12.5 million to allow for that change was part of the change request and the request was approved. So that means that we can spend more money. The deadline also a shifted because it requires more work. And that was also an attentional quiz that was approved. So instead of having a mumps to deliver now we have nine months to grow for these issues. The key issue is that the key staff developer turnover, so we have a very technical team and they end has a lot of turnover and there will be concerned about this. So we did a bit of a brainstorming and we have a bit of a kind of a solution with being able to take resources from other projects and selfishly on our own project. Because it's a very important project, is very strategic project. And it looks like we have some, some agreement on this. Just to give you an example of an issue. Next, gardening stakeholders, the technical team morale has been down due to staff turnover putting more pressure on other. So this is more a note if you like, there is this turnover and F0, 11 guys leaves the others have more work and more pressure. So it's something for me as a project manager to keep an eye on and to work with the teams manager. As mentioned, I don't have the hard line of reporting with them. It just a dotted line, but I need to make sure that I keep them happy. Project governance. I've done my monthly report and there is a note on next Steering Committee will happen on August 24th. Other activity of note, the website will migrate to a test environment on the 27th of August to allow for a test him to perform the initial testing. So that just to note also that you would put in your report, you have date where you implement the project. But it's also good to give some milestones in between. So you go from the development environment to the test environment and after to the production environment. So don't worry if you don't fully understand this environment, businesses just to give you an idea of any activity that could take place. So this was the last slide on execution. And now we have one thing to do. We have to close this project. 32. Closing phase introduction: We have implemented our project. So now we can just move on to another project, right? Not quite. We still have to close the project. They are times where we don't have time to close the project. Sometimes someone comes to you at the end of your project. If you're a project manager, NSA band, you have to work on something else. Now forget about this. So closing doesn't always occur as well. So that's already the second phase at that I mentioned, it doesn't always occur. And the reason is that sometimes people just move on too quickly. You turn and you will look at your team. They've already gone, they're really working on other projects. Same for, same for the project manager. Sometime they move very quickly on other projects. But it's always good practice to do it. And I like to do it as much as I can. And I will show you some of the activities in a actually quite important. Let's have a look. The question I used to summarize closing is, Is it all done? And how did we go? So the project manager clauses the project when all activities are completed. Some key activities that occur during closing. So that might make more sense when you have a look at the next slide, but for the moment, I'll go through these quickly. So is everything completed. The budget clause, the budget Close and means that there were some money we give it back more or less or we give a final report on on the money. He said no more open issues. Does a production team know how to maintain the product? We need to make sure that we handle the older knowledge to whoever will take care of the product moving forward. And how did we go? Any lesson that we could learn for the next time we do a similar project. Let's say you are the project manager, you do something very similar and you would come to this project, listen, learn and you would say, Oh, what are they learned to make sure I don't make the same mistake? And this lesson learned, it's usually done during a formal meeting which we call the post-implementation review. And if you're lucky, you even have a post-implementation review document that summarizes all the, all the things that we've done well and all the things that maybe we didn't do as well or we could improve on. Do we want to reward the team? Usually, the answer is yes. Do we have the formal approval to close? So this is the approval part, if you like, you need to make sure everybody agrees. Can I close it? And then the project managers can write a closure document. And this is where they put the final numbers for the budget may be. And they can refer back to the post-implementation review for listened, learned. So anyone interested can just have a look at this document that I want to go to the next slide and show you some examples. 33. Closing phase: examples of activities: Let's have a look at some activities that can occur during the closing of the project. I like to split it into two types of activities. I think it makes it a little bit clearer. Make sure you don't lose track of anything. So there is a closing activities and they are the handover activities. I just want to go through the closing activities first. So there's all that he's reporting and paperwork. Obviously the project closure document, That's very important that the stakeholders signing off on the project closure document also, not just a matter of sending the document and see all the best, but sometimes just between you and me, please don't say that really. Only else. The project closure and then never get signed off. You know, it's hard enough to get the interest and and to get someone to sign on the dotted line. But asking them to sign a closure document, It's quite scary. So they they usually you'll ever get anything back. And then you can find all the documentation. As far as resourcing, you know, obviously you pay the final invoices and you publish the final budget figures that in your financial team, if you have one, they'd be very interested. And then you obviously release all the resources that you do not need anymore. Lessons learned. If we can a post-implementation review where we get opinion from everyone. Hopefully it'll be a peaceful meeting. Handle their activities. I like to put them into two types, the deliverables and then the risk and issues. So the deliverables. So we need to make sure that we have all the sign-off from the stakeholders. We need to make sure that we provide the documentation of the product to the team that will be maintaining this product. And we need to make sure that they understand the obviously and then risk and issues. So that's interesting. So usually have a few issues. It see you implement a website and it's still a glitch somewhere that you try to fix as hard as you could, but you can still fix. So what you have to do is you have to handover that to the team that will take care of the product. They will fix it themselves minute the project cannot go on forever. And sometimes it's a bit rare, but you could have some outstanding risks and you can hand them over to let them know just so that, you know, we might still have this risk. But at the end of the day, it will not happen during the life of the project. You keep it in mind. So that's it with closing the project. Let's have a look at the example. 34. Project example: Closing phase: Closing phase for our project example, the website to be implemented. Under the scope part. We said there's no No atonic work, so we've done, we've done it all. We've implemented all that we were supposed to deliver. The coast. The budget closed at 12.3 million against our estimate of 12.5 million we have delivered under budget issues. There are three outstanding technical issues slash defects. Those will be handed over to the production support slash BAU, which mean business as usual team. So it was a website and they still free defects on the website, but we want to close the project and we handed over to the production team governance. We had a PIR. And I will be sending the minutes to all the executive and to all the stakeholders and all the project team members. Celebrations, Yeah, the project team will add the final greetings On September 2005. As I hope you will have once you finish this course. 35. Introducing the roadmap: Now, I would like to introduce you to the roadmap that have created. You have your process, your four phases on top, and you have your land areas to keep an eye on on the left. Now the roadmap can be used two ways. You want a refresher on what we do during initiation. You go down that way. And then you take everything. And then no one know what's happening in execution sent him. That's a sequential way of having a look at things as the project progresses. You can have a look at the other way. And let's see scope. What do we do in initiation on scope planning? What do we do in planning on scope execution? What is happening to us? Cope during execution and enclosing. So you can have a look at it in a vertical way and horizontal way as well. 36. Roadmap walkthrough: Welcome back. So this is the roadmap that we mentioned at the beginning of the course. I think it will make more sense to you now, now that you went through the part 2 and we walked you through the process, etc. Look, scope. During initiation, you ensure that the key components to be delivered are clearly stated. As you go into planning, the business usually create a detailed business requirements and the project manager will usually summarize the scope in a PNP. The ring monitoring. What you need to do is to keep an eye on the scope. And if there is a deviation, you need to address it with a change request if the business comes to you and then when a change, you need a change request. During closing is also very important. You need to make sure that we turn it so that the business is satisfied. Budget slash cost. In assessment of the initiation, you have an order of magnitude. It's high-level budget. In planning it go into more detail. During the execution, you make sure we keep on track. And during closure, we return the funds. Schedule, initiation, high-level implementation dates. You go into planning, you have a detailed planning. You are in execution, you monitor regular, you, you make sure that we keep on track and that will take you a lot of your time and this is where all your issues will come up. The schedule is being delayed and closing. There is nothing to do. Nobody cares about when you will close the protect. You will not get a lot of pressure on this. So I'll just simplify, put new action they risks. During initiation. I mentioned that this is where the highlighting the key risk is really critical. During planning, you update the risk register. If you have more risks and you plan for the risks a bit more precisely. In execution, you monitor and update regularly. I talked about monthly meetings with everyone and their enclosing. You return the risk contingency, which is say, if you have to plan for a risk, he said I want more money because if this risk happen, I want to be able to do a, B, C, and that cost me money. And this, in this case, you would return that money obviously at the end of the project if the risk has not occurred. Quality in initiation usually we don't do much. During planning. This is important. This is where you plan for, for the quality. And during execution, obviously you make sure that everything is being done according to the book. The project manager is responsible for the quality to be implemented. That is not really responsible for the quality itself. If you have a top-notch test manager and she tells you everything is tested, I'm confident, it's all good and they show you the test results. Perfect. That's all you need. You don't want to go and testing yourself, but you need to make sure that the testing plan has been implemented. In closing, There's no action quality. Now you could argue that the PIR and the lesson learned if you do all these meetings properly and you close properly, this is part of the quality of the project, but this is not critical at this stage, the product itself has been implemented and your project is reaching the end phase. Issues. As mentioned, you in trouble if you have issues during initiation, but usually it's pretty quiet. They start to crop up into planning. And this is where you create your issue log. And then during execution, this is more or less all that you do is you fix issues and you monitor them and you and you are looking at them and enclosing you, you check if there's any outstanding issues and if they are, you make sure that you hand them over to someone else because I still need to be fixed. You just don't want those to be forgotten. Project administration during initiation. Your key job as a project manager is to run the project charter. That will summarize the findings. Same from planning. The difference is a project management plan. Summarize the findings of planning. During execution, you need to make sure that you communicate. You chair meetings, you produce reports, project reports. It's all about communicating with stakeholders and lungs. And then in closing, you run the project closure document, listen and document and analyze stakeholders. You create a stakeholder matrix or you tried to do it's not often, don't. And then you had the child, the project team definition. This is where you define your team in planning. You refine it now you know more information. So you might want to bring more people into it. You might want to outsource some components of it. And execution. You execute the communication plan. You execute the communication plan based on the stakeholders. For this type of stakeholders, I'm going to communicate this way. So you have your weekly meetings with your team, say you have steering committees, you have four more reports. And imposing this, there's nothing to be done. Approval. So I have approvals, as I mentioned, in a separate area because I think it's important to highlight the key parts that need to be signed off. During initiation. The key thing to be signed off is the project charter. By the business. Usually they are the one want the project or by whoever has initiated the project. During planning. Pmp needs to be approved, signed off. During execution. A lot of things need to be signed off along the way depending on the structure of the project. So for an IT project, you will need to sign off on the design, on the testing, on going live. But on other types of project where these components are not included, then it could be simpler. You can just say, okay, I'm finished, everything all is done. Are we good to sign off on this project during closing the project material document, if you manage to have it signed off, if it be the very good. And that can be signed off by the business, the steering committee or whoever. So this is the roadmap. I found that my students are responding very well to it. And it's also at the end of the course. It's also a very good way to summarize and review everything. So I haven't really worked you for it exactly word for word. So have a look. But that's a good summary of the project management process. 37. 7 key documents in Project Management: Welcome back. Now we are more in a summary part of the course. So a good way that I've found sometimes to really understand a process and really actually nail a process is to really understand its outputs. I have selected seven documents that I believe if you understand them, you will understand project management better whether you want to become a project manager, but also if you any type of stakeholder and you are involved in the project. So you could ask the Project Manager for any of those documents. And then 1, you will sound like you, you know, what you what you're doing to that will really help you better understand the project and where to find the information that you require. No big surprises. I believe that I've mentioned already those documents, but it's good to have a look at them from a different perspective. I think it's very good for retention. I'm sure you're dying to know what 07 documents are. So let's get started straight away. Here they are. Project charter reports, any type of reports, schedule, issue, least risk register, budget, and PMP project management plan. As such right away with the project charter. 38. Project Charter: As you can recall, at the end of the phase, we need to decide if yes or no, we are going ahead with this project. So this document should help everyone. And actually small formality, I think usually the decision has already been made, but it's good to refer back to this document, whether your project manager or a stakeholder, you can go back to this document and you can have a bit of a time machine and you can have a look at how it really all started. So this document contains the cost, the timeframe, the key risks and the likes when end of initiation phase. And why this document has been created is to provide the formal approval to proceed as a project. 39. Reports: Next documents are reports. What type of reports that I'm just saying report. It means any type of project report. It could be the Weekly Report to be the steering committee. It will be the monthly report. So what happens is, the more frequent the reports, the more detail you put into them. You Weekly Report are usually for your manager or even for the team. Just to give them a quick update on what's happening, what we've done during the week. But as you go up the chain, they don't have time to go through all these details. You have steering committee report has to be very succinct. Only the key issues and how are we doing. And the monthly report is it usually also for executives or people that are, in theory, we are more and more busy as we go up the chain is not always the case, but this is what they want us to believe anyway. When weekly, monthly, or ad hoc. Why? Because those reports provide an up-to-date status on the project. There is also a quick way to check the project status. It's called the traffic lights. Green and the red green. It usually means that the project is going okay. And the means some issues started to creep in. And red is a project is not going well, it's probably going to be late or above budget. Why do we have those traffic lights? As mentioned, the top-notch executives, they usually go through 2030 project report, but this is a good way for them to quickly go. Usually they focus on the ones that are not going well. And we understand why. So that's it for the report. 40. Schedule: Schedule, so it's sometimes called a plan. The parameters calling it a project plan, it's a bit of confusion with the project management plan that we'll see. But it's for me, it's anything that has vapor in it. It can be a Gantt chart. So a quick look refresher. What again, child is looks like this. Or it could be just a simple list of milestones. Or I like to do in my report, I just put the key milestones so we don't have to go through the full Gantt chart every time when could be look at anytime, usually during the initiation and during planning also it's still being drafted is still quite high level. But at the end of planning, you should have a very solid schedule and all your assessment of the project would be based around that schedule. Why? I mentioned these arrows you to have an idea of where the project is. Add not only by the end debt, but also by the milestones. If you have a project that you are interested in that is going to be implemented in July and you go to who see the project manager in February and you ask him or her, when is this projector we're going to be implemented? Are we on track? It's gonna see it. That's fine. July will be implemented. But if you look at the schedule and you will notice some milestones happening in maybe February, March, April. And you can check how the project is tracking in reference to those milestones. Because otherwise you don't want to wet early July and C, So are we how are we on track or not? Are known by the way, it's going to be September now. So this is what you want to avoid. 41. Issue list: Now let's review the issue list. So to document containing the project key issues, including the impact of the issue, who is owning the issue, and when we are anticipating to resolve the issue, same thing. You go to the project manager. How are we doing and say, Oh, we have a couple of issues, but you don't really want them to be summarized that quickly. So you can go to this document, you can have a look. The impact of the issue. Is it an issue that is actually impacting the budget or the timeframes? That will be the key thing I want out of this, the impact of the issue. Who is owning the issue? We don't want to be in a situation when I thought you were working on. And there is also this assumption that the project manager is managing everything. I think I already talked about that, but it's very important that any type of issue, technical analogues that the project manager puts that to someone else. It's very important that the owner or the issue knows that he or she has to fix it. And by when and when are we anticipating to resolve this issue? Because I'm working on it, that's not good enough. I mean, sometimes it's very difficult to assess, obviously, but we need another date where we can meet and say, well, we agreed on this date now, still trying to work on it. Can we do something to help analyze? When you're hopefully you don't start raising issues during the initiation of the project when it's not even a project. But I would say that it's during execution that this document is most active. And why I mentioned it already, the display that you know, where they are, the issues, who wants them and how close are we to fixing them. We want to remove the vagueness of the report. We want to really understand where we add. 42. Risk register: Now for the risk register document containing the project key risks. As far issue, we need to document the impact of the risk. If, if this risk happens, is it going to impact anything, budget, timeframe or it's just going to be a bump on the road. What are we doing about that risk? We could accept it, we could avoid it, we could mitigate it. Mean that there's an area of things that we can do. But I think for these fundamentals course, I'm not gonna go into, into detail, but if you aware that there is acceptance, avoidance mitigation, that's already a very good start. You could say Yes, I accept it and say Yes, I know this risk could happen. That's fine. I'm okay with it. Not an add-on. I don't want this re swap and then I want to avoid it at all costs. In ordering the work, you know that there could be some very heavy rent. What do we do if we have Iran's? It's good to have a plan for that. Owning a risk, you need to monitor the risk. And if something occurs, you need to initiate the mitigation plan. You cannot do that all the time as a project manager on all the risk, you need to have an owner. For that risk. You could say you take care of this risk, you monitor it, let us know if it becomes more likely to happen. And when it occurs, let me know. We will initiate the mitigation plan or we will do what we said we'll do if that risk, okay? When used anytime that we created during the initiation, it is key during the initiation, as I mentioned, I don't want to repeat myself too much, but a risk could be so big that we just decide we don't do the project at all. So while this list make everyone aware of the risk of the project would face, this is unawareness communication tool. And this is the way I like to say it's awareness communication tool. 43. Budget document: What to look for: Budget. There is no standard in project management. There is not one single template that all project managers use. What's important is the numbers at the end of the day doesn't really matter how you get there. This document need to include several things. How much money we have allocated to the project, how much money we have spent so far, and how much will it cost to complete? I have. On the next slide, I'll show you very technical diagram on this. So when, during created during the initiation where it's still broad brushes and during planning, this is really when we have the final version. As for the schedule, once the planning is approved in a project management plan, we have the schedule and the cost that they are frozen. And after they are being used to check if you are over budget or under budget. Why? Because we want to be able to compare a with B plus C. I started the project here, 40 million, say, this is the budget allocated. And now you have several mumps into the project. You have spent 20 million and you redo your budget, you you recalculate. This is what I have left to do. How much it's gonna cost me to perform those activities. It will cost you 22 million and to finish the project. So you had b plus c and that gives you 42 million. And you know now that you're going to be over budget, you might be able to do things to bring you back and Costco. So this is why it's good to be aware of that early. 44. PMP = Project Management Plan: Final document, the project management plan or PNP. These documents created at the end of the lining. It is a very important document as well because we have completed planning, so we know much more. And you are expected as a project manager to have a good grip on the cost and the schedule at this stage. Unlike initiation where everything is happening quickly. Now you have done all your planning so you should know much better or much money you will need. And when the project can finish. On top of that, this document really dictates how we will run the project, who will be testing. We're going to add to some of the work, what are the quality controls that we'll have in place? This should be the first document that you asked for your project manager. You take over a project. You want to know what is in this document because at freely, this is your baseline. This is what you will base your work on. This is what you can check if we're going off course is created during planning and signed off at the end of planning. So when we go into execution, we have this document sign-off printed on our desk. And y, as mentioned, it can be used as a reference. 45. How to talk to a PM to get what you want: Welcome back. We still summarizing, reviewing things at this stage. And what I think is important is how do we talk to each other during a project? I believe this will help you if you are involved in a project. You know already some of the jargon, you know, the questions to ask. So I think there will be very helpful for you to keep an eye on this. Those are suggestion that I have. Don't ask them who's involved. I'm sure you can answer that one, but what do we ask them? Can I check the stakeholders released as much and it's not often created, so there'll be, there'll be a good test. Don't ask where we add. Ask. Can I see the last project report? Because I want to really see numbers. I want to see the real thing. Don't ask. Are we thought of something? You can say, Can I check the risk register because the project manager might tell you, yeah, yeah, we follow that. But if you can access the register, then you know all the key risks. You can select only the key risks and you can check what are we going to do about those and who is owning them. That's a much more granular view of things. And also you can see, oh yes, they released this all the risk to others thought about that one. It's good to know that they've thought about it. Don't ask this any problems. It's just too vague. And if you'd be very hard for you to differentiate the small program from the big problems. So what I suggest is any key issue in the issue list. But you could have an issue as does the morning. And then leaving it solved. If you go and see your project manager and it's a she's at a desk and you go to her and you ask her, have any issues and entities. You are, Hey, we have this R that is just came up and are really overwhelmed by it. But, you know, it might just be finished by the end of the day. So she must just be thinking about that issue now because it's critical and it just came out. But you want to have a look at the long-term view as well. You might have issues in your issue list that could be even bigger than the one she mentioned to you. Don't ask any change of plan. Ask any change request approved. Because once again, it has to be approved until it's a change of plan. Say they tell you, I don't know. They want the center want that. But this is just noise until it's approved, then you're better off just knowing what has actually been approved. That removes all the noise. How did we go on this project? And then everything went well, is that true of any lessons learned? Can I see the document? Can I see the PIR? Because it's very vague. Once again, I mean, it depends on how interested you are in a project. Obviously, you might not care that much, but if you care a lot, let's say you want to, your project manager and you want to do a project that is very similar, you're not going to ask the PM. How did we go? You say, I see the lessons learned document. If they don't have a lessons learned document, the best thing for you to do is you ask the project manager, but also ask the other stakeholders. Because a project manager to have a very specific view, it went okay, Let's stake holder might have a completely different view. I mean, the envy of the way around the project manager might think that was issue after issue after issue, but the technical teams or the stakeholders might think it went okay, lets it some suggestions on how to get to know more on what's happening behind the scenes on the project. You could ask those questions to the project manager. 46. Project Management always the answer?: Just to note to close on the project management, I suppose, is that some companies can be quite small and at the same time, quite mature with a strong governance. And they don't always need projects for smallish activities because you have very flexible. And when I know that someone is doing it, they know that he or she is doing it. They have visibility. And therefore they, they choose not to use Project for those activities. They can also, as they are small, they can easily keep track of the coast and arrives on the other end of the scale. Large companies, usually government companies are very big companies. They usually have a project for everything. So it can become quite heavy. And also the benefits I think sometimes are quite questionable. So they like the idea of having all the budget centralized, all activities visible from a center point. So they can see exactly what's happening, how much money is being spent across the board on those activities. They love having everything centralized so much that they are willing to pay the price for overusing project management in a way by having a project for everything. So the challenge with project management is not in the process itself. It's when it's overused. So we're getting really close to the end now. They just move on to the conclusion. 47. Conclusion: And now this is the end of the course. I hope you enjoyed it. I enjoyed providing those courses. For this one, the challenge for me was to provide you something not too long. I want it to have it a bit of a condensed view and project management. But at the same time, I wanted to give you something useful, something that you can take home, and something that will help you in real life. So I didn't want to give you something to high-level, you know, those things. So high level that you don't learn anything from them. And that's why I was trying to give examples like a website, something that is quite concrete. If you have any questions, obviously, I'm always happy to answer them. If you want some advice, you can send me a message. If you could take some time to have a look at the bonus video after this one way I can talk about some others of my courses. But in any case, whatever you decide to do, I'm just wishing you all the best. 48. Next steps: Welcome to the bonus video. So this is the video where I tell you about my other courses. Suppose so please feel free to turn that off if you're not interested. At the moment, I have two other courses. I have one on Microsoft Project, which is a tool that is being used to develop schedules. So you do not absolutely need to have Microsoft Project. You can go through the course and learn more about Microsoft protect. And if you have Microsoft Project, then you can do the exercises as well. Another course that I have is regarding project management, but in a more detailed fashion. It's eight hours long. I go into much more detail on every phase of the process. Also have one component in there that it's called an async project management. So you can really become a top node project manager. So this is it. That's all I had to say on this video. Once again, all the best. Welcome to the introduction of this course. So this course will show you all that you need to know about project management theory and in real life, and also how to ace it as a project manager, had been a project manager for 20 years. I've also been a project management coach for 10 years and I've also worked with project managers myself as a program manager, as a manager to a really understand what is expected of project management to ensure that at the end of this course you are project management experts. I will be using the role of diagrams, templates, example quizzes, truly make sure that the concepts are really understood. But at the same time, I will also highlight the differences between the theory and the real life. The project manager 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 to become more efficient. In other words, I will show you what is important, elicit, and 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 A's project manager. I 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. It's all done healing project plan. In the third part, in part 3, we will review on the high level some methodologies so you can see how this course relate to them and I will give you my opinion and how important they are and really put all my 20 years experience into this course. So 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 are 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. But this course is a 15 minute long overview. I know 15-minute is long, but I've created that for those of you who aren't sure 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.