Acing Project Management - Part 1: Project Management course (and in Real Life situations context) | Ben Moreau | Skillshare

Playback Speed

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

Acing Project Management - Part 1: Project Management course (and in Real Life situations context)

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

93 Lessons (5h 3m)
    • 1. Acing Project Management: course intro

    • 2. Let's get started!

    • 3. Detailed course overview

    • 4. Understanding Project Management - Check how it could have all started!

    • 5. Things to know for the course

    • 6. Terminology used

    • 7. What is project management

    • 8. Role of the project manager

    • 9. Introduction to Part 1: PM course

    • 10. Phase 1: Initiation - Overview of

    • 11. Purpose of the initiation phase

    • 12. PM role in the Initiation phase

    • 13. Project Charter

    • 14. Scope during Initiation: introduction

    • 15. Scope: example and tips

    • 16. Cost during Initiation: Example

    • 17. Types of cost

    • 18. Initiation: 3 points estimate for costing

    • 19. Project cost example at Initiation

    • 20. Stakeholder part 1 introduction

    • 21. Stakeholder part 2 Stakeholder definition

    • 22. Stakeholder part 3 Stakeholder Matrix example

    • 23. Stakeholder part 4 communication plan example

    • 24. Risk Management during Initiation

    • 25. Defining Risk types

    • 26. Defining Risk outcomes

    • 27. Defining Risk Severity

    • 28. Risk Register example

    • 29. 32 Risk tips

    • 30. Project Structure Introduction and basic structure

    • 31. Project Structure: Project Office

    • 32. Project Structure: Project outsourced

    • 33. Project Structure: Steering committee 06 05

    • 34. Optional: Project Charter example

    • 35. Optional: Additional Examples

    • 36. Phase 1: Initiation wrap up

    • 37. Phase 2: Planning section overview

    • 38. Phase 2: Planning purpose

    • 39. Role of PM during Planning

    • 40. Project Management Plan Definition

    • 41. Requirements: Introduction

    • 42. Work Breakdown Structure: WBS definition

    • 43. Scheduling: Introduction

    • 44. Scheduling: Breaking down Execution

    • 45. Execution planning examples

    • 46. Building a Schedule: Steps and example

    • 47. Schedule Types part 1 Milestone and Timeline views

    • 48. Schedule Types part 2 Gantt Charts and attachments

    • 49. Costing during Planning: Introduction

    • 50. Costing: fixed Price and Time and Material

    • 51. Costing: FP and T&M Example

    • 52. Budget example

    • 53. Schedule based budget

    • 54. Budget contingency

    • 55. Quality planning introduction

    • 56. Quality planning - How do we do it?

    • 57. Quality: Types of Testing

    • 58. Quality: Example of Testing for Soft development projects

    • 59. Optional: Project Management Plan Example

    • 60. Phase 2: Planning wrap up

    • 61. Phase 3: Execution section overview

    • 62. Execution intro

    • 63. Purpose of the Execution phase

    • 64. PM role in the Execution phase

    • 65. Scheduling in the Execution phase: introduction

    • 66. Critical path definition

    • 67. Schedule monitoring

    • 68. Scope Management

    • 69. Change control

    • 70. Issue Management: part 1 Introduction

    • 71. Issue Management part 2: Issue Register

    • 72. Common Issues

    • 73. Project Meetings: introduction and types

    • 74. Meetings and Reports: What to discuss

    • 75. Meeting minutes and template

    • 76. Project Reporting: Introduction and what to include

    • 77. RAG Status introduction

    • 78. RAG Status with tolerance

    • 79. Project Report example

    • 80. Budget tracking: intro and Actuals Definition

    • 81. Tracking budget month by month

    • 82. Earned Value simple example

    • 83. Earned value formula and Example

    • 84. Earned value for Scheduling

    • 85. Phase 3: Execution - wrap up

    • 86. Phase 4: Closing - section overview

    • 87. Closure purpose

    • 88. Project Closure activities part 1

    • 89. Project Closure activities part 2: PIR

    • 90. Phase 4: Closure wrap up

    • 91. Part 1 Recap - overview of phase activities

    • 92. PM adaptation for each phase

    • 93. Part 1 - conclusion

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

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

This class is Part 1 of a 3 part program designed for those wanting to learn and excel at Project Management: (See below for 3 part breakdown)

If you ever wanted to understand project Management, become a project manager or bring your project management skills to the next level...

Then this course is for you.

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.

So I have learned from it and wanted to make a course that would provide you with all you need to understand project management - both the theory and the practical / real life components. I also wanted to make it more palatable by including diagrams, templates, plenty of examples and some quizzes.

As part of this course I also provide a framework to go beyond being just a standard project manager - to really ace it. A very concrete, step by step framework that if you follow - will really take you to the next level in project management, you would be out there with the best!

And finally this course includes an introduction to the most common methodologies/standards in Project Management (PMP, Prince2, Waterfall, Agile).


Who this course is for:

  • Anyone interested in Project Management

  • People interested in becoming a Project Manager

  • Project Managers who want to up their game.

Course outline:

  • Part 1:¬†

    Introduction, tips to follow the course, introduction to Project Management, the Birth of Project Management legend.  

    The full Project Management course (including all phases of Project Management, Practical view, how to simplify, with lots of diagrams and examples)

  • Part 2:¬†

    A framework to ace it as a Project Manager, including the overall Project Management context and what to say at interviews.

  • Part 3:¬†The course in context of some Project Management standards (PMP, Prince2, Waterfall, Agile)¬†

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 

I have been delivering as a Project Manager for more than 20 years working for (amongst others) IBM, HP, large Financial companies, Telecom and Government agencies.

I have also mentored and coached Project Managers for more than 10 years in various industries.

My certifications below as Project Manager

- Prince2

- PMP/PMBOK (Project Management Professional)

- Agile Project Management

- MSP (Managing Successful Programs)


I am also a Life coach, fascinated by all things related to Self improvement, Self Development and overall being a better human being each day...


See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

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. Acing Project Management: course intro: Welcome to the introduction of this course. This course will show you all that you need to know about project management in theory and in real-life. And also out to a seat as a project manager, had been a project manager for 20 years. I've also been a Project Management Coach for ten years and I've also worked with project managers myself as a program manager. As a manager. So I really understand what is expected of project management to ensure that at the end of this course you are project management expert. I will be using the role of diagrams, templates, example, quizzes to really 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. But the second 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 eat 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 Manager. In the third part, in part three, we will review on a high level some methodologies so you can see how this course relate to them. And I will give you my opinion on how important they are. Really put all my 20 years experience into this course. So if you are interested in project management, if you interested in getting into project management as a project manager. And maybe if you are 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 to me. 2. Let's get started!: Well, thank you so much for taking on this course. I really appreciate it and I hope it will be worth your while. So please don't hesitate any point in time if there's something that is unclear or if you want more, something added, as I will say, no conclusion as well if you want, if there's enough demand, I'm happy to add some topics. So if you haven't seen the course outline, the next video will provide you more detail on the overall course. But if you just want to dive straight into it, please go into the tips to review this course and there's some suggestion on some resources to print. And after you can go into the little story on the birth of project management. So thanks again and all the best to you and hope you get a lot from this. 3. Detailed course overview : So what follows is a course outline. It's a bit long because I wanted to be very thorough. If you are still hesitating, if you're not sure if you want to purchase this course or not, I thought I would help, even towards the end, there is a bit of a comparison table based on your liberally furor that will tell you if the court is suitable for you or not. Having said that if you have already committed to the program, to the course, it could be useful if you like to have a thorough understanding of what's ahead of you. But if not, feel free to skip it and go straight to the next lecture. Welcome to the course overview. Before we get started in course content, I just wanted to have a quick overview of the pharaohs of fi, first, this five components, if you like that, I have put together to ensure that the course is one, hopefully pleasant to follow and to that will increase retention. So there is a practical view on concepts, real-life scenarios. So that should make the course easier to learn. So there'll be a lot of examples for obvious reasons is always better. For example, some time we don't fully grasp the concept, but as soon as their example comes, yes, we see how it relates to realize. We will also show as much as possible how to simplify how we can implement what we have learned quickly. You know, and I think also that will make it easier to master. So at something simple, easier to understand, easier to master. And then you can take it from there in all of diagrams. And I think they are great way to communicate a concept sometimes, so there'll be a lot of those. And finally, for part one, which is a course in part three, which is a standards, there will be quizzes. Nasa, we've put that behind us. Course content. What will you learn? We start off with an introduction, some suggestions that I have for you to take the course. So for instance, there is a roadmap here that what I call a roadmap. I know that some of you like to look ahead with what's in a course. So they like to have to print out or put that handy on your tablet so you can follow where we add the various functionalities. But some just prefer just to take it step-by-step. So it would be completely up to you. But I will suggest some resource that you could print. We will review what I have called The Birth of project management. So it's something that is completely personal. Don't quote me on it. It's how I imagined that a project management was born to have done allele a story around that. And that would be a good way to introduce you to project management and how I think the various phases of project management were born. So that will lead us to the phases of project management and the, and the various activities to project management. And after briefly, we'll provide a definition of project management and the role of the project manager. And we will finish by quasar AD. So and then we will move on to part one. So part one is the course of project management. So the structure is very simple. Project management is divided in phases. So during this course, we will just go through the phases more or less, will have an overview before hand and after we review the four phases, which are initiation, planning, execution, and closing. And after we'll do a review and a wrap-up. Within those phases, some concepts, topics, tools will be explained. And I just wanted to review those with you. So we won't go through the full course. I just wanted to highlight what will we cover amongst other things. So for each phase that we will review, we'll discuss a phase purpose. We will provide the key competence, what it means if the outcome sought on the, on the very high level. After we review the project manager role, for each one of those phases, we will review stakeholder management. That would be obviously like all topics that I'm running. You fruit now, it will come back for different phases. We will review who, how the stakeholders review how we can classify them. And we'll review an example on how to store this information then and make a communication plan. Nowadays, we will review or so the project structure. We have a few slides around this. This is just one structure, but I think it's important sometime on your phone, you need to protect manager's role to understand the structure. So we'll have several examples of structure. We will review risk management, will review risk, severity, how to assess it, and we will review a very precise example of risk register. So how to structure it properly and the different types of outcome that we could have for each risk listed will review scope. The importance of scope. Why is it useful how to, you know, created? And we will review the change control process. So that's not all as I'm mentioning, but just to give you an idea of how the course is structured and the different type of sludge you could have. So we'll talk about the scheduling where I will provide some suggestions how to build a schedule. Based on this, how would also provide some suggested steps to build a schedule. Different representation of a schedule. How to monitor schedule using the MS project software. What is a critical path and out to quickly check it on the schedule. We review obviously cost and budget, which is also very important part of project management. I will suggest a very easy way to split to start to get you started on a budget. I will review with you a few of those examples, very concrete, very clear. Hopefully. We will review a concept called earned value, which is the project management methodology like to discuss. But as you've seen, I'm just gonna go back to that slide here. I'd just like to present it extremely simply, initially after we go into more complex examples. But always the example, always the concept of adding something practical and an example to go, to go along with it. We will review quality management. So this is when, you know, usually you start getting to sleep. I'm trying to make it as interesting as possible. It is quite important, but it's showed that when you, it's quite heavy to learn when you go through all these project management courses. So hopefully have simplified it and at the same time kept, kept it very practical and complete as opposed to provide a lot of information here, highlighting the ones that are really important will reveal. So obviously issue management. We some slide around this and very clear example of the issue register with a template project meetings. So we will review also that in part two where I gave you my proper way on how to manage project. But we will review in part one here, the, you know, to buy the book way and the different types of meetings that you can, you can have. So there is also obviously templates that we will review and discuss. We will also discuss project reporting, which is very important to perception of a project manager. So also will walk through a template where reviewers, so the closing activity, so I put closing a bit separate because it's something that is often rushed, but I'm hoping that have provided a way for you to know really the two key components of this. And I'll explain why something that you can use as an abort in T2 shine as a project manager for the very reason I was providing before, it's often rushed. So if you do it properly then I think you stake holders would be impressed. I will provide some templates, or we've seen that. We've seen some of the templates, but they will be more and examples. Once again, this is just to give you an example, there's a project management plan, which is a document a project manager creates. So I will give examples of the stuff exactly. Take a project as an example and exactly what you should put in and you can put more, but, you know, the starting point I think is very important. So that's it. So it was just a quick overview of some of the topics that you will see the So before you commit to this course, you know, you know what, your get more or less hopefully with this. So that was for part one. B2 is the framework to really take part one and really take it to the next level to really ACT. In my view, they will be free components. The first component, we will review the project management context. What is the context of a project manager when he joins a company? What does he or she has to deal with? And after we'll go into the framework. So the framework is not something fluffy, something very concrete. I will tell you exactly what you need to do. I will provide you is examples and the likes, but it's, it's, it's very, it's very concrete serif or levering that point, but it's not something fluffy That would be nice if you could do these buddy, not just do ABCD. So and finally, we will go into a tiger tip. So I interviewed a lot of project managers and I have been interviewed obviously as a project manager as well. And I have done the hard work and I know what works and what doesn't work. So we can review these. So that's it for part two. Fat-free, it's raw methodology, so path free, I put it towards the end so that you can see how this course fits in with the existing methodologies if you like. Pnp and prints too, if you haven't heard of them, they are project management methodologies. You day obviously very long, take weeks to learn and they have very thorough examined arrives. So obviously, I am not going to give you a PNP and a prince to cause this. So this is not the purpose of this course. But I wanted to give you some context to show you how these course relates to PNP and prints too, more or less. The idea behind that was just to show you that it's more or less the same. All project management methodologies are the same. So we reveal so waterfall and agile, waterfall being no by default method used for project management. I will just go that very quickly and a Zhao, I will provide a little bit more information. I will show you an example. And we'll also, towards the end, provide a comparison between HR and waterfall, the pros and cons. So if you want to ring waterfall in a jar, you can use both using the part one of the core. So it's just a different way to deliver the work if you like. That seed, we only left with one question. Is this course for you? This course is for you if you want to understand project management. If you want to become a project manager, or if you want to perfect your project management skills. And we, if we go into a little bit more detail, if you if you like, I don't know you. So I just just gonna go through different levels here and see if that, if that's a match for you. So let's say you are beginning early man, and you don't understand project management at all as this course is definitely for you. I mean, I'll take it from the beginning as I was saying, I was just giving you a little story and how I imagine the project management was born. So I think that you will find that very useful. So there's three parts in this course. So if you're a beginner or lay man, I would suggest that you start obviously with part one. And after you do PO2 and after you do part f3. So this is for you if you're in this category, if your intermediate, I really think you're going to learn from it as well. I'm putting all my experience in this as a coach and as a project manager. And you will I am sure you will get something for part one, part two, part three. And if you don't, then I will gladly reimburse you. I think it's part of the terms of the course anyway. Now if you advanced, Mm-hm. Sure, you could learn from this as well. I really put some effort into putting a framework together. So the PO2, I would be surprised if you don't get anything from this. But you could also get something from part one and part three, I believe so. Actually, I'm quite interested if you've if you want to have a look. This is how I would really suggest it potentially, potentially. And yes, here. So that's it. So we went for the course, philosophy, diagrams, examples, practical view quizzes to help you retain information and our lives are provide a precise description of the course content, which is, has three parts. The first part, the course itself, the second part, know-how to really take it to the next level. And the third part to give more a bit of a context of discourse amongst other project management methodologies. And hopefully we finally answer the question is, is cause for you or not? 4. Understanding Project Management - Check how it could have all started!: So the next few slides is completely made-up story. More targeted this time here if you've never done project management. And I think he will introduce you to project management from a different angle. What I found is in the project management methodology is and tell you, yes, this is a four phases and the likes and this is the purpose of each phase, but they don't tell you how they came to light and why create them to start with. Also, if you, if you a little bit familiar for project management, I recommend that you go through these. I don't think it's hard to watch. I think it's a rabid fan as some photos and some diagrams in it. So hopefully you'll enjoy them. Then of course, as we progress through the course, you will get the form or buy the book tap of meaning of each one of those phases. Having said that, let's go into it right away. Welcome to this part of the course. Ok, so don't quote me on this please. This is, this is probably not accurate. So these vertices, how I imagine as a bit of a learning tool, how project management could have been born. So imagine there is a queen, she has leaders, but they are always focusing on the daily task on the walls and stuff like that. So but she still has large project that she wants to implement. So the work is disorganized. Anos projects, teams are tied more, they seems to be always running out. So she sits, she, she's saying, you know, I have leaders, but that's not sufficient. And if someone really focusing on this. So we were about to witness the birth of project management. Issues as large and ever lacking coordination, monitoring, and a solution, provide a dedicated resource to manage methodically worked to completion. A project manager. Are there for mq project manager to the queen. Go and make sure things are running smoothly. Gimme occur from time to time. So thanks. I suggest that we catch up after it's all done to close things off and see if we can improve things for next time, we do this. Ok, so we have a project manager already and we have our business owner. So let's see how it worked on the first project they had. First project, Trier won the queen gather project. And the project manager was doing role of monitoring, was doing a role of fixing. See what I mean, and communicating as well. And after the closure. So that's why I was mentioning before. Let's let's catch up at the end of the project is to check out things where we're going. And then the queen can have the benefits of a project. So a completion project manager reports back to the queen as agreed. What did you say? Okay. I think we can improve on this. I was not sure what I was monitoring against. When was this old you I didn't know. Much more legit I have I was not even sure much money I had. It would have helped if I knew some of the stuff that could happen beforehand. Like nobody told me about this. Who was I supposed to communicate to and how, you know, the queen was too busy, she didn't return the core. And what was this project total body any way? What was the plan? Okay, well, he's lucky. The queen is quite nice person, so okay, okay, I see your point for an XP project is stick the time to sit down and plan on how we communicate, how we do things. We can progress when we all agree on a plan. So let's have the blend first. We agree on a plan and then we progress. Let's do this. Okay? So those are the tasks that the project manager was doing before, but now is added a couple of more tasks. He added some planning, and then there was a plan approval. So how did that go? You think trial number two? So again, project let's see, took two months of planning and after the plan is presented for approval to the queen. Okay, Planning is finished. It will cost you 51.6 pounds of gold. And we should be able to complete it in 26 months or so. On a side note, we might lose 51.3% of our Army process. I mean, this is obviously precise for one reason there you see what I'm getting at. So the queenly or DC where all this waste, we do not have the money, we don't have the pounds of gold. And I can't afford to, uh, to use because the 26 months to finish really to see the benefits, it is not worth it. I wouldn't approve this project if I had at least a rough idea of the cost and how long it would take to wield that huge risk of losing half Miami. So she was not aware of the risk. And she just heard, but the incredibly high cost and how long the protocol and and the worst part is it has spends two moms or two moms paying the project manager and all this team to come up with something that she knew she didn't want. Surely, there's a better way to do it. So that the project manager goes back to her and say, okay, I suggest we do quick assessment this time. Note this to moms blending free most planning. We do a quick assessment and give you some basic information before starting planning on our projects. We can give you the high-level cause timeframes who will participate. So this way you can decide if starting the project, planning, even it were four, I'll have to warn you, it won't be as precise, but at least you have, you have an idea and you can make a decision. So let's see, I admit. Final trial. So before there was planning, plan approval, monitoring, fixing, communication, closure, all that was already happening. But what they have decided this damage to add two steps. So notice this is not project anymore, just an ID or a need. Okay, it's not a project yet. It's just, you know, some discussion that happened. Yeah, why don't we do this or we absolutely need to do that. And there's an assessment. And then there is an action here. Is the project approved? So after a couple of weeks, not no. Moms, your assessment is completed as agree. They say they'll do a quick assessment. Quick assessment completed costs you roughly 30 pound. That this is all just so that you can keep up. This is a final project. This is the third project if you like this. So this is why it's not 50 pounds anymore. It's only for 30 pounds is a different project. It because sure, free 30 pounds of gold and we should be able to complete it, sinks, mumps, no loss of Amin a process. Would you like to go ahead. It's not a project yet. It's doing the assessment. And she said, Yeah, like this process much better. Now I have some key information before I give the go-ahead for potential projects. I realize it's not as detailed as during planning, but it is enough for me to approve or decline project proposals based on FM mesh. And you gave me we had a winner. Let's go ahead with this project and notice, now we have a project. This, we don't want to call it project it. Because in the previous example, there was just too long to an adequate decided. We're not gonna do it, so it's not a project. So anyway, yay, okay. Now this is what we have. We have all these activities that happen. The project not being a project here and all that productivities and after the queen can have the benefits. So what we can do is we can group those activities in what we call phases in project management. Because we realize all those two could be grouped, the blue ones there could be grouped in, let say we call it the initiation phase. We, the second pallet, we add it, we call it the planning phase. So initiation planning. So this is how it was at the beginning. So what do we do for the other activities? We split them into two groups. We have the execution here, and we have the clothing that was agreed at the very beginning. When they said, you know, let's, let's agree to catch up at the end to see if we improved or not. So this is why they have, they've improved their processes by catching up during the closure of the project. So what we have here, its phases. So we have outline if you like, four phases, initiation, planning, execution, and closing. And what we have on the left-hand side of this diagram is activities. And we have in this case, 12345678 activities. So some of those activities are just approvals process, they are actually an important step. So they are, they are there. So that takes you from an ID to a project, to the benefits of the project. We need something that absolutely has to do. We don't really want to have this policy implemented, that we are being asked to have this implemented, so it's a need. But we still go through this process any way of assessing and project and benefits. So that's it. My take on project management. You can see why there is this different types of phases. By catching up after the project, you can do you your next project better. The execution, it's all go-go, go. The planning is to give you a more precise idea of what the project will be like. An initiation is really to, you know, do we even want to do this? But we will review all this. I just thought I wanted to link back that story with, with the next one, which is really when we start to go into more detail on this. So that said, let's move on to the next part of the course. 5. Things to know for the course : So before we get started, just in case you don't know how how it works. Yes, it's the first time you take this top of course. For some lectures, there are some attachments to them. It can be PDFs where I put some of the slides there. There can be Templates, registers. When we go into scheduling, I will attach some schedules. So for every lecture, feel free to have a look at these attachments on time that can help you can have them handy if need be. But right now, there are two PDFs attached to this video, and I think they'll be quite useful for you to print or have handy during the life of the course. They are both roadmaps. The first one is just show you an overview of the phases and the key components of the phases. The second one is very similar, but it also shows you what are the outputs of a project manager. What at the end of the day, the project manager needs to create. So I suggest you print those. In the next video we'll talk about terminology and also suggests you print or you have handy the one on terminology. Another notice that you'll see on some of the slides, there is sometimes an advanced written on top right, top left. So this is just to tell you that if you are a bit overwhelmed, feel free to skip those. I know when you go through a long course like this, sometimes you just, your brain wants to have a break, so just skip them and maybe you can come back to them later on. They are a bit advanced. That means they are command in project management, but not as command as the, as the other components. So now let's have a look at some of the terminology. 6. Terminology used: This is a terminology that I was referring to. So let's give some definitions. I promise I won't be too long, but it would be worthwhile. So product, the product is end goal for the project. You know, when you build a bridge, for instance, the end product or the deliverable. It's the bridge. It's what the project bridge. So you'll hear me mentioned products. That means what the project will give you deliverables. So there are components the project team we need to deliver at the end of the project. In the example of the bridge, or could be the bridge, etcetera. But B, also all the operation manuals for the bridge. All the here give the various document test results and arrive. So anything that the project team produces Morris BAU or to businesses, Julie, if you're not familiar with this, it's part of the organization that runs all daily activities. And this is why project management was prone. Because everybody was so focusing on what they were doing every day and out of the Sudan, you have a large project coming in and you know, and everybody is busy doing their own stuff, so they have dedicated resource. So business as usual is the part of the company that do daily activities and the project teams focusing on project. So the client, customer, business. So it's a stakeholder needing the project outcome. So it's more or less for who we are working. I will use those terms. I will use business more often than client or customer. So upper management, executive team as opposed to manager that we'll see later. Upper management for me, it's it's it's part of the business that I that are above you in a way that doesn't mean that they are involved in your project. But in senior broader sense, not necessarily the working on the project, but it could be the CEO of the company, could be an executive manager of another part of the company. And the manager, when I refer to as a manager, also known as line manager, program manager for the project manager. It's your boss. If you're a project manager is the guy above you. So when I say, do you have to give these to your manager or you have to give the to your to the business. They are different entities. 7. What is project management: Next we are attempting to define project management. Please bear in mind two things. The first thing is that there are so many definition of project management. I'm not attempting to give you one. I've created one that reflects way what project management is. But there are those out there. They usually include the word endeavor, which I really wanted to avoid a lower cost. And this is one thing to bear in mind is there are always exceptions. And some companies use project management in a very flexible, flexible way. So nothing is set in stone. And in a way that's what interesting about project management. But let's get into those definitions. What is project management? Project management is a practice of coordinating the work of a team to achieve a specific goal as at a specific time. So the reason why team he has is you don't really need a team. And putting in brackets. Because in my view of project management, and not only in my view actually predict management can be a one-person. I mean, I'm sure you've heard of this disguise running a project on their own, but what is key? He has a specific goal at a specific time. So if it's not a very specific goal, it cannot really be called a project management h gets more business as usual. And at a specific time as well, when it becomes ongoing, when it becomes something recurring, that happens every free moms or even every year. It did. They shouldn't be called projects. They should be, they should be given another name. It's a once off project. And note that a specific goal needs to be loud enough or important enough to be a project. You know, you have a business is your team, they have something small to do. Do they need to have the whole project team WES reporting process in place and with a budget and arrives probably not. So it's not a project, it's just an activity that is on top. So to be called a projecting to be large enough. So this is just referring back to business as your project team and projectivity as separate from the company's business as usual resources. We'll see that sometimes that can be shared resources. But as entities, they are considered separate. 8. Role of the project manager: The first challenge I would say when you're a project manager is to ensure that the team understand your role when especially when you go to company, they've never had project managers or project management. They see you rubbing and they think, oh, there's a new admin guy there. Let's ask him or her to do this, to do that. So it's very important to set boundaries at the beginning. But for the companies that are more mature, they know what project management is. You know, I think it'll be much easier, but, but still, they're still be tempted to be the person who does what nobody else can do. So it's very easy to fall into the trap and do a lot of things that you are not supposed to do. So let's discuss the role of the project manager now. So the role of the project manager, he or she owns the project, responsible for it. Doesn't always have all the authority. The treaty is responsible to get things over the line. Let's have a look at a few bullet points. So the PN, that's another, that's another acronym for project manager or project management. The project manager plans or activities, obviously with other resources. But he has the responsibility to plan. When all this is plan, coordination and prioritization of activities, reporting, communication. Sitting executive's how things are going. Issues. That's a big one during the execution phase, as we'll see, this is the kick patient of a project manager. I mean, you could argue there's no if there were no issues, who would need a project manager. So this is what we do. And just some friends and budget are respected. That's also a big one. As we've seen in the beginning, the story of the Queen. She was having all these activities burning money. So someone is to be accountable for. It. Ensures sufficient quality has been applied. I mean, this is why we're seeing quality is not the most popular of all activities in project management that, you know, in my view, if you, if you deliver something on time and on budget and it's not it's not good quality or he's not the something that the business wanted, then it's, it's, it's not better. So implement within constraints for me to good way to summarize the role of the project when I'm Manager, there is something to implement. He or she has to implement within all the constraints which are timeframes, budget, and the right. So here we have our summary of what is project management and the role of the project manager to complete, we could draw the similarities between our life and accompanies live if you like. We all have our daily activities to do. And this is why I'm doing live coaching now as well. Because the similarities with project management are so obvious. We all have things that we would like to do, but we never get around to them because we are focusing on our, on our daily lives. And companies are the same and this is why they bring in project managers. So they can really focus on that and they have to do it. And you have to do all the coordination. And the other was, chances are it would if it, if it happens, you will happen at a much slower pace. Now, having said that, let's move on to part one. 9. Introduction to Part 1: PM course: So welcome to part one of this course. So part one is a full-on project management course, all the theory, but at the same time with a practical taken it. So during part one, we will review each one of those phases that we have defined. During the introduction. We start with a high-level review and after we will drill down into more detail for each one of those phases. So let's get started. 10. Phase 1: Initiation - Overview of : Let's get started with phase one initiation. If all we do is have a quick overview of the section. We will discuss the purpose of this phase. We will discuss the project manager role. In this phase, we will review the creation of a key document, which is called the project charter and various components of this document. But more precisely, we will discuss the scope. Cost is stakeholder management who will review the risk management? We will review the structure of the project and then we will wrap up and provide some examples. 11. Purpose of the initiation phase: Welcome back. So next, we will be defining the purpose of the initiation phase. The first thing to bear in mind is this initiation phase does not always exist. Another project management methodologies out there telling you, yes, you need to have an issue unphased, but in real life, sometimes it doesn't exist. So just as a quick reminder, the initials and phase is whether you decide if the project we go ahead or not. But there are some companies that don't care. They just want to do the job. Sometimes they have just a mandate. They have the budget, and they want to do it. And I don't want to have to go through all the initiation process. And sometimes they just don't have the choice. Sometimes it's just the government necessity sometimes to legal change that is required. And therefore, no point discussing if we're gonna do it or not because we know we have to do it. And also what happens sometimes is initiation phase happens behind closed doors. You are not involved and I think that makes sense. Why involve a project manager when the project is not really, you know, concrete yet. So there will be a group of executives discussing several project ideas and decide after a while we do this and that. And then they can bring the team. They can say, well, we want to project manager for this. We want to put a project charter together. We'll see what that means. But now let's assume that the initiation phase takes place. The purpose of this phase, in a few words, why are we doing this? And is it feasible? The key components that we need to make this decision is we need to have a look, scope. There's copays. What is this about? What are we doing? The cost and the schedule. So it could be a very good idea, but if he takes for years, he might not be a good idea by the end of it. And of course might be also prohibitive, might be just too expensive. We more or less put on a business case. Sometimes the business case is being done separately by the business, but sometimes the project manager, if he's part of this phase, would assist in creating a some type of a business case who cut the because benefits strategy goals that come out of it and see if yes or no we can go ahead with this project, will have a look at the key risks. Sometimes there is a risk that is just so big that the business will make the decision straight off the bat not to go ahead with this project. So for that reason, it's important to highlight the risk. Now we don't want to go into planning and execution. And after reorder these risk is just too big. And he just hits us and he just can sell to the project. And then when we are reasonably confident this project would go head, we can start putting a project team together will have a look at the key resources. If the project manager involved, they really will assist with this or starting, gather resources from the the business teams and to put a project team together. The key outcomes hot is yes, to get approval to start the project familiar, we need some type of sign off and we will see that we will use a document called a project charter that is sometimes used to put all these components, all these details on the project together in one document and we'll get this document sign-off and then we can say, yes, we we call it, this project has been approved and we can formally go into planning. Now let's review the role of the project manager. 12. PM role in the Initiation phase: The role of the project manager in initiation phase is optional. Sometimes, even when there is a formal initiation phase occurring, the project manager is not involved. I think that makes sense. There's no point in involving a project manager if we are not confident the project we go head. So in this case, the project manager will be brought in towards the end of the initiation When we are quite confident that the project will take place and then we can build a project team around the project manager. And the other thing to bear in mind is that sometimes the project manager comes from a third party, say when a project is outsource. So the role and the origin of the project manager depends, will depend on the type of project and in the initiation phase, they will decide as a decided project team, they were also decide who they want to protect manager to be a project manager, job P part of the company, or would they be part of the third body, or maybe one project manager each? So we will review different scenario under the project director component of this course. We talked about the project charter and this is what we'll be reviewing next. It's, I would say the key reason why the project manager is involved in his phases, the business would like someone to put all the paperwork for approval together. And this is where the project manager role starts with paperwork. So we bring all the components that we've seen before that from part of initiation into one document. 13. Project Charter: Now let's review the project charter. So the project charter is a document the project manager puts together towards the end of initiation, really to summarize all the findings of the initiation phase, all that has been discussed, put that in an ass document, the schedule, the budget, and the big risks, as we'll see, and put all that in a document. Can you please sign off this document, everyone, too? We all agree what we are doing. And then when this sign off and you can go into the next phase, you can go into a more precise planning in a way. So next we will review all the key components of the project charter. And then we will go into more detail and for some of those components. So you have here listed the key component of this document. The project objectives and a business case are often included in these documents. So the business would stepped the outcome they want from the project and any benefits and why is it worth doing? We will review the scope in more detail in the following slides. The scheduled at the state would be very simple. Some high-level timeframes with an ended, you know, we will see this, we know we have some examples at the end of these slides. We will review this. The budget. We will also review which type of machetes expected at each stage of the project. As mentioned, the risks are important early in a project, so we will need to list them as part of this document. And then the project team, the stakeholders, we discussed that already, but we will go into more detail on project structure and stakeholders list and arrives. And if possible, we'd like to confirm early in the project who will be the approvers for this project. So most of the components listed here will be refined during the next phase, during the planning phase. So this is a suppose what I had lunch and early in his courses at some components will be seen in the initiation and then reviewed in planning and then monitored and managing execution. So as something to bear in mind. Sometimes some of these components here can only be defined later on. Sometime the initiation goes so fast that risk for instances only and a budget can only be fine tune during planning that we stick to the theoretical view and hopefully we'll have all these components included. 14. Scope during Initiation: introduction: Welcome back to the course. So the first thing to define when we start a project is what are we doing? So this is what we call the scope. Sometimes is called requirements. You will see later on that you know, the scope and requirements could mean the same thing more or less. And we'll see this COP is more high level, it's more than the boundaries. And requirement is more detail what's inside requirements? The terminology that business analyst law like, like to youth. So what is important bearing in mind that we are only initiation and the project might not even go ahead. What we need to bear in mind is that we don't want to get bogged down into too much detail sometime we don't have a lot of time either. So the scope during initiation, it has to be very high level. We want to make sure that we have included all the big chunks, all the big components of the project. So this is, this is critical because if you forget one of the big chunks, then it's, the more you progress in a project of the more difficult it is to bring it back. If it's a small detail that then that that's easier. But what is as important as what is in scope is what is out of scope. It you have to make it very clear on the document that we do not do this. We do not do that. Imagine you're an executive and you have the assumption that something is included in the project only to realize halfway through the project that it was not included. So this is why you, you, you, you give them a chance. You say, well, this is out of scope. This to make it clear, we are not doing this. And then they Executive She has the opportunity there to say yes, but I want it in and then it's not too late because the budget hasn't been locked in yet. We can go back, increased the scope and Crito scheduled whatever. But at this stage, it's it's still okay. The more you progress, the more difficult it will be. So now when I suggest we do is we have a look at an example. 15. Scope: example and tips : I'm just going to show you an example here that I think will show you the level of detail that is sufficient in a scope. Let's take the example of a website that needs to be stood up. The managing director wants to start selling its product on the website. He doesn't have a website, but he does have the resources to ride the content. And it needs a project for someone outside is team to set up the infrastructure around the website. So the project statement could look something like this. The project will include and that means that the project will have in scope is sourcing and registration of the host named infrastructure for hosting the website. These on Beale rollout security testing and setting up the ongoing maintenance. We said we fit body. So we can add more words to this. We can suppose that the stage say as much as we can. But usually we don't have that luxury and we just yet, this is what we want. And this is on the high level, what we would like to protect data out of scope. It's to avoid any misunderstanding with a project team when the business will engage a project team is this will be out of scope. We don't want you to write the content of the website. We will take care of the policy approval and the ongoing maintenance of the website. We really don't want you to do it. We just want you to organize the maintenance for it. So we doesn't have to be complicated. It just few bullet points like that are usually enough. If you have someone from business who ever say, Oh, that's a bit vague and then you can drill down a little bit. As I was saying, usually has to be done very quickly. Don't pay attention to this. Just to highlight that we can sometimes make things very simple, very complicated. I've never had the business or program manager or anyone telling me, Oh, your scope statement doesn't hold water. So as long as everybody agrees this is really what is critical at this stage. That doesn't prevent the fact from the scope is very important. But if the process doesn't have to be complex, the scope can be changed, it run. So this is what we call the scope control or the change control. So that will be elaborated more in the next phase. So during initiation, we wanna make sure that the key thing to remember is we want to make sure that we do not quote unquote, forget any law loud chunk of the project. And we want to also obviously, clearly stipulated what we do not want the project to deliver, which is the narrow scope component. But that's pretty much sheep for the scope during initiation. 16. Cost during Initiation: Example : Welcome back to the course. Let's review coast during the initiation. Initiation, as we've seen, it's all fast and high level. We don't have too much time to spend in detail analysis. So the key message is the same message that we had for scope. I just do our best not to forget in the large component. So obviously cost would be also discuss during the next phase is to the ring planning, where we will learn how to put a budget together. And we will also be reviewing coast during the execution, we will keep track of our budget. But for the moment, let's review how we can put a course together just during the initiation phase. 17. Types of cost: So let's assume we have someone from the business who has a product idea. Sometimes they've done all the hard work for us and they've done their own investigation. They already had a coast and it just handles the paperwork. But at other times, they are requesting the project team to big data course for them. So obviously this is assuming that there is projecting that can assist regardless of who's doing the cost. It's usually done on a very high level. So before we get started, I just wanted to highlight a couple of ways that of course can be calculated. The first of course, estimate is the rough order of magnitude ROM estimate. You would hear that. So that can be done by combination of expert judgment. Top-down estimating, an analogous estimating. The ROM estimate is is perfect for an initiation. It's something that is very highly though, but still give them an ID if they can afford it or not. And expert judgment can be used sometimes is you have one of those gurus, for instance, to setup a website, as we said before, someone who say, Oh yeah, you wanna set up a website, have all infrastructural down that's going to cost you around 200 grand or the likes. So that's something that is sometime, sometime used. Want to kick off the project quickly. We free up the $200 thousand and then we will get started. Another method that is used is called the top-down estimating. And it's the high level estimate as well. But it's calculated by adding all the high-level components of a project together. For instance, you for the website with other cost of the materials, the course of the of the contractors and the likes. And you would would add all that up and I would give you a high level ID. So it's very similar to the next one which is the analogous estimate. It's, it's an estimating that is being done by using a previous example of something that has been done that is very similar. So this is more, this is, as I was saying, this is perfect for initiation because it's high-level. The stage, yes, the business is with some prime expecting a plus, minus and 3 estimating that we'll be seeing in the next slide. The second type of estimated score, detailed estimate. There's only one way to have a detailed estimate, it's just the bottom. But, but when we go into planning, we'll see how, how this is actually used. We can sometime also called this definitive, which is a bit scary initiation to how the definitive budget, when we know all the smaller components and we add them all up. We are usually pretty close to the final estimate. So this is more suited for the planning phase? Yes. 18. Initiation: 3 points estimate for costing: So I mentioned when we discuss the ROM, the three-point estimation, I just found out to be a bit tricky because if you go to the business and you tell them this will cost you 2,000,000 plus or minus the press being the worst case, the minus being the best case, then it doesn't usually fly. When you say, well, you could, you could pay it, that will cost you 200 thousand, but it could go up to 300. Fascinated, usually you'd be scared too, but they lack, lack the best-case. But they don't really like the worst-case. But it's sometimes with Rahm is to be expected. We are on the high labor stuff. So please bear in mind that it sees only a rough estimate and you could have some additional cost to read, but we could have also a dreamer and that would be the base case. 19. Project cost example at Initiation: I want to give an example. So just to show you that once again, initiation phase doesn't have to be too granular. Following our previous example, I'm just reminding being simpler here quickly being sampled off the website and that is being setup so that the CIO of the company has estimated the cost of this website and you will be around 520 K. So infrastructure 200 k, design, build and test 200 k. Security testing handed K. Ongoing maintenance, 20 K, you add all that up. You have 520 K. So the CIO, It's you have an expert judgment. Even if the project is outsource their CIO of the company leading the project, they will come to you and I will say, Yep, you want to have that done? These guys can this company can do do it for you and it's usually around 520 K to be precise, because of this maintenance that comes at a 20 kit extra. So this is the example that you would have when you rely on the expert judgment to do the estimate. So that's pretty much it for the cost. Once again, when we go to planning, we will be a bit more granular on how we can come up with the course. But initiation quickly, they want to know on a high level how much it will cause they're gonna get approvals. They can add a little bit on top if they use the free point estimating so as to make sure that they can cover some contingency there. But that's all that is required. And in your project charter, you would add Steadman project cost and you would just list these and it would be perfect. Once again, like for the scope, if you know more if you are can be more granular. Yes. By all means, go for it. But usually you don't have that luxury. 20. Stakeholder part 1 introduction: Welcome to the stakeholder management part of the course. So in project management, there's a lot of stress on delivering on time and on budget. But for me, the project is not a success. If at the end of the project you have stakeholders that are unhappy, it doesn't matter who it is. For me, it's not a success. Just to give you an example. So you could be on time and on budget. But what you deliver is not exactly what the business wants. It is what we agreed to do at the beginning of the project. For them. Everything has been signed off and the likes, but they're not fully satisfied. So why and the unsatisfied did, did, did we really engage with them during the life of the project? Some project managers really don't like to engage to mesh with the business and ask them how they are and if they are happy with what we are doing because they are concerned that the business would come and say, oh, actually, I'm not really happy with that. And the project managers would then have to do a lot of work to, to include this. But for me it is something I'd like to do. So I want to know I want to know how they feel about what we are doing. I want to know if there have maybe they changed their mind somehow. I want to know that, I need to know that. So in order to quote-unquote track of stakeholders, we need a tool. So there's a tool that is commonly used. It's called the stakeholder matrix of the stakeholder engagement metrics. So it's being done in two parts. The first part would be to come up with a list of all the stakeholders. And the second part would be to assess the stakeholders. So we would assess how interested they are in a project. And we will also assess the influence that they could have on the project. So that's very important. So during part two, we'll review Another way to truck stakeholders. So it's not part of the formal project management methodology. So that's why I have it in part to it's more my own stuff. It is part of the framework that have created. And it's actually a tool that I'm that have created and an amusing that has served me very well over the years. So I just like to suggest it as well as another way for you to quote-unquote truck stakeholders. But for the moment, we stick to the former methodology and we start putting together a stakeholder matrix. 21. Stakeholder part 2 Stakeholder definition: First, let's have a look at the definition of a stakeholder. So a stakeholder is anyone involved in a project or being impacted by it? Who are you working with? So that could be, that's the obvious ones that, that, that your team, your peers, even influence the project management. And you are working with who we receive the benefits of the project that's more around the business, external customers to users. There'll be receiving some of the benefits who can interrupt the project? I think this is something that is often forgotten. Yes, the business wants this, yes, the projecting me super motivated. If someone can come let fear then out of the sudden interrupted but the project and that, that is something that needs to be done. I mean, in government for instance, you could be running on the project very happy. Everybody's happy, but there's a budget cut. And that's something that you need to keep an eye on. So they will be part of your, of your project. It would be a stakeholder that we need to maintain the relationship was if we can at least be aware of their presence. Who provides the Monet that obviously your stakeholder as well. Who will operate the end product that uses all the contractors, suppliers. So we need to put a stakeholder list together. One way to go about it is to start on stakeholder matrix, where we put all the stakeholders and we categorize them based on their interest and their influence on the project. First of all, we have some stakeholders who don't have much influence and they don't have much interest. So we will monitor all doors so they more or less that, that cannot really impact the project and don't have a strong interest in the project. Minor. If we move to the left, to the right, sorry, we have the stakeholders that have low influence, that they have high interest in it. Top-left will have some stakeholders that are very high in France. And they have a low interest, yet we need to keep them satisfied. But I'll come back to this one because this is my mom, I need my favorite. And then you have the high influence, high-interest, and you need to manage those closely. Those are the guys that can have a lot of influence on the project and are very interested in it. This is the guys are more or less you need to keep happy. Another way to manage closely, I would say keep happy that my, my favorite grouped to keep track on because they are, they are the one lurking is this group here, the high influence, low-interest, smallest, the stakeholders who sometime they are just there were against the project. So that's why they have low interest. But they could enter the project potentially because they do have high influence. So this is the group that how would personally be very well if I'm in the one that have high interest, you could argue that as they have a high interest, don't worry about getting in touch with them because they will get in touch with you because they are interested. So this is why for me, I think the top-left is, is as if not more important, and I miss one. 22. Stakeholder part 3 Stakeholder Matrix example: So busy slide. But there's no thing like an example. Let's say we have a project, the software development project. And then we have managed to list all our stakeholders here. So if we look on the left-hand side, there's a Project Manager, test manager that we have looked then manager, we have the business analyst, we have the infrastructure team lead, finance manager, senior user, and et cetera. So for instance, a project manager, you has high interest and I'm sorry to say he hasn't medium influence is doesn't have that at high and influence on the project. Obviously you can, you can make it can influence the outcome of the project by speeding things up when he can. But at the end of the day, we cannot just say, let's stop these projects that that's not the role either. Test manager is a building assembled Somalis just testing. Of course, they have high interests because they, they the one that will be testing the thing. And, but an influence is medium. Once again, it kinda be toasted. Stop it. So we'll have a look at the communication colon. At the end of this. Development manager, he's got also high interest. I would submit your men freelance business, not East High, even low influence. Just an example. I mean, obviously you would have situation where I interested in influent, excuse me, is different infrastructures to team lead Sam. And then we go to the finance manager. So the finance manager would have a low interest sometimes in a high interference. So this is the scenario we're saying before, and that's why I say it's, it's, it's really for me a key while you wouldn't show measure of interest. But at the end of the day, it could say, sorry, we had to pull your budget and give it to another project if he's not really. So this is why it's very important to have a strategy to deal with these planets manager, senior user, same thing, low-interest, maybe something it didn't, it didn't want to go with a new product. It doesn't tell you the new software, but he's got a very high influence at the end of the day if we do all this work and he says, now sorry, not happy with this. And then that's something that we have the length of the project, try and influence him or her. And then you go down the list, operation manager, business representative. The last one I want to mention is a senior executive. So he's in a category, obviously high interest, high interference. So those are also the one that you need to manage closely. But at least as I we're seeing, you know, you'd see them. They wouldn't be lurking in the dark as opposed to maybe some finance manager or the senior user. So don't, don't, don't take this as, as a, as a truth for all project. You just, you just one example of how things could could be, could be on a project where, for instance, the finance manager as, as a very high interest in it, because it's going to improve. This is bottom line at the end of the financial year. So it is just an example. 23. Stakeholder part 4 communication plan example: Something that was said in a previous slide is regarding this matrix that can be used as a basis for communication plan as part of the project. Sometimes you have a communication plan. And what I think is the best way to do it is to use these stakeholder matrix here. And the stakeholder management plan. If you want, you can call it this way two, more or less put your communication plan together so you kill two birds with one stone. Here you have your matrix. By the way, this is not something that can always be, be published for obvious reasons. But you can, you can tailor your communication and based on the interest in influence factors. So if you take an example, the finance manager here, so I have already highlighted is high influence but he has low interest. So I need to find some type of strategy to to to mores raises interests and to make sure I doesn't come at the last minute to know to take some money off of the project. So what I have here, for instance, attempt to communicate regularly, keep closely in a loop on any budget related matter matters. The senior user, you would have the part of the Steering Committee try and bringing in a steering committee, her and the attempt to communicate with rigorous outside a certain community. So we will discuss the steering committee later on. But that's just to show the communication colon is use it how we will be communicating with results, stakeholders, and just wanted to ally below. And we can very quickly go through the communication strategies. We would have 3T others, des manager. We will bring her to the productive meetings. We will send emails. That's where we will communicate with her development manager. We will it will be part of some part of the project team where we send emails. The infrastructure team lead. We will be bringing to weekly project meetings to get his buying because sometimes they're working on so many projects, it's hard to get them interested. The operation manager in our communication we would have. Keeping in the loop by sending witty reports will increase engagement when close to implementation date, because the interest will grow as we get closer to the delivery date. The business representative will make her part of the weekly meetings and we will communicate with emails. The Senior Executive, obviously we borrow steering committee will review the steering committee electron and m. Then obviously, you know, you can put some notes. And for instance, the senior user here denote is the reason why is been put in a category as low interest is e has not shown great interest in a project that's been focused on other more important projects. So that could be a reason. So it's been working on the very critical or the project and we roped him into this research project and it's not fully with us, is not fully interested. So that's dangerous because we could be as a user, the person using the product. And if he comes into laid and that could cause challenges to the project. So that's it for stakeholder management. We have seen how to identify stakeholders of the project and we can put them into a neat little list. And also in that list we can just more or less draft our communication plan. As it was mentioned earlier. I mean, we don't always want to publish. This. Weight is we can probably remove the interest in appearance may be some stakeholder might not want to be seen in a category with low influence or the like. So it's something we have to be sensitive. It's more something we keep in our files. And but the communication blend, obviously we can tidy it up. We can remove the keeping the loop by sending weekly reports and comments like this. But we can say, well this, we will communicate with the steering committee of the email for a project meetings merges more, suppose, politically correct. So that's hit pause stakeholder management. Next, we will look at the exciting risk-management part of a project. 24. Risk Management during Initiation: Welcome to the risk part of the initiation. So let's imagine we have a business person just got the informal approval to go ahead with the project. And she is quite excited and she wants to go for the initiation phase of the project quite quickly. She might be a little bit biased because she's so excited here and you want this to happen. So she might not be very open to someone telling her that there could be risks for the project. So it just a matter of during initiation, we wanna make sure that all the large risks are being naan by the executive team. We want to help her identifying some key risks that could potentially worst-case scenario mean that the project is being conserved or postponed. Remember, the scenario that I gave if you watched the video on the birth of project management, the queen said, well, if I know that I could have lost half my army, I would have gone to head with, with this project. So that's the same thing we need to make sure that the business, the executive team, everyone is aware of the key risk for this project. And we list them into the project charter and everybody sign that off. And then we are all aware of what's ahead of us more or less. So in order to, to track those risks, we use a tool is called a risk register. And the next video, we'll tell you how we can get started with that. 25. Defining Risk types: Welcome back to the course. To get us started with putting together a list of risk where we can do is have a look at the various risk types and see for each die P4 we can identify risks. So we can do that with a business. Always the whole project team actually for that matter. To start with, we have the cost risks. That's an obvious one. What could go in a way of the project that will increase the cost of the project. And if the cost of the project has increased, what would be then the overall risk to the project. So there are some projects that have a very tight budget if you go over it more or less, this a big risk. So mothers have more tolerance and m, And the nice case, it's a, it's a little bit different. Schedule risks. It there is slippage in a schedule is at a big risk for the project. What could delay the project? What impact would the project have if there is a slippage in the schedule? For instance, you could have a date that is non negotiable at the end of it. Or you could have a data has been said, but if it moves, it's not a big deal. You could also have some reputational risks. If the project is not managed properly, is a reputation risks that could occur. Let's say you, you implement a web site that has a lot of visibility towards XNOR uses and you more or less messy Dad. That would be a beak reputational risk for for the company. Strategic risks. Either project in nine with the company strategy, or is there a big strategy change coming up? So if we know that there is a big strategy change coming up for the company, then x o in six months time is that there is that gonna pose a risk to the project at that point in time. That's something to think about. Then we have the legal risks, regulatory risks, contract risk. If we enrolled with third parties, all the steps of risks. And finally, always risks associated with external factors or hazards otherwise. So in this category you could, you could, you could go nuts. You can put stones, flood have quakes, vandalism, labor strikes. So you could go completely nuts with a so comments heads should prevail. Now, we have created a list of risks. The next step is to decide what we do with those risks. And this is the purpose of this next lecture, is to have a look at risk outcomes. What do we do with those risks when they occur? If they occur? 26. Defining Risk outcomes: Now we can have a look at what we do for a specific risk is five types of action that we could take. We could accept it, we could avoid it, we could transfer it, couldn't get it, or we could exploited. So let's take them one by one. Lee. But when we go into the risk register review, we will give an example of each one of those. So that would also had another layer. And to your understanding, if I can put it this way. So what does that mean? We accept the risks, that mean that we are aware of it? Yes, we know that could happen, but if it happens, it happens. So be it. No problem. We aware of it either. We don't want to do anything about 80. There's nothing we can do about it. So we just accepted. We can also avoid it. Considering the projector is a bit of an extreme. But you can, what you can do is change the planner to avoid this risk. You can change the way you were planning to do things. You project, the implementation strategy, for instance. Another thing you can do with arrays, you can transfer it to someone else, say Darius's risks. We don't really know what to do if it occurs, so you can transfer it. And an example would be entrance. What you can do with the risk as well as to mitigate it or reduce it. So you take action to reduce the likelihood of the risk, or you have in place an action to take if the risk occurs. So if you, if the risk occurs, you know what to do sometime that will mean an increase in cost of the project because we have to take some additional actions. But we'll see that as well. Risk can be exploited. So that only works for positive risks. Positive risks is a raised dot if it occurs. That's good for the project more with an example, you know, you could have caused a drop, for instance. And then that would mean more money in a, in a budget. And if there's anything we can do to increase the chance of this, of this risk to occur, then we could take action so that we can exploit. So I know that the notion of positive risk is, is not easy to grasp. So that's it. So that wraps up the risk outcome. 27. Defining Risk Severity: Come in front of you is a table to assess risk severity. So the way it works is we need to know two components of risk. We need to know the likelihood of the risk and we need to know the impact of a risk. And from that, we can detect by referring to that table, the severity of the risk which could be low, medium, high, or extreme. So let's have a look at likelihood first. Likelihood can be almost certain, likely, possible, unlikely are rare. And the impact a significant minor, moderate major or CV. So you will find some variations on this obviously from depending on where you work. If you know the likelihood of the risk, say you know that risk is rare. And if you know that the impact would be severe. So you know, you go there CV and they would put it through HIV, almost certain it could be someone being on sick leave, for instance, for the life of the project, Yes, it's it's almost certain that someone will get sick at some stage. And what the impact would be significant if it's one type of resource. But if it's another type of resource, the impact would be higher. And then you might want to do something in case that resources is sick. Just to give you an example. So as mentioned, the companies would have different criteria. This table will look different depending on where you work. And there is not one standard that's been used across the board. But I think that gives you a very good idea of how we can assess risk severity. It is not always done, but I think it's a good tool and I think if you do it, it would make you look good. That allows you also to put a little bit of perspective on the risk when someone comes to you and tell you, well, there's a very high risk that if the soccer then, and after you, you dig, you dig and you realize that the likelihood is unlikely and then the impact is only minor, moderate, and you can say, Yes, I understand your concern. The risk is in a risk register, but at the end of the day, the severity is only medium. This is it for risk severity that we can go to the next part of the course. 28. Risk Register example: As part of the risk management process in initiation, we create what we call a risk register, which is a document Excel where all the rocks that were we list all the risks and the impact likelihood and severity and the action that we take. So this is register that has already prefilled with a few examples. An example of each one of the outcomes that we discussed. So we, if we start with the first one, we put a risk number, we put a date raised, we put a date. Risk cursory description here, a word on this red part, Ethan, then it's, it's good practice and it will make you look good if use this at, I think it's, it's a very good way to describe a risk using if, then otherwise it can become very fluffy. You can say what if this happens and the impact is not clear? So that really forces you to login risking the very structure away. And he makes the impact directly as well. So if the flight is concerned, then the budget would be impacted. So what is the impact? We have? Put the Apache as major. We have decided the likelihood is possible. We go back into our major and possible, possible measure here. Possible here gives us a severity of high. Though the severity he's high. We need to allocate an owner for each risk if it's if it's if he stays open. So who'll be actively managing the risk? And if the risk occurs, who will address, address it. So it's very important that if you are the project manager to avoid to have your name here. And is it really a project management risk? But it's not always a project management is sometime you have to lock for the issue login. We will see later on, you need to make sure that someone actually owns the risk, monitors it for you, keeps an eye on it for you, and he's ready to action if the risk takes place. So that's that would be reviewed or so as part of the roles and responsibilities, it's very important to have a stake holder responsible for each of the project component, the action. So we have decided that we will be transferring this risk. The travel insurance, for instance, I could be an option to transfer it. You pay a premium that front. This way you avoid the risk. The risk is still open and obviously he can still occur. But if he does occur, then you know what to do. You have an outcome, you have an action, you have someone to do it. So this is the first example, transferring the risk. If we go to the next line, either asked trends strikes in Paris, for instance, very unlikely, I know, but then we will not be able to travel to Madrid. The plan go on holidays. Your plan is to take the trend. From Paris to Madrid. So the impact you, you rate it as, as measure, it's unlikely. But if you look in your matrix and if you notice the severity is still marked as high, so the owner will be done. And here you've decided to avoid the risk, yada, I don't want that risk to occur. I I don't even want to be worried about it, so I want to avoid it. So forget about the trend. I will rent a car instead and then you can close at risk. This is not a risk anymore. So you don't want to drag this risk along with a project with you because it's close. Someone raised it, we've avoided it so close, gone. There is the next risk, the risk number three, say it. If it's raining emitting during heavy during the week, then the complete trick will not be comfortable. Bit of an understatement, but it's just, just to give you a very simple holiday example. So the impact you see it as moderates, not the end of the world. And the likelihood is unlikely. And that gives you severity only of medium. So it's not high, it's a severity of medium. So the poor John is still responsible for this, responsible for everything. But you decide to accept this risk and you close at risk. You say, yeah, my Ran Yes. Unaware of it. Thanks for raising it, but I accept it. Or you will have these two risk like this in a risk register because you would take one or 21 of the two auctions, but just for this example as well, and Fourier freebie, if you have the same risk here, some impact likelihood severity, Simona, you would decide instead to mitigate it. So you plan some indo activities just in case. So you would, I don't know, bring some board games. You would just prepare yourself before the before your holiday projects that you would prepare some activities to play in those. So if this risk arm then you know what to do and this risk stays open because you don't accept it. You mitigate its difference with this one. Final example of a risk. If there are buses going to the beach, then we will not need to our cow and then we can save some money. That's an example of a positive risk. So the impact is moderate, the likelihood is possible. So the severity, quote unquote severity being positive severity is Hi, Joe honesty Leona. Action not come. You exploit this risk. Yes, we aware this will happen and if it happens, yeah, we can use the money saved. Movie tickets, for instance, I think it shows. It shows well what is a positive risks and how it can be exploited. The fact of having a positive risk is not very easy to understand. So I think with this example, hopefully that's makes it slightly clearer. 29. 32 Risk tips: So to finish on risk with initiation, I just wanted to give a couple of tips. So the first one is to include the key risks on your weekly reports, but also on the meeting minutes. So that has a few advantage. First of all, for you as a project manager that reminds you of the key risks obviously. But that also allows your, your team member to be aware of the risks, although also allows your management to be aware of the risk and to be reminded of the risks. Yes, we're working on this, but we have those risk. Let's not lose sight of those. That allows everyone to check the status of the risks. It doesn't get lost into a rich risk register. So not everybody. Actually, almost nobody would access the risk register apart from the project manager. So the risks have to be showing some way. And I think those two artifacts that are a good place for them. So you can, for instance, also use your weekly meetings to check if there are any new risks coming at. Your team members would be happy to remind you of those and also let you know if some that cannot occur anymore so we could close them. So it's a good practice for the second tip is to a formal risk review meetings. So what you will do is as early as you can in a project, ideally in a, during the initiation, you have the brainstorming session on risks. So what would this brainstorming slosh for more risk review meeting look like? So what you could do as a starting point when there is no risk there, you could use the risk type that we've seen before and then you build you your risk register. But ongoing in project, what you can do is still try and bring everybody back and review the existing risks. Check if the severity as change. You can brainstorm in a new one. Close the ones that are not valid. What is key for these types of meetings, attendance? You need to do your best to make sure that every part of the business, every stakeholder, attend these meetings. The reason is you don't want to have someone coming to you in the middle of the project and tell you, well, what about that risk? Have you thought about that risk? But if that person has been invited for this early meetings, then they cannot say much because they have been there, they've been involved, there have been given a chance to raise all the risks. So it's just a matter also took avail yourself Rayleigh bit, because there's always someone would come to you and say, what about that risk? So if you have your initial risk meeting and after you have regular risk meeting, you, you move the responsibility in a way from yourself to the broad spectrum of stakeholders, we have to take responsibility for these risks together. So it's not the project manager is concerned only frequency. We will mention one initial meeting where we start with a blank page or some gestures we put together all at the business knew that we knew and after every month or every quarter, depending on the length of the project. So that's pretty much it for the risk management. Thank you for your patients. So now we will be discussing the project structure. 30. Project Structure Introduction and basic structure: Welcome back to the course project structures. So towards the end of initiation, when there's a good chance that the project will go ahead. We put together a team, project team. So in this section we will review different scenario internally managed outsourced project structures. And we will see how they relate with other parts of the business. Let's have a look at a basic project structure internally managed. No contractors know felt buys. You are sitting here as a project manager. You have a team working for you. Sometimes. You have several teams. Sometimes. And if you work on several projects, you would have similar several projects team members, he as well. You have peers, you can have other PMs, they're working alongside you. You usually reported to a program manager. Program manager is a manager who manages several projects. So it's called a program. The projects can be related or not. But at other times you can just report it to an executive. Program manager implies someone managing several projects, but sometimes you would, you could report directly to a business area and Executive Director or even to a line manager. And that would occur if there is no pore program manager, if it's a smallish project, smallish entities Militia Company. So you would have all the steps of reporting possibilities if you like. And, uh, you you would have sometimes team leads, the team needs would have their own team members. Or you'd have sometimes team members working for you with a direct reporting line. One thing of note is you could have resources working for you a 100% of the time, which is called a fully dedicated resource. Or you could have shared resource. You have a team member here, Peter is actually shared resource between yourself. And the other project manager here is working on two projects. So this pit of a red flag, you need to make sure that is work allegation is as agreed. So if you can, in a ideal world, try to only have dedicated resource, but not always possible. Another scenario highlighted here, it's Mary. She shared that with BAU. That's even worse in a way because she is working for the business as usual team and the business is your workload is not linear. So they would have periods where they would work intensely and maybe some other periods which little bit quieter. So definitely maybe another warning senior here to make sure that Mary works allocated share four on this project. So as a bit of a risk mitigation, what you could do is when you have shared resource, you could put that on Azure risk. And I have a risk here. It's likely that the memory will be dragged along some BAU activities, especially if they do production support under the IT environment and the right. And to finish just a quick note, just to mention that this is called matrics environment when the project manager takes resources from other teams. Just to give you an example of a basic project structure when the project is internally managed and there is no Project Office. And we will see the projector fees in the next slide. 31. Project Structure: Project Office: Welcome back to the course, the exciting world of project office. Project to fees. And I give you a bit of a few acronyms here, apologies called the PIO or PMO, is more or less a pool of mainly project managers and project coordinators. They are usually managed by a project of his manager. Their main role being to allocate project manager and project, I mean resource. But there will be also managing them so that you could have hard reporting line if you like, between the project manager and the project coordinator to the project office manager, they set standards and policies for all projects. So you join a company. They insisted that, you know, prints two or PMP or anything else. But when you join them, you realize that, you know, they follow some standards, dark, quite different, and you have to work with those standards. And for me, this is just another argument that learning one of those prints to o PMP certification, it's more good on your resume and to attract potential and hiring companies. But on the real world, it's rare that you would have to work to work with those methodologies. You just use the company's standards and policies and the likes and the role of the project or feces. They would sometime consolidate all the reports provided by the project managers and they would, of course, verify you on report and they will chase you down if you haven't provided them on time. And they would regroup all those reports from all project managers and consolidate them and provide them to the executive teams. They would then show the process are being followed, of course. So they'll give you Standards and then relax so they want to make sure that the processes are being followed. And if you're lucky, they can provide you with some training as opposed like any type of management team would. So that's a quick overview of the project of his. Now we can have a look how that fits in. And we did the org chart that we saw before. So this is same as before. So we are sitting here as a project manager, you reporting to the program manager here. But at the same time you have some type of doted line to a project of peace. And you can be working alongside a project coordinator. You say, sorry, I'm too busy with this project and likes and need a project coordinator. So the project coordinator would assist you. Project coordinator could help you with things like organizing meetings, writing minutes could also help you escape your rights. And based on the experience of the project coordinator, that, that can be more or less useful. But as mentioned, this is a good way into project management as a, as I will mention in, in part three, I think this is an excellent way. Sometimes I don't need to know any any other project management methodology. So you would go in here and then you would end up here probably. But let's leave it as is for the project office. And let's have a look at another type of auction that you could have. 32. Project Structure: Project outsourced: So let's have a look at another project structure in the scenario where the project is being outsourced to contractor to referred body. On the yellowish here, we would have the usual internal structure was program manager, business around them and a project manager's day. And then in greenish we would have the contractor. They would have their own structure usually for large project, they would have a project manager and the company would have an in-house project manager as well. So the flow of information if you lock would be from the team here to the project manager, contracting and the project manager in house. And after the reporting flow will go up to the program manager. So that's just one scenario. If you like. Sometimes the project manager, he could report directly to the program manager or the business area sometime when it's very small, they don't need project managers. So therefore, the team lead could report directly to the in-house protect manager. But for large projects to project managers, one on each side. 33. Project Structure: Steering committee 06 05: I come back. So to finish some project structure. When we discuss communication, we mentioned the steering committee we as a group that needs to be kept in the loop and we need to have a structure way to communicate to these group. So the steering committee is the temporary structure that is being set up for the project so they can over oversee the project and provide some key decision. And, and I was gonna say advice, but it's more than advisor really supposed to really steer the project. So the structure more or less is made of high level stakeholders. And, but sometime they bring experts to this meeting to enable them to make a decision. And they're usually the sign ofs for, for the, for the key decisions. So they are very important group. So let's have a look of what typically the steering committee is made of. So they have what we call a senior user, which is a Senior User is the end user of the product, if you like. They are the one that we'll be using, what the project delivers. There's also a senior supplier, which is not always present. But when the protections that soul's though when there is someone supplying the good or service than they would attend here. And then the Senior Executive, also called business owner. So this is the person really responsible for the project. The project is for him or her. So in a category of stakeholders, they will be high interest and high influence. So as, as the project is made for them, then they have the Magda core more or less. Either if at some stage I decided projects not worthwhile anymore, they just make the core. So very important. So what's interesting with the steering committees, you would assume that the project manager isn't military attendee, But, but sometimes it's a Project Manager doesn't attend. For some time, is the project manager's manager attending? So they raise the bar a little bit. They want to get a bit of an independent view on the project. So if he's not always your decision, but it's it's best if the project manager at hand. So that's all I wanted to mention. Really honest steering committee. A group of high influence people meeting to discuss the project. And when there's are some key issues they would, they would make the core. They can also be used as escalation point. This is where I sit is good as a project manager that you attend because you can raise your key issues. And that's it for project structure. So next we will wrap up the, the initiation phase. And we will start by taking some examples before wrapping up the faith. 34. Optional: Project Charter example : So earlier in an initiation, I mentioned the project charter document, which is a document the project manager creates to regroup all the findings of the initiation phase. And this is being used as a way to get the business to sign off on the project and we can go ahead with a project. I just wanted to give you an example to wrap the initiation phase it, because I think it always helps. I think, as I mentioned, the project charter can be a bit scary. Sometimes you see these huge templates with all this information and needs to be in. But he doesn't have to be. If we start with something very simple and we just add a few words around it. It can be actually quite a short exercise, especially taking into consideration that most of the content of this document is taken from other stakeholders, from the stakeholders to denote riding much of the content. Let's take another project for a chance, building a bridge. So one of the section I was suggesting we have in the project charter document is the project objectives. So very simply, the project concerns the burning of a bridge on the soft side of the city. Something very simple like this for the project objectives. When they had some business case paperwork and arrives, you take things from the document and you put them in the same for the next section here, benefits and business case. That's something that you would often take from the business. I have here, the current traffic on the center of the city has become and sustainable and he's causing delays. And therefore we need this bridge. You then go into the high level scope, what is in scope, and what is out of scope. So I've really simplified it. I think earlier under scope, I had several bullet points here. Just really simplified it. Obviously you would have more wisdom is, but it's just to highlight the structure of the document. So in scope, the building and the testing of the bridge. This is what we want to project. Do we want the project to build a bridge and to make sure that you would have more subcomponents. I would think that's a bit vague util you would say where it needs to be done and the likes. But this is more or less to give you an idea of in and out of scope. So out of scope you would have communication to road users and all the rotating it serialization for instance, you don't want the project team to take care of this. You will take there are these yourself. This is Iraq scope. The high-level schedule would be just key milestones. You would just say by John, I would like to finish the planning phase 20-20, one March. The company would be engaged. June, this has to happen. And, uh, you would you would wonder completion by 22-23 implementation budget the same. We had a Quick look on budget. We talked about the rough order of magnitude. And one of the way to get to the rough order of magnitude was expert opinion. And then we have an expert in building a bridge. You just don't want to improvise too much. So you really need someone, you hired someone, an expert. It knows how how it's done, is a specialist is done that many times. So with 120 million to build the bridge and the budget as a council, sorry, as a budget of 150 million. So it looks like it could work. The key risks, bad weather will delay construction. So you would worry that if there is bad weather than the construction will be delayed. And then you put that in your risk register. And you would then decide what do we do with this. We will just accept it. You want to avoid it? There'll be more difficult. You probably could mitigate it. Maybe you do some indo work well while it's reading. I don't know, but that's that's a starting point. You would refer usually to your risk register. You would, you could attach your risk register to the project charter to really help everyone make a, make a sound decision. And other risks that have listed here. Obviously, I'm not a bridge-building specialist, but I like this example. So road authorities dependency, it could delay implementation date so that you would imagine you would have a huge loops to go through to build a bridge. And one of those being the policies, the standards and arrives. So that's something that would cause delay. So as part of the risk mitigation, you try and speed up that process or really at least to understand what are the steps involved. You would give also the project stricter another view of the protective. So you've decided to go to outsource the project. Obviously, you didn't have handy specialist team to build breach. So you would have a team made of the following. You would have an internal project manager. You would put Maurice miss part of the Council. She would be your internal protect manager. And you would have Project Manager from two different companies. So you would have your company XYZ for for doing, I don't know, the construction itself and ABC to do something else. So you will have a team made of free project managers because this project would be so, so big that the third party would have project managers. You would set up a steering committee and part of the stakeholder list. A. Suppose a steering committee will be made of the senior user, which is the road authority representative. So the senior user, you would be representing everyone using the bridge. So obviously you cannot have all the users, but he would be the one representing all the uses. The senior super malaria would be Company XYZ. They are the key guys, are lucky guys reading the bridge, so they will be the senior supplier. You would also have the senior executive and that's that's that's a boss. That's how I would assume as mayor of the city. So he or she will be the one making, making key decisions in the project. And then you would have a stakeholder, at least. I have here just duplicated the steering committee. You would obviously have a project manager. You would have marine names, you would have the project managers of these two companies, and you would have anyone you can think of list of approvers required? Yes, that's important. You you would have the senior executives will be sending out the document after review from the management team. So you know that the key approval for the project would be the mayor of the city. So that's a bit of the wrap-up of the project charter. I hope it makes sense. We're not done with example. We still have a couple of examples after this one, but I think that hopefully is just the ceiling, all the information that you've had in his face for the initiation phase. And you have also a template in your resources. Once again, the template, every company would have a different type of template. So if you join us, protect manager somewhere, they would give you a template. But I just wanted to put a template in the resources just to show you that it doesn't have to be too complicated. Let's have a look at another example, but this time on some specifics components of the project charter. 35. Optional: Additional Examples: So I'll just focusing here on few components of the Project Charter, which are the coast schedule, the business case, and the team. So first example, you would have a software delivery. So the highlight, high-level cost. You would have the service provider XYZ that's provided an estimate of 150 k and 50 K. I'm going so it is outsourced environment. And this is usually the best way to get an estimate because you know that service providers are doing these day Now, as I was mentioning, they have big teams. So there will be, give you a very precise precise cost high level schedule so that the provider as estimated from moms. So then based on that and based on when the project can start, you should be able to give the business unimplemented implementation date up to you if you want to add some contingency or not. So the business case, we need an accounting system to avoid manual input and human heroes costing us 75 thousand per year. So they are telling you that one of course would be 150 k and 50 K ongoing. And what you are telling them that I would set a 75-50 per year, so is that worth it? So they would say, well, 50 k cost for 75, saving, Yes, it's multi 5K per year. But you that really with the hassle taking into account that you need to recoup your initial cost. So you put all that up to them and you know, they can make an informed decision. The team bring a team together, the service provider provides us with a project manager. Steering Committee will be setup with this project manager and a senior resource from XYZ ID, which is, which is the service provider here. Next project. As an example, you develop a website. So the high level coast, you have an SME or subject matter expert or another word for a guru, estimated at $30 thousand. You have a valuable skill. You said that we need this before Christmas. That's more the business imperative. So you would get the estimate from the SME and you'll see that even if that could work. The business case is we want an online facility to reduce the amount of phone calls and there's some numbers there. So once again, you would put all these numbers together for the business to decide. Caused VS. Savings. Is it worth it? And a team, and our team can do the work. So we won't be an outsource project like the previous one. It would be an entirely manage project. We use Mary as a project manager and the rest of the team as already been set up. So you can rest easy that we can run this project not problem. Another example that I've just actually given an expert estimated 120 million, the high-level schedule. The expert mentioned three years. Bridge is required to avoid congestion and put the team together. We know this Pm specialized in British constriction, so we will hire him as a contractor instead of having, that's another scenario and the previous one, I had someone internally from the console. But you realize that to be more confident, maybe to have a specialist project manager and you would hire him or her. Final example just just just to keep it going on holidays such as I like to give various range of examples. So high-level cost, well, we have 5 thousand bureau to span the Oliver schedule. You have two weeks business case. We really need a break and a team of those kids. So as part of the bearing in mind, we are in the initiation phase, so the project has not started yet. So in other words, if you stay with the going on holidays project, you have 5 thousand the rotor spins and you have to fix a variable and then you can more or less decide, well, is the business case worthwhile? Do does it hold water due to I have. Can we start planning on this? And this is, this is the advantage of asking yourself this question before, before we go into, because if you, if you go into planning and if you start investigating, it arrives And after you realize, well, we don't even have the Monet for it. Oh, we don't even have the relief for it. So I wanted to finish with this example just to highlight the importance of getting the key thing is writing the initiation phase. Because after just to let you don't want to go into all this planning, only to realize that, well, they are not viable project. And that's your purpose of the initiation phase. 36. Phase 1: Initiation wrap up : Welcome back to wrap-up of project initiation. So I started off this phase by stating that the project initiation doesn't always, okay, or at the very least dozen OKRs, formerly just a bit of a reality check as opposed to what you could be learning in to some project management standards methodology and the likes. The, you will have a scenario with someone that management and executive. They would just come to you and let you know. Yes, you have a project. We already worked out the budget and this needs to be implemented by such a date and it's usually quite aggressive. So this happens is, it's important for you when you get involved at this stage to be very active at trying to find any potential gaps. Because anything that is missed out at this phase, it'll be very, very difficult to, to fix later on. Need to challenge very tactfully the resources that came up with this quote in it to try and find out how did they come to that quote, you need to check if they have forgotten anything to include that code. Quote. Sometimes they come up with quote, but I don't think about all the overheads and the like. So as a project manager, you really need to make sure that everything is included. And to avoid that, you know, as you do the planning eros wall, that they didn't include these. I didn't include that. So Challenge tax Fourier, That would be my recommendation. If you're high involving nice initiation to make sure that the full course provided early impossible because once the budget is allocated, then it will get harder, if not impossible as you progress in a project to amend and change. So you see the initiation phases are analogy. If you want to start a painting, the initiation phase where, you know, outlined the largest shapes on your canvas. If you forget one or if you don't do one right, then it doesn't have to be precise broad-brush. But if you forget large chunk, then it would be very difficult to rectify. So we have a quiz to wrap things up and will be continuing with the next phase, which is project planning. 37. Phase 2: Planning section overview: We'll come back to the course face to planning section overview. So in this section we will review the purpose of the planning phase. We will also discuss the project manager role. In this phase, we review an important document the project manager has to create during this phase, it's called the Project Management Plan usually. And the key components of this phase that we will discuss will be the scoping requirements, scheduling, cost, budget, and quality planning. We will finish as usual was an example of the document created by the project manager. And then we will have a wrap-up and some quiz as well. 38. Phase 2: Planning purpose: We have now completed initiation, congratulation. The project is approved. Now we are studying planning. So planning is planning for the execution, which is planning for the next phase, more or less. Planning is, how will we be delivering this? And what exactly do we need to do? Because initiation, it was already at high level, high level tanks. Now it's time to know the small chunks, so we need to go back to the business and and asked them what exactly am put out on paper and we could all sign off and agree. But now let's review in detail what's involved in the planning phase. So what is the purpose of planning? It's more or less, how will we be doing this project? I will be performing the activities of the project. It's subtle look at the key components that are involved in planning. We go back to requirements, get more granular. You beat of the lower level. What exactly do we want to achieve? What is included or excluded? We set the boundaries a bit more in a more refined way. Will have a closer look at a schedule. Now we are not into the broad brush anymore, so we are really looking at each step that is required, the dependencies, the duration of the steps, and that should give us a final delivery date. We have looked at the budget and cost into much more detail. We have looked and other local stakeholders, if they are still okay, more closely or so in, uh, the roles and responsibilities. This is the key document that will be delivering at the end of this, of this phase, we had the project charter and initiation. And in this phase we will call the document that is created by the project manager, the project management plan. And then planning all other activities more or less. Depending on the project, you will have more or less activities here I've listed a few. We planning on how we will be reporting on a project. Do we need to keep any one in the loop on quality control, we talk about quality. Can we check what we are doing is right? Communication? We talked about that to the stakeholder. How are we going to communicate and who and how? We'll have a look at planning for procurement. Do we need to buy anything and if yes, how we'll be doing it. And we'd have also, of course, we'll have a look at the risks. So though there are outcome sought from planning is to know how it's project activity will be contacting, conducted, sorry. 39. Role of PM during Planning: Welcome back to the course. Lets have a look at the project manager role in planning. During initiation, the project manager created a project charter. And during planning, the project manager creates a project management plan that would encompass all the findings of the planning and will submit these four sign-off. He or she has another document to create some type of work to do. On top of that, the two key activities that the project manager needs to do is to finalize the schedule and the budget. Those are, those are key and they are very important. And they need to be done with a lot of detail. On top of this. Of course, the project manager need to ensure that all the planning is done correctly. I just listed a few here. The PM needs to ensure that the planning of activities is history, that the requirements are clear, scope is defined, that the team structure as finalize full list of stakeholders is created. That resources are available. That's very important obviously for the planning and the schedule that everybody's on board. We could have a list of stakeholders, but here are not engaged. And if they, if the resources are not available, then we won't go very fast. So usually what we do is we have a kickoff meeting where we engage all the stakeholders or the project resource and see if anyone has something to say, say it now, otherwise, we are going we need to ensure that the reporting is defined. As mentioned earlier. And all the steps are taken to deliver a good product which is planning for quality. And that communication is clear. On top of that, it's ever look at the risk register also what we added. So that's a lot of things to do during planning. It's very active phase for the project manager. 40. Project Management Plan Definition: Once again, that's what your project management plan could look like. I have taken some of the components that were in my first slide on the project planning that I've added a few here. The critical success factors, which be, How will we decide if the project in a success or not? That's something that we could include in the project management plan. We could list all the deliverables. If you remember from terminology, that's everything that the project will be handing over at the end of the project. The work breakdown structure. That's something that is a way to least requirement. So what is required from the project? And I have an example of this later on. You could also have constraints that haven't mentioned before. A project approach, which is, how will we be doing this project? Sometimes, sometimes it's not required because the way to do the project is quite standard. But if we do something a little bit different, I suppose it's always good to do listed. So that's another document that we need to create. And next, we will start to review the first component, which is going back to scoping requirements. 41. Requirements: Introduction: Welcome back to the course. Now it's time to go into more detail in our scope. So on one side, we have the business. They need to tell us what exactly we need to do. On the other side, the project team could be a business analyst and architecting whoever really need to make sure that they understand what the business wants. This is a critical step because all that we do in execution will be based on these requirements that the business is providing us. And we will see in next slide, How important is requirement is, and how important is it to get it right? So how do we create a requirements document? There's usually some type of business analyst involved on behalf of the business to put all the business won't Tina, in one document. It could be called the business requirements document. It could be called the detailed requirements document, but it can also be a requirement matrix at a high level. And the advantages of the requirement metrics, it's quite quick. To go back to a requirement. You would have the requirement he and has a number associated to it. I'm just giving you an example here. That's quite useful as we'll see, if it's not a requirement matrix, there will be some type of other document anyway, where the requirements are clearly articulated. Just to stress the fact that this exercise is quite important for the project. We will use the requirement metrics or any type of recommend document during the execution to design and build the product. It will also be used to check the scope. So if the business here have you thought about that halfway through the project and if it's not in the list, we said, sorry, that was not in this list. So we need to do a change control. It will be used to check the quality. When we had a testing. They will go through all this requirement and they will confirm that the build has been done properly and then include all these requirements. And the final acceptance. When the product is completed, the business will go back with this list and will ensure that yes, they have these yes, they have that tick, tick, tick, and it's all done. It's especially important in a, in a vendor environment when the company is contracted to do a work just to before you sign off and free up the money. You would usually have some discussions around the requirement. So the requirement here, for instance, you know, we're just going to have here some some category could be a compliance requirement, could be a security requirement or it could be just a design requirement. And then you would have some type of description. Now could be a good starting point. For instance, security requirement or transactions on the website must be encrypted. And then you could have something more detailed. And an if. 42. Work Breakdown Structure: WBS definition: Before we move on to the next part of planning, I just wanted to briefly mention a tool as we are in requirements that business analyst use sometimes too. Visualize the requirements that are required by the business on the project. So it's called a WBS, the work breakdown structure. And it's just a fancy way to decompose deliverables into smaller checks. So it can be used, it used mostly by business analysts, but it can also be used by project manager. So for instance, here today I have the example of a project that I have decomposed using the WBS chart. So the way it works is it goes from the more complex, the more detail component. And it works really subcategories. So if you have, for instance, I have the higher component, which is my project is to go on holidays. I decompose that protect into the key activities that I feed are required to deliver this project. And then under each key activity I have smaller activity and the reach. So if I just take one example, the side destination. So my project would be similarly days and my subproject, if you like, my slip component would be decided on destination and ender decide on destination. I would have brainstorm ideas, check the weather. And the next subcomponent is, how am I going to decide on eating R3 and have a look at the timing. I'll have a look at the stops I want to have and asides that I want to visit. So in other words, it's when you go from top to bottom you get more and more granular and it's a good way not to forget anything. It's called WBS work breakdown structure. Just wanted to mention it just in case you you hear about it and you can say, yep, I've heard of that. I know what it is. 43. Scheduling: Introduction: Welcome to the scheduling part of the program. As we've seen with scope, scheduling during planning has to be more thorough. It has to be a complete. During initiation, we were just happy with some key milestones. But during planning we have to do a full plan, a full schedule. When we build a schedule during planning, we are mostly concerned about the activities that will take place during the execution phase. Nobody's really interested in what's happening in the closing phase, maybe your, your project office so they can appropriately rare gets some of the Project Management Resources and the likes. But a business you project teams and anoxia are mostly interested in the execution. So this is where we spend most of our time planning the execution. So this catering obviously is important for the coordination of resources. It's important to know, you know, you cannot just taking resource and let them go whenever you want. So you probably wouldn't be working with other managers. You need to tell them when a resource will become available, when you need to have access quarter-on-quarter another resource, obviously the coordination of activities. So you can tell the teams this activity we finish on that debt. And then the other team, if they had a dependency on this activity, then they can start. So they can put all that in, all the team lead can put that into the plannings. Obviously the implementation debt, that's a key one. But also the final coasting because some costs would be dependent on the length of your project. For instance, Project Management is the obvious one. The longer the project, the more time you would need to spend on the project. It doesn't mean you need to spend 100% of your time. But the longer the project, the more the project management cost will be. The same for Samba contain and some admin, some overhead activities would be the same category. 44. Scheduling: Breaking down Execution : Welcome back to planning and the scheduling part of planning. After the introduction, I wanted to show you some typical components that fall under the execution part. So it's always a good idea when you plan for a project to check if, if you fall under this scenario here. So at the end of planning, you move into execution. So in other words, in planning you need to plan for the execution. That's as we mentioned earlier. So you have to look forward or what's, it's the execution will entail. So there are instances where the execution will be decomposed as follows. So you would have the design, build, test and then the implementation. So that's typical for an IT project. And you would have the requirements would occur before and during the execution will, you will do the design, you will do the build, you will do the test, the implementation, and after the execution component will end. So during planning, you do the requirements gathering. So the business will come with a requirement matrix or business requirement document. And that will tell you what needs to be done in detail. And then the magic where during the execution you will go into design and how we will do it. So sometimes there's some confusion. A design is not power of planning, although it will be tempting to put it there. But it's not. What is in planning is you, you gather the requirements and then design is part of the communication. These are, we will tell you how you will lose it. This is the recurrence. We tell you what you will do and the design, how you will do it. The requirements on the high level business, yeah, I wanna website that data has these data has that and the rights and the business analyst as part of the design, will tell you how they will convert this requirement into something concrete, how the webpage with exactly be designed. And after we move on to build, so the developers below construction, they will use the design document produced here, and they will use it to build the product. When the build is completed. Hopefully you would have a test step here where you will check if the work is properly done. And Asbell requirements. This is what we were saying before. The requirement document is used for design, for build, and for test. Finder. Step after testing is you do the implementation. So as you can see, that can be very useful to put a, a draft schedule together. You would have a heading with a design or hitting with Bill, test implementation. And under each heading you would have the more detailed tasks. 45. Execution planning examples : Welcome back to the course. Now what we can do is we've seen this model before where we can go from design, build test implementation. Where we can do is have a look at projects and see do replanning if they fit within that model. So here I have five projects and let's just go through them quickly and check for each one of those components here. If the motor so the first one is a software delivery. So what would be the requirements for this? That would be the business telling us what they want the software to do. So that works with, so we can really relate to a requirement here. Design will be usually use software specification of some kind, and it will be done by the business analyst. The build will be all the coding configuration and relaxed done by the developer. So there's no surprise there because software delivery is actually the one that it's actually an IT development project and, and the smarter fits IT development project. So to come back here, test test of software VS requirements. Yes, so we tested our list would be involved in implementation. There will be a go live, whether users can access the system. That works. Now developed a website are also kind of IT project. The requirement would come from the business that would tell us what type of Woodside they want and which functionality that they want to have. The design that will be the same, that will be a designer website design here, the being done the build, creating quarter-on-quarter website, which is more configuration these days. As far as this is concerned, yet specialized team. There's the website. And on top of that, obviously the business recommend do the UAT implementation? Yes, we go live as well, provide full access to the website. So that works. Take building a bridge. The requirements. I think we've seen building a bridge before. So the requirements, the government or whoever wants these bridge, outlines what taps her breezy won't. So the design would be done, I would think by an architect will have the planned and the likes the bill will be done by the construction team. Test we will be testing the breach solidity. So that's an interesting one. I assume they also test components before, but I don't know if you've seen those on the internet, but they put 50 bit tricks on the bridge and they more or less tested. I don't want to know what happens if, if it doesn't work, but I think they do that. Be quite confident that the test is quite solid. And implementation, yes, on one dataset that's hit the bridge is quote unquote live and cars are allowed on the road. And if we take the quote, unquote project of going on holy days, the requirements, whatever that is, this, we all need holidays are suppose at some stage, the design would be preparing the itinerary and the beard would be to make the bookings test. You can't really test a holiday. I mean, I wish I could test my holy days, but I suppose you could do a dry run with all the bookings. And the implementation is when the early day starts landing on the moon and say we want to go to the moon. So this, this is requirements. I would imagine it would provide more detail than that. But the design, a rocket being designed and we build the rocket taste, I assume they do lots of tests, but it can't really test going to the moon ones to us and after, okay, that's, that's, that's the right one. Let, let go now live. So they would do some type of tasting. So it's debatable if this model works for these, we think maybe yes. And the implementation that say 321 go. Here, you have it all the components. Very useful when you want to create a plan. 46. Building a Schedule: Steps and example : Let's continue with the project planning scheduling. I have some suggested steps to build a schedule here. Step 12 free. Obviously, I think that building a schedule is quite intuitive. I think we all know about project duration dependencies. We have all planned something. Somehow. It's funny, the holy days, that's what I'd like to give this example. It's everybody hopefully has done that at some stage. Step one, we list all the tasks required alongside with the effort required. A third is amount of time that would be actually spent on doing the work. The duration will be the time spent from start to finish. So you could have some delays sum width times in between. So that will be taken into account during the duration. Is a quick example here for you. Take the builders two hours to fix my roof. But if you take into account all the going back and forth, it would take them two weeks, the duration, but there will be actually working on my roof for just to us. So if we go back to our example here, it's building a fence with a gate. So you would list all the tasks that and please don't comment on hose. Just assumption that what is required so 0.5 days to build a material free days to install the Post, one week to put defensive. And today's to build an installed the gate. So we start off with listing all the tasks. Step two, we list the dependencies between the tasks. We reviewed a task that cannot start before another one has completed. So for instance, we cannot start building the fence prior to getting the material. We cannot put defensive without building the material. So we cannot start putting the fence without the post. So we cannot do this without the post. Do we list all the, all the, all the dependency between a task libraries ever committee has advanced. Sometime the relationship can be between task can be more complex. For instance, some tasks that can start a few days after another one as started, or sometimes I need to finish at the same time. An example is we need to finish the Fed at the same time as our neighbors finished his. Because we want to make sure they're exactly at the same height, for instance. So that's a bit of a complex dependency the, that we can have. So this is what I put as advance. If you're a beginner, you don't really have to worry about this scenario or the stage. Step three, we put it all together. We review the resourcing and a constraint for those tasks. Who is doing those and how many resources we have available. And this is where I was mentioning before, effort and duration as two terms that are often used in project management for the scheduling method is actually the time to actually do the work and duration. It's a time. It will take, taking into account all the, all the dependencies, the constraints and the right. So for instance, what I have here, let's have one week to biomaterial is we need to find a proper food. The show's MyNode be open and arrive. So this is to show you that 0.5. day's task can turn into a one-week task. And this is what would happen in project management as well. Sometime could, some task could have one-day effort, but on the plan you would put five days because the resource is not often available, works part-time or the right in will take, in fact two weeks to put the facet fences. As a contractor is working part-time. So when we effort, but the duration will be two weeks, resource might not be available. So that's more of a constraint, if you like, until a certain date. So you, you list your constraint. Shops are closed during the Easter break, contractors away or me. So you can list them enough to Monrovia problem, you might finish the project before the project might start. After. Two resource available with the same skills could work on the same task. So that's more positive situation. Something to bear in mind when you put your schedule is a secondary source for available from the tenth of May. And then you list all other constraints. Defense need needs to be built by the 12th of June. That could be a type of constraint. So that's it. Step one, the effort. Step two, dependencies between those dependencies required. Because when you have a look at the resources and constraints, then you need to take those dependencies into account. So that's just an example of how you could go about building a schedule. And how would you represent this? You can just represent this this way to the business. I've taken all the affording duration into account and as you start to kind of march, I put all that together and I'll give me a completion date. It's a small scheduler, but just to illustrate the three steps that I had heard before, we will see other ways, obviously to present a schedule with this type of schedulers will see it. It's quite good to present on the, on the very high level to the business. 47. Schedule Types part 1 Milestone and Timeline views: Hello again. So let's review some scheduled tabs that you could come across. So I ever presented here two scheduled tabs that are quite common. They focus on milestones. For the first one is called milestone view. We just list the tasks and then we put the completion date here on the, on the right hand side. So usually you would have all your key important project tasks. And when they will complete that gives stakeholders and idea of when some key milestone will be completed. The second one is a project timeline. It's a little bit similar. It focuses also on milestones, but it's a little bit more visually, if you like. So there's the completion date he 30th or December, and the name of the task is here. So it is quite user-friendly. So I've done this one in Microsoft Excel. I think it's, it can also be done in these you. So let's review the advantages of this type of of schedules. So they are great for management of steering committee reporting. Obviously, they are very easy to read and they focus on the key components. They are easy to include in reports. So you can just copy this and put it at the end of your report o, that gives you a everyone and ablate on the schedule. And also with the project team. They are better have afield to get people motivated and focused on the tasks at hand. So the Gantt Chart that we will see you on the next slide, it's more complete, more detail. But I, I found that your project team sometimes trigger to visit a, they don't have the time to go into the more detailed tasks, so that's perfect to get everyone focused. Ok, so the software development here, nice to finish on the second of February. And that gives everyone a bit of a goal and a clear view on what needs to be achieved. 48. Schedule Types part 2 Gantt Charts and attachments: So the other type of schedule that you will come across definitely is a Gantt chart. Again, shot is the gold standard. As opposed for project management scheduling. It allows for complex dependencies and even you can even do your budgeting with it. So this is what it looks like. So on the left-hand side, you have a project tasks. And on the right-hand side, it's a bit of a more visual way. Going back to the left-hand side, you would list your tasks. Here. You can group them. For instance, you could have the planning grouping and you'd have all the tasks for planning execution, all the tasks for execution. You would have the effort that I discussed earlier. You could put the duration instead of the effort. You can put resource names. You can allocate a resource for, for, for this task and for that task. And the software will let you know if a resource is double booked, if he's allocated to more than 100%. So it's quite a good tool for the project manager. Take a look at the pros. Yeah, it's great for complex project. Calculates the completion dates based on dependency. So you didn't have to do to do it all manually it or told calculated. On the downside, it can look a bit overwhelming as, as I mentioned in the previous slide. So we business in project teams. So I would, if you wanna use it as a tool for communication, I would strongly recommend to keep it to one or two pages because I've just represented one-page. Here are more or less here have one project on one page, but sometimes there will be 1011 pages. So It's a bit unreasonable to ask a project team member to review it. And for you it's a bit becomes a bit of a of a maintenance nightmare. So the tool that we use for this type of schedule is Microsoft tool called, called MS project and Microsoft Project. But you can also do it with Microsoft Excel and actually show you an example in a resources talking of resources. Here we are. So I have included one of these grandchild Universal's done with Microsoft Project. So obviously if you don't have Microsoft Project, you won't be able to access it. So for that reason, I've also put it the PDF format. And I've also provided an example of a gantt chart that has been done with Excel. So if you go into Excel, if you want to create a new workbook and you go into the templates and use kind for gunshot, You will be able to find some gunshot templates that you can use. So that's, that's if you're really keen that if you really want to play around with Gantt charts, but obviously Excel doesn't have the same calculation advantageous that Microsoft project would have. So that's it for project scheduling. Next, let's go into the planning for our project cost. 49. Costing during Planning: Introduction: Welcome back to the course. So I'm sure you've guessed it. During planning, we get more detail, whereas it was the case for scope as it was as careful schedule. Now for budget, we get more and more detailed. We need to to have everything ready. As we'll see. As you probably know your progress in the project, the more difficult it is to change a budget. So we do a complete budget. During initiation, the high-level coast was estimated and we called it the order of magnitude. Now we are in planning and it's time to go more granular. So we do a bottom-up estimate, which means that we add all the smaller component that we would have found when we did our schedule and our design. So we cost attached to each one of those components. So we do this after the schedule is completed because some costs would be dependent on the length of the project. For instance, the project management cost, usually more, more expensive if the project is longer because it's based on the number of days that the project manager would be involved. And once this project cost alpha analyzed, we refer to these budget as our baseline. And during the life of the project, we will be always referring back to that baseline to check if we are still within the budget boundaries. 50. Costing: fixed Price and Time and Material: So when we get started to putting our coasting together, one way to go about it is to make it clearer, is we would split our costs into time and material and fixed price. Just to give a quick explanation on each one of those determined materials, of course, calculated is depending on on how long the project, all the task is going to take. So we're not really show it could take ten days, we take 20 days. So we would have to make an estimate on how long it would take to finish the task. But if it takes longer, you will be more expensive. If he takes less time, it will be cheaper. So we don't really know, so we say it depend. This is why in this example here, you would have the contractors. You bring someone in for a day. If you finish the task in four days is 4 thousand, but if he finishes it in six days, it would be six. Obviously, you would have some type of estimate, but he's not really fixed the price. The same as we discussed for the project management cost. It depends on how long the project is. Functional managers, it could depend on how involved they get. If the projects get more complex, maybe they would get more involved. And you could request a model concerting as well. In the middle of the project, you might realize you need something and then you would bringing us down in material. And also the purchase. You know, you don't really know, sometimes invents how procurement activities will take place. It's sort of been vague here, but you would always come up with some types of estimates. The fixed process, it's more concrete, you know exactly how much you are going to have to pay up front if we look at examples, your hardware purchases. So that's the one that we know. We will be needing. We know in advance how much it would cost. You can have a fixed price on a troubling if you know you need to travel for the project, you can calculate it exactly in advance. You can have also some type of service that it's fixed price. Someone comes to fix something. It doesn't matter if it takes them five days or ten days, you would pay only the same prize. And for, for some goods as well. Here, Arnie exempt. It's just some examples of that PUT here, but obviously the, you know, you could have a bigger list. So maybe just to wrap up with a very quick example is, let's say you go on holidays. Before you go on holidays, you know, some costs would be fixed. You would have paid for your hotel, say you would have paid for your, for your flight. That's fixed price, but some other will be more and Tammy material if you want to call it this way, for instance, the middle. So you don't know exactly how much will be spending every meal. You don't know how much pitch or exactly you will spend that you would have an ID, you would make our estimate. You would say, well, $50 a day for four meals, for instance. It's still considered a Talmud material because you don't know exactly in advance, but you would have some type of estimates, an ID. So this is obviously the cost to keep an eye on. So if you look in the vendor client environment, the common material is obviously preferred when you other vendor. Because if it takes you longer than you get paid and after you covert way. On the other hand, the fixed price would be the one preferred by the client because they know exactly how much they're going to pay in advance. 51. Costing: FP and T&M Example: So to reiterate a bit regarding this fixed price and Time and Material Concept and wanted to give you an example. So if those concepts are clear to you, feel free to skip that video. But I always like to provide an example. So if we go back to the fence leading offense example, you could have potentially two options or combination of the two. Let's go for option one. Option one, you decide to go fixed price or the contractor gives you fixed price. So the total budget is clear. For all the wood nail him post sort of fixed in the labor also is fixed. It will not cost you more than this. So as a client, you know that the price, and we'll logo above this amount. There's always exceptions, but this is the idea of the fixed prices. In theory, you stick to these price. So as a contractor, you could potentially have a greater margin if you, if, if this was a bit of an estimate and you have a dream run and then you have a little bit of money left. But if, if you take you much longer than you could potentially lose money. So you could go or so with option two. And with the Talmud material. So either liquids tell you, look, I have no ID but our labor is 50 draw parallel. But usually as I was mentioning, that would give you a, an estimated, we say around $2 thousand, but it will be toughened material anyway. So rest assure that you will not pay more than, than, than is required. So as a client, you are unsure really how much it would cost in the end, exactly. But you have more confidence. You will pay the right price. As a contractor, you do not have the same pressure to potentially losing money. So if, if there is a problem in a job takes longer than you still pay on a Harley rate. So this, these are the two options that you could potentially have. There's a third option. You could decide to have some fixed price and some Talmud material like for instance, a contractor, I could tell you, we give you all the materials, fixed price, so that's $750. You know how much exactly you're going to pay for those. But we will have the labor as as Tom and material, so we'll give you $50. For that. We will charge you 520 p alpha. 52. Budget example: Welcome back to the course. Lets have a look at a project budget example. So what I have here is a bit of an example of a simple project where you would have and project management coordinator and a developer and a tester, There's obviously would be more resource involved, but I just wanted to give a, give you a very simple example. And I wanted to split it between talent material and also in fixed price, you would have the Talmud material. You would have the estimate of how long the project is. You would have the 50 days here. So that will be the length of the project's multiply by the rate and you would have a cost here. So for timing material, as I was saying, this is just an estimate. If the project takes longer than your costs will increase here. Tammany material. Again, if the estimate is wrong, then this would could increase if it was a underestimated. All those resources are the number of days. And now you have the red per day and I give you total cost. That caused hopefully will not change. But if they are, if there are events that goes in the way of the project, the issues then these, these costs could change. So in fixed price scenario, then it's more convenient of those. So the purchaser, silver, it's going to cost you $20 thousand, you know, it security testing. It's going to cost you $10 thousand and you do it. So this is how you would put your budget together. You would add all the time and material, and you would add all the fixed price. And that would give you the tutor estimation, the danger zone, Time and material. So that's the one that you need to keep an eye on. Could potentially be an opportunity if things takes, take less time than Plan. But that's your starting point. 53. Schedule based budget: That's another example that I wanted to give. I've put this, put it under the advanced category. Feel free to skip it. It's called a schedule based budget. Instead of giving your finance department a bulk cost at the end of the project, you actually split it on a monthly basis. This would look something like this. Let's assume that we have the Talmud material here. You would have every mumps here. You would have an estimate for you needs to build. You have 75 units and you have an estimate of 100 low per unit that you build. Obviously being Tammy material, this is just an estimate, so it could cost more to build ten unit. So how does this work? You would tell your finance department or whoever you management you would say at the end of January, I would have spent 10 thousand, end of February, 20 thousand, and of March 30 thousand, etcetera, till the $75 thousand at the end of the project. Sometimes the finance department only free up the Monet on a monthly basis, so there will be handy for them instead of handing you a 75 thousand and they would just dripping feed you every every mom. So here we have production is planned to freeze for April. Therefore, your tutor cause for April will increase and then you would reflect that on your monthly opinion day. And that's your project budget. So the difference with this budget example and the one I provided earlier is that we provide a monthly estimate of unearthly project would spend. And as you'll see, it's quite convenient when we are tracking our budget. So in other words, end of February, you can check how much you have spent and compare with this amount. And I will be more accurate instead of only comparing with the final cost of the project at the end. So during execution, we will review how we can track the steps of budget. 54. Budget contingency: To finish on costing a quick slide on contingency. Sometimes when you put your budget together, you can put four some contingency funds to be added to your budget. So you might be okay to do it, but they don't always allow you to do it. So they are mainly two types of contingency. Money that you could get. One is a risk contingency, the other one is estimate contingency. So when you overall budget, you would have your base budget plus the risk contingency at plus the estimate contingency. So the only thing is you cannot access those under certain conditions. So the contingency for risk, you will only be allowed to access it if the risk realize and you had some action that actually costs money to fix the risk. And the contingency for estimate. So that that's more contingency. If you are not very confident, raise your estimate. Let's say you are. It's a technical project and your technical team has provided you with an estimate, but they are not extremely confident with it because it's a bit of a greenfield for them. They have never done it before. So you could go and say, well, this is my budget, but I would like to have 10% on top because of these component here. That is, that is a little bit scary and we, we are not fully, fully confidence. I think sometimes it's a good way just to reduce your budget instead of, of going the full monty and having this, these two together as your baseline. You say, well, I will go for these budget, but just as a heads up, there is some contingency here that might need. So that's it for the contingency. 55. Quality planning introduction: So welcome to the quality part of the course. I'm sure you've been waiting for that one. So it's my job to make sure that I don't lose you at this point in the course. When I was learning project management, as soon as we got into the quality part, I was just anyway, but I think that quality doesn't have to be so excruciating. It's just a matter of for the project manager to ensure that the quality is being applied. You have the responsibility of quality on your own processes. And you have the responsibility to ensure that the quality is applied on the overall project. So it doesn't mean that you have to measure things yourself and check things yourself, but you have to make sure that whoever is best placed to do these measurements is actually doing them. Let's have a look at quality in a little bit more detail now. So most of the times teams know what they have to do to ensure the quality. But the challenge is that quality can be quite subjective. Therefore, we need some way to measure effort we are doing or what will be delivering is of quality. So we need to ensure that the final product and also the delivery process would be of quality. So the replanning restate what we will do to ensure that the quality across the project, what actions we will be taking. The outcome can go either inequality plan, as mentioned, or we can go, she says as a section in the project management plan, which is, which is more common. 56. Quality planning - How do we do it?: Planning for quality, how will we achieve it? So the way I see there are two key components involved in planning. We need to ensure that the processes and controls are in place. Even as a project manager, I need to ensure that they're following my own process or that will ensure quality to the project. And at the end, hopefully, that can reflect back to the quality of the final product. So in order to check if processing controls are in place, we could ask ourselves the following questions. We could ask ourselves which processes and controls will be using. So we could list those and that would make everyone feel more confident that the quality will be applied. And we could also ask ourselves, are there sufficient or do we need to set up additional processes and controls? So for instance, we could say the change control process will be used to avoid a scope, scope creep. Make sure that we don't go out of scope. And if we want to go out of scope, who will just have the change control process to keep us in track. And we could say the budget will be reviewed monthly. We could say we will review all the process at one bumps into the project to ensure that they are still valid and they are efficient. So that's we don't want to reinvent the wheel here. We have usually, usually procedures at we, we want to use, but it's always good to have a fresh look at those and to confirm they are, they are still valid. And other parts of planning for quality is testing the final product. So it's good to have all your processing controls in place, but the final product needs to be of quality as well. That's, this is what the stakeholders want at the end of the day. So what questions do you ask yourself? How will we test the final product? So usually you would have tested him and they know what they have to do, but it's always good to save those different type of strategy or external teams will be involved with this. What are the criteria that will satisfy us? The final product is of good quality. So at the end of the project, we need a way to say yes, this is exactly the final product that the client or the business or whoever wants. So we need to have some type of acceptance criteria. So here we stipulate which testing will take place. What do we do if the test failed there probably a process if either testing is not good. And we send that back to the built-in analogs that we can specify all that. So here in our project management plan, we could have testing would be outsourced to company X, Y, Z. We could say it was a it will provide a weekly report on testing. We could say that will provide us with a test plan that we will be reviewing. And here we could say that the acceptance criteria would be that all the testing has been completed ends and only minor issues left. So once you've released all that, everything, everybody, sorry, is more confident that you would have a quality product towards the end. So having a quality product doesn't mean having a solid product, but it also means that it's actually the product that the business wanted. So the final word on quality, if you like, is in theory that the project manager role in quality is not to perform quality. So you don't go to the team and tell them, you know, show me show me what you have done so I can check it. So you you would be more asking questions. You know, what have you done to ensure quality? Have you followed your, your testing processes in arrives? So if you see something by all means go sometimes to website development that has actually happened to me. Check the work, the guys at dawn and realize that, you know, I saw a few defects already. So I just I just mentioned it to them. If there's something really abuse gearing. Yes, of course, do eat specially if you have time. But if not, you just need to ensure that the quality is being applied. 57. Quality: Types of Testing: Here on the slide, I have listed all the, not, not all the main types of testing that you could come across. And I just wanted to just to give you an ID that will test the final product. They are sometimes a lot of testing that, that can occur. So this way, if you, if you hear about those words, terminology, you, you'd be familiar with them. Starting from the top. And I've put some green styles here to highlight the key ones. You would hear the system integration testing or seat. So that's usually done for software development projects. And though you could develop the software, it could work perfectly. But if he doesn't integrate well with other internal or external software components, then that, that's not good. So an example, if you test a new accounting software, if it integrates properly with legacy applications, you don't get to continue this up. I've put it under the advanced slide. It's only for your information that the stage. Now the next type of testing, which is more commander, suppose its core, either the functional testing, the system testing or sometimes just called testing. So it's usually done by a specialist team, a test analyst, and they check the final product works properly before handing over to the business. That they have test scripts. And it's more formal testing that what a business would do at the end. They are a team of specialists. In other words, it's very good to have that down before the business comes into play. As an example, you know, the test team could check the navigation of a website is working as designed that we could take all the links one-by-one are working properly. So all the functionality would be working. So do user acceptance testing. So that's when the final testing takes place before we can release most of the time. So the business would come in. We would give them for the scenario of website, for instance, we could have access to, to, to OwlTest and garment. And they would come with that test scripts and they will check if the software is actually what they required. They check that the product meets expectations and requirements before we go into implementation. So an example, they could check if the correct process be calculated on the product sold on the website. Next, I mean, those are slightly different, but I put them all into the categories. More resilience, stress testing, performance testing, or check the final product is robust enough under extreme condition. For the website, you would you would simulate the role of people using the website. For the breach. It which is the example here, you would bring I don't know if you've seen these, but they bring no 50 huge trucks on the bridge to ensure the breaches solely, Jennifer, I don't know what would happen if if it's not if it's not enough. So I think they probably know what they're doing. So that's another type of testing that you could have. There's also the production verification testing or PVT or production testing or post-implementation testing. Let's take the example of the website that no, let's say you go live on one day, in the morning. When you're alive, the users come in as a, as an external user and they would check that the website is, is working properly. The system is live, but still define our testing before everybody, everyone gets seen. So take the implementation of a software Live, works as it didn't taste. So website going live but only if users can access it. So that's the scenario was just referring to. So as mentioned, there's a plenty of type of testing that you could come across. This unit testing. So this is usually done by software developers when they do they on their own testing prior to giving it to the, to the specialist team. So you might hear that, but you know, it's more or less developers doing their own work. You could also have penetration or pen testing, which is quite popular at the moment. It's to ensure that the website cannot be hacked. So it simulates cyber attack and check if that no, it cannot be attacked. That website is safe. Release testing also, you might hear that, oh, that's more to find our testing that we do before software is released. So if you'd be overwhelmed, just bear in mind is to you, we'll just call them the testing itself and the User Acceptance Testing. 58. Quality: Example of Testing for Soft development projects: I just wanted to show you as well what he would look like on the software development project that you will have. So here you have all the planning. Here you have the execution too, which is a design development. And then you would have all the testing. And I just wanted to show you where I would fit in. The first testing that you would have would be here. So the team would be doing this development at the state. And then after you would have the system testing. And after this you would have the business. They would come and do their user acceptance testing. This one is known. Here you would have the penetration testing, usually it's being done at the very end when there's no more software chance being done. So they want to check that the website is safe. And then just before going live, you would do to your post implementation testing, PVT or production testing. So you see that quality in a project can occur at several, several times. Not only you have your, your recurring processing controls quality to be put in place, but also you have some, some key milestone here around its type of testing. 59. Optional: Project Management Plan Example: So next we have an example of the project management plan, but have put it as optional. But it's a good way for you to understand what happens in planning and how the final document looks like. So hard and put all the way forward what you should have in a project management plan. It's actually quite succinct in a way, but I'll walk you through every part of the project management plan so you really understand what this document is all about. Let's have a look. Welcome back to the course. Project planning comes to an end. So we'll have a look at a project management plan example. I'll have that on two slides. It's more or less to review all that we've seen during that phase. And just to give you a bit of an idea as we did at the end of each session. So the project is building a breach. So we would have the scope statement, Blue beat similar that when we had an initiation, but we will go into more detail. I just have here, build abridge the job includes all elements of the bridge, but exclude all traffic lights. That will be done separately. So you would go into more granular and you would have more bullet points in these high-level scope. But obviously, at the end of planning, you would also have all the business requirements. So the business requirements don't come from this document here. There will be provided separately. So you can refer if you like, any endoscopes had men saying the scope is all the business requirements that we have produced separately for this project to be a success. We wanna breached we ready by the first of February 2022 or the second of January 20th, 22, if you read the dates the other way, with literal disruption to traffic around the building size. So this is clear as to be done at that date and we don't want any disruption. So the project team know, know where they have to do. The project approach. The work would be probably our souls would be hiring a company XYZ to do the work. A console Pm will be coordinating the work testing would be outsourced to company a, B, C. So that's giving you the high level approach of on the how will be progressing with these, with this project and this document, if you give it to executive, They would know how we will be doing it. So this is useful for them. If we have some constraints, we can release them as well. Construction should not interrupt the current traffic that was also mentioned, the inner scope statement. The breach must be operational by first of February, so that that's also part of the critical 66 felt L. So if you have any constraint, things that are preventing you from moving as smoothly as you, as you would like to you. You would list them here. Deliverables, bridge. But we go a little bit more granular layer also want as part of a deliverable will be operational restrictions. We want a maintenance schedule to use after the bridge is completed and you can list them all. Go crazy. You, if you are a business you want released here of all that the project would give you at the end of the project schedule. You can says the milestone view here. What I will do is I would put the milestone view here. And depending on, on where you work, sometime they are interested in more details schedules so you could attach your, your Gantt chart towards the end. This will have to be signed at a business. So the business wants some confidence that we'll be meeting your timeframes. And the best way to provide them with confidence is to give them a break down all the tasks and by which data will be completed. Continuing on the project management plan, the budget. So here you have a very detailed budget. So you you can provide them the detailed budget, but in this document, you can give a summary. You can see the total cost he search and across two years. And then you refer to the budget breakdown and timeframes. If if it's a budget based on the schedule, the quality, you can make some statement here, or you can refer to the company's quality management plan. But you could say things like, you know, the company ABC, which is a company we have hired to do the testing. Abc will be entering the breeze, would be tested to best practices and we presented testing strategy for approval. You could almost say that ABC will be testing to give us the green light for when the bridge is ready to go. That's clear. So when the businesses out there, they okay. That's okay. It looks like this has been taken care of stakeholder list. So you could, you could duplicate the stakeholders leap that you had in your project charter, or you could be more granular if there are any changes and arrives. You could list them here. Communication, communication you have, you would have your communication plan. Or if not, then you can just let them know when a project updates will be will be sent. You can mention if there's a steering committee and you can also mentioned that the outsourced company will be providing their weekly report to your project manager. And the project manager will escalate anything significant issues. Risk register. So we already have a risk register from the initiation phase. So we can refer to the risk register here and we can say, well, we have noted down on the risk, the contingency Manet for this risk as I've been a bit included in them in a budget, if that's the case. So you can provide a few sentences here on the, on the risk. And then you can mention any other planning document, procurement, communication, human resource, Anything that can do way I see this document is anything that can make the person who will be signing this document field better. You listed listed here. Existing procedure would be followed. Know that planning document will be required as the stage but the project some if required. So that's it for the example of the project management plan. You can have a look in a, in a resources. There is Corso draft template just to show you that the Project Management Plan cast a very simple, obviously, depending on where you work, if you wanna go into project management, you would not come up with your own template. Usually they would have their own templates and, and you would have to use them. But it's always good to have an example of some ways. So there you go. 60. Phase 2: Planning wrap up: So that's it. We finish with project planning. So to summarise, project planning, be as thorough as possible to avoid any surprises during the execution of the project. In initiation, we needed to have the big chunks, right? In planning, we need to be very granular, very meticulous. We need to make sure we have everything plan very thoroughly. So the more thorough We are, in theory, the easier the execution will be, and the less surprises we will have. We will always have surprising execution, but the idea is to reduce the amount of surprises that we could have. So ensure that the requirements are as precise as can be. So that's something that sometimes is difficult to get control of because the requirements come from the business in a way comes from outside the project team. So this is why you have to be a bit thorough with us. And when they give you a requirements, you check with your video team. Is that good enough for us to get started in them, in the execution? So get everything sign off before you get into the next phase. The requirements, you project management plan, make sure it's sign-off by everyone. So there's often pushes to start execution as soon as possible. So use your common sense there. You don't want to sound too and all and say, no, I'm not going to start execution until everything has been signed off and I don't think you will come across as someone very flexible if you do that. But use common sense and stress that sign offs are really critical. So now there's only one thing left Morris is to do the work and do the execution. But before we do, don't forget the quiz. And I'll see you on the other side of this. 61. Phase 3: Execution section overview: Welcome to face free execution section overview. So as usual, we will start off by providing the purpose of the execution phase and also the project manager role in that phase. And then we will discuss the following activities. Scheduled management, scope management, issue management. We will have a closer look on meetings reporting will also have a look at coastal tracking and very specific component, of course, trucking, which is an value which I have flagged as advanced because it's not always present in project management. But I suppose it's something good to know. And finally, we will wrap up on this phase and there is a quiz as well. 62. Execution intro: Welcome back to the course. So now planning is completed. Planning is completed. That means we have our sign off on our plan, on our project management plan, on the requirements from the various documents that we have. So it means that now we are okay to proceed to the execution of the project based on the plan that we have provided and that has been accepted. Now let's have a look in more detail. What we need to do during the execution. Planning has been done. This phase is more about monitoring, controlling, fixing issues, and reporting progress. Have a look at the key components. Of course will have to do some coordination. So that depends on the maturity of the teams. Sometimes it can be very easy as it seems I used to work together so they coordinate between themselves. But sometimes a more hands on approach has to be done for the project manager. Reporting, very important to report. So that has to be done usually on a weekly basis, but sometimes a fortnightly. So it depends on where you work. If you project manager, quality control, making sure this is take, taking place. I've looked at your processes, communication. Make sure that everybody or the stakeholders are being communicated to and how productive going. If there are some purchase, reviewing the risks as well. This has to occur. Managing issues. Of course, we'll talk a bit about that later on. Monitoring the schedule and coasts. So that's one of the key component. We will review the three key components in just a minute. And review. Project management is not just about rolling tasks. If you feel that the trend is going in the wrong direction or there's some tragedy strategy changes. This is where you really make a difference and say, well, hang on a minute, is it's still worth doing this. And then at the end of all that, you do some implementation. So there's just a snapshot of the key component. All depends on the type of project, the amount of work you will have, but this is a good salary. But if you are still daunted BY these lists, let's review the three key components that I believe you'll be involved in as a project manager. For the first one is reporting non-negotiable. This has two. Apparently there's only one thing you do during the week is to do your reporting. If you don't report on time, your management team, business, project office, or whoever would think that you are not on top of your project. So this is my advice. Reporting goes first. It's tempting to say, well, if I do reporting, I don't have time to do anything else and I hear a lot of that from project managers, but put that aside, trust me, reporting goes first. Second thing is managing issues. You might have a lot of issues. You might have less issues, or you might have issues that don't need management because the team is mature and they know how to fix it. And they, and they have processes in place and the likes, and they are quite self-sufficient, but sometimes this is where you spend most of your time. And finally, have enlisted coordination but monitoring the schedule and the cost. It's something that obviously you have to do. So you have some, either use your Gantt chart or prefer to have the more granular task lists were can really tick them off as I progress. But those, those three activities should keep you busy. During execution. 63. Purpose of the Execution phase : Welcome back to the course. The wheels in motion. We've had our sign off in planning and now we can do the execution. Planning has been done. This phase is more about monitoring, controlling, fixing issues, and reporting progress. Let's have a look at the key components. Of course will have to do some coordination. So that depends on the maturity of the teams. Sometimes it can be very easy as it seems I used to work together so they code in it between themselves. But sometimes a more hands on approach has to be done for the project manager. Reporting, very important to report. So that has to be done usually on a weekly basis, but sometimes a fortnightly. So it depends on where you work. If you project manager, quality control, making sure this is take, taking place, have a look at your processes. Communication. Makes sure that everybody, all the stakeholders are being communicated to and how the project is going. If you have some purchase, reviewing the risks as well. This has to occur. Managing issues. Of course, we'll talk a bit about that later on. Monitoring, schedule and coasts. So that's one of the key component. Will review the three key components in just a minute. And review. Project management is not just about rolling tasks. If you feel that the trend is going in the wrong direction or there's some tragedy, strategic changes. This is where you really make a difference and say, well, hang on a minute, is it's still worth doing this. And then at the end of all that, you do some implementation. So it's just a snapshot of the key component. It all depends on the type of project, the amount of work you will have. But this is a good summary. But if you are still daunted BY these lists, let's review the three key components and how I believe you'll be involved in as a project manager. For the first one is reporting non-negotiable. This has to happen. It is only one thing you do during the week is to do your reporting. If you don't report on time, your management team, business, project office, or whoever would think that you are not on top of your project. So this is my advice. Reporting goes first. It's tempting to say, well, if I do reporting, I don't have time to do anything else and I hear a lot of that from project managers, but put that aside, trust me, reporting goes first. Second thing is managing issues. You might have a lot of issues. You might have less issues, or you might have issues that don't need management because the team is mature and they know how to fix it. And they, and they have processes in place and the likes, and they are quite self-sufficient, but sometimes this is where you spend most of your time. And finally, have enlisted coordination but monitoring the schedule and the cost. It's something that obviously you have to do. So you have some, either use your Gantt chart or prefer to have a more granular task lists were can really tick them off as I progress. But those, those, those three activities should keep you busy during execution. 64. PM role in the Execution phase: Let's review quickly the role of the project manager in execution. So it'll be a bit of a repeat of the previous slide. And this is what I want to go through this one quickly. We saw all the key components of execution, the project manager being involved in all components, then it will be very easy to guess what is the role of the project manager and execution. But before we start, I would just wanted to mention that sometimes execution is a bit of a smoother ride for project managers when there's no issues and arrives. But regardless, this is the phase of the project where the project manager is the most in view. So where anything that happens on the project closely or from a distance, the project manager will always be the first of contact. Actually, if something happens in your note, the first of contact areas, they could mean that there is something wrong in a project. You should really be the first of contact. Having said that, let's go for the role. Coordinate work between teams, we saw that monitor the schedule and budget are let let people know there's a there's a slippage, report on it and fix it. And Joe qualities performed, communicate project, progress, fascinated purchases, manage issues, and monitor risks. So as you can see, it's more or less a repeat of what we had before, but we've reviewed that and now we can move on to schedule, which is, as mentioned, that's one of the F3 key activities we are monitoring, do schedule. 65. Scheduling in the Execution phase: introduction: Let's review scheduled tracking as part of project execution. So during planning, we created a schedule with detail milestones and dependencies. And right now during execution, we just a matter of entering those tasks are done. And we just monitor the progress and we address any slippage even better if you can anticipate slippage and prevent them that there'll be very appreciated by your management team. So how do we do this? So I'd like just to mention quickly Part three of this course. Part three of this course, we will discuss briefly the difference between two methodology which has waterfall and ajar. So for this part here I want to stress that this is more addressing the waterfall component. Waterfall is more or less when you do just everything once you only have one planning, one implementation and lights. If you are working in an agile environment, you have a different looking schedule. So how do we track this? We, we use usually a software called MS project. And again, child that we've discussed in planning. 66. Critical path definition: On the slide we have a Gantt chart representation. The one I mentioned in planning using the MS project software. I just wanted to mention to get us started on the critical path and what it is. So critical path is the path of the schedule which infant impacted the world schedule will be impacted. So that's the way I like to see it. In other words, it is quite intuitive really that you know, that if a task is delayed, the will protect would be delayed. And we would call, we would say that that task is on the critical path. Let's review this quickly. So what we had was we were doing the design, the design which was this, we're doing the development, which was this an after we were doing the testing. So if the design is delayed, as this task here comes after and is dependent on the design, then this task would be delayed. And if this task is delayed, then du will project would be delayed NFO the implementation date will be delayed. In other words, we say this task is on a critical path. This task is on the critical path and likes. Now if there is a task that is not on the critical path, like for instance, this one here that is not on the critical path because there's plenty of time for this task to complete. Let's say training documentation. The writer of the training documentation is not here or is she sick or drives and he or she is not going to be able to start until that point in time here, this ten days work without delay the project loop. Because there's plenty of time in more or less has until the 26th of July to to complete this task, which is the beginning of the next tax because which is a training requires is training documentation. So I have just one task here that is not in the critical path. All the other task, if they are delayed, that would delay the implementation. And this one if, if, if delayed will not delay the implementation. So that's what a critical path is. 67. Schedule monitoring : Let's continue with schedule monitoring. So I just wanted to show you how in theory the project manager can check if a project is ahead of schedule or behind schedule. So I have a screenshot here of MS. Project gunshot on the right-hand side and our tasks on the left hand side. So we have to task names, we have the duration and we have the percentage complete and all these updates, the start and finish dates. So in order to check if we are on schedule or not, we are having a look at the task here and the percentage completion here. So for each task, we allocate a percentage completion. So here we have this task here, a 100% complete and the percent complete. So all the planning tasks are complete. So that means the planning is completed. If we go and execution, we have the design document a 100% complete to its dawn and development tasks. Those two tasks are 20% complete. The all the others have not studied yet. On the right-hand side. And again to help, but part of the screenshot, we can check if we are ahead of schedule using today's dates. So today's date is this vertical red line here. And this insight line that is within the bar shows us the completion of that bar. So here a 100%. So you see around fruit and all this other line through here, only 20% of the task has been completed. So the inside line is 20% of the, of the bar. So it takes you here only when in theory, if you own time, it should take you just write bang here. If you were ahead of schedule, this insight line should be in the future. So that so that would mean that we're ahead of time. So obviously that's all very theoretical. And those tasks being largely would have on these MS Project or on a spreadsheet, or somewhere. The developer would have all these task listed and the racks or you could have a more granular on precise way to track, but the id is on his high level, if possible, to have a percentage completion. So if the team can, they would tell you, well, we are around 20% completed, 25% completed. You would put that in and I will give you a very quick visual way to check if you are on time or not. So here you will be concerned because we've seen that those tasks on the critical path. In other words, if they are late or project implementation will be behind. This task here is not on the critical path, so it hasn't started, should've started while back. Virtual concern because it's not on the critical path. So you see you have all these time here to have it completed. So that's just a brief overview of no scheduled monitoring, how he's done. This way. Keep this simple. One or two pages if you can, do the rest outside. So this gives you, nevertheless is very important because it is a central point if it weren't for the project to have a view on where we add, it's good for your cells, but it also good for the productive members, for the management team, for the steering committee is it gives them a level of comfort knowing that there is a central scheduling in place. 68. Scope Management : Welcome back to the course. Let's review scope management. So during planning, we have precisely defined how scope. We have business requirements. We have a business requirement document or the requirement matrix. Whatever process we used. Now, our job during execution it to make sure that we stick to those requirements. When it makes sure that we do not perform activities that are out of scope. Because that would most certainly increased project costs and timeframes. So we have to apply a little bit of project quality control. And there's a process that we use and that is called Tange control for that purpose. So this is, and I will discuss this in part to the interview part of part two. It is a question that you will probably hear when you go and interviews as project manager. It will be along the lines. You know, what do you do if the business comes to you with additional requirements? And here's the enzyme. So let's have a look a bit more closely at what the change control ease. 69. Change control: So if there is a change in the requirement, regardless of where it comes from and the reason for it. The project team really needs to assess the impact. And potentially what we call a change request needs to be raised and that we need to get approval from the steering committee so I can walk you through the process here. This process is really dependent on the, on the company itself. But I will show you that the vanilla version if you like. So the starting point, we have an additional requirement from the business for whatever reason. The first question we ask ourselves is, Is requirements small enough? Sometime is just so small that okay, we, you know, the business forgot to mention that they needed this. But we discuss with the team and they say, oh, this is fine, we're just going, we can just slip it in and we can just do it. So and then what you do, you just you just include the requirement in a scope. This additional requirement is very small and your equity is in scope. But what I have here is a shortcut is not always accepted. So by your management BioProject 2F0. So they say they are this is more, I don't care that they didn't want it. They're gonna keep coming reserves, more requirement or the wide. So that depends a lot on, on on where you work. It's it's a good I think it's a good way for as a project manager to show that you're flexible. Yes, it's a small requirement, but we can slip it in so it's good for your relationship with a business. But at the same time, if you're management doesn't want to, then you Just as opposed to undo it. So what happens if the requirement is not small? So the business, we ask them to raise a change request for a proposal to the change requests a document, Word document, or or whatever that the business will write to formalise it? Yes, we need these new requirements to be assessed. Sometimes it's not a business, sometime is a project manager that actually doing it on behalf of a business, but that's not really important at this stage. So in order to do this, yes, so this is the change requests that we will see how we can fill that in simply. On the next slide. That is more or less document where you input some information on the change that you want? There is the committee somewhere. I could be sometime just a steering committee or sometimes just an agreed approver somewhere that had a look at a distended request and it will have the impact on, you know, on schedule sometime the impact on cost is going to require more money and the rock so they had a look and either approve or decline it. So let's have a look what happens when I approve it. So when I approve it, there are two things that occur. The first thing is. We include this requirement in scope. So yes, we will be doing this requirement. And what do we do is we change our budget. Let's say there was more money attached to this requirement, but it has been approved. So now we go we can we can put more money in our budget and we can have a baseline schedule, data plans as well. So we're squeaky clean. We had a baseline. Now we do a new baseline because everything has been approved. Now, if the change request is, you know, is turned on, you just log the change request somewhere. You just file it, and then you don't do anything on these new requirements so that this has been turned down. So that's a quick overview of what happens. A new requirement could be found for many reasons the business relies, they forgot something or as part of the more precise work they realize there is another piece of work that needs to be done. So if it's small and if you can include included in a scope and just keep working on it, benefits not more than you have to have a keep keep keep a track of it and have a bit of a log. So you you put a change request. If it's approved, do the change your baseline if it's not stays out of scope. So this is what a change request look like. Simplification. Again, this is all you need. Unfortunately, you have to use templates that says that you are, you are being provided with. So you don't always have to you don't always have it so simple. But this is the minimum I would I would recommend. So you have an ID so that allows you to keep track of it. You have the name of the requester, you have a description. And let's go with this example of the bridge. Again. The business said at the bridge needs to have an additional set of lights at ISAF and trends. And you have reference to more precise requirements so you know which type of light where they wanted to exactly, right? So this is linking your back to the requirements. As a project manager, you have to assess the impact of this change. So that's your role. That business is not gonna do it for you. So you have to check specially if there is a change in the schedule and the budget, if you have the resources for it, etcetera. So here in this example, additional costs and extended time frames as below, packed, schedule the project. We need another free mumps that either budget, you need another $20 thousand. So when that goes for approval, they know how much extra money they would have and I know that it will take longer to date either. So when I assess yes or no for that change request, they they they know all the they have all the elements in hand to make that decision. It's always good to have options. Now here the options are a little bit. Black and white is either you do it either you don't. So the Option one is do the omega change and postpone the initial required after project implementation. That can be an option. Don't do it at all, be another option. Or you accept that new delivery date and you accept the expenditure. And then you say the the change approved and obviously which option you have chosen, and then it's signed off. So it's always good as project manager to try and find several options here. Now here there could have. Here. This suggestion is to have done after the project implementation instead of saying, we don't do it at all. But sometime there are several, several options you can find ways to implement this change. We may be at a lesser cost or faster. If you can Bringing maybe more resources overrides to do the work. So be lateral thinking for option, it's always good. 70. Issue Management: part 1 Introduction: Welcome back to the Course, issue management, defend path. So there is kind of a process to manage issue is which is more or less looking the issue into an issue register and manage it to resolution. But there is no really a magic formula on how really to fix those issues. So when they issue is logged, it's more or less up to the project manager to work with the teams, the various teams to fix the issue. So there's a lot of brainstorming, lateral thinking, influencing that needs to occur for the issue to be resolved. And we'll show you in a couple of slides, the most common type of issue that we have. But before we do that, let's have a look how this tool that we have, the issue register. 71. Issue Management part 2: Issue Register: Once again, this is issue register in its simplest of forms. I don't believe that needs to be more complicated than this. And once I've introduced you to all the columns, I can, I will show you the two most important ones. So first of all, it is sometimes called issue log. I think I mentioned that already, or issue register. There is a template in the resources if you're interested, which is more or less a carbon copy of this. We have the issue number so we can reference to eat quickly that raised we have a description as precise as possible and we have the impact. What is the impact of the issue on the project? And usually it's a delay in implementation due date. When is this issue due to be resolved so that it doesn't impact the project? Sometime we have an issue, yes. But either the task is not on the critical path, o is not immediate concern. We need to know by when it will become a concern. So this is a due date for resolution for the issue. The owner, very important, we need to allocate someone to resolve this issue. And if at all possible, not the project manager. Why not the project manager? Because the project manager role is to coordinate all activities of the issues and to manage the issue to resolution. But most of the time, the issue itself cannot be fixed, quote unquote, by the project manager. It comes from a technical team is come from, uh, from another team. If its resource not available, then it's a resource manager, then is to fix the issue. So the project manager needs to avoid being being the owner of the issue. The status open or closed. The latest update. You know, it's good to put dates on these date these occurred and after you put all the subsequent date and related risk number, when a risk occurs, it becomes an issue. So for instance, this here as not applicable. So these issue here doesn't come from a risk. But this was highlighted as a risk initially, and now the risk has occurred and therefore it, it's an issue. So this is just a couple of example. The first of John, securities testing resource won't be available until the first affair. The issue is, will delay implementation as it takes testing isn't a critical path. Tetris is required by 155 jobs, so we can still fix it without it impacting the protect implementation date. We have managed to get an owner here. So the test manager, in his situation, the manager of the testing results, is the one that is owning this issue. And provide an update here, the test managers at 22, attempting, sorry, to free up resources. We provide an update by the end of the week. That's good. So then again, 1 third buddy to provide ongoing maintenance of the website. Still not selected. Guys, we want you during the risk. Now the risk is occurred so major because we cannot go live with without the ongoing maintenance. The due date selection is required by the completed by the 29th of Jan or otherwise that will delay the implementation. We managed to find that an owner, Natalie, the procurement manager. So this one out. So it's not just a matter of putting the aura and what for her here to fix the issue. Obviously, we didn't need to be managed activity by the project manager. And Natalie provided an update is looking good companies been earmark and your diligence is in progress or do the 1449? Have a look at the two key colon? I'm sure you've guessed them already. So the owner, they need to be reminded that they are issue owners for this and that they have date, due date, which is as again, most important colon. So once you have an issue and you manage to have an owner, your due date, then things are under control. They are not you are not left here as the owner to try and chase everybody up to fix the issue has been clearly established that there is an owner and there is a due date. 72. Common Issues: So let's review the most common issue which tasks RPN schedule. So this is more or less an outcome and as potentially an infinite number of causes for these. But I just wanted to highlight two key one and see if we can address them earlier. So common cause for a delay and how to reduce the likelihood. So if we take them one by one, the first really causes, you know, the estimate is wrong. So we try and use contingency as much as possible. When we provide our estimates. And two, we push the teams to be as detailed as possible so that would allow them to uncover any sub-tasks that might not have thought of. So you are more likely to find at that point early all the tasks that are required, but that would or should occur in planning during execution, it's too late. The resource not available. That's quite common in when resources are shared. So how to reduce his avoid shared resource? I mean, have you alarm bells as soon as someone tells you where you can have these resource, but he or she is being shared with another project or another business as usual team. Avoid if you can put that as a risk. I have a shared resource. Also, a way to reduce the likelihood is looking resource early and formerly. Get it in writing that you can have that resource from that date, from that point in time. Another cause for delay is a resource not scale for the job. That's a bit, that's quite tricky sometimes, but at the end of the data will impact the project. So try and discreetly tech credential. How does resourced resource worked on these type of activities before? And as soon as you notice it during execution, are let as early as possible and put that down as a, as a big risk or the cost for delay additional work found. So that's what happens when a detailed estimate and it disturbed breakdown of the task only occur, occurs the ring execution. When that occurred during planning week still good because we can attempt to change the timeframes and the budget, but during execution it's too late. So there are two causes that's for the that was addressing. The first one, detailed estimating planning that would reduce the likelihood. Same as this one. But additional work phone is detailed. Scope treatment would address this issue as well. Well would reduce the likelihood as well. In scope. In planning, we mentioned the need to be as detailed as possible, and this is where I would pay dividends. And that the scenario. So your design team or your development team would say, Well, I realize I need to do this as well. I was discussing with a business and they say that needs to be included. And then you're difficult situation that if you don't really include these, the business will not be happy. And so therefore, you need to be able to push them towards change control, towards raising a request. But in order to do that, you need to demonstrate to them that what they are asking you now is out of scope and was stated out of scope in a document that you have provided m of course, nobody knows where it is, but you you'd be tactful and you would just highlight that to them. To more things. Use contingency if you can. During planning. I mentioned that the estimates could change and try and get some contingency Monet. Or hero, if you notice the resources nodes killed, you know, use that as an excuse to get contingency. Whenever you can, obviously, preferably in planning. But even if you do that in execution, it's good because it allows you to anticipate potential Dealey and try and fix it before the delay is impacting the overall project. Brainstorm the team on the risks that could cause delays. At the end of your meetings, guys, do you think about any risks that could cause delays? And some resource will be more than happy to come with tons of them. Take note of them and just try and sort out the potential dangerous ones. So this is it for issue management. So managing issues is really where you can show off your skills, show off your lateral thinking. Good things happening, anticipate problems and when there is an issue, stay on it until resolution. Let's go to the next path. 73. Project Meetings: introduction and types: Welcome back to the course. Project meetings. Not always very popular. Who is team members? But very useful for a project manager. So in part two, I will show you how I feel you can get the most out of these meetings. But for this part here right now, I will show you more how it is done in a more traditional way of managing meetings. So project meetings can be used to coordinate work and for us and the project team and escalate issues or get assistance from the management team. So-called in-network and influence and motivate the project team. That will be more for your project team meetings. And this will be more for the steering committee if you attend them or management team meetings. So as I mentioned already, there's two types of meetings. The project team meetings that you have with your team. This is the one that you are sharing. You invite all your team members and you chair the meeting and you have the agenda, you will have minutes. And Steering Committee or any management executive meetings. These ones, you don't really chair them. Usually you are just a participant this meeting. So let's take them one by one to productive meetings. The traditional way what you do is you, the project manager gets updates from team members. You look around the table and what did you do this week? Yes, that sounds good. Then you you take all this into account after the meeting, you you go to your schedule and you update your schedule and your issue register if if if any, and you write your minutes and you send it across. So it's also the opportunity for team members to discuss issues that don't always meet outside to meetings. So that's a good opportunity for them to discuss. You can of course, coordinate the work. When one finished the task, the other one can, can start in two or three days. So you have to coordinate this. And this is where you do your issue resolution. The steering committee, the project manager is there to provide updates, not to get updates anymore, to provide high level updates. And I will show you on the next slide that difference between the two types of meeting the difference of detail genetic gave for each one of those. So now this is your opportunity to escalate major issues. I don't like putting big issues on the table during meetings, so I would usually go and have one-on-one chat or phone call to give everyone a heads up. And if possible, have an issue resolution strategy ahead before I drop the issue on the table. So that's something that I think it's very important to do. So this is usually no chair by the project manager, is chaired by the steering committee member, business owner or the likes. So two types of meetings. One way, when you, you really have your outcome, what you want to get from the team. And another one When you're a participant and where your chair would have her outcome that you want from the meeting. So this is your outcome and this is the steering committee outcome that is to bear in mind. 74. Meetings and Reports: What to discuss: I come back. So we'll review reports a bit later on. But this slide here works for both for meetings and report. Trying to highlight the difference of content that you would have in meetings and reports depending on which type of projects. So I mentioned this to key meetings that you would attend. This one that you will chair the protective meeting, and these are the one that you will be a participant. Obviously, there are tons of other meetings that you will be involved with, usually ad hoc. But this is really the two key ones. So if I take the component here one by one, we can check to which meeting it applies. So for, for instance, is when he high-level update and status update on key milestones. So that can be done for both types. Doesn't hurt to give your team and a bit on a high level schedule. And for the steering committee? Yes. The more detailed update on progress in past week, what's happening next week? What have you done exactly? How did you go? Yes, that goes for the project emitting Steering Committee. Don't need to know that finances. But at up dead, How we doing is really not needed for the project meeting. Unless you have some resource that are really switched on with budget and arrives. But they don't know, they don't come across very often. So I would say don't bother them with this. And sometime it's quite confidential. They're not even aware of the of the budget of the project steering committee yes. Management meeting? Yes. That's a key thing. They they want from you early-stage small technical issues. Small project team, yes. Steering committee, management team. Know they don't want to know about it. They would know if they have to worry about them or not. So don't mention them. Key project issues, yes, the one that we're potentially delay the project, increase the cost. And the one that I can influence yes. Give, give give these to both projective meetings so they can work on them. Steering committee, potentially, though, that they can escalate and assist action items? Yes. Project emitting? Yes. They need to know they need to know what they have to do for the next meeting and the impact if they don't do it. Action items. Well, as mentioned, the project manager is not really chairing this one, but it's very important for you to overlook if you have any action items that you needed to do to report back to the steering committee. And if you manage to do that, not too obviously, you can also give them action items during the Steering Committee. So if you are very setter with that, that's something that you can do. 75. Meeting minutes and template: Welcome back to the course. We've had our meetings always good form to send meeting minutes if only bullet points. But usually you'll be provided with a template. So you can send the outcome of the meeting after the meeting to order meeting attendees. What I'd do is initially if the template is too complex, always try to remove some headings. Always like to simplify because the more headings you have, the more parts you have in your meeting minutes, the more open you are too a more S putting incorrect information and that's provide you a lot of overhead as well. So I've provided you here of list of things that could go in, in a meeting, minutes. The attendees, and apologies. That's quite important. If someone was not present when we when we made a decision with someone never turns up it's good to have them on this list. Decision mentoring meeting, that's very important. So we all agreed on something. It has to be located somewhere. A quick summary of discussion. So we don't want this person say this and then this other person reply this. I don't think we do this anymore. It's not very useful. What is the plan for the following period? That's something that we can do to get everyone focused. The action items that's also important. If we come across a discussion point that needs resolution, then we locate in your action items. What are the key milestones ahead? Once again, to get everybody focused if there's any concerns raised. So concern is not yet an issue, but it's good to put that down. First of all, they make them feel better because I know it's on a piece of paper. And then for you it's a bit of a heads up at something could turn into an issue. You can also go crazy and put all the change requests. One of the outstanding or approved. So that gives a team the heads up. There is some work that he's going to come their way that was not originally included. A key issues always good form to review all the key issues. So you can double these with the issue register review. Or you can just leave the key issues here so you can get your updates on issues by the issue owners. The key risks are linked to how the key risk as well doesn't hurt him. And that's opens to discussion. And they can have a look at the risk and say, well, I'd like to add another risky for possible analyte. And then yes, so that's something else to to reduce the issue of resource being available. So elect to have order, order leave requests listed here. So what are the key ones? Decisions? We want everyone to remember what has been decided. So there's no surprises. And we have agreed on a way forward. Action items very important as well. People need to know that they have something to do by a certain point in time. The key issues always. So that's more or less the types of minutes I would have. The key with the freaky freaky ones, decision med action items and cashews. And after, depending on the templates that you come across or if you can make tools, maybe use this as a starting point. So to finish on project meetings, let's have a quick look at a template that I put together. It's in a resources. Another recommendation that I have is if at all possible, try and send the meeting minutes before close of business on the same day. There's nothing like receiving meeting minutes of a meeting that was done 12 weeks ago. And you will see that that happens. So do it what? It's fresh in your mind. And do it while it's fresh in meeting participants, mine as well. If you send a minutes while it's still fresh in my mind, the more likely they are to review it and provide feedback. Also, it will make you look efficient. Remember, I joined a company and I had a meeting with every man, all the stakeholders and arrives and ascend the meeting minutes on the day with an executive summary in an email. And I had a lot of good feedback from everyone so that it was a good start. Okay, so that's pretty much it for project meetings. Next, we go into project reporting. 76. Project Reporting: Introduction and what to include : Welcome back to the course. Let's review project reporting. So we saw that sometimes with meeting's minutes, you can tweak them to your own preferences. We project reporting, it's more unlikely that you be able to just create your own reports. You might be lucky and you can do it. But most of the time you have the ARM templates. Having say that, even if you use templates, you can still Terrell what's within each heading. And this is where a suppose you need to tell our the report to the audience. I mentioned that already delivered a report on time that would make you look very efficient. Even if there's problems on the project. If you deliver it on time, it's always a good practice. The number and type of reports would vary depending on where the project manager works. Most of the time, you would have the usual weekly reports. That's more detail for your management team and the likes and but sometimes the project office would put all the protect managers reports in one bucket for the monthly report. Sometime you would have to report to your steering committee maybe on a monthly basis to how many reports you'd have to deal with if you're a project manager is really an unknown quantity. Having said that, I just wanted also to show you what can be included in a report. Just to reiterate, the reporting content can be tailored to the audience, but not really the heading. So here what I have is an overall rack status that we will see on the next slide. What it is, rack set is four components. We'll see on the next slide. We'll have an executive summary. This is more for Humphrey CEO executive type of reporting. Other projects. That is obviously how you trick tracking against the schedule. You'll have the progress down in the previous period. That's usually something that they like, is to show that you have actually done something. What is the plan for the following Period? So the period could be week or month depending on top of report, least you achievements. So even if this is not something that they ask, I think it's good to give achievements, to give the project team that boost the key milestone ahead, just to have everyone focused and the change request. That's something that you could have in a report. I think it's always good to keep track of those are ones that are being outstanding, one approved, or the one declined. The Jakob data as well. Tracking against the budget baseline executive that something that would be very interested in. The key issues. Also, if you need to escalate to a project report to usually for someone higher up Diane yourself. So it's always good to put them here, the high level ones, so you can get help for escalation, Sam, with the risks. 77. RAG Status introduction: Welcome back to project execution reporting. So when we saw the project reports, I mentioned rug. So sometimes in your project reporting you need to provide a rack status. So what is rags? So RAG stands for red, amber, and green. It's color-coded way for you to provide a high level visual on how you project. He's going sometime executives have to go through 2030 projects. And I see this project green, green, green, green, green. I can just, I don't even have to review them. This one, MBA, Ooh, it's thought to have a look at and read. So you probably guessed that green is good and red is not good. So there's no clear standard. So and sometimes when you come in a company, they already have their, their own standards there we see green means that you have this. Amber means that you have that. Red means something else. So green obviously is always well, the way I see it is some issue on the horizon that could impact the project. So things are starting to fall more or less. Read, The project is currently being impacted. Another way to look at is how much do you want your executive to pay attention to your project right now? Use it for yourself. If my, if my project as some issues and I'm on top of them, they don't really need to know. So I just put the project green. If I know I'm going to need their help and I don't want to tell them at the last minute, I gave him a bit of a heads up and I put it MBA. And if I need help right now, I put it right. Let's have a look. Project prayer components can be visually tracked using the rag. Components that can be tracked. So I said this is way to track your, your overall project status. But you can also use it for your scheduled. For instance, you can say my project is going okay, green, that the schedule is starting to have a bit of MBA to it. The budget also could be the same. You could be on drug, you project would be green, but your budget is starting to fall apart. Anything else? Can never oc status, communication, scope, stakeholders, happiness, resourcing, risk issues. Some companies also have a bit of a formula. If you have two of those embedded and the project should be NBA. For instance. If you have one read, the project has to be at least MBA. If you have all greens and one red, it's still ok. So as you can see, many ways to use it and, but it can be a very powerful communication tool. So now let's move on to the next part. 78. RAG Status with tolerance: So to finish out with these racks status, sometimes there is a mechanical way for you to calculate your rock status. And this is an instance where your project had been provided with levels of tolerance or on schedule and cost. So they would have, for instance, the first level of Iran's is 10% and the second level of turbulence is minus 20%. So for a schedule it sits if your project is ten month, so you would have still okay if we deliver between 1011 month or 1012 months for the second level of tolerance. So if we take this example for a budget, you have a budget of $100 thousand. If you realize halfway through your project that the cost to complete, which is a budget estimate at completion assay, is between ninety thousand and one hundred and ten thousand and you are good. It is green. If on the other hand, you realize that your budget at the end of the project will be smaller than 90 thousand or bigger than 110 thousand, then you should put yourself and be honest. Unless it's even worse and you estimate would be an 800,000, both 110 thousand. So that sounds a bit crazy. But most of the time, even if you're doing very well and you will be ending your project well below your budget allowance. Then you have to report it as red and you have to explain, why didn't you spend more money? They think the thinking behind this is that why are we so far all the mock while I do, did we just overestimate and Iraq? So they went to really understand why. But some don't, don't bother with these edges. Interested if we are going over budget or not. So that's it, that wraps it up for the ROC status. 79. Project Report example: So to finish on project reporting, as I did with Protect meeting minutes, I have included in the resources a template of a report that you could have. So feel free to go and have a look. In these instances out of just failed a few bits and pieces so you can check out how it looks in real life. So you have the rack set is here. You have the project summary, you have the key reporting stake holders involved here. You're right, a quick status completed this week, planned for next week. You provide this scheduler debt. So this is a marched on view. And you can even have the rack status not only for the overall schedule for each task. A lag these visual way. So you can, it's very quick for them to SEO status for scheduled green, green, green. Oh, there's a red here. Let's have a look what it is as opposed to just willed. But it will tell you the Sam. So here green, green, green, OK, and save the more expensive than estimate. So they can have a quick look. Key issues that to one that we want them to have a look at. And usually prose onto escalation. So that's pretty much it. Next, we go into course. 80. Budget tracking: intro and Actuals Definition: Let's continue this budget tracking. So this is obviously a very important part of project execution. On a regular basis, we need to review what has been spent and calculate what is left to be done. So we can add the two and check if at the end of the project will be, will be good. So first, how do we calculate what has been spent? So what has been spent? We call that actuals Latinos, who I'll be talking about actuals from noun. During planning, we split our cost into two categories. So there was time in material and there were fixed price. So how do we track actuals on those? So for Tom and material, you need to use the time sheets and the hourly rates if you have human resources working on it. And you would calculate the total amount of hours in a highly read. So that will give you the human resource cost. You'd have invoices for contractors as well. So that could be also for Tom and material or there could be a fixed price invoice. So there will be no surprise. They usually would work with a finance department and they would have allocated a project, code. A project. So you should be able to go to them and ask them how much have I spent so far. So they would extract actually all the actual code for your project. So that just some ways that you can keep track of what has been spent. 81. Tracking budget month by month: Let's continue this project execution tracking budget. So during planning, you've put a project budget together. With this example here, it could be something like 100 days, this daily rate or give you a budget. 50 days at this red, give you a budget, fixed price, 20 laptops give you the, so you, your budget at the beginning of the project is 300 thousand. So I wanted to introduce you to a couple of terms if you like. So estimate to complete its your estimate at 1 in time of how much money you need to complete the project. The actual rules, we just talk about those. That's actually the money spent overall until now. And the estimated completion will be your estimate. Now taking into account the actual and the estimate to complete. So that's your estimated completion. That means how much do you think you would spend at the end of the project? That will become clearer with some examples. And that's a variation. So that's, that would tell you if you overspent or underspend. So estimate at completion is to be compared with a project budget. Here's the magic formula. Estimate to complete plus actuals, estimate a completion. So beginning of the project, no problem. Free a 100 thousand to complete estimate at completion friend and Pfizer. So now let's move to January. Step one. We are reassess all outstanding work. So that will be our estimate to complete. We asked the guys, How much time do you need to finish a task? And they said only need 90 days. Only 90 days and look like these guys haven't started, so they see this the same amount 50 days. So that gives you an estimate to complete 276 thousand. Step two, we're going to attempt sheets. We go into our contents, finance person, we check our invoices and we gather only $18 thousand. So we're estimating over cost. So we add this to this. What's left to be done and what we spend, and that gives us this amount here, 294 thousand. So initially we told a steering committee it will cost friend, advisor and to complete the project would cost us 300 thousand and now it's only 294 thousand. So we are the moment $6 thousand head. If we were taking only this value, it'll be, it'll be very difficult for us to assess. If we're going to be meeting this $400 thousand or not that we need both. Ok. Let's move forward to February. Sam. We just ask the guys how long, how long. But oops, this guy realize is something more to do. And the, the estimate such depth. So the overall estimate to complete these 276, it's the same, it's just a coincidence. The actual is 35 thousand. The estimated completion is now friend and unheard of and fairs and so this causes problems. And now we are overspent. But it looks like in March we had appeared around there's us turning 60 days, 60 days, and 60 days. So that gives us 192 thousand. So the actuals 78 thousand, estimated completion 270 thousand. So the variation from the budget is 35 and two-way back on track. So it's a bit of a roller coaster where it was more to show you that, you know, if, if you track without these two components, then it's, it's, it's, it's meaningless in a way. So it's good to have both of those factors for you to take into account. So this is it, this is how we track budget. It's important to do it in a structure way on a monthly basis. Sometimes we are being asked to wait on weekly basis, but as oppose your best judgment to start with. And then depending on the standards that are where you work. So this is it for tracking budget. 82. Earned Value simple example: Welcome back. Project execution, budget tracking. Now I have an advanced categories. So as mentioned, if you're a bit overwhelmed at this stage, feel free to skip this. We will be discussing and value. So in value is part of all the project management methodologies out there. It's a tool that you can use to track how is your project going. It's often explained in a very convoluted way. And this is what I really wanted to bring it down to its simplest form with two examples. The first one extremely simple, the second one a little bit more realistic. So let's do this. So n value, it's the value of what you have already done. It's a value of the work that the project is already produced. So when we had a look at the GA tracking previously, what we did was we calculated the estimate to complete and we added actuals and our gave us the estimated completion. So that's, that was in a way looking forward. What is left to be done and value it's more looking back. How have we been doing. But at the end of the data should give you the same result. Example. We have five houses to paint. This is our project. We have a contractor. We pay him $10 thousand per week. Any oh, she tells us this one week to paint one house. So you have five hours to paint. Your tutorial estimate is 50 thousand. So what's important here? It sets an estimate when Week two, penthouse. So you see he or she tells you well, it takes me one week dependent house and as far as to pen so your estimate would be 50 thousand. It seems quite straightforward. You come back three weeks later. And you're actually was actually 30 thousand because you are paying this company 10 thousand per week. So after three weeks, you are spent 30 thousand. But when you check, you notice only two houses had been paint, and the third one has not even started. So the earned value, which is the value of what we have built so far, is 20 thousand. Because we were expecting 10 thousand expense per house that now we only have two houses painted. And we already paid 30 thousand tourists or looking good moving forward. So you go, so this is your first example. 83. Earned value formula and Example : Let's continue with earned value and value. Value of what we have built so far. If it's greater than the actual rules, then you're under budget. But as we seen an example just before, with the houses to be pent, when you're in value is smaller than your actual stand, your over-budget. You didn't get what you paid for in a way. So as mentioned, I wanted to give you another maybe more real life example. Let's say we have a project to build 75 units without going into more detail. It's a very simple project. You just need 75 units of something built. So it's time and material. You were told it cost you 100 thousand to build one unit. So building material, this is where you will be doing your your budget is a scheduled base budget. You know, orangey color. And you have planned to build 1010151515. And then the end, you should have your 75 units. So here we track the actuals, the money spent at the end of each month. So here we have end of January has spent 810 thousand weapons, 7 thousand. So at the end of March, we spent 25 thousand. So here what we do is we calculate our earned value. We go and take a mini units have actually been built. At the end of January. We see that eight units have been built already. Alarm bells because we're supposed to have ten and February and other ten and of March, only five. Okay. So let's have a look. So end of March situation. We plan to have build 30. We have only build 23. And the end of the jet figure that we have now gives a project team a false sense of security. So you'd be taking a budget, you would say, we cool, after free mumps have only spent $25 thousand and that's ahead of my schedule budget. I'm doing very well. But you have only spent 24 units. So I think the end value is, is a good tool so you don't get too comfortable. So obviously this is simple example, PR in a way that, you know, it's very easy to, to check the end value because you just referring to units. So it's very easy to count how many units have been down there, I suppose. And this is where the theory sometimes doesn't work in practice, it's not always as easy to check the value of something. When you work with several teams and they all have their own products to create an array axis, it's not always easy to check how much they have produced. So let's have a closer look on nice what that would look like on a child. So this is how you could represent it. Bearing in mind, you're still in the advents section here. So we are in March here. Some example that we have spent only 25 thousand when we should have. The planned value was 30 thousand. But we've only created this. So if you do that, put that on a chart with this being the planned value, the actual costs being there and being there. So the value in green. So this is what you have done at the end of March. In blue, actual cost and the plan value it's there. So that's really good visual way. If this, if this goes high and this doesn't go as high, and means that you are spending more than, than what you have produced. Quickly. Final example on earned value. This time is just to show you that the actual cost could be above the planned value. So it's more or less the same project. But they actual change. So plan you need to be build 30. We have only build 23. But this time you are curious even above the planned value. So you even worse situation than before. So that's just to show you the actual cost here is above the planned value. So right from the start, you know, there's something wrong. So that's it for and value on budget. So it's a very good tool if you can do it. I think it's a very good way to look back and check how, how efficient the Timaeus. 84. Earned value for Scheduling: We have finished with budget and we also have finished with scheduling birth before we finished execution. And I wanted to show you that the end value can also be used to assess the schedule performance. I don't know if you've noticed that on the previous slide. So when we review the budget, we compared earned value with actuals to see if we are doing well with our budget. So if the earned value is less than what we have spent, we know we are behind budget, that we'll be having an overspend. And we can do the same with scheduling, but this time, instead of comparing the earned value, is actually, we compare the value with the planned value. So if the value is greater than the planned value, we have built more than we what was planned to build by this point in time, we are ahead of schedule and the other way around. So let's have a look at the example. I think it will make it clearer. So for budget, we calculate, we compare the actuals and the end value. So here the accuracy was bigger, the end value. So when you were doing well with budget. And if we want to use this tool for schedule tracking, we compare this time the n value is a Planned value. So the n value here a smaller than the planned value. So we are behind schedule. So it's quite an intuitive tool, maybe a fancy terminology to do something that we could do otherwise quite intuitively. But it's always a good tool, as I was mentioning earlier, to know. 85. Phase 3: Execution - wrap up: Welcome to project execution wrap-up. So we've completed our execution. As part of the execution, we still have the implementation. So t