The Practical Project Management and Agile Crash Course | Hani Badr | Skillshare
Search

Playback Speed


1.0x


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

The Practical Project Management and Agile Crash Course

teacher avatar Hani Badr, Management consultant and mentor

Watch this class and thousands more

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

Watch this class and thousands more

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

Lessons in This Class

    • 1.

      Section 01: Introduction

      3:42

    • 2.

      Section 01: The Story Behnid This Course

      1:50

    • 3.

      Section 02: introduction, what are projects?

      1:38

    • 4.

      Section 02: projects are unique and temporary

      1:40

    • 5.

      Section 02: projects produce products, services or results

      0:37

    • 6.

      Section 02: projects create value

      1:34

    • 7.

      Section 02: projects are subsets of programs and portfolios

      2:53

    • 8.

      Section 02: vision mission, and strategy

      2:49

    • 9.

      Section 02: wrap up

      3:50

    • 10.

      Section 02: mentoring moments Part I

      4:00

    • 11.

      Section 02: mentoring moments Part II

      3:36

    • 12.

      Section 03: introduction, project manager's role

      2:37

    • 13.

      Section 03: stakeholders

      1:19

    • 14.

      Section 03: resources

      1:00

    • 15.

      Section 03: manager role process

      1:38

    • 16.

      Section 03: wrap up

      3:21

    • 17.

      Section 03: mentoring moments

      3:04

    • 18.

      Section04: introduction, project management processes

      1:26

    • 19.

      Section 04: project management processes

      2:26

    • 20.

      Section 04: initiating

      5:32

    • 21.

      Section 04: planning Part I

      5:41

    • 22.

      Section 04: planning Part II

      7:01

    • 23.

      Section 04: executing Part I

      4:45

    • 24.

      Section 04: executing Part II

      5:17

    • 25.

      Section 04: monitoring and controlling

      3:35

    • 26.

      Section 04: closing

      5:12

    • 27.

      Section 04: wrap up

      7:16

    • 28.

      Section 04: mentoring moments

      8:00

    • 29.

      Section 05: introduction, agile vs waterfall

      4:49

    • 30.

      Section 05: Check-in

      0:18

    • 31.

      Section 05: waterfall and incremental lifecycles

      5:53

    • 32.

      Section 05: agile manifesto and principles

      3:56

    • 33.

      Section 05: Scrum

      6:47

    • 34.

      Section 05: wrap up and mentoring moments

      4:08

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

Community Generated

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

124

Students

--

Projects

About This Class

A practical learning experience designed to help you build essential Project Management and Agile skills while having fun!

This learning experience offers ~2 hours of highly interactive animated video designed to keep you engaged and deliver messages straight to you with no time wasted.

Content delivery is supported by practical examples based on real-life projects from different industries to simplify the concepts and give you a practical sense of how it's currently applied in industry.

Written by a seasoned Program Manager and Management Consultant who has been in the business for more than 20 years. He has worked for top Technology and Management Consulting firms including McKinsey & Company, HP, EDS and Valeo, in multiple locations globally.

The course focuses on essential project management skills and practices currently used in industry . And is tuned to the PMBOK Guide 7th Edition terminology and Agile Scrum practices.

Is best fit for learners who need to get  up-to-speed with project management in a short time including:

  1. Newly managing a project or about to manage a project

  2. Returning project managers who need to refresh core concepts or earn PDUs

  3. Technical professionals who plan, or want to decide whether, to shit career to project management

  4. Management executives from different disciplines, who want to build or refresh foundation project management skills

  5. University students who want to get a practical view of how project management play in real world

  6. Professionals seeking a soft introduction before embarking on a in-depth study for PMI PMP or ACP (this course will be step one, you'll need to register for a more advanced course to prepare for these certificates as a next step)

Course Content

Animated video lectures covering 4 fundamental topics (02:15 hours):

1. What are projects?

2. The project manager's role.

3. The project management processes and areas.

4. What is waterfall vs. Agile lifecycles?

Mentoring moments :

A video series where the course instructor shares his technical and career advice based on more than 20 years of experience.

It focuses on how to make best use of project management and make your way towards becoming an amazing project manager.

Other design Aspects

The course uses many design approaches to ensure you're engaged and having fun while you learn:

  1. Animated content with visual aids

  2. Story-telling approach

  3. Knowledge supported by practical examples

  4. Suitable for any business domain

  5. Natural, and simple, communication style suitable for any age or seniority level

Meet Your Teacher

Teacher Profile Image

Hani Badr

Management consultant and mentor

Teacher
Level: Intermediate

Class Ratings

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

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

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

Transcripts

1. Section 01: Introduction: Hi, thanks for stopping by. Do you want to build essential project management and Agile skills in shortest time? And while having fun. I have designed this course for you. My name is, excuse me. Actually, I have designed this course. As a matter of fact, it's me who have designed it. It's actually me know, it's me. Guys, the camera is rolling. Come on. The practical project management and Agile crash course. My name is Hannah. I'm a management consultant, is more than 20 years of experience practicing the Project Management Professional. I have worked for top consulting and technology firms serving recognized client brands in four continents and across multiple. I have designed this learning experience from a very practical point of view to bring you the best practices currently used in the industry to help you add value to your current project and advance your career. Now, let me tell you the four main learning objectives for this course. Oh, hello there. I'm Heather. I will introduce you to the definition of projects through building my dream home. I'm also the visual designer for this course. I hope you will enjoy it. And I'm your instructor for this course, I would share with you my best practice framework for a project manager's role. It's very practical. And I'm Maggie, a seasoned project manager on an exciting project to build a skyscraper. I will explain to you what are the project management processes and what are the different areas which must be managed on a project to make success? I will be sharing lots of practical examples from my current project to make these concepts crystal clear. How does that sound? Hi, I'm Danny, and this is nanny were to project managers working with very different approaches. We will show you the differences between waterfall and agile and take you on a journey across the river and introduce you to the Scrum framework. Of course, we will be having mentoring moments. When I shared with you practical advice on how to apply this knowledge in real life and get the most out of. This course, brings you more than two hours of carefully designed videos which have been animated and sought through word by word, who engaged and to give you messages straight to the point. You might be a fresh project manager about to manage your projects or thinking to switch careers. And academic student or a returning project manager, even the senior leader who haven't managed projects and wants to build that knowledge. Whatever it is. This course will help you build Foundation, project management and Agile skills quickly and while having fun. So what are you waiting for? I hope we can have you with us. See you in there. 2. Section 01: The Story Behnid This Course: Hi there. I'm happy to have you here, and I want to share a bit of my story with you. After more than 20 years of working for some of the world's top consulting and industry firms, I decided to leave my full time position and dedicate six months of hard work to design this learning experience for you. My goal that was to share with you not just knowledge, but the practical insights I had gathered over the years. Things that you can apply directly at work starting tomorrow. This course is designed with one thing in mind, making learning as interactive and fun as possible. I've incorporated animations, data visualizations, and real world examples to make complex concepts easy to understand and put into practice. I also want to tell you that I am committed to improvement and that you can help a lot by leaving a rating for this class here on skill share. I'd love to hear how was this course helpful for you? What can I do to make it even better? Your thoughts will help a lot to shape the next learning experience that I will be creating for you. And finally, I believe learning is better when shared. If you know others who are on the same similar management learning path, please share this course with them. Together, we can spread the knowledge and help each other to grow. And lastly, if you ever have questions or just want to discuss anything, don't hesitate to reach out for me. I would be really happy to receive your message here on skill share. I really like to hear from you. Thank you very much. 3. Section 02: introduction, what are projects?: All right. It's likely that you have heard many definitions of what a project is in your professional life. Having a solid definition for projects is extremely important. It will help you to understand what your project is and what it is not, as well as your role as a project manager. It will also help you to draw boundaries around your project. Understand how does it fit within the bigger picture of your organization. Clients and other parties involved? In this session, we will explore the key definition of projects as stated in the PMBOK Guide. And according to current industry practices. Now, let's get started. In this session, you will learn the key elements of defining projects. Projects are unique and temporary in nature. They produce products, services, results, and enabled value creation. They're the building blocks of portfolio. Now considered a tool for executing the organization strategy. Let's get started with the first element. 4. Section 02: projects are unique and temporary : A project scope can be simply defined as the work required to produce project deliverables. The scope is unique, which means this work hasn't been done before. And the work must be completed by specific dates. And that's why the work is temporary. So projects are unique and temporary. Let me give you an example. Hipaa hired a company to build her new dream home and she needs it in 12 months because that's the date she plans to move in. The scope of this project would be to build the home for her with a unique design that she wished. And the timeline is 12 months. And that's simply what a project is. Let me give you another example. Tesla is designing the future version of their model X car. This needs a project because this design doesn't exist today. So the project's scope is unique. And there's a deadline for the designed to be completed for production to start on time. So the work is temporary. On the other hand, when the car design is approved and the manufacturing starts, the work is not unique and it's not temporary. The factory will produce thousands of the same car model. So the work is repetitive and the production operations will continue as long as Tesla need. So the work is ongoing. So projects are unique and temporary while operations are repetitive and ongoing. 5. Section 02: projects produce products, services or results: Projects produce deliverables, which can be many things. A project deliverable can be a product like building a residential tower or creating a new software. A project deliverable can be a service like training all staff on a new skill or installing a new equipment. It can also be a result like a market research or a strategy. So essentially projects can deliver products, services, results, or even a combination of those. 6. Section 02: projects create value: Day after day, we are shifting towards a value-driven economy. Organizations are striving to deliver value and customers are more and more asking for value. Remember, your client has certain value which they want to get delivered. And that's why they are making the investment in your project. It's as simple as that. Projects help organizations to create value and meet its stakeholders needs. Either it is external stakeholders such as clients and third parties, or internal stakeholders such as employees and shareholders. At the end of the day, it's all about value creation. Projects can deliver tangible value, like increasing sales or market share. And it can also deliver an intangible value, like creating brand recognition or improving an organization's reputation. This value can also be something which has a social or environmental impact, like promoting diversity or reducing environmental pollution. Or it could be introducing a change which helped the organization itself to move from the current state to future state. For example, if your organization is running a project to introduce a culture change, to shift from an old mindset to a new mindset. This would be a good example of how organizations use projects to create value. 7. Section 02: projects are subsets of programs and portfolios: Although each project has its own unique objectives, in some instances, there are dependencies between projects which makes it more effective to group these projects together. In other instances, the number of projects is so many that it becomes difficult to track each project individually. In these instances, projects are grouped and managed under larger elements, such as programs and portfolios, which are essentially containers for projects. They allow organizations to better manage and coordinate project work. Let's explore together a detailed definition for programs and portfolios, along with some industry examples. What is a program and what is a portfolio? A program is simply a group of related projects that are managed collectively. It's important to note that these projects are managed collectively for a purpose which is to get more value. That wouldn't be possible if we manage each of these projects individually. Let me give you a quick example. You're building a business park and there are three projects which needs to be completed for the business park to be built and launched. One project is for the construction work. The second project is to install the IT infrastructure. And the third is to sign agreements with the business owners who will operate out of this business park. If you look at these three projects, there are dependencies between them. For example, if the construction work gets delayed, it doesn't make sense to buy the IT equipment at this point in time, it might be a waste of resources if you do that also gives some business owners have aggressive targets and they need to launch within three months. You might need to speed up work on construction and IT projects to meet that target. Maybe you decide to complete one zone of the business park, which you can launch in three months so that the business owners can get started with their businesses. So managing these three projects collectively allows you to take decisions to better manage dependencies, properly allocate resources and deliver more value. And that's simply what a program is. Now, what is a portfolio? A portfolio is a group of projects and programs managed collectively to meet a strategic objective. Let's say a grocery retail company is running a portfolio to attract 100 thousand new customers. And one of the things they need to do is to build a big grocery shop in a new area. In the middle of the work, they realize there's an opportunity to achieve the same target by building an online shop. The decision then can be taken to stop the work on the physical grocery shop and use the same budget to build the online shop. It doesn't really matter which projects and programs you run if you meet the strategic objective of the portfolio. And that's what a portfolio is. 8. Section 02: vision mission, and strategy: Maybe the most important aspect of projects is that they help delivering an organization vision and strategy. Whether it's opening a new business or transforming the way we currently run business. Projects helped to make it a reality. Now, if we look at the way organizations work, an organization typically creates a mission which describes its purpose and the distinctive value it wants to bring for its clients. Then it comes up with a vision which describes the future state for this organization. Then a strategy which says, how are we going to get to this future state? And finally, the organization defines the work and breaks it down into chunks of work, which are delivered through projects, programs, and portfolios. And hence, they are essential for delivering an organization's vision and strategy. Now, let's take an example of an organization's mission, vision and strategy and see how projects help to deliver them. In telephone has a mission which is to connect for a better future and drive positive change in society. Their vision is to become a new generation connectivity provider and the preferred operator for businesses and individuals in Europe. They've designed a three-year strategy which has many strategic objectives. Increase operational efficiency, upgrade network to latest available technologies. Become a digital first organization and provides seamless customer experience. Many portfolios, programs, and projects will be required to achieve these strategic objectives. For example, an important portfolio is to increase online sales by 300%, which serves the organization strategic objective to become a digital first organization. There's a key program under this portfolio. Redesign the current online shop. This program has many projects under it. Upgrade the IT servers, replace current e-commerce software and redesign e-shop interface. So these three projects are under a program which is under a portfolio that is linked to one of the organizations strategic objectives. And that's an example for how project helped to deliver an organization strategy. 9. Section 02: wrap up: I hope you have enjoyed navigating the knowledge in this section. Practice and fun are about to start. But before we go there, let me tell you what I would love that you walk away with from this section. First, projects have a defined scope, which is all the work we've committed to do as a part of this project. The word is temporary in the sense that it has a defined start date and end date. Projects produce unique deliverables which haven't been created before. Remember, your favorite car is the result of a repetitive and ongoing operations. While is it designed for the same chord is a result of a project. Projects are unique and temporary. Second, project deliverable is the outcome of its word. It can be a product which is a tangible outcome, such as a piece of software. Can also be a service, which is an effort we do to serve clients, such as installing an equipment to a client side. Project deliverable can also be a result, such as a market research or a cultural change. Third, project helps an organization to deliver value either internally for itself or externally for its clients. This value can be tangible or intangible. Most importantly, projects create value. Next, programs and portfolios, they both contain projects and aim to better organize work and maximize the value delivered. A program is simply a set of projects that are related or dependent on each other. Managing these projects collectively allows for better managing dependencies and in turn, maximize the value delivered by these projects. On the other hand, a portfolio is comprised of a set of strategic objectives. A portfolio has the authority to decide which projects to create to meet its strategic objectives. It also has the authority to stop projects. If it turns out that they are not helping to deliver the thing. The key thing is meeting the strategic objectives of the portfolio. And that's it. No way. The final and maybe the most important point is that project helped delivering an organization's mission. Projects come at the end of the funnel, which stopped by a mission, vision and strategy, which are eventually delivered through projects, programs, and portfolios. So projects are very practical tools which organizations use to fulfill its mission. All the previous elements of defining a project. Having a solid understanding of them makes you a more amazing project manager and makes your organization more success. Congratulations, you've completed the first step towards becoming an amazing project manager. In this section, we have learned the key elements of defining projects. Projects are unique and temporary. They can deliver products, services, outcomes, or a combination of these projects create value and are the building components of programs and portfolios. And they are considered a tool which helps the organization deliver its strategic objectives. 10. Section 02: mentoring moments Part I: Welcome to with these mentoring moments. In this series, I will share with you some practical advice on how to apply the knowledge you have acquired in this section in professional life. Let's get started right away. A, understand well the driver for your project, what value it delivers, and for whom. Typically there is one or more individuals who have raised the need for your project because it adds value to their business. I suggest that you speak to these people, introduce yourself as a project manager to build your own view of the value they want, even if your scope has been already written and is very clear. Try to confirm your understanding by talking to them and learning expectations and priorities from their point of view. This will help you to understand what makes success on this project. And it will help you to build good relationships which will be helpful afterwards. Also speak to people on your organization who have the background on this project so that you are on top of old information which has been already gathered. Understanding the driver and value of your project is the first step towards success. B, make your scope tight and understand it well. You might be joining the project after the scope has been defined or while it's being written. In all cases, you must make sure your scope is. Scope is one of the areas where every word matters because it has an implication on the work you're responsible for. I want you to think about scope as the fence that you built around your commitment. If the fence has holds, you never know what can walk in through it. And it will be an open question whether this is in or out of your scope, which can be very distracting for your project and can cause failure. What if I tell you is that the G God project's scope is to stop the theft incidents. While it's true that this is one of the main results of the project. However, it doesn't accurately describe what your scope is. Now, if I tell you that your scope is to design and produce a battery that is GPS enabled, and that helps to collect data in case the battery gets misplaced. Now your scope becomes more specific and the work you will be responsible for becomes so forth. Writing, project scope and requirements. As a professional, there are business experts specialize only in this area. However, it's a skill which project managers need to master as well. Because in some instances they are the ones who would write the scope and requirements. In other instances, they are the ones who review with hand, identify gaps. So they must know how good looks like when it comes to defining scope and required. If this is your first project, I suggest that you refer to examples of well-written scope from your organization or on the web. Also speak to business analysts to get help or training on how a good scopes looks like. Finally, as a project manager, you should be the one who is most knowledgeable about the scope. This helps you to play a primary role on the project. Delivered what it's supposed to deliver, and guarded against items that are not in its scope. Understanding the scope well should be one of the first priorities once you have joined the project. So make sure you understand the 12th and makes sure the school. 11. Section 02: mentoring moments Part II: Seed, bead, precise, defining your project deliverables and test it with client. Whether your project will be delivering products, services, or results. You need to accurately describe what you're going to be delivering. Clear definition of deliverables also help you to define accurately what work needs to be done. So it becomes clear what worked and deliverables, or in your school. To define deliverables, goes through your project objectives and think what the outputs are going to be and who is going to need these out? Refer to previous projects in your organization and see how did they define deliveries. Speak to your client to understand their expectations as well. If you're going to build a house, the outputs can lead the house design, construction licenses, the completed building, and the site investigation reports. You should then take each of these and break it down so it becomes clear what exactly are you going to deliver? For example, the house design can include an interior design and exterior design, a software copy, and a printout of the design. The more you're able to describe deliverables in detail, the easier it becomes to set clients expectations and eventually have approval when the project output is delivered. Remember, your client is the one who is going to eventually approve these deliverables. So identify who will be the approver for each deliverable. The approval for the design will probably be the design department, while the approval for the finished building will be the construction department. So each deliverable will have a different approval. Additionally, test your understanding with the approvers by showing them that definition of the deliverables early in the project. Have them sign it off. So there is a solid agreement which will enable success late. So define your deliverables accurately and test your understanding with clients. De, think beyond your own project and understand the strategic objective itself. Because projects have a start date, end date, and a defined scope, sometimes we tend to think only within the boundaries of the project. While success is to look beyond your own projects. This is simply because your project is a piece of puzzle. You must understand the remaining of the puzzle so that you can fit your piece in. Projects ultimately serve strategic objectives. Understanding the strategic objectives help you to define your project objectives and deliverables at the store. It helps you to think of alternatives and prioritize work effectively as you execute on your project as well. Additionally, understanding the bigger picture helps you to build relations beyond your own project and think what additional projects are needed in future. You will help growing the business for your organization and help yourself to grow. So always think beyond your own project and understand the strategic objective it serves. 12. Section 03: introduction, project manager's role: The role of the project manager is a very exciting role. If you enjoy taking responsibilities and being a key driver for success. This role is for you. It's a very central role as well. The first name that comes to mind whenever the question is asked, who's responsible for that? And probably is the one who keeps me awake at night thinking, how are we going to deliver what we promised our client? Maybe the easiest way to describe that role is that the project manager is the one who pulls all pieces of the puzzle together so that we have a full picture. So it's like you're responsible for everything. However, this doesn't necessarily mean that you do the work yourself or even have the authority for every decision on the project. But rather, you are the orchestra leader who doesn't play any instruments, however, leads all musicians so that they play a beautiful concert. Also, your likes the coach for a football team. Don't really play. However, you plan and guide the team so that they play. And when the match. As a project manager, you are primarily an integrator who pulls everyone and everything required to meet the objectives of that project. Whether it's a resource agreement or someone who needs to act, it's the project manager who must make sure it happens. Let's explore together the different areas a project manager is responsible for, so that we have a clear understanding of that role. In this session, we will learn the key responsibilities of a project manager. Integrating all elements of the project to ensure success, engaging stakeholders to ensure positive contribution to the project. Securing resources required to carry out the project work, managing the project process to make sure our work is orchestrated. The project manager is the leader responsible for the project. His role involves doing many things, including managing the project stakeholders, resources and the process to deliver the project objectives. 13. Section 03: stakeholders: The project manager is the one who engages project stakeholders. In other words, all individuals and organizations who influenced the project and who are also affected by the project. He engages them to make sure they are actively contributing to the project and are satisfied with its outcomes. For example, he engages clients to agree scope, highlight risks, get support from the client organization, and clarify the project status. He also engages the organization leadership to get their sponsorship for the project, obtain necessary approvals, communicates status, and formalized decisions. And he engages suppliers to negotiate best price for the products and services they provide and follow up with them to make sure they deliver what they promised. As for the team, he is the one who puts the team together, creates an environment where they can perform, clarifies the work that needs to be done, facilitates required training, and motivates the team to do their best. All this is a part of managing projects, stakeholders. 14. Section 03: resources: Project resources include all physical resources and skilled individuals required to get the work done. For example, a construction project will require physical resources like building materials and construction equipment. It will also require skilled individuals like design engineers and construction labor. The project manager's role is to determine how much resources does the project needs and to secure budget and approvals for it. Also, to make sure that the resources are secured on time for the work to be done. Another example is if you're developing a mobile app, you will need physical resources like laptops and software. You will need office space where the team will sit. You will also need skilled individuals like software developers and testers. It's the project manager who must make sure these are available. And it is a part of managing project resources. 15. Section 03: manager role process: One of the main responsibilities of a project manager is managing the project process to make sure all work is organized. This involves many things including always having a plan which guides the project work and shows the dependencies between activities. This could be a plan for current week or the overall project. Even planning agendas for important meetings and what the team will do today. The idea is to plan ahead for all project work. Managing the process also involves leading the execution of project work. For example, assigning work to the team, mobilizing suppliers, engaging leadership on important decisions and reviewing deliverables with clients. The idea is to make sure we're always doing the work we're supposed to. Additionally, managing the process involves assessing project progress and determining whether the project is on track and taking necessary actions. Like getting support from project leadership or helping the team to speed up the development so that we hit our target. The idea is to always take corrective action to keep the project on track. So managing the project process essentially means looking into the future and determining what needs to happen and in what sequence. Then making sure all the work is done in that sequence and on time. And that project stakeholders are engaged. And all that is a part of the project manager's role. 16. Section 03: wrap up: Congrats for completing the lectures about the project manager's role. How did that sound? Well, if it sounds like, wow, the project manager seems to be responsible for many things and it's not clear what he or she does exactly. That's kind of normal. Also, if it feels like some concepts such as managing the process are not fully clear, it's okay as well. These concepts will become clear as you navigate the remaining of the knowledge and will become clearer with practice. So don't worry. Let's recap what we have learned. The primary role of the project manager is to hand in high quality deliverables. Whatever it takes to make that happen is your responsibility. In fact, all what we've mentioned, including managing stakeholders, resources and project process, or only enablers for you to deliver in high-quality and are not ultimate objectives. Let's go quickly through these three elements against a managing stakeholder. Stakeholders are people and organizations that are concerned with your project. It's your role to engage them, make best out of their contribution to the project. This includes anyone who has the authority or capability to help your project to deliver. Whether in client organization or in your own organization, whether senior or junior. You must pull them in and make sure they contribute to your project as need. Be. Managing the resources. A project uses physical resources, such as construction equipment or laptops. It uses human resources as well, such as design engineers or software developers. Your own is to determine how much resources are required and make them available in time so that work can progress. See managing project process. A process is the order by which activities are carried out. As a project manager, you must ensure work is organized and done according to a defined process. To do that, you start by creating a project plan which specifies which work activities needs to be done, in what order and at which point in time. After planning, execute work activities. Then continuously measure progress and determine whether these activities are producing high quality deliverables as planned. We take an action to bring things back on track. Managing the process also applies to short-term targets, such as planning the current week or the upcoming. You always have to look ahead and determine what needs to be done. And that's what managing the process mean. So to conclude, you managed to take hold these resources, ends up process is the ultimate objective of producing high-quality deliberative, which would make your clients happy, as well as authentic. 17. Section 03: mentoring moments : Who would be the best project manager? What do you think? Well, this depends on many things, including the situation, the organization, the culture, and other things. However, let me share with you a few common things I have noticed which make best project managers. When it comes to stake holders management, the best project managers are the ones who in first place have great relationships with all stakeholders involved in the plot. They have an excellent network and they do effort to maintain their relations within that Netflix. They understand the needs and agendas of all stakeholders and try to create interest and influence them to act in the benefit of the process. They are also excellent at managing expectations and communicating important information precisely to leadership, clients and other stakeholders. They know when to raise a red flag, went to celebrate, achieve. They are always at the center, the action and all the go-to person for everything important. When it comes to team management. They are great leaders for their teams. They guide and coach the team so that everyone makes their best. They build trust and create a safe environment where issues are openly discussed and resolved. They are very short when it comes to problem-solve. Help the team to come up with alternatives and help removing roadblocks. When it comes to physical resources, they carefully planned for resources required for the project so it doesn't become an obstacle at a point in time. They protect resources and make best use out of. Moreover, they understand which resources are essential and which resources are it's just nice to have. And they fight to make the essential resources available for the success of the project. And finally, when it comes to process management, they are the ones who understand the real priorities of the project and they get ultimate focus for it. On the other hand, they do effort to get rid of unnecessary work so that the team is productive. They keep everyone informed about the project and they make sure there are no surprises by clearly communicating is everyone. Additionally, they get feedback and input from all parties. Was that the plan is realistic and they are very organized and disciplined and at the same time, they understand the value of this project is supposed to deliver. And they use the process as a tool to deliver this value rather than making the process and objective in it. These are just a few things of many things great managers, I'd say, above all, it's the ownership, passion and high ambition, which makes the best project managers, such as yourself. 18. Section04: introduction, project management processes: A process. What does this word mean? Some refers to it as overhead work which wastes time, and others treated as the ultimate objective. Which of these is correct? Also, what the scope mean? What does the risks mean? How about other areas like cost and schedule? What should I do about it as a project manager? In this session, we will learn what a process is and what are the five project management processes. Additionally, we will learn what are the different product areas and manager is responsible for and how do they work together with processes? Let's get started right away. In this session, you will understand what a process is. What are the five project management processes and what are the project initiation processes? Understand the different project areas and learn what is planning, execution, monitoring and controlling and closing processes. 19. Section 04: project management processes : What is a process and what are the project management processes? A process is simply a sequence of steps that you follow to achieve something. Let's say you want to go for an amazing vacation. You will do many steps. First, you will start by selecting a nice destination for vacation. Then you determine how much money you're willing to spend on that vacation. Following two, that, you list the sites you want a visit and the activities you like to do. At the same time, you may want to check whether there are family or friends who may like to join you. Then you bought the tickets and hotel, you head to airport and start your vacation, visit the site and do the activities. And finally, you head back home after having enjoyed your vacation. Imagine if you didn't do any of that and just get out of bed on the vacation day trying to get your trip started, there would probably be much less chances that you would be able to go to the place you want with the budget you have and the people that you like. So the whole idea of having a process is to increase the chances of achieving what you want with the available resources. Now, if we apply the same concept of project management, any project needs a group of processes to be able to achieve its objectives. A process should be simple or complex depending on the project. The idea is that having a process increase the chances of success because it helps you to have a defined approach for delivering your project. In project management, there are five main process types that any project use. The pen book guide seventh edition in previous editions defines these as the five process groups. The first process group is for defining your project and getting authorization to get the work started. This is called initiation. The second process group is for planning the work which needs to be done to deliver your project objectives and is called planning. The third one is for executing the plan and is called execution. The fourth is for measuring how work is progressing and taking necessary action in case the progress is not as expected. And it's called monitoring and controlling. And the final one is for closing your project and getting sign-off and is called the closing process group. Let's explore next. What does each of these five process groups mean and why are they important for any project? 20. Section 04: initiating: Hi, how are you doing today? My name is Maggie. I've just been appointed to manage a project to build a skyscraper. I would love to show you how I use the initiating processes to define my project and get authorization to start. Let me introduce you to Tim. He is my manager and is the sponsor for this project. The sponsor is the person who initiates the request for the project and has the authority to assign resources to carry out project work. I'm going to work with him, my client, and other stakeholders to create a project charter, which is a document, we use it our organization to capture the project definition. I will then get Tim's approval on the charter so that I'm authorized to start the work and use resources on my project. And that's simply what happens during project initiation. Now, let me tell you how do I define my project? There are questions regarding different project areas which I get the answer for and write in my charter. First, I need to define clearly the project objectives. I spoke to Tim and my client, understood that the main project objective is to build a skyscraper. The client has an objective to make it an iconic building that will help to attract tourists. So it's not just to provide more real estate space in this area. The city government has an objective to reduce housing costs and avail more commercial office space in the city center. Clarifying project objectives is the first step towards defining the project. Another area would be client requirements. Is it a 50 stories or a 100 stories building? How much residential space versus commercial space is required? How about the building structure and frame? Is there a specific type which your client wants? I clarify these requirements with client to make the definition of my project clear and capture it on my charter. Next, what is the scope my organization will be responsible for? The scope should be clear. Are we going to supply building materials? Do the construction work, extends utilities and fully finished the building, or maybe only a part of this work. A clear scope definition helps the organization to decide whether they can take that project. How about the budget required for this project? This must be determined so that it's clear how much is this project going to cost? Likewise, what is the business value expected and does it justify this investment? Determining project budget and clarifying whether the project is financially feasible is also a part of the project definition. Another area would be risks, which are uncertain events which might happen in future and can negatively affect my project. I tried to determine the potential risks for my project. Maybe the soil type is not suitable for high-rise buildings. Or the price of building materials is expected to rise as it's a three-year project. Additionally, there are usually information that is not available at the time of project initiation and we must make assumptions for it. I don't know the exact area and shape of the land which the skyscraper is going to be built on. So I will make an assumption about it. Also. I'm not sure which neighborhood it will be in. So I will make best assumption about that at the time of initiation, there might be constraints as well. The materials required for the building structure might not exist in my country. Or the laws might not permit buildings higher than 20 stories. All these risks, assumptions, and constraints are a part of my project definition. And they helped my organization to understand whether it's a high-risk project. To take. Another question would be, who are the stakeholders involved? Like my client, my own organization, and third-party suppliers who will provide me with building materials and equipment or even participate on the construction work. How about the city government? They have regulations and plans for building skyscrapers in the city, and they must be involved in the project. Identifying stakeholders helps to define who should be involved in this project and who it serves. Another area would be resources. I check what team and skills are required for this project and determine whether they're available or can be made available. And I estimate what is the size of the team required, in that case. The same for physical resources. They are a part of the project definition. Having a clear answer to all these questions helps to create a clear definition for the project and helps leadership to make the decision whether this project should be started. Once the approval is obtained, the project is formally started and can start using resources to complete project work. So the initiating processes helps to create a definition of the project and get authorization to start. 21. Section 04: planning Part I: Hi again. Let me show you how I use the planning processes to plan my project. I do this by collecting inputs from different stakeholders on my project. Then I create different sections of my plan which covers different project areas. I reviewed the created plan with project stakeholders as needed. This is very important so that everyone agrees to the plan and I know whether it's doable. I then freeze my plan, get sign off for it from my organization, and start executing project work based on it. Proper planning allows for work to be done in an organized way and increases the chances of success for my project. A project plan is more than a time schedule, which shows the date for each activity on the project. It covers all project areas such as stakeholders, quality, and communication, and defines how each area is going to be managed. The pen box Sixth Edition defines these areas as the knowledge areas. The PMBOK seventh edition defines performance domains, which includes areas which has to be taken into consideration while planning as well. Let me tell you the most important project areas and how do I plan for each. The first area is scope. Scope planning. I detail of scope, determined detailed requirements and get them signed off. Let me introduce you to John. He's a business analyst in my organization and he has been assigned to my project to help me create the detailed scope and requirements. During initiation, scope had been defined only at the high level. So he will create a detailed scope statement which lists the work we're going to be responsible for and the deliverables we're going to produce. We will break down work to a detailed level. For example, a part of my scope is to build a skyscraper frame. To do this, I need to create a design, do land digging, layout, foundation, build the frame, and quality check it. Furthermore, to develop the design, we would research best designs available, developed design options for my client to choose from. Create the design, do quality check for it, and sign it off from client. So we keep breaking down work until we reach a level that is difficult to break down further. This makes the work we're going to do very clear. John will also create detailed requirements which describes how our deliverables will look like. This is usually an extensive exercise which involves running interviews or workshops with clients, stakeholders to collect their requirements and determine the main characteristics of our final deliverable. Like whether it's a 50 stories or 100 stories building and the type of building frame the client wants. Then I get sign off for scope and requirements so that there's a clear commitment between my organization and client. And that's what happens during scope planning. Another area is scheduled. I create a work schedule which has the work activities or tasks my team needs to do. I estimate the duration of each activity is going to take, determine the sequence by which work activities are going to be carried out and assign resources to it. For example, there is a test we have to do to determine whether the soil is suitable for building. I sit with my team and we create the task list required, which would be identified three land spots to take samples from. Digg eighth inch holes. Take the sample and seal it in a jar, send the soil to lab, do the lab testing, and create the lab report. Then we estimate the effort required for each task, and we sequenced the tasks on the project schedule. Then we assign resources to the tasks, either individuals or physical resources required to do the tasks. This tells us the total duration for these tasks and the number of resources required. I do that for all work activities on the project. Then I freeze the schedule. It's called a baseline schedule. And from this point on, the project is expected to execute the work as defined in it. And that's how I create my project schedule. Next area is cost. I need to estimate costs for my project. To do that, I use the work breakdown which I've developed while planning scope and estimate how much is each work element going to cost. For example, I've planned to do the design. In order to estimate the costs for that, I need to know all costs involved, like design engineer hours cost, and the cost of specific software required to create the design. So I estimate all costs associated with the design to understand its total cost. Similarly, I estimate costs for the remaining of the work, such as digging, construction, and testing until I determined the total cost for my project, which is the project budget. And that's what I do to plan my costs. 22. Section 04: planning Part II : Another area is risk. I will do further analysis for the risks I had identified during initiation and determine if there are additional risks. I will create a risk register which captures all risks on the project. In my organization, there is a risk practitioner who will help me during planning by sharing best practices and helped me identify potential risks based on his experience in this type of projects. We will then classify risks to understand the most significant ones, determine the potential impact of these risks on my project. And think of actions I will do to minimize their negative effect. One risk I had identified during initiation is that prices for building materials might increase, which would be an additional cost for my project. I just talked to one of the financial experts and understood that there's a high probability that this will happen. I will classify this as a high impact and high probability risks on my risk register. I will then calculate the potential impact on my project in case prices increase. This will be equal to the total amount of materials which are expected to increase in price, multiply it by the amount of increase. Usually, a project includes a budget for risk in its overall budget, which is called risk reserve and is used in case of risc occurs. Next, I will now plan actions to minimize the negative impact of this risk. I will plan to sign a contract with a supplier for supplying building materials over three years at a fixed price increase per year. This will ensure that I will not bear more costs in case the price is increased significantly in future. This way I will transfer the risk to the supplier so it doesn't impact my project. And that's what I do to plan for risks. Another project area is stakeholders. I will do further analysis to identify my key stakeholders, determine their needs and plan how I'm going to engage them. For example, I had identified during initiation that my client must approve the skyscraper design before construction can begin. During planning, I realized that the client has a full design function which mandates specific design standards and to design approval process which normally takes six weeks. This design function is clearly a very important stakeholder and they must be engaged early on the project to ensure the design will meet client standards and that it will eventually get approved. I will build relations and speak to them early on the project to understand their design requirements. I will have several reviews with them while we're developing the design to incorporate their feedback, then I will seek their approval for the design. Understanding the needs and interests of each stakeholder helps me to plan how and when I'm going to engage them. And that's what I do during planning. As for project resources, the initial team size and required skills had been defined during initiation. However, during planning and design detail up the work, it becomes clear how many people I need, what specific skills should they have, and at which point in time I will need them. Same thing for physical resources. I must determine exactly how much steel, concrete, or building equipment will the project need and at which point in time? So I do that during planning for resources. Next area is procurement. My project will need suppliers who will provide me with materials, services, or skilled individuals. I will determine which suppliers do I need and plan for making agreements with them. It starts by identifying the scope of the supplier, which is the product, services, or skilled individuals he will provide my project with. Then I will request suppliers to provide us with proposals which describes what they're going to provide, a price offer to indicate how much it's going to cost. Then comparing their offers and selecting a supplier, then signing contract with the selected supplier. My organization has a procurement function. They have specific guidelines and processes for procurement, which I must adhere to while doing procurement. So I do planning for procurement based on it. Next area is communication. I will plan what to communicate to stakeholders, when and how. To do that. I will define the specific meetings and communication methods. I will use. For example, a project kickoff meeting to announce the project start. Ensure clarity about the objectives and ensure that everyone is aware of what is expected from them. A weekly status report from suppliers to indicate progress of their work. Daily team meetings to communicate to them the activities they need to work on and understand whether they need support. All these are examples of the things I determined to plan for all communications. The final area is quality. I will include activities on my plan to check whether deliverables are meeting quality standards and client requirements. It's important to check for quality as early as possible in the project and not wait until the deliverable is complete. This helps to reduce rework and deliver on time. I usually include quality engineers on my team or hire a supplier to do these quality checks for me, it's important that the person or party checking quality is different than the one producing the deliverable so that they would have an independent view of the product. So during quality planning, I determined resources and activities required to ensure my deliverables are meeting quality standards. So planning cover many areas and aspects of the project, including scope, schedule, cost, risk, stakeholders, Resources, Procurement, communication, and quality. All these work together to make a good plan. The objective of planning is to proactively think what work and resources are needed in order to succeed and ensure that work will happen in an organized way so that we have clear basis for execution. Are you ready to get started? 23. Section 04: executing Part I: Hello, there. Are you ready for takeoff? I'm sure you are. Let's take our journey to execution now. Execution, in a sense, is the fun time. It's the time to do everything we've planned to, even the things we didn't plan for and just found out they're extremely important. You have to do them during execution. It's also time to see our work turned into actual products, services, or outcomes which we can sense and show the client. While initiating and planning involved lots of document work. Executing involves lots of real work and on-ground action. In fact, the whole idea of planning is to get the execution right. However, it's important to note that no matter how much effort you put in planning, execution will not go as planned. This is because the reality is always different than what you had imagined on paper. Even if you have talked to people who have done similar work before, or if you personally have done similar work before. There are things that will go slightly different than planned, and there are things that will require full re-planning. It's normal that this happens during execution. Execution is where you typically spend most of the time on a project. And it's critical that you get it right so that the project delivers real value. Like planning. Execution involves doing work in several areas to make sure your project is progressing and delivering what it's supposed to. These areas include securing budget and spending it on project resources and activities. Assigning work to your team, signing agreements with your suppliers and making sure they execute work on their side. Managing project risks, engaging stakeholders, and communicating important information, and checking quality of the deliverables. Let's see few examples of what happens during execution for my skyscraper project. First area would be cost. I had estimated a budget during initiation. Now I need to start spending this budget as planned in order to progress project work. I will seek approval to start spending that budget. This is required in my organization even though the initial budget was approved during initiation. It's a procedure they follow to be able to control spending across the whole organization. During execution, I will control my costs by frequently comparing the amounts my project is spending to the original estimated budget. This allows me to stay within budget and avoid cost overruns. Next area would be team. If we assume the first piece of work is to do the design for the skyscraper, I will work on assigning design engineers to my project. Sometimes the resources, such as the design engineers are already a part of the organization. And I need to work with their department managers to provide me with the resources. In other cases, I may need to hire new resources that will require working with HR, following certain recruitment processes, and getting approval for hiring within the organization. Once the team is onboard, my big mission would be to build a highly performing team. To do that, I will introduce them to the project, explain the objectives of the current phase, clarify their roles, get their confirmation that the plan is doable and then assigned to them the work activities which have been planned. It's also essential that the team is well formed and motivated. This is key for project success and does a typical challenge for our project, especially towards the beginning of execution. To do that, I will do many things, including running team-building activities, setting clear targets for them, understanding their development needs, and helping them to grow. Also helping them resolve conflicts, remove roadblocks. The idea is to make sure they're always happy to be on this team and are able to do their best. 24. Section 04: executing Part II: The other area is risk. I will check whether the risks I had identified are likely to happen and then do actions to minimize their negative impact. For example, I've interviewed experts and read market forecast reports and concluded that building material prices are very likely going to increase. It's now time to sign contract to supply materials over three years this planned so that I'm in control of the costs for the building materials. Similarly, I will keep checking whether other risks are likely to happen and do actions to minimize any negative impact. And also look for new risks, which I may not have been aware of during planning and manage them as well. Next area would be procurement. I had determined that I need suppliers to provide me with building materials and construction equipment. So I will obtain proposals from different suppliers, select the best supplier, and signed contracts with them. This involves following the procurement process of my organization and working with the procurement function and getting certain approvals. Once I have signed the contract with the supplier, I will ensure that they have a plan on their side to deliver me the building materials and construction equipment on time. And I will ensure that execution is progressing on their side throughout the project. Another very important area is stakeholders. This is where project managers should spend lots of time during execution. It's important that stakeholders are properly engaged throughout the project to ensure they're contributing to its success. I will seek to build good relationships, understand expectations, and engage with different stakeholders. For example, I will engage leadership to make them aware of what is working well on the project and what requires their support before it turns to an issue. And engage clients early to understand their view of how success looks like and try to meet their expectations. I will get their feedback on work products early in the execution to understand whether it's meeting their expectations. This will increase the chances that they will eventually approved my project deliverables. I will engage other functions within my organization which affect my project. Such as the resource department, which supplies made with project team. The project management office, which helps to trap all projects across the organization. Or the procurement function who administrates all contracts with suppliers. All these stakeholders affect my project and it's essential to engage them at the right point for the project to make success. The other area would be communication. While progressing work is important. It's equally important that all stakeholders are informed about the status of the project and that their input and feedback is collected throughout the project. I typically communicate with different stakeholders through different communication channels. It could be a daily meeting with your team to assign work and help removing roadblocks, or a weekly call with my client to communicate the status of the project. A monthly status review with my organization CEO to discuss progress and risks related to my project. It can also be status reports, emails, or even WhatsApp messages, which I share with different stakeholders. The idea is to ensure everyone has the same understanding of project status and that they understand what is required from them for the execution to be successful. The final area is quality. It's extremely important to ensure that the project output is of high-quality. This involves doing many activities right from the start of the project and until you've successfully delivered to client, it's now time to allocate a senior resource to review design so that I'm sure it's of high-quality. Also to send a preliminary version of the design to the clients designed function to do an initial review. It's also time to determine which labs can help you test the quality of the steel and concrete used on your construction site. Whatever you plan to ensure high-quality of work and deliverables, you need now to make it happen. So execution is nothing but taking your plan to the real-world and having it implemented. It's very exciting and challenging at same time because once the project is kicked off, it's like a moving train. You need to make sure the journey is smooth and that the train will finally reach its destination. As the rest of project processes, it involves doing work in many areas and engaging many stakeholders for the execution to be successful. 25. Section 04: monitoring and controlling: Now it's time to see what happens during monitoring and controlling. This is Dave. He's a project coordinator who helps us to collect data to determine status and report our progress. Depending on the status gathered, I normally create action plans to keep the project on track. Let's see how it works. The objective of monitoring and controlling is to answer the question whether your project is on track to deliver its objectives and take necessary actions. If not, let's say you're on a mining project. The key question is not whether you're doing the drilling. The key question is whether you have found the gold or that you're on track to find it. Else, what action can you take so as to find the gold? Let's see how can a project know whether it's on track to deliver its objectives? It's mainly through measurement. During monitoring and controlling, I collect data which indicates the project progress to date. And I compare it to our original plan to determine whether the project is on track. Let's go back to our skyscraper project and see how we can measure progress. I had originally planned to complete the digging within three months, and we're at the end of the first month and only 5% of the digging has been completed. This means that we won't be able to finish the remaining of the digging in two months if we continue at the same rate and that we must take an action to avoid delays. To understand where these delays come from. I've talked to the construction site manager and understood that she hadn't received all the digging equipment required. And in turn, the work hasn't progressed as planned. So I talked to my supplier and understood they have been facing delays clearing their equipment out of customs, which led to the delays. I then explained to them the consequences of this delay on the project and agree the solution for the building equipment to be onsite within one week so that the work can progress as planned. So the idea is to collect data which helps you to measure progress against plan, and take actions to keep the project on track. It's important to note that monitoring and controlling typically happens early in the project so that you tried to prevent the issues before they happen. Let's take another look at the previous example. Monitoring and controlling ideally should have started at an earlier stage. We should have checked whether all building equipment were expected to be on site before the digging starts. In many cases, it's possible to anticipate these issues early in the project by talking to your supplier or other experts in this area. Then you would be able to find a solution for it before it causes actual delays to your project. Being proactive makes your monitoring and controlling more effective and increases the chances for success. In the same way, you should measure progress and other project areas to understand whether your project is on track. Here are a few examples of the questions you should be asking. How much is my projects spending compared to the original budget? How many work activities have been completed compared to the plan ones? How many defects have been found on project deliverables? And how many deliverables have been approved by client. Answering these questions and taking necessary actions to keep the project on track is essentially what monitoring and controlling is. 26. Section 04: closing: Closing a project is the final step which marked success for all the hard work which had been done throughout the project. The closing process group is as important as the remaining of the process groups. In fact, your project will be successful only after you've closed it out properly. In many cases, there are loose ends towards the end of the project, which makes it difficult to successfully close it out. These loose ends could lead to additional work and costs which were not planned and can indeed affect the success of the project. What is closing a project mean? Closing a project means that you've completed all the work required, delivered everything you've committed to in your scope, and that your client approves all these deliverables and have made all payments. Also, it means that your organization is happy with the outcome of the project and that you've satisfied all the requirements for closing out the project. Such as formally releasing the project resources, documenting lessons learned, archiving project documents, and closing all contracts with suppliers. Let's explore in more details what typically happens during the closing process group. The main element of closing out your project is scope. For a project to be successfully closed, you need to make sure that all the work has been completed and that your client has reviewed and approved all project deliverables. In our skyscraper example, typically the client would need to sign off all deliverables such as the design, the frame, and the finished building for the project to be closed. Reviewing the deliverables and getting sign-off from clients should happen gradually throughout the project so that client feedback is accounted for and so that there are no surprises towards the end of the project. It's important as well to give client a proper handover for the project so that they're able to use your project deliverables and do future modifications for it. If required. You may need to deliver specific training to client team to make sure they're comfortable to own and operate the project product after your team has left. As for project financials, you need to collect all payments from client and pay any outstanding payments to suppliers. Then do a financial closure for the project so that no one will be able to charge costs to the project after it has been closed. This is normally done with the finance department of the organization. For a project team, I will ensure they get recognized for the work they've done on the project and that they're aware of their performance evaluation for this project, including their achievements, strengths, and development needs. It's important as well to understand how do they feel about their overall experience working on that project, including the things they've enjoyed and the things which could have made their experience better. They have to contribute to the lessons learned which will be collected for this project as well. I will inform them about their performance evaluation for this project so that there is clarity about their contribution to this project, and so that they're able to further develop their skills after the project, they should be aware of the next steps regarding their project assignment. And I will inform their resources department that they have been released from my project formally. As for physical resources, I will return any remaining physical resources back to my organization so that it would be used by other future projects. Next, project documentation. It's very important to collect lessons learned which captures what has gone well on this project and what could have been done in a better way so that future projects would benefit from it. It's important as well to do a final performance review for the project which compares all results of the project to the original plans. For example, what was the actual duration of the project compared to the original schedule? How much did the projects fan compared to the original estimated budget? What was the quality issues faced and how did they get resolved? This will help to create clarity about the achievements of this project and would be a good input for the lessons learned exercise as well. Also, I have to archive all my project documents so that it's accessible for other projects in my organization after project closure. Next, project communication. I have to make stakeholders aware of the key achievements of this project and the lessons learned out of it. Also to announce the formal closure of the project. It's good as well to highlight any upcoming projects which relates to this project so that there is clarity about next steps. So closing your project essentially means that you formerly delivered all your scope. You have Mill further financial commitments. Your project resources have been released. All stakeholders have been informed, lessons learned has been collected and project documents have been archived. And most importantly, your client and organization are satisfied. And that's simply what closing a project is. See you next project. 27. Section 04: wrap up: Alright, How does that sound? I hope you have found this section informative. This might have been a bit long, but the good news is that having reached so far, you have gained knowledge in the most critical project areas and understood the main types of processes. The initiating processes are used to define a project and get authorization to start. Planning processes defines work which must be done in future to deliver project objectives. Good project plan increases the chances of success because it guides execution and helps to anticipate issues before they happen. So we can avoid them. If we fail to plan. With planning to execution is simply taking your plan into action, which might involve doing work we haven't quite planned for. As reality is always different than the objective of monitoring and controlling is to check whether work is progressing as planned and understand whether the project is on its way to deliver successfully. Closing a project is defining and sometimes the trickiest time of the project. Successful when all deliverables have been signed off, an old project records have been closed. There are nine different areas which must be managed in the project. Let's recap each and see what happens in each area from initiation to closure. Scope represents the project commitments, including what word deliverable is the project responsible for? The first version of scope is the written during initiation, then it gets detailed up during planning. During execution, the scope guides the work with the project carried out while monitoring and controlling, validate whether scope is being delivered or on its way is to be delivered. Success. As deliverables get completed, we seek sign up for it until we sign off all project deliverables. At the end, project schedule shows start dates and dates and dependencies between work activities. A high level schedule is defined during initiation. Then it gets detailed up during planning to be used as basis to assign work to team during execution, during monitoring and controlling the originally planned work activities are compared against the completed activities to determine whether a word is being completed as planned. If not, a corrective action must be taken until all work has been completed during closing. The project budget is defined and approved during initiation. It gets detailed up during planning through a cost estimation at the side. During execution, the project consumes budget as planned and continually compared to actual spend amounts to original budget to ensure that the project stays within budget. By the end of the project, all payments must be collected from clients and all outstanding financial commitments of the project must be settled. Risks are uncertain, events which might occur in future and can negatively affect the project initiative. The risks are determined during initiation and they affect the organization's decision to take on the project. Risk plan includes actions to eliminate or minimize the negative impact of risks. During execution. The project keeps monitoring the status of risks and keeps carrying out actions as planned. During closure. The project documents the list of risks and submit it as a part of the lessons learned exercise. The lessons learned are then made available for the rest of the organization to be used by future projects. Stakeholders are all individuals and organizations concerned with the project. The project starts by identifying a list of key stakeholders and refines it during planning, as well as determine their specific needs and plan for how to engage the stakeholders should be constantly engaged during execution so that they contribute to the success of the project. We should also keep checking whether they are satisfied with the project outcomes during monitoring and controlling. And finally, they should be informed about the project achievements. Lessons learned, and next steps by the end of the project require the sources are determined during initiation. Then we determine specific resource requirements during planning. We then work on securing these resources during execution and track whether we are getting the output we planned for. Resources must be released by the end of the project and return to their home department of the organization. Procurement is the process of sorting goods and services required for the project from a third party supplier. During planning, we determine what types of suppliers are required and plan for signing contracts with them. We then signed contracts during execution, constantly monitored whether they are delivering what their support. Then we close contracts by the end of communication, planning is determining who to communicate to on which topics and at which point in time in the project. Then we communicate with stakeholders as planned, and check whether communication is happening effectively. The project closure involves a formal announcement and communication of project achievements and lessons learned. The role of quality is to ensure that we're building the right deliverables as clients specified. We first plan the quality activities we're going to carry out, such as testing, and then carry out these activities as planned. During monitoring and controlling, we look at quality data to determine whether the project is delivering the required quality. At closure, quality should have reached the agreed levels with client. That's it. I hope you have enjoyed that. Let's move on now. 28. Section 04: mentoring moments: Welcome to this mentoring moments. I would love to share with you a few tips on how to make the most out of the knowledge you have gained so far and use it to make success on your project. First, project initiation, it's usually a great opportunity to join a project right from the start. So make the best out of it by collecting as much background on the project as possible and master its content. It's also the time to show your creativity as the scope gets defined. Show that you are the person thinking ahead and trying to scope a solution which will deliver that value to clients. It's also time to build great relationships with key stakeholders and understand the expectations and agenda. For your team. Clarifies the roles early on the project and help them to work as a team. This is one of the key challenges towards the beginning of the project. As for risks, it's extremely important to understand the amount of risk and make decision makers aware of it during initiation. And finally, remember that when your organization is putting a manager on the project, they are primarily appointing a leader. So make a great first impression. Second, planning. Planning is a very important area of the project. However, it's important that you don't overdo it and allow execution to start as early as possible. Trying to make the plan perfect might get you into loops of planning, might delay or even lead to cancellation of the project has a guideline. You're planning should take around 10% of your overall project timeline. Another advice is that while you are planning, prepare for execution so that once your plan is approved, you are able to hit the ground running. A good plan is one that is created with input from the team and different stakeholders. And it's one which is committed to buy all these as well. So make sure you have their buy-in, especially your team, as they are the ones who will make it happen. If they don't believe it's doable, there is less chance that they will make it up. Quality is an integral part of your product. So make sure you have a high bar and plan quality activities in every day's work. A high-quality product is a result of continuous attention to quality and not a result of a single quality check, which happens after the deliverable is called planet like that. It's easy to overlook risks and have a biased during planning the thrust will not happen. Avoid that bias by carefully thinking what can go wrong and how to minimize its impact in case it happens. Studied history projects, and talk to experts on the door. If there's going to be bad news, it's best that we've prepared for it. Estimating costs during planning is tricky because the project budget had already been determined at this point. However, use the planning period to break down and carefully estimate costs. This will help you to make trade-offs, find alternatives. Keep cost estimation within the original body. In all cases, if there's going to be a deviation, it's best when you find about it early. So that you can involve decision-makers on finding a solution, rather than surprising them later on when it's late to take an action. The same applies for school. You should depend it up and determine whether it's in line with what you had imagined during initiation. And finally, realistic projects. Schedule is one which has contingent. So build your schedule with reasonable amount of contingency to have a chance to catch up with delays when it's all mature that no schedule will be executed exactly as planned. So make sure to create room to recover delays when they do happen. Execution and monitoring and control. They both happen at the same time. Once word gets started, there's a natural bias to focus on execution and firefighting. This can easily distract you from other things which are equally important for your project. So step back and think about these other things. Like where do you stand with unknown risks? And are there additional risks? Make sure you're not only building the product, but also checking the quality in parallel. Also that you are clearly communicating the status of your project and asking for feedback. Your team needs to know whether we are on schedule or behind schedule so that they can adjust their face to meet the deadlines. So ensure they have that view. It's important as well to ask yourself, how much is the remaining of the world going to take? The can indeed be the case that you are on schedule now. However, there are new information which makes the rest of your schedule not feasible when compared to the original plan timeline. So be proactive looking for these things and finding solutions. The same for costs. Always check your actual spend and compare it to the amount which you are expected to spend throughout the rest of the project so as to know whether you are still expected to remain within budget. So generally, avoid focusing only on task execution. And step back and think about the big picture. Next. Closing. While it's important to focus on deliverables, sign off during closure, it's equally important to properly close your project by doing many other things. Such as communicating closure to all stakeholders, releasing resources, closing the project, financial books, submitting lessons learned, archiving document, closing contracts with suppliers, and doing whatever the organization requires. To close. This is the only way to ensure that your project. Many projects get called on for open actions after they have been closed. So make sure you type all loose ends before you move on. And finally, bear in mind that every organization has its own processes and specifics. So do effort to learn these and seek advice of people who have applied it. The same for organization culture. Spend time to learn it so that you can operate within it. You will be surprised to which extent organizations vary in what they define as a good practice. So not only understand the rule, but understand how it applies these in your organization. I wish you all the best. 29. Section 05: introduction, agile vs waterfall : Hello. Are you curious to know the difference between waterfall and agile? Then let's dive right into it. As agile suggests. In this session, you will learn the difference between waterfall and enjoy life cycles. The waterfall and incremental life-cycles. The Agile Manifesto and practices be a giant implementation using Scrum framework. How to choose the best life cycle for your project. Let's get started now. Hello there. Let me introduce you to read. Read our lives near a beautiful river. And she would love to build a bridge so that she can reach to the other side of the river where she believes there are so many trees with beautiful fruits. Rita calls for Danny and nanny to help her build a bridge. Danny works with a waterfall approach. While nanny works with an agile approach. Danny will spend a period trying to understand what Rita wants, carefully document her requirements, and take her approval. He will then spend another period designing the bridge and then take her approval. In the same way, he will build the bridge and quality check it. While doing the work. Danny will keep telling Rita how work is progressing so that she's happy and confident. She's going to get her Bridge in time. By the end of the project, Danny will take Rita across the bridge to reach her dream area on the other side of the river. While Danny is very clear on what he's going to build and his approach is very structured. There are chances that reader will not like the bridge as she gets to use it for the first time only by the end of the project. Moreover, there are chances that the area which the bridge leads to is not exactly redoes dream area as she's never visited the other side of the river and not sure which area exactly what she finds most beautiful and full of fruits. Doing any changes at this time to the bridge will be at a great cost for the project because it has been already built. This can be frustrating for Rita as she's been waiting for too long to reach the other side of the river and get the fruits. On the other hand, nannies approach is different in agile. She's great with experimentation and she likes the challenge. She will start the project by roughly understanding the area Rita would love to visit. Then attempts to cross the river using a bamboo vote. Moreover, she will take Rita with her. While the solution will not be final. This first journey will help her to learn about the river and the area rita loves. On the other side. She will use what she learned to build a rope bridge. And again, take Rita across it to see whether she likes it and modify it if necessary. At this point in time, Rita will already have access to the fruits, so she's happy and sure she's making the right investments. Finally, she will build a wooden bridge. By this time, nanny is pretty sure that Rita will love the bridge because she uses it the earlier ones and already loves the area where it leads to nannies approach is very flexible and can adapt to what Rita needs even if she was not sure what is the end result she wants. Additionally, it allows rita to cross the river early in the project and already start getting the fruits. However, it might take more cost to build multiple bridges until she reaches the final solution in the same way she did. And she might not be able to deliver if Rita keeps changing her mind constantly. Each of Danny's and nannies approach can be suitable depending on the type of project. Danny's approach involves lots of planning upfront. It is suitable for projects where the outcome and client requirements are clear right from the beginning. Like building a highway or a warehouse. On the other hand, nannies approach is adaptive. It allows the project product to change throughout the project to meet the client requirements. It's very suitable for projects where the outcome is not clear and were lots of experimentation is required. Like developing a new piece of software or creating an innovative design for a future product. Which approach are you going to use for your project? 30. Section 05: Check-in: Hey, there, are you enjoying this course so far? I hope so. If yes, I would really appreciate if you could leave an honest review. Your feedback will help me a lot to improve not only this course, but also any future learning experiences I design for you. Thank you very much. 31. Section 05: waterfall and incremental lifecycles: Hi again. This is Danny. Let me tell you more about waterfall. Waterfall methodology is the traditional way of doing projects. It tries to get the project deliverable right from the first attempt by carefully planning upfront and tightly controlling project execution. A waterfall project follows a single development life cycle which has sequential phases. To build your dream home in waterfall, the project phases can be requirements definition, site selection, designed, land excavation, foundation building, gray structure building, and interior finishing. Now let me tell you how I'm going to use waterfall to manage my upcoming project. It will be to develop a grocery website. I will create a detailed plan early in the project to show what work is going to be done, how is it going to be done and by whom? The plan will cover all project areas, including scope, cost, schedule, risk, quality, resources, stakeholders, communication and procurement. I will then seek approval from my organization in client for my plan. Once I get the approval, the plan becomes a baseline plan that is not expected to change. I will save a copy of it so that I always remember the original plan we started off the project with. I will then start project execution according to the plan and try to avoid any deviations from it. I will determine detailed project requirements through workshops with my client and business experts. Then get the client sign-off on the requirements, which means that they agree to this set of requirements and that it's not expected to change. Then my team will do the design. As a part of the design, we will create a prototype for the website. The prototype helps to show my client how is the website going to look like at the delivery time. I will then take sign off for the design for my client. I will do the same for every phase, including development, testing, and deployment phases. During execution, I will use strong monitoring and controlling mechanisms to keep my schedule, cost, quality, and risks under control. I will create status reports which compares the actual project results to the original plan. And I will run regular meetings internally in my organization and externally with clients. During the meetings, I will share the project achievements and status, ask for support where needed, and seek decisions to help the project continue execution. If the client wants to change any of the project requirements. There's a formal process that I will follow. First, I will write the new requirement and a change request document. Then I will determine the implications of this change on my schedule, costs, quality, and risks. I will capture these implications on the change request document. Then I request my client to sign off the change request. Once it gets signed off, I will change the project baseline plan to reflect this change. This means that the schedule can get extended for the budget might increase. If the change involves significant additional work. I will continue executing the project in the same way until the final deliverable is produced towards the end of the project. After that, I will show the website to my client and allow them time to test it and seek their approval for it. Then I will close my project. And that's how I use waterfall to manage my projects. The waterfall approach is a well-defined and structured approach. It aims to minimize scheduled delays, cost overruns, and risks by following a defined process. It is suitable for projects in which the desired outcome is clear upfront. Using waterfall can be tricky though, in situations where the project final outcome is not clear or if changes come late in the project life cycle. Imagine trying to change the grocery website design after it has been built. It would be a very costly change. You would have to do the new design development and repeat the testing. So as any methodology, it has its pros and cons and specific types of projects that it's fit for. Now, let me tell you quickly what an incremental life cycle is and how is it different from waterfall? Waterfall approach has a single development cycle. An incremental approach breaks down the project into multiple development cycles. Each cycle produces a set of project deliverables. A good example would be building a travel website. On the first phase, you start by developing features which allow the customer to book a flight. On the second phase, you would features for hotel booking, then features for ground transportation booking on the third phase. Then if phase to add features which allow you to book your whole trip combined. So each phase adds features which build on one another until the final product is reached. This allows you and the client to learn from each phase than refine the requirements and development approach for next phase. Hence, it adapts to client requirements to an extent by breaking down the project into groups of deliverables which are developed incrementally. Each phase is like a small waterfall project. It goes through requirements definition, design, development, testing, and deployment. However, breaking down the project into multiple phases, avoid a Big Bang effect at the end of the project. It allows some flexibility for changing client requirements and refine the work approach between project phases. And that's what an incremental life cycle is. 32. Section 05: agile manifesto and principles: Hi, let me tell you how did the Agile approach emerge and what is the Agile Manifesto? Agile methodologies emerged to meet the need for a suitable approach to manage software projects were waterfall was failing to deliver in many instances. In 2001, a group of software industry leaders work together and created the Agile Manifesto, which was the basis for agile development. The manifesto had four main concepts. We value individuals and interactions over processes and tools. Working software over comprehensive documentation, customer collaboration, over contract negotiation, and responding to change over following a plan. This was not only changing the way projects are managed, it was changing the culture and mindset and creating a space where delivery team and client can collaborate to deliver value rather than sitting on two different sides and negotiating scope. The manifesto listed 12 principles as well. Satisfied customers through early and continuous delivery. Meaning that clients doesn't have to wait too long before they get the actual project product. Welcome changing requirements even late in the project. That's because changes helped to address client needs. Deliver value frequently. Because when the clients receive value, they become confident in the investment they're making in the project, and they can benefit from this value and their business early in the project. Break the silos of your project. In Agile, a single team has individuals of different skills, such as engineers, testers, business analysts, all working as one group. This improves productivity dramatically and great, a great sense of teamwork. Build the project around motivated individuals. As motivation and trust is the way to get the best of the team. The most effective way of communication as face-to-face, as written communication can create barriers in understanding and delay the progress. It can be much more easier to stand and talk to the person rather than spending 30 minutes composing an email. Working software is the primary measure of progress. This is because the client will only be happy with the project product, not the detailed plan or the status reports. Maintain a sustainable working pace. The amount of work should be reasonable so that the team can continue work and deliver with the same pace, rather overworking the team before deadlines. Continuous excellence enhances agility. This means that if the software is built with high-quality, it will be easy to modify. So it will enable you to respond quickly to changes. Simplicity is essential as it helps to come up with a smart solution while minimizing the unnecessary work. Self-organizing teams generate most value. This means that the team take a big part in organizing the work to deliver value, rather than relying on the manager alone to do that. Regularly reflect and adjust your way of work to boost effectiveness. This means that an Agile team continuously learn and look for ways to improve the way they work so that the team becomes more effective. These four values in 12 principles help to boost the team productivity and focus on delivering value early on the project. Agile was originally created for software projects. However, it became used for other types of projects where there is uncertainty about the outcome of a project and were lots of changes are expected throughout the project, such as product development, new designs, and business process improvement. Any project where the requirements are dynamic and evolving can benefit from the agile methodology. Do you want to go Agile? Let's go for it then. 33. Section 05: Scrum: Hi, my name is Charlie. I would love to show you how I use Agile to deliver value for my client on my software projects. There are many frameworks which you can use to apply Agile in your project. A very popular Agile framework is Scrum. Let me show you how it works. It defines specific roles, artifacts and ceremonies, which when played together, delivers value continuously to our client. Artifacts or work outputs, which could be a document or a product. While ceremonies are communication events, which we hold regularly to organize the work. As for the roles, let me introduce you to my team. Please meet Jack, the product owner on the project. He understands the client business very well and he helps us create a view of the product we're going to develop. He's very keen that this product comes to life and he helps us to prioritize the work according to client needs. We will start the project by creating a list of software features which are client expects. We call it a product backlog, and it is one of the scrum artifacts. We will then start short cycles of development. We call it sprints, on which we select features from the backlog. Develop it, show it to client and deploy it. Let me introduce you to my development team, also called the scrum team. The team include designers, developers, and testers who worked closely together and we usually sit in the same room. Our project objective is to build an online grocery website. It will take us several development cycles until we build the website. We call it sprints. And it's usually two to four weeks long. At the beginning of the sprint, we will hold the first ceremony, the sprint planning meeting, on which we discussed what works we're going to do and how we're going to do it. We will look at the product backlog and select the high priority work for this sprint with Jack's health. We call it the sprint backlog, which is another scrum artifact. This sprint we're going to focus on three features. User login, grocery search, and shopping cart. We will break down the work into user stories. A story describes a small piece of functionality from the user perspective, and it is a part of a feature. For example, as a shopper, I need to be able to enter my name and password to log onto the website. Another story can be, as an administrator, I need to be able to reset the password for a shopper to enable them to login. These two stories are a part of the login feature. Our sprints are going to be two weeks long. We will select the number of stories that we believe can be developed within the two weeks. Without overworking the team. We will use a big whiteboard and create a card for each story, which we will place on the white board. Every day. We will start by a short meeting. We call it a stand-up meeting. And it's another scrum ceremony where everyone in the team says what work they have completed yesterday, what work they're going to do today, and what obstacles are they facing? We will update the story cards on the whiteboard as we speak and move it from the planned column to in-progress column or complete columns. We will also create a list of impediments which are delaying the progress so that we can try to resolve them. This gives us a visual view of the work progress and the issues we need to overcome. It's called information radiation. It's very powerful and we use information radiators whenever there's an important concept or information which all the team needs to know. We simply draw a chart and hang it around the room. As a scrum master, I'm considered a servant leader for the team. I help them to overcome obstacles so that they can be productive. I also coach them on the scrum process so that they can organize the work among themselves and improve the way they work. I don't try to tell everyone exactly what to do. At the end of the day, success is the responsibility of the whole team and agile, we use a burndown chart, which is an important Scrum Artifacts, which shows us the number of stories completed from day to day. This is an easy and amazing way to give the whole team of view of the amount of progress to date. Usually, it's very difficult to make everyone aware of the status on daily basis in a waterfall projects. So it helps everyone to adjust their workplace and prioritize work in order to meet the Sprint objectives. By the end of the two weeks, we will do a sprint review meeting with our client. This is the third Scrum ceremonies where we will demo the functionalities we have developed and take clients feedback. We will use the feedback to update the backlog for next sprint. We will package the code we developed into an increment, which is another important artifact, and we will deploy it. The client can indeed change their mind. It's a main advantage of agile that they can. And the theory says that the client never knows what they really want before they see the actual product. So we tried to help them know what they want early in the project by showing them a working solution. And finally, we will do a sprint retrospective meeting, which is the last Scrum ceremonies, on which we will go around the room. Everyone will share what they believe have gone well in this sprint. What didn't go well, and what can be improved on next sprint. This helps us to improve the way we work every sprint and ensures that all teams feedback is incorporated. We also look at how many stories we've completed during the sprint so that we understand how many stories were able to complete per sprint. We call it the team velocity. On next sprint, we will select the amount of stories which we are able to complete according to our velocity. This helps to make the workload reasonable. We will run several sprints on which we will add features to the software until we complete the work and the client is happy. And this is simply what Scrum is. What do you think? See you on next sprint? 34. Section 05: wrap up and mentoring moments: I hope you have enjoyed that. Let's recap this quickly. Waterfall breaks down the project into discrete phases that are sequential in nature. It applies strong control and tends to discourage changes to deliver the original scope on time and within budget. An incremental life cycle breaks the project into phases. Each phase is like a waterfall project in itself. It tries to minimize a big bank effect at the end of the project by allowing a chance to learn from previous phases. Agile, on the other hand, encourages changes. In places, extreme focus on delivering working products early in the project. This allows deliverables to evolve with client feedback. It defines high-level features and then goes into rapid, short sprints, which produces parts of the project. This allows the team to continuously learn and focus on high-value features. That simply what waterfall, incremental and agile means. Welcome to this mentoring moments. Let me ask you, which life-cycle are you going to use for your upcoming projects? Choosing the right life cycle means higher chances of success for your project. So it's quite important to get it right. A waterfall lifecycle is a good choice when there is clarity about the project requirements upfront. When high certainty on delivery is required. It's also fit for projects where does the scope is relatively small. Possible to complete the whole project using one cycle of developed. An incremental life cycle is a good choice for more lengthy projects, which have a big number of requirements and where requirements are fairly clear upfront as well. An agile life cycle, on the other hand, is a good choice when requirements are not clear and are expected to change a lot throughout the course. It's also a good choice when the client is seeking immediate value delivery and wants a pragmatic solution. So selecting the right lifecycle totally depends on the nature of your project. Also, bear in mind that your project might use one of these life cycles and might use a combination of Z cycles as well. For example, if you are building an IT datacenter, you can use waterfall for constructing the building and use Agile for the computer hardware and configurations that will be used on the datacenter. Selecting the right methodology and adapting it to your project is called tailoring. And it's a very important skill for a project manager. Tailoring happens as a part of planning and it reflects on all aspects of the project. Finally, bear in mind that waterfall and agile mindset. After all. A waterfall mindset is conservative and aims to minimize risks in every possible way. And agile mindset is the learning and exploration mindset. It's also much more dynamic and adaptive. So make sure that you have the right mindset and that the organization you're operating within also have the mindset for the type of project you will be running. It's time to rock now. All best.