PMP Certification HARDCORE 10 Projects 35 PDU PMBOK+ 2 Exams

We will now start the next section of this course: The Fundamental Concepts, & Frameworks of Project Management. In this section, we will take a whirlwind tour of the very broad landscape of Project Management. This is going to be a BIG PICTURE view of the fundamental concepts, the ethos, and the history of this topic. Every lesson is going to be important and it will give you a solid foothold, for what we are going to cover over this entire course.

I have no doubt, you will already be very familiar with the concepts I am going to cover in this section. But, we will need a common ground, a common framework of terminology, and a common scaffolding for the Project Management Professional - and THAT is what will be covered in this course. So, without any further drama, here we go:

The Long Road: A Brief History of Project Management.

Project Management, though formalized only in the 20th century, has ancient roots. Thousands of years ago, magnificent structures like the Pyramids of Giza, the Great Wall of China, and Roman aqueducts were realized through early forms of project management. These ancient endeavors required detailed planning, coordinated labor, time estimation, resource management, and stakeholder control—though there were no Gantt charts or Agile sprints. Instead, they depended on well-organized command structures, practical knowledge passed through generations, and sheer human discipline.

The modern era of Project Management began to take shape in the mid-20th century, particularly with the rise of large-scale engineering, defense, and aerospace projects. The U.S. Department of Defense and NASA faced logistical and technical challenges that required new levels of coordination. Out of these needs came techniques like the Work Breakdown Structure (WBS) and Critical Path Method (CPM).

In 1969, the Project Management Institute (PMI) was founded. Its mission: to standardize project management practices and create a body of knowledge accessible to professionals across industries. By 1987, PMI published the first edition of the Project Management Body of Knowledge (PMBOK®), and the rest, as they say, is history.

Today, the PMP® (Project Management Professional) credential stands as the most respected certification in the field, validating one's ability to lead projects successfully using globally recognized standards.

Why Project Management Matters More Than Ever.

In a world driven by complexity, innovation, and rapid change, projects are how we get things done. Organizations use projects to launch new products, improve systems, expand infrastructure, deliver services, and solve unique problems. Project Management provides the structure, discipline, and flexibility to do this efficiently.

Without strong project management:

- Deadlines are missed.

- Budgets spiral out of control.

- Teams become disoriented.

- Stakeholders lose trust.

But with project management:

- We deliver value predictably.

- We navigate uncertainty with confidence.

- We lead teams toward shared goals.

From launching a mobile app to building a smart city, project managers are the orchestrators behind the scenes.

The PMP Course: What You Will Learn.

This course is built to help you understand the language, logic, and leadership of modern project management. We begin with foundational concepts: what a project is, how it differs from operations, and why project management has become such a critical discipline across industries.

You will explore:

- The life cycle of a project: from inception to closure.

- The development life cycle: from Waterfall, to Agile, to Hybrid.

- The structure of PMBOK: including its knowledge areas, process groups, and ITTOs (Inputs, Tools & Techniques, Outputs).

- PMBOK 6, 7, & 8: covering project principles and performance domains.

- Tailoring: how to adapt practices to your project’s size, scope, and environment.

- Artifacts and Documents: everything from the Project Charter to the Risk Register.

- Enterprise and Organizational Context: because no project ever exists in a vacuum.

In total, this course is designed not just to prepare you for the PMP exam, but to help you become a better thinker, communicator, leader, and problem solver.

What Makes Project Management Unique? Unlike routine operations (like processing invoices or manufacturing widgets), projects are:

- Temporary: with a start and finish.

- Unique: creating a distinct product, service, or result.

- Progressively Elaborated: meaning you discover and refine as you go.

To manage such initiatives, you need a diverse skill set:

- Technical knowledge of planning, budgeting, and scheduling.

- Leadership to guide teams.

- Business acumen to align project goals with strategic priorities.

- Agility to adapt when things change—and they always do.

PMBOK 6th, 7th, 8th, and the Future.

PMI continues to evolve its standards to keep up with global trends, which is always evolving.

PMBOK® 6th Edition focuses on processes organized by Knowledges and Process Groups. It includes detailed mappings of Inputs, Tools & Techniques, and Outputs.

PMBOK® 7th Edition introduces a principles-based approach. It moves away from prescriptive steps and instead focuses on performance domains, value delivery, and tailoring. PMBOK 8 is revert back to earlier knowledge base.

This course draws from all three editions (and where appropriate, the future editions) to give you a holistic understanding.

Course Structure: What to Expect.

Over the next several lessons, we will take a structured, well-paced journey through a foundational and advanced concepts of professional project management. We begin, naturally, with the basics: an exploration of what defines a project and how projects differ from routine operations. This helps you develop a sharp, functional lens through which to view all project-related discussions.

Next, we move into the reasons why project management is so important across industries, helping you appreciate the broader impact of structured project practices in today's business and innovation environments. Once this groundwork is laid, we broaden the scope to compare projects with related domains such as programs, portfolios, and operations—ensuring you see the big picture in which projects live.

With clarity on that ecosystem, you’ll explore the Project Life Cycle and how project phases unfold from initiation to closure. We will also dive into development life cycles—understanding how predictive (Waterfall), adaptive (Agile), and hybrid models are chosen and used.

Once the foundation is set, we’ll introduce the tools and techniques that project managers use every day. This will be followed by a deep dive into the ITTO framework: Inputs, Tools & Techniques, and Outputs, which are the heart of PMBOK's process-based approach.

From there, the course shifts focus to Process Groups and Knowledge Areas—two of the most critical organizing systems of the PMBOK. We’ll even look at how the two intersect using a useful mapping matrix, often referenced from page 63 of the PMBOK Guide.

We then explore how data flows through a project—from raw facts to actionable reports—and how these help with communication, governance, and decision-making.

After this, we shift toward adaptability, exploring the concept of tailoring—how and why project practices must be adjusted to suit the project's context.

You’ll also learn about key project artifacts and documents, like the project charter, stakeholder register, and risk register, followed by a look at the broader project environment as described in PMBOK 7.

This includes detailed lessons on Enterprise Environmental Factors (EEFs), Organizational Process Assets (OPAs), and how organizational systems influence project execution and governance.

Finally, we take you into the world of principles and project domains introduced in PMBOK 7. We compare the evolving landscape across the different PMBOK versions, and end the section with a focused discussion on key concepts from the PMP exam point of view, particularly the essential themes.

Each of these lessons is carefully designed to build upon the previous one, deepen your understanding, and help you master the tools and mindsets required to become a confident, capable project management professional.

You will then find each lesson designed to:

- Build understanding progressively.

- Include real-world analogies.

- Reinforce with examples and summaries.

- Align with the latest PMP Exam Content Outline (ECO).

Final Thoughts: Becoming a Modern Project Manager

This journey is more than a certification. You are digging deeper into a profession that combines logic and empathy, strategy and execution, planning and agility. Project Managers are not just taskmasters. They are value enablers, change leaders, and strategic thinkers who make visions real, and make your projects a success.

By the end of this course, you won’t just be ready for the exam. You’ll be equipped to lead projects in real-world settings—across industries, continents, and challenges. So take a deep breath. Grab your cup of coffee. And let’s begin.

Welcome to the world of Project Management Professional.

In this lesson, we will begin from the absolute fundamentals. Let us explore the concept of a 'project'. What exactly is a Project?

On your screen now is the official definition of a project, from the PMBOK.

"A project is a temporary endeavor, undertaken to create a unique product, service or result."

This is a short, sweet and powerful definition, which is loaded with a lot of meaning. Embedded in this definition are 5 important aspects, that you must understand perfectly. Let's examine these aspects one-by-one.

Let us now break-down the definition of a project. I have highlighted the different aspects, and we will go through them one-by-one. 

1. The word 'temporary' implies that a project is not permanent. Projects should always have 'begin' and 'end' dates. Projects start, when you decide what you are going to do. Projects end, when objectives are realized. Or, in other situations, projects can end just because you decide to stop doing the project. Under no circumstances, should a project be left 'indefinitely ongoing'.

Any work that is 'indefinitely ongoing', is called as an Operation. It is not a project.

For example, consider the company Tesla launching a new car. The initial design, and setting up of a production line is a Project. But the ongoing manufacturing on a daily basis is an Operation.

Similarly, the initial setting up of a restaurant with all it's complexities, is a Project. But, serving food to customers everyday is an Operation.

You should be 100% clear on this concept, without any confusion. I urge you to come up with 2 more examples like this and enter it in the Q&A forum, under the heading "Project vs. Operation".

Okay, the next loaded word is 'endeavor'. This special word implies that projects require people, effort, and budget. A project is not a naturally occurring phenomenon, or an act of nature. It requires boldness and a commitment of resources, to achieve something.

The next word 'unique', implies that if a project is successful, then there is no need to repeat it once again. If you repeat the project the next time, it becomes an operation or maintenance.

For an example, consider a project to build a national highway from City A to City B. Once the project is completed successfully, your focus shifts to maintenance rather than repeating the project once again. If you have to build another highway to a different city, it is yet another unique project.

The fourth aspect of a project is the result. This implies that projects are necessarily undertaken with clear Objectives in mind. It can be a product that is sold in the market. Or, it can be a service, or a capability, that is the result. It can be an outcome, for example a research project that develops knowledge for the technical team.

All of these are valid results of a project, but in all cases a clear objective is aimed for.

Now, these are the four aspects that are visible. However, there is a hidden aspect that is implicit, and that is 'non-trivial'. If I take a walk in the park in a new city, is that a project? The answer is no, because it is trivial.

Atleast from the perspective of PMBOK and your PMP exam, you should always assume that the project in question is substantial. 

And that was the last aspect that we will discuss. In this lesson, we have understood the definition of a project. We have understood what would qualify as a project, and what would be an operation.

In the next lesson, we will build upon this knowledge and explore the importance of Project Management! So, I'll see you there.

In this lesson, we discuss the importance of Project Management to an organization. Today's business environment is rapidly evolving. Every few years, there is a paradigm shift in customer expectations. Technology is creating disruption in every business domain. With every passing day, budgets get tighter, timelines get shorter, resources get scarcer, and change is accelerated.

In this global situation, organizations create business value through Projects. So naturally, it is important for us to understand what good project management looks like, and also otherwise. Before I proceed, I would like to clarify a point. Project Management is not just the "Project Manager" as an individual. In this lesson, we mean the entire Project Management ecosystem, within the organization.

With Effective Project Management, organizations can:

- Meet Business Objectives - this is the ultimate goal,

- Fulfill Stakeholder expectations,

- Increase predictability of all variables in a project,

- Be more successful in all negotiations,

- Deliver right outcomes at right time all through project lifecycle,

- Provide proactive Risk Response,

- If risks turn into issues, then Resolve them,

- Optimally leverage available Resources,

- Recognize, Salvage, or End projects that are not successful,

- Manage project constraints (i.e scope, schedule, quality, resources, risks, and cost),

- Proactively respond to the Market conditions,

and finally

- Manage change.

Now, let us how the situation is, on the other hand.

An absence or ineffective Project Management results in:

- Missed requirements, right from the beginning of the project,

- Missed deadlines,

- Cost over-budget,

- Poor quality,

- Rework,

- Waste,

- "Scope creep", i.e. an uncontrolled expansion of the project,

- Loss of reputation,

- Unsatisfied stakeholders,

and ultimately

- Failure to achieve objectives.

Remember, in this lesson, we are not talking about the Project Manager alone. Our perspective is on the complete Project Management ecosystem in the organization. Are there any aspects that I have missed in either camp of Project Management? If you find any, please open a new thread in the Q&A section, title it "Effective PM" and state your findings.

And I will see you in the next lesson, where we will discuss the interesting topic of Programs, Portfolios and Operations.

In the previous lesson, I briefly mentioned the "Project Management Ecosystem". In this lesson, we will explore the ecosystem prevalent in most project-driven organizations. We will observe how the benefits derived from a project based ecosystem, delivers much greater value than individual projects.

Multiple Projects that are related to each other, are usually rolled into an entity called as "Program". Why do we do this? The reason to do so, is to get benefits (and control), which are otherwise not available from managing projects individually, such as within resource management and in cost benefits.

In the same way, multiple Programs can then be rolled into a "Portfolio".

Projects, Programs and Portfolios, can exist in any combination. Here you see a clean and symmetric roll-up. 

In this next example, we see a different arrangement. Here, we have a Program with projects, and also other individual projects (without a program), ALL rolled into a Portfolio. This is also a perfectly valid arrangement.

In the final example, we see a Program with constituent projects, and also individual projects, existing independently without any Portfolio.

In the big picture, you can see that any meaningful combination is possible. The Operations, which you see at the bottom of the figure, can support or influence, any of the projects, programs or portfolios, and vice versa too. Moreover, any of the projects, or programs could include Products offered by the company. Notice, I said Products.

A quick side-note: It is very important to understand, that a Portfolio is not a LARGE project. many people make this misunderstanding. Rather, a very large project is called a MEGAPROJECT. You will have heard this term quite often :-) How do we identify a megaproject? As a rule of thumb, megaprojects are budgeted at a billion $$ USD, or more. Or they may affect a million people or more. Or they might run for many years. Anyway, you get the idea.

Now, let's see an example to better understand this relationship of projects, programs and portfolio. I have chosen Microsoft for the organization, because we all are familiar with Microsoft products.

"Office Suite" or "Office 365", is a Portfolio. Microsoft Word, Microsoft Excel etc. are Programs, that churn out new versions and avatars every year (for example, the desktop apps, web apps, mobile apps). Observe that these programs support their namesake PRODUCTS.

Within each of these programs are multiple projects that are churning out new features. One of the projects is working on latest AI-enabled support feature, another project is working on cloud support, and so on.

There is another Portfolio for Operating Systems, and the key program is Windows 11. Again notice this will be a very large program with hundreds of projects being executed simultaneously.

Finally, notice that there is a separate program called "CoPilot", which is being run independently without any Portfolio. In the future, when another related product is launched, everything might get rolled into a new Portfolio.

As an exercise, I want you to visualize the structure within any one different Fortune 500 company (for example Apple, Google, Tesla, Oracle, Amazon..), and build-out the hierarchy. Post your design in the Q&A section.

How an Organization decides to build, and govern it's value delivery system, depends upon multiple factors. Let's compare some of these factors between Projects, Programs and Portfolios.

1st factor: Scope.

Projects have pre-defined objectives. Scope is progressively-elaborated during the project lifecycle.

Program scope covers all the component projects it is made of. Outcomes are designed to be synergistic.

Portfolios have Organizational scope with strategic objectives.

2nd factor: Change.

Both projects and programs expect, manage and control changes. Programs will try to minimize risks and impact, by optimally sharing all types of resources amongst projects.

Portfolio managers have a much broader perspective, and view changes in the external environments like government regulations, industry and market trends.

3rd factor: Planning.

Planning for a single project, is typically elaborated progressively. That is, planning gets more elaborate as we go further into the design. At a program level, the inter-dependencies amongst projects are planned. At a portfolio level, planning is largely strategic, and aligned with the company's vision and mission. 

4th Factor: Management. 

5th factor: Monitoring.

Monitoring at a Project level involves the work of producing products, services or results as per project objective. At a Program level, monitoring involves cross-project benefits, goals and schedules. At the portfolio level, monitoring involves aggregation of organization-wide resource allocation and performance, strategic changes, profit and loss etc.

6th factor: Success.

Project level success is measured by product quality, timeliness, budget compliance and customer satisfaction.

Program level success is measured by component projects efficiency and effectiveness.

Portfolio level success is measured by aggregated investment performance, & org-wide benefits realization.

These factors are of course not the complete list, but these are the most common factors used by organizations. If you understand these factors, it will help you understand the dynamic nature of an organization's value delivery system. We will not address Programs and Portfolios any more in this course, and this much is sufficient from the PMP exam perspective. We will continue our focus on Project Management.

In the next lesson, we will explore the project lifecycle. See you there next!

This is a very important lesson, where we will discuss the basic lifecycle of a Project. The word 'lifecycle', normally used in Biology, to refer to the series of stages that any organism undergoes from birth, to eventual death.

For example, remember the life stages of a butterfly from an egg to caterpillar to pupa and finally a butterfly. Similarly any project, goes through multiple stages or phases, from beginning to completion. The key aspect to notice is the cyclic nature of this phenomenon.

On the screen now is the absolute basic lifecycle of a project. Any deliverable of a project, is typically first initiated, then planned, then executed (i.e. the work is actually done), and finally closed (i.e. completion activities are done). This whole set of activities, is monitored and controlled, at every step of the way.

For small or simple projects, just this very simple lifecycle model is sufficient to manage. But our real life projects will be far more complicated. If your project is really big, or if there are external constraints, then you can manage it in 'PHASE's. By definition, a 'phase' is a set of logically related activities, that has it's own deliverable. Let's see an example now, of a more complex project where the basic model is adapted.

In this screen, we see an example of a fairly complex project that is broken-down into 3 phases.

In the 1st phase, your team builds a website and deploys it online. In the 2nd phase, the website is populated with a massive amount of data, by the data team. In the 3rd phase, the product is launched, with a worldwide marketing campaign.

The most important point to notice, is that each phase is made up of the same basic lifecycle we saw earlier. For example when you are building the website, you will initiate the phase, then plan it, develop it and when it is ready, hand it to the next phase. And all the while, you will be monitoring and controlling everything!

The key point here, is that the same basic lifecycle model is applicable, for the whole Project, and for constituent phases.

The lifecycle model is repeated for the next two phases too. It is NOT necessary that you have to repeat all the activities in every phase. For example, you might probably skip Initiating or Planning in some phases. This is called as "tailoring" of the lifecycle. And that is how you will build out the complete project.

The example we saw just now was straightforward, and every phase ended completely - before the next phase started. But this need not always be the case. Some phases might iterate multiple times in a project. Or, multiple phases might overlap each other. In ALL these cases, we will still adopt the basic lifecycle. We will look at such situations in the next following lesson.

The basic lifecycle model that we saw in this lesson is very important. It is applicable both at a macro level, and a micro level of the project. So you can apply it to the entire project, and to the smaller units. This model is flexible, so you can choose only the activities that are meaningful in a given situation. This model is dynamic, so you can run multiple phases together if you want (i.e. of course, if you have the necessary resources).

We are going to use, and expand this basic model, all through this course. It will form the foundation of several important concepts coming just ahead, such as Process Groups and Knowledge areas. So... see you in the next lesson!

In the previous lesson, we discussed the basic project lifecycle model. In this lesson, we will expand the same concept much further. Let's begin with a quick recap of Project Phases.

It's a common best practice to breakup a large project into smaller, manageable chunks called Phases. A thumb-rule is that every Phase should have atleast one Deliverable. This deliverable can be anything - either customer facing, or internal, or interim. Naturally, the activities within a Phase will all be related. Also remember that phases can be sequential, iterative, or overlapping.

At the end of every phase, a review is done of the deliverable. This review is called as a "PHASE GATE", and it is an opportunity to check the performance and progress of the project. Based upon the review, you should take project decisions - whether to continue or terminate the project, what work you have to repeat, or rework or improve and so on.

Here on the screen are some examples of project Phases. You can name the Phases anything meaningful to your project. Please pause the video here, and observe the names of these phases.

The KEY POINT to note in this slide is that, in every project there will always be one or more phases, where you are doing the actual work that creates a product, service or result. That's when you are 'developing' or 'executing' the project. For example, if you are building a skyscraper, that's when the physical construction happens. If you are creating an AI software product, that's when the coding happens. We call this phase as the "Development Phase".

This "development phase" can have it's own lifecycle. And it is called as the "Development Lifecycle". In common literature, the terms 'project lifecycle' and 'development lifecycle' are often used interchangeably. We will now examine this 'development lifecycle' in the next slide.

Okay, now we come to the real meat of this lesson. The Development Lifecycle can be either Predictive, or Adaptive, or a Hybrid of both. Many practitioners have a lot of confusion with the topic that we are going to discuss now. I will make it real simple and please give extra attention. We will examine these three lifecycles from the perspective of Scope, Time, Cost and Change.

* In a Predictive lifecycle, all the key parameters of the project are planned meticulously upfront, and fixed at the beginning. That is, the Scope, Time and Cost are established early in the project. We will first strive hard to establish "what we want, how much time it will take, and how much it will cost". Predictive is the earliest form of project development. Massive construction projects, and infrastructure projects, large banking financial software, national defense & security projects, healthcare, mission critical projects, operating systems, are all in fact, run in this way, think all Fortune 500 companies. CHANGE is an ENEMY here, but change is inevitable, and has to be very carefully managed. Because scope, time and cost is rather fixed, predictability is high. Predictive lifecycle is ALSO called as "Traditional lifecycle", or "Waterfall Lifecycle".

* Adaptive lifecycle is the modern solution, to tech disruption in project management. It started as a direct response to the Internet revolution. Adaptive is the same as "Agile". It is a very broad umbrella of flexible methodologies. The first and foremost idea is that Change is expected, and often welcomed. Change happens to Scope, and accordingly Time and Cost are knobs that will be adjusted, to achieve your objectives.

Adaptive lifecycle has two fundamental streams - Iterative and Incremental.

In an iterative lifecycle, the project is divided into smaller parts or iterations, each of which goes through the entire development cycle: planning, requirements, design, implementation, testing, and deployment. "SCRUM" is an example of iterative methodology. We will cover Agile techniques in much greater detail later in the course, with hands-on projects.

In an incremental lifecycle, the project is divided into increments, and each increment delivers a part of the functionality. Unlike iterations, each increment MAY NOT go through the entire development cycle from start to finish. "Kanban" is an incremental lifecycle methodology. Hands-on examples later.

* The (coolest) new kid on the block is Hybrid lifecycle. Here, you just take the best of both worlds. You pick and choose the best tools and techniques that will OPTIMIZE your profits. The core technique is to identify elements of your project that are well known or have fixed requirements, and use predictive tools and techniques. And then use Agile tools for the evolving aspects of your project. Keep experimenting and improving from your learning.

Here is a question for you: What are the Top Two evolving aspects of your own work universe, that are less predictable and can use some Agile tools? Please answer in the Q&A section, with title "Hybrid Options".

Before ending this lesson, there are three IMPORTANT points for you:

1st. There will be a question in your mind: "Should I be conversant in all methodologies: Predictive, Adaptive (Incremental, Iterative) and Hybrid?"

The PMP Exam is 50% Predictive and 50% Agile & Hybrid - as stated in PMI's own ECO. And so is the job market outside. So Yes, you should professionally be capable of running a project in any methodology. You are perhaps highly skilled in one methodology and rusty in others, and this is perfectly normal. This course will cover all the lifecycles mentioned in this lesson.

2nd. Who decides the Lifecycle Methodology for a Project?

The Project Team should decide the lifecycle, taking all internal and external parameters into consideration. It's not your boss, or your customers who should drive this decision. But be careful, while choosing the lifecycle!

3. Everybody new to Adaptive has a question "Is planning necessary/present in Agile?"

The answer is "Planning is present in ALL lifecycles. The question rather is 'how much planning is done, by whom and when?".

Okay, with that, I will end this lesson, and see you in the next.

In this lesson, we will understand the role of 'Tools & Techniques' used in Project Management. Every Profession has its own Tools and Techniques.

Whether you're a chef, a surgeon, a carpenter, or a project manager, tools and techniques are at the heart of your craft.

• A chef uses tools like knives, mixers, ovens — and techniques like sautéing, blanching, or braising to transform raw ingredients into a gourmet dish.

• A surgeon uses tools like scalpels and endoscopes, but it’s the technique of laparoscopic surgery that ensures a safe, minimal-incision procedure.

• A carpenter has hammers, saws, and measuring tape as tools, while joinery, sanding, and framing are his techniques.

In all cases, 'tools' are the instruments, and 'techniques' are the ways or methods to use them to achieve a desired result.

Similarly, the Project Management profession is no different. Whether we’re planning a budget, resolving a team conflict, or engaging stakeholders, we use well-established Tools and Techniques (T&Ts) recommended by the PMBOK® Guide.

What exactly are Tools and Techniques?

In the PMBOK, Tools and Techniques are a part of every process.

A TOOL is something tangible, or it is software-based, that helps you perform a task, for example: project management software, or checklists, or templates, or diagrams.

A TECHNIQUE is a method, or procedure, to carry out work, like brainstorming, root cause analysis, or Monte Carlo simulation.

Every PMBOK process includes Inputs → Tools & Techniques → and Outputs. So, T&Ts are the bridge between 'what we receive' as inputs, and 'what we produce' in every step of managing a project.

Consider an example: In the process "Identify Risks", we might use:

• Tools: Risk Register Templates, Prompt Lists, Checklists

• Techniques: SWOT Analysis, Expert Judgment, Assumption Analysis

Tools & Techniques are how project managers turn theory into action.

So, now the question is 'How Are Tools and Techniques related, or similar in nature'?

Although “tools” and “techniques” are distinct terms, in practice, they’re often *paired together* and used in complementary ways:

For example:

• A Cause-and-Effect Diagram (i.e. a Tool), is used in conjunction with Root Cause Analysis (Technique).

• A Scheduling Software (i.e. a Tool) helps apply Schedule Compression (i.e. a Technique) like crashing, or fast-tracking.

In many PMBOK processes, the line between the two is blurred. Some resources (e.g., expert judgment) might be categorized differently depending on the context.

How Are Tools and Techniques Different?

Let’s break down their distinctions a bit further.

# 1. Tools are more tangible; Techniques are more conceptual

* Tools can be templates, forms, software, or diagrams.

* Techniques are structured approaches or logical sequences.

For example:

* Histogram (Tool) vs. Trend Analysis (Technique)

* Checklists (Tool) vs. Checklist Analysis (Technique)

# 2. Techniques require expertise; Tools require usability

* Using a tool might need training.

* Applying a technique requires deeper judgment, contextual awareness, and decision-making.

# 3. Techniques drive insight; Tools drive execution

* Techniques often help analyze, evaluate, and decide.

* Tools help document, visualize, and communicate.

Does Every Tool Have a Technique?

No — not every tool has a paired technique, and not every technique needs a tool.

Let’s illustrate:

| Scenario | Tool without a technique | Technique without a tool           |

| Tool-only      | A milestone chart used to visualize key events                                      | No specific technique needed       |

| Technique-only | Negotiation technique used in procurement                                           | Might occur verbally without tools |

| Both           | Risk Probability & Impact Matrix (Tool) + Probability-Impact Assessment (Technique) | Perfect pairing                    |

That said, many effective project management practices rely on combining both. A tool without methodical use might be underutilized; a technique without support tools might become inefficient.

Why Tools & Techniques Matter to a Project Manager

As a project manager, your ability to apply the right tool or technique at the right time is what transforms you from a coordinator to a strategist.

Here’s why T\&Ts are crucial:

# 1. Standardization: PMI’s standard tools and techniques help you bring consistency to how projects are run across teams, industries, and geographies.

# 2. Predictability: Techniques like forecasting, variance analysis, and earned value management provide a data-driven foundation for decision-making.

# 3. Problem Solving: You’ll face team conflicts, unclear scope, shifting priorities. Techniques like conflict resolution, facilitation, and negotiation are your tactical tools.

# 4. Stakeholder Engagement: Tools like stakeholder maps or communication models help you strategically engage and influence project stakeholders.

# 5. Risk Mitigation: Risk-related tools like the Probability & Impact Matrix, and techniques like Monte Carlo simulation, help prevent surprises and control outcomes.

# 6. Time & Cost Optimization: With tools like network diagrams and techniques like schedule compression, you can manage constraints smartly.

In essence, T\&Ts are your *leadership levers*.

How You Will Learn T&Ts in This Course

As part of this PMP preparation course, we will deep-dive into approximately 150 key Tools & Techniques, organized by the PMBOK’s Knowledge Areas and Processes.

You won’t just memorize them — you’ll understand when, why, and how to use them, with real-world project examples, visual aids, and case study-based exercises.

Here’s a taste of what’s coming up:

| Category                   | Example Tool                      | Example Technique                             |

| -------------------------- | --------------------------------- | --------------------------------------------- |

| Risk Management        | Risk Register, Prompt List        | Root Cause Analysis, SWOT                     |

| Schedule Management    | Gantt Chart, Project Calendars    | Critical Path Method, Schedule Compression    |

| Stakeholder Engagement | Power/Interest Grid               | Stakeholder Analysis, Facilitation            |

| Quality Management     | Control Charts, Fishbone Diagrams | Process Analysis, Quality Audits              |

| Cost Management        | Cost Baselines                    | Earned Value Analysis, Forecasting            |

| Communication          | Communication Models              | Feedback Techniques, Communication Competence |

We’ll group these under three primary categories:

1. Data Gathering Tools & Techniques :  Interviews, Surveys, Focus Groups

2. Data Analysis Tools & Techniques: Variance Analysis, Trend Analysis, Cost-Benefit Analysis

3. Data Representation Tools & Techniques: Bar Charts, Histograms, Scatter Diagrams

And yes, we’ll also explore interpersonal and team skills, such as:

• Conflict resolution

• Motivation theories

• Coaching and mentoring

• Emotional intelligence

These too are categorized as Techniques under the PMBOK, even if they don’t rely on a formal tool.

From Knowledge to Application: Your PMP Edge

During the PMP exam, you’ll be tested on your ability to identify, select, and apply the right T\&T in various scenarios. Here’s what that might look like:

# ? Example 1: You’re planning stakeholder engagement and need to determine their influence and interest.*

→ Use the Power/Interest Grid (Tool) + Stakeholder Analysis (Technique)

# ? Example 2: You’re behind schedule. What should you do?*

→ Apply Schedule Compression Techniques: crashing or fast-tracking

# ? Example 3: You have project quality issues recurring over several phases.*

→ Use a Fishbone Diagram (Tool) with Root Cause Analysis (Technique)

You’re not expected to know only *what* they are, but also *when* and *why* to use them.

Closing Thoughts: The Art and Science of Tools & Techniques

In project management, Tools and Techniques are not just procedural—they are strategic weapons.

They allow you to:

* Tame uncertainty

* Resolve complexity

* Lead teams with confidence

* Deliver value reliably

Just like a carpenter isn't defined by his saw, or a chef by her knife — a project manager is defined not only by *knowing* tools and techniques, but by *mastering when to use which*.

By the end of this course, you’ll be equipped to:

* Recognize over 150 Tools & Techniques recommended by the PMBOK

* Understand which process they are used in

* Apply them logically in scenario-based exam questions

* Bring them into your real-world projects with confidence

Your Next Step

In the upcoming modules, we’ll begin exploring Tools & Techniques by Knowledge Area and by Process Group, and walk through:

* Their purpose

* Their mechanism

* Exam-relevant examples

* Practical exercises

So sharpen your virtual pencil — you’re about to build your PM Toolbox.

In the previous couple of lessons, we had a deep discussion of the project lifecycle. And now, the question is - "Given the design of a Project Lifecycle, how do we then proceed to actually manage and execute the project?" The Project Manager's answer to this question, will become evident in a little while. In this lesson, we explore the concept of Project Processes.

Let us understand 'project processes', with a couple of simple analogies.

Consider the English language. Starting with just 26 elementary alphabets, words are created. Words form sentences, and then sentences form the entire English language. Eventually, you can create an entire library in English, starting from a,b,c. In this analogy, Alphabets are 'project processes'.

One more analogy. Starting with just 7 musical notes Do-re-me and so on, the musical universe can be created. And in this analogy, the musical notes are 'project processes'. I can't resist but quoting Julie Andrews here - "If you know the notes to sing, you can sing almost anything! :-)". Naturally, any analogy will break apart if you pull it too long, so I wi ll return to our topic :-)

There are a total of 49 processes in Project Management. These are the elementary building boxes of Project Management. Any project in the world, in any business domain, using any lifecycle, can be MANAGED, using elementary activities, called as PROCESSES. Not all projects need to use all the 49 processes. You have to choose the appropriate processes that make sense to your project. And like phases, processes can be sequential (i.e. one-after-another), or iterative (i.e. repeatable), or overlapping (i.e. multiple running at the same time).

Now let's look deeper. The best way of visualizing a project process is like a tiny engine. This small engine take in some input/s (for example some data), and creates some output/s (from example some document). How does input turn into output? By using appropriate Tools, and Techniques.

So, now we get the full idea of what an elementary process really is. A process takes inputs, applies some tools and techniques, and throws out a deliverable, or a document, or a decision, or a result. The output of one process, then becomes the input of the next process, and so on until all the deliverables, have been churned out. In short, they are called as ITTOs.

The PMBOK guide SIXTH EDITION, lists a total of 49 different processes. This here is an example of a process called "Plan Scope Management". Notice the recommended set of ITTOs for this process. Every one of the 49 processes can be denoted in the exact same fashion, but with different ITTOs.

Therefore, any ENTIRE project can now be visualized as a series of individual processes, logically linked to each other, by the outputs they produce! On the screen are some examples of process charts. So, now let's return to the question from the beginning of this lesson. "Given the design of a project lifecycle, how do we then execute the project?".

The answer is to break-down the lifecycle into a series of PROCESSES. Then use specific tools and techniques of each process, in specific order, to generate deliverables. And your project is executed! 

Now let me summarize again, because this knowledge is super useful.

1. Is EVERY process used in every Project? Should I use all the ITTOs that are mentioned? No, only use what's required, and what is meaningful.

2. Are processes used in Agile and Hybrid projects also? Yes, absolutely. Again, remember it is the overall lifecycle that will vary with any given methodology. You convert the lifecycle into a process chart and execute it.

3. Can processes be sequential, iterative, overlapping? Absolutely, yes and that's how you build out your project phases.

4. Can different processes have the same ITTOs? Yes, but in different combinations. You will later see that some ITTOs are commonly used, and others are rarely used.

You may have some more questions at this point of time. I recommend you retake this lesson again if required. But all queries will get cleared up in the next few lessons. So, I will see you there!

In the previous lesson, we had a detailed discussion on project management processes. There are currently 49 processes as detailed in PMBOK6. These 49 processes, have their inputs, tools & techniques running into the hundreds. So the question that we will ask and answer in this lesson is "As a project manager, how do I know the correct process to apply at any given situation". There are several ways of understanding, and making sense of these processes and we will examine the concept of process groups in this lesson.

You DO NOT have to memorize each of the 49 processes, for the current format of the PMP exam. This was not the case a few years earlier, and exam questions tested your memorization of the process names, and their ITTOs. Fortunately that is not the case now. Rather, the PMP exam now, will test your deep understanding of the logical utilization of the processes. There are generally, 3 types of processes:

1. Processes that are used only once, or at specific predefined points in the project. For example, there is a process called as "Develop Project Charter", that is performed only once, during the Initiation phase of a project. Similarly, the process called "Close Project or phase", is performed at predefined points as a Phase Gate review or during project closure. 

2. The second type of processes are those performed, whenever the specific need arises. An example of this is a process called "Acquire Resources". You might perform this process in any phase, whenever resources are required. Another process called "Conduct procurement", is similar and performed as and when required.

3. The third type of processes, are those performed continuously throughout the project. For example, the process called "Define Activities" is typically performed in every phase, especially so in Adaptive (Agile) development lifecycle. Similarly, different testing and verification related processes are ongoing throughout the duration of the project.

Now we come to the main part of the lesson. The 49 Processes can be categorized (i.e. grouped), by two separate techniques, "Process Groups", and "Knowledge Areas". In this lesson, we will only look at the first technique called as "Process Group mapping".

You should remember this figure on the screen from earlier lesson. It visualizes the most basic lifecycle of a project. It has the phases for Initiation, Planning, Executing, and Closing. All of these phases are encapsulated with Monitoring and Controlling.

We can group together all the processes that are performed during the Initiation of a project and call it the "Initiating Process Group". This method of categorization will give us 5 Process Groups! This makes it super convenient to the project manager, as they will now know which processes are to be performed during any point of time in the project lifecycle.

So now, we have 5 process groups, and every one of the 49 processes will belong to one of these groups.

1. The Initiating group contains processes performed to initiate a new project (or a new phase). Here, you will basically be seeking authorization to start the project or phase.

2. In the next Planning process group, you define the scope, objectives, estimate the resources and design a schedule etc for the entire project (or for the next phase).

3. Executing process group is where the actual work happens. You will manage work, risks, communications, procure raw materials and so on.

4. In the Monitoring and Controlling process groups are those processes that will track the work, review the progress, perform testing, verify results etc, all though the lifecycle.

5. Every project (or phase), has to be formally closed. And that's where the Closing group come in.

So these are the 5 process groups, and finally let's see all the processes categorized in this way, in the next slide.

So, finally, on this slide we can see all the 49 processes, categorized by process groups. Feel free to pause and have a look if you want, but I suggest you wait until the next lesson :-)

There are two points before I conclude this lesson:

First point: Ignore the numbers that precede the process names in this table. They are just the section numbers from the PMBOK guide. I always retain the numbers as a quick reference to the actual source.

Second point: Process groups are NOT phases! The grouping was done logically from the basic phases of a project, BUT process groups are NOT project phases themselves. This is a subtle but important difference.

In the next lesson, we will see the second technique of categorizing these 49 processes and we will combine both techniques. See you in the next lesson!

In the previous lesson, we discussed Process Groups, and in this lesson we investigate the concept of 'Knowledge Areas'. Just like process groups, Knowledge Areas are used to categorize the 49 processes of project management. A "Knowledge Area" is just a specific domain within Project Management. Project Management has ten knowledge areas. Every one of these, has it's own requirements, best practices, inputs, outputs, tools and techniques. This lesson will be a brief intro, with examples.

1. Integration Management: Is the first and most important Knowledge Area. It involves coordinating ALL aspects of a project effectively to meet its objectives. This includes developing project plans, executing those plans, and controlling changes as they occur. As an example, imagine a construction project to build a new office building. Integration management ensures that ALL aspects such as architectural design, procurement of raw materials, construction scheduling, quality and budgeting are all coordinated, aligned with the project goal.

2nd Knowledge Area, Scope Management: Consider that you are managing the development of a new software application. Then scope management first ensures that all the required features, functional and NON-FUNCTIONAL requirements both are clearly defined in the project scope statement. Then, it involves managing changes to the scope during the development to prevent SCOPE CREEP. Scope Management ensures that the project delivers the intended outcomes (AND NOTHING ELSE).

3. Schedule Management: Consider a marketing campaign project, schedule management involves creating a TIMELINE that includes tasks such as market research, advertising, strategy development, content creation, and so on. It ALSO ensures that all tasks are completed within the specified time frames i.e. tracking.

4. Cost Management: Consider  a project that involves the construction of a new bridge. Cost management involves estimating the costs of materials, labor, equipment, and other resources required for the project. It also involves tracking expenditures during construction to ensure that costs do not exceed the allocated budget.

5. Quality Management: involves ensuring that the project delivers outputs that meet all requirements and expectations. It involves quality planning, quality assurance, and quality control.

6. Resource Management: Imagine you are organizing a large-scale event like a Metallica Music Concert. Resource management includes hiring event staff, securing concert venues, obtaining necessary permits, managing finances, and coordinating logistics such as transportation and accommodation for performers and support staff.

7. Communications Management: Project information needs to be generated, collected, disseminated, stored, disposed - at the right time, and to the right people.

8. Risk Management: Suppose you are launching a new product. Risk management involves identifying potential risks such as market competition, supply chain disruptions, or technical issues. It includes developing risk mitigation strategies such as market research, diversifying suppliers, and conducting product testing to minimize the likelihood and impact of these risks.

9. Procurement Management: Let's say you are constructing a office building. Procurement management involves planning, solicitation, identifying and selecting contractors for work such as construction, electrical, plumbing, and landscaping. It also involves negotiating contracts, monitoring contractor performance, and managing payments throughout the construction process.

10. Stakeholder Management: Consider a Community Development project. Stakeholders are the local residents, government agencies, nonprofit organizations, and other businesses. It includes conducting public meetings, gathering feedback, addressing concerns, and building support for the project within the community.

Now, we have seen all the 10 knowledge areas. The Project Manager is ultimately accountable for all the areas, but directly responsible for the Integration Management. The PM can delegate the other areas, except Integration Management. You should know all the 10 areas, by rote. In the next lesson, we will see the 49 processes classified by BOTH PGs and KAs. So see you in the next lesson.

Do you remember the "Periodic Table of Elements" that you studied in High School? I am sure you do! This table, created in 1869, by Dmitri Mendeleev has had significant impact on Science and Technology. There is a great deal of inner logic and order to this table. Many new elements have been added over the years. Scientists use this table to discern trends, predict behavior and so on, all the time .

There is an equivalent table like this, in Project Management, with similar impact. In this lesson, we will see one of the most famous, and most important MAPPING TABLE in the study of project management. In fact, the previous few lessons all have been a logical buildup to this mapping table.

Okay, so finally this is the table that maps the 49 elementary processes of project management to the Knowledge Areas, and the Process Groups. Observe that the X-axis is for the Process Groups. There are 5 PGs - Initiating, Planning, Executing, Monitoring & Controlling, and Closing groups. Correspondingly, the 10 KAs are on the Y-axis. Notice that some of the cells have multiple processes, and some of them have none at all. Planning PG, has the most number of processes representing every KA, and Closing PG has the least. M&C PG has processes in every KA, similar to the Planning PG. Attached with this lesson will be an Excel sheet with this table. Download it, and you will be able to find several other patterns within it.

Because of this table, every process now has a set of co-ordinates. What actually does that mean? This table pinpoints the most appropriate actions the PM should perform, -in any phase of the project, and -to any of the knowledge areas.

For example, suppose your customer asks "How will you PLAN for RISK in my project?". Your reply will be located in this specific cell, which intersects PLANNING process group, and RISK knowledge area. So, you can discern how powerful, yet simple, this mapping table is!

Ok, now the biggest question is: Can this table be used for Agile projects?

The answer is Yes.

You can just pick and choose, whichever process useful to you. The trick is to identify the areas which are predictable in your project, or in your business domain. For example: If your project is Agile but has strict quality requirements, then a lot of the processes might be useful to you. The entire "Quality" knowledge area, and the "Monitoring & Controlling" process group.

If you handle AGILE projects, I want you to pause for a moment now. Match this table to your project, and identify atleast 1 NEW process that you can adopt from this table. Answer in the Q&A forum of this course, with the title "Hybrid process adoption" .

This table shows the history of the PMBOK guide and the mapping table; Notice, the Sixth Edition of PMBOK is extremely important because that Agile Practice Guide was included in the PMBOK for first time. Until that time, it was only Predictive.

The 7th Edition released in 2021 was historic, and a tectonic shift in the PMBOK guide. The book became generic - i.e. it became lifecycle agnostic! It moved away from process-oriented perspective, to an OUTCOME-based perspective. The message given to the Project Management community is:

1st: It doesn't matter which lifecycle you use, the SUCCESS of your Stakeholders is more important.

2nd: BOTH Predictive and Adaptive practices have 50-50 equal importance. This is the reason, PMBOK 6 is NOT superseded by PMBOK 7. Both are valid. As I create this lesson, the absolute latest development is that PMI has released the "Process Group Practice Guide". Therefore, the current configuration is PMBOK 7 with two practice guides - one for Predictive, and another for Agile | Hybrid.

I hope that the history slide was not boring. PMBOK 8 is scheduled late next year. This course will be updated every 3 months or so, so rest assured it will be focused on latest syllabus, and sufficient for your exam. Please note: you should MEMORIZE the PG and KA names. Don't memorize the process names. We will cover each one later in the course. With that, I will end this lesson and see you in the next!

In this lesson, we discuss about project data, information and reports. There is an old quote which goes like this: "a man is only as good as his tools". In the world of project management it should be: "Managers are only as good as their reports". Reports are a critical tool that the PM uses, to tell the story of their project to the world. In this lesson, we understand how great reports can be created.

A project is like a treasure hunt. You have to make key decisions throughout the lifecycle, and you have to enable your customers to make critical decisions. Decisions are powered by INSIGHT. 'Insight' means a clear understanding of a complex situation. 

Insight is derived from great REPORTS. These are your weekly status reports, monthly reports, internal reports to your team, or external reports to customers, technical recommendations, justifications, software release notes, and so on.

Reports are derived from Information. The "controlling processes" in your project, decide the parameters that are significant to you. For example, when you BASELINE your schedule at the end of planning phase, then it becomes a part of your project information repository.

Ultimately, information is gleaned from raw data. When your project is being executed, a whole lot of data can be captured. Some examples of raw data are: physical work completed as on date, raw material consumed, customer reported testing bugs, number of open change requests,

In the next slide, we will see a process flow chart, that shows how data is transformed within a project.

In this chart, observe how the executing processes create work performance DATA. This is basically your working team giving you data about the work they have performed.

Raw data gets transformed to INFORMATION by the controlling processes. For example, the testing team will infer a list of 'Major Issues' from the raw data. Or you might identify the 'Critical Path Tasks which are late'.

Finally, you will extrapolate all the information to build a 'Monthly Project Report'. For example, you might end up recommending that a further 100K USD be invested into risk mitigation of your project.

Reports are communicated out to stakeholders, and can also enable change control though different project processes.

Now, to conclude this lesson, there are two points to be noted.

1st point: Great reports don't appear by magic. They require great foresight. Right from the beginning of the project, you should plan for the data and information that power the reports. For example, without schedule, cost and scope baselines, you just can not track deviations in your project!

2nd point: Great reports require cost EFFORT, and TIME. These should be factored into your schedule, else you can't expect to create decisive reports on your project.

And with that, I'll conclude this lesson, and see you in the next.

In the previous lesson, we saw the mapping of the 49 processes to KAs and PGs. There are hundreds upon hundreds of tools, techniques, best practices within those 49 processes. The million dollar question now is "How do I use this mapping table to my project?". 

So far, I have been answering this question as "You have to pick and choose the process you want". In this lesson however, we will finally see  see how this is to be done. This deliberate adoption (and adaptation) of processes, to make it suitable for your environment, and your project is called TAILORING.

Why should we tailor?

The answer is "Because every project is UNIQUE, by definition." You know that NOT every tool/technique/input/output is required on every project.

TWO main goals-  to optimize resources, and to focus on customer needs. If you are going AGILE, then you don't want to waste your precious time writing hefty requirement docs.

How is tailoring done?

ALWAYS begin tailoring with the 6 project constraints. EVERY project has different constraints of Scope, Schedule, Cost, Resource, Quality, and Risk, with different PRIORITY. OBSERVE that all 6 of these constraints are within the Knowledge Areas!

The PMBOK 7 edition, recommends a 4-Step tailoring process:

Step 1: The Project team should select the best development approach based on knowledge of the product, tech stack, delivery cadence etc.

Step 2: Tailor for the Organization. Your organization will have it's own larger delivery philosophy. You will have to prove that your approach is not a threat to the organization's strategic goals, but rather it is beneficial.

Step 3: Tailor for the Project. This is where you will cater to the needs of the people on your team. Here, you can tailor to the culture, preference and knowledge of your team.

Step 4: Implement ongoing improvement. Tailoring is NOT a single, one-time exercise. You can tailor adjust & adapt, every single day to optimize. Stay nimble and keep your focus on winning the project.

Every project needs a tailoring. You should customize the practices, tools, techniques, ground rules etc, according to the 6 constraints of your project. While you tailor, you should ensure your bosses are are happy and your organization benefits from your tailoring. This has only been an introduction. We will look at tailoring techniques ahead in the course. With that, I will conclude this lesson and see you in the next!

The lifecycle of a project is documented in several *artifacts* even before the project starts, and even after it's finished. In this lesson, we take an interesting view of a project, through these artifacts. "So what is an an 'artifact'", you might ask?  An artifact can be a document, template, logs & registers, plans, baselines, visual data & charts, reports, agreements & contracts, etc.

Broadly speaking, there are 8 common reasons for initiating a project - and they are listed here. Whatever be the reason to start a project, a Business Case document is typically the very first document to be created for a project, and it is basically an economic feasibility study. It builds the monetary benefits case for a project to be launched. The Business Case says: "We can spend X amount of money and get Y amount of benefits". The benefits can be anything, tangible or intangible, immediate or deferred.

Once the benefits are deemed attractive enough, the next artifact called 'Benefits Management Plan' is created. As the name suggest, the focus of this document is on BENEFITS. It will address the questions like "What are the TARGET benefits of the project?, How do the benefits align with Org's business strategies? What is the timeframe for realizing the benefits? Who is the owner of the project i.e.e the person or department, that is accountable for realizing the benefits", and so on.

BOTH these documents are created before the project is initiated. And finally after the project has ended, they are referenced to again, to check if project is a success or not. These 2 documents outlive the project and that is the reason they are called as "Business Docs", and not project docs. And they both are inputs to, and give birth to the Project Charter.

The Project Charter is an authorization document. A PM is 'authorized' to utilize the resources of the Org to execute a project, by the charter. Now, depending on which part of the world you are at, your industry, your Org's practices, and various other factors, these artifact names may be different. But within the project management world of PMI, these are pretty much standard documents and you should be very familiar with them.

There are various other business artifacts that are created during the lifetime of a project. For example, bid documents are used in vendor management (buyers & sellers). You might be the vendor, or you might be seeking vendors. The most common documents are - Request for Information (RFI), Request for Quotation (RFQ) and the Request for Proposal (RFP).

Agreements & Contracts are legal documents. 'FP' is a Fixed Price contract which is typically used for well-defined products & services. T&M stands for 'Time & Materials contract'. This will only establish a fixed rate for services, but not an exact statement of work.

IDIQ stands for 'Indefinite delivery Indefinite quantity'. These are open-ended contracts, with upper and lower limits established, and a fixed time limit. These contracts are used in exploratory projects like in architecture, engineering of new products etc.

MoU (i.e. Memorandum of Understanding), SLA (service level agreements) are other kinds of legal business documents. 

Now, let us look at the Project documents. The BIG elephant in the room, is the Project Management Plan. This mega document describes how the entire project will be executed, monitored, controlled, and closed. It's a conglomeration of about 12 other plans, 4 important baselines and some other docs. We will go through all these documents later in the course, so I will not delve deep in them now.

There are another 33 important project documents, that can be used in your projects. They include logs & registers (like issue log and risk register), calendars, visual information (like the Gantt chart, Network diagram etc), estimates and forecasts, and so on.

Now, in this slide, we will discuss the important concept of BASELINEs. If you are not familiar with baselines, then you should pay special attention.

So, "what is a baseline, and why is it super important?"

Whenever we start a new project, we first plan how we are going to execute it. We start with the Project Objectives (i.e. the Scope), break it down into tangible deliverables (i.e. the WBS). The deliverables are then broken down into smaller tasks (i.e. the Schedule). The schedule will tell us the time-frame & the resources required. The resources all have costs attached. Thus we get the costing for the project.

Therefore, at the end of the planning phase, we have established the ESTIMATES for Scope, Schedule, and Cost. Before we jump into executing the project, we save these estimates. These estimates ARE the BASELINEs! This is our PLAN for how we will execute the project. It is sacrosanct because we have to stick with this plan as much as possible.

Now, as we know very well, when plans meet the real world, all nature gets agitated :-) When you execute the project, changes will come in from ALL directions. The PMs duty is to track the 'ACTUAL progress' against the 'PLANNED progress'. That is, you have to track the project, against each Baselines. If you have not saved the baselines, you will be clueless about the deviations occurring in your project - and that is why Baselines are so important.

Baselines are the super condensed form of your plans. These 4 (WBS, Scope, Schedule and Cost) baselines are the most important for your project. They are collectively called as the PROJECT BASELINE. There may be other baselines too. For any non-trivial project, they must be saved under change-control.

In this lesson, we have explored the broad gamut of artifacts generated for project management. While there are a lot of artifacts, most organizations will standardize these as templates. From a PMP exam perspective, you should be familiar with the USAGE of all the artifacts mentioned in this lesson, and nothing more. You will not be tested with the actual contents, or formats of any of these. And with that I will conclude this lesson, and see you in the next.

In the previous lesson, we discussed a wide variety of project artifacts. These artifacts are INTERNAL to an Organization, and are only ONE factor of many that influences a project. Projects exist within internal and external environments, and they can influence a project either positively or negatively. In this lesson, we will only briefly see the layout of influences on a project, and then expand this in the next couple of lessons.

What are the external influences on a project?

1. Market conditions: your competitors, market trends & fashions, how much market share your company has, latest technology trends, patents and trademarks can all influence your project.

2. Social & cultural influences: today the projects are global, your customers and/or team-mates maybe from a different culture or timezone and you should know how to manage them, the political conditions, regional customs, different holiday calendars, working times etc. These are some examples of the external influences.

3. Global geopolitics: The corona pandemic, the wars in the Middle East & Eastern Europe has no doubt, had MASSIVE impact on project economy worldwide, and all of us have experienced first-hand :-) 

And now, what are internal influences on a project?

Your organizations infrastructures, knowledge repositories, facilities, human resources, governance structures, Project Management Office i.e. PMO, etc are all internal influences. We will explore these in upcoming lessons.

Overall, it will be important for you to analyze these influences on your project, and you sould try to maximize positive impact, while reducing the negative impact.

In this slide, we will explore how projects are influenced within a PRODUCT lifecycle. As of today, the disciplines of project, program, portfolio and product management are all getting tightly interlinked and interdependent. So this understanding is very useful.

what is a product? A product is an artifact that is produced, and is quantifiable. Simple, generic definition. For example, consider the Sony PlayStation. It is an incredibly popular product. On the screen we see the classic PRODUCT LIFECYCLE.

Any product goes through the phases of Introduction > Growth > Maturity > Decline. This lifecycle typically spans many years, or many decades as in the case of the PlayStation. The curve shows sales and impact on the world. It slowly takes off, peaks, and eventually peters-out.

Now observe how different projects are launched during different Product Phases, and are influenced completely by the product environment - from creation to retirement. The ENTIRE product lifecycle can be encapsulated within a portfolio.

And with that, I will close this lesson. We have seen that there is NO project that exists in a vacuum, but rather the environment massively influences projects. In particular, we will explore 2 MAJOR factors called EEF and OPA in the next lesson. See you there!

There are 2 MAJOR types of factors, that influence a project. The first type is called EEFs - i.e. Enterprise Environmental Factors, and the second is called OPAs i.e. Organizational Process Assets. You should memorize these 2 terms (EEF & OPA), and be very conversant with them for the PMP exam. These factors together influence about 90% of all the 49 project processes that we study throughout the course, and that's the reason these are very important.

EEFs, as the name suggests, deal with the environment of a project. They are further divided into 2 types - internal and external. Let's explore both of these next.

Internal EEFs are those within the Enterprise: the Org culture, structure, governance. When I mention Apple as a company, it will evoke some perception of the company's culture, reflected in their products. Similarly for the Army which is an Organization (& runs trillions of $$$s worth of projects), evokes some perception of the culture of discipline, teamwork, reporting hierarchy etc. These factors influence how the organizations run their projects.

The companies that execute high quality projects, will necessarily invest a lot more on the infrastructure, support systems like the IT platforms, training for employees to improve competency, and so on. The reverse is also true. These factors can majorly influence your project positively or negatively.

Similarly, the EEFs that are external include - market conditions (for example, right now, the market is very hot for electric vehicles), Social & global issues (for example, right now wars are breaking out around the world, and this will impact certain type of projects), and then there are legal restrictions, availability of academic research (large data modeling & machine learning has impacted AI), Industry standards, international currency exchange rates, and so on. External factors like weather, local regulations, and resource availability, impact construction projects. All of these are EEFs external to the project.

And now I will conclude this lesson with some predictions on Enterprise Environmental Factors, near term future. There are some MAJOR global trends that will impact EEFs in the next 1-2 decades. Climate change will dominate global concerns. The world's population is aging rapidly. There is a already a shift in global economic powers. But everything is not doom & gloom. AI will disrupt ALL domains imaginable (agriculture, medicine & healthcare). Transport & tech will enable much greater international collaboration. All of these will impact the global project economy.

The final point I want to repeat is that EEFs (& OPAs) are an input to most of the 49 processes. So, they will be MENTIONED all through the course, but I will not explain them again later. And with that, let's move to the next lesson, where I will talk about OPAs.

In this lesson, we will discuss OPAs (i.e. Organizational Process Assets). OPAs include ANY artifact, or practices or knowledge that belongs to an Organization, which can used for the benefit of the project. OPAs incidentally can belong to a supporting Organization too - for example, from your vendors or contractors :-) Unlike EEFs, OPAs are all internal, and are very specific to the Organization only. Since OPAs are all internal, the project team has greater control over the benefits, and they can also proactively contribute to the OPAs.

There are two categories of OPAs - First are the 'Plans, Processes, Templates & Docs', second are 'Knowledge repositories'.

Do you remember the standard list of Project Management Plan, & Project Documents that we saw from a few lessons back? Any mature Organization will have templates for all of these documents. These are an OPA. It will typically not be expected that a PM has to create any of these from scratch. Rather, you will just be expected to fill up the template, get it reviewed and approved, and you will be ready to roll. The template will contain a MASSIVE wealth of knowledge, wisdom, past lessons and so on. And you will get all of those treasures, just by starting out with a template document.

For example: in the Initiating & Planning phases, the templates can give you TAILORING instructions. Product or Project lifecycle models can be purchased or customized and used as templates. Your company might maintain pre-approved suppliers list, and different types of contractual agreements.

In the Executing phase, you might utilize change control procedures, or traceability matrices, UI guidelines, testing checklists and so on. All of these are OPA.

In the Closing phase, you might use AUDIT guidelines, or acceptance criteria templates, or handover checklists and so on. These assets can be used anywhere, or everywhere, and prove to be INVALUABLE to your project.

The other category of OPAs are the Knowledge Repositories. Mature organizations store a whole lot of historical DATA, that can be used by other projects, to their great advantage.

Some examples are configuration management data with versions of software and hardware components, baselines for standards, policies and other documents.

Financial data with budgets, labor hours, costs incurred, cost overruns, etc.

Lessons learned from earlier projects are invaluable, and are used to make quicker decisions, prevent mistakes, and repeat previous success.

Issues and defect data repositories, typically carried in bug-tracking software can provide useful insight into design flaws, technical competency of the team, management issues, and so on.

These are only some of the knowledge repositories, and practically any useful information can be stored and retrieved at the appropriate time for the benefit of ongoing projects.

In this lesson, we learnt about OPAs, and in the previous we discussed EEFs. These are the two types of MOST COMMON influences on a project. They will together provide inputs to mostly all of the project processes. They are ubiquitous, and I will assume you have understood them well as we go ahead in the course. In the next lesson, we will take a big picture view and learn about the nature of Organizational Systems, and their impact on project management.

In this lesson, we will discuss Organizational Systems, and their impact on Project Management. A project in execution, is like a living being within an ecosystem. This system provides responsibility, accountability, and authority to a Project Manager, within an Organization.

So, let us understand: WHAT are the aspects of the Organizational System that we must understand?

The 3 aspects that we will discuss in this lesson are: Governance frameworks, Management Elements, & common Organizational Structure Types. Your understanding of these concepts, will be tested in the PMP exam.

No the question is: WHY should we understand Org Systems?

Because this understanding helps Project Managers EFFECTIVELY use all their tools, to the maximum - their power, influence, technical competency, leadership skills, and political ability (like their networking skills).

Project Managers should strive for a deep understanding of their Organization's governance framework. This framework should form a scaffolding for all the stakeholders including the customers, and the project team.

The elements of this framework are - Rules (such as the ground rules for a project, which include mutual respect & co-operation, working times & calendars etc), Policies (for example the HR policies, and IT policies, safety & security policies etc), Procedures (for example how to engage with suppliers, how to procure raw materials, how to requisition budgets), Norms (these are the INFORMAL rules - for example, how we conduct business, how we make decisions, how we communicate etc). What are the relationships within the Organization? (which departments work together, depend on each other and so on). Finally, there are Systems and Processes through which the Organization functions (such as the Financial systems, the onboarding & deboarding HR processes, claims & complaints processes and so on).

A Project Manager's effectiveness, directly correlates with their skill in navigating through THIS governance framework. 

Now, let's discuss the KEY components that makes up 'General Management' within an Organization. These are the Management Elements. Every Organization will treat these elements differently.

The elements are:

-Division of work amongst the team, based on delegation & availability;

-Authority to perform work;

-Responsibility given to an employee based on skill and experience;

-Discipline of action (e.g., respect for authority, people & rules);

-Unity of Command (i.e. only one person gives the orders. You might have seen companies where many people give different orders or equally worse, nobody knows who gives the orders :-)

-Unity of Direction (when there is one plan for one objective, with one head);

-Goals of Organization should precede any individual's goals (people with hidden agendas);

-A fair payment for work performed (whether it is for employees, or contractors or for vendors);

-An optimal use of resources;

-Clear and open communication channels;

-Provision of the right materials to right person at the right time.

-Fair & Equal treatment of all people;

-Safety & Security in the workplace;

-Generating the optimal morale for everyone;

So, these are the key components of general management, that every Organization handles differently, because there are different Organizational Structure Types. In the next slide, we explore these different structure types.

There are many, many different Org structure types in the world. In this table, we have 10 different types listed out. You can see the type names in the first column. Feel free to pause the video and read through the table.

There are only 3 types that I want to draw your attention to, where the Project Manager's role is STRONG, and authority provided by the Organization, is HIGH.

1st is the "Strong - Matrix" type of Organization. In the Matrix type of Organization, employees have a dual reporting structure. They report BOTH to the functional managers, and to project managers to whom they have been assigned. PMs will have moderate to high authority.

2nd type is the "Project-oriented" Organizations. These companies typically have long duration projects, and strongly knit teams where PMs have high to total authority.

3rd type is the "PMO-driven" Organization. PMOs here are typically focused on Programs or Portfolios, and the PMs again have high to total authority.

In all other types of structures, the authority of the PM will be LOW to moderate. In the PMP exam, you might get questions where the Organizational Structure type will be mentioned in the question's narrative, and you will be expected to know the authority they have, to deduce a solution to the question. In the future lessons, I may mention one of these types, and you should be able to interpret the authority of the PM.

So, now we come to the conclusion. In this lesson, we have discussed Organizational Systems. These systems are typically defined by their - Governance frameworks, Management elements, and Organizational Structure types.

Understanding how the entire system operates, puts YOU the Project Manager in a position of strength. It helps you to EFFECTIVELY use all your tools to the maximum strength - power, influence, leadership skills, etc. And with that, I will end this lesson, and see you in the next.

This will be a very important lesson, where I will introduce the "12 Principles of Project Management". Since this topic is very broad, I will only be introducing all the 12 principles here. I will discuss each of these principles in greater detail later, when we encounter them during various case studies. These principles first appeared in PMBOK ver.7, in late 2021 and were developed, from input and feedback, of thousands of global project practitioners from different industries, different backgrounds, different organizations. The only thing common was that they were all into project management.

So, we will start with the million dollar question: "What exactly are Principles?"

Principles for any profession, serve as foundational guidelines for strategy, decision-making, and problem-solving. Different professions use principles in different ways. Some use them as rules, laws or morals. However, the 12 principles of project management are only intended to GUIDE the behavior of people in projects.

Okay, so now let us meet each of the principles.

1. "Be a diligent, respectful, and caring steward."

The word "Steward", means a "Caretaker", or "Custodian". As the Project Manager, you are the custodian of the project and all resources allocated. Diligent care for all resources including the business, the people involved, and the environment. Demonstrate personal integrity, honest and trustworthiness.

2. "Create a collaborative project team environment."

Encourage a collaborative environment where team members communicate effectively, and work together toward common goals. Example: Holding daily stand-up meetings in agile projects to discuss progress, challenges, and plans.

3. "Effectively engage with Stakeholders."

Involve stakeholders throughout the project lifecycle to ensure their needs and expectations are understood and addressed. Example: Regular meetings with clients and end-users to gather feedback and incorporate it into project plans.

4. "Focus on value."

Prioritize activities that contribute the most to achieving project objectives. Example: In software development, focusing on features that provide the most value to end-users rather than adding unnecessary functionalities.

5. "Recognize, evaluate, and respond to system interactions."

A SYSTEM is a group of interdependent components, that work together as one unit. The project is a system and it interacts with many other external systems. The Project manager should be responsive to system interactions, to maximize positive results. For example, the best implemented software applications provide API interfaces that allow other applications in the ecosystem to communicate and utilize them, resulting in much bigger and more useful applications.

6. "Demonstrate leadership behaviors."

Inspire and motivate team members, stakeholders, and other project participants to achieve project success. Example: Leading by example, demonstrating commitment to project goals, and providing guidance and support to team members throughout the project lifecycle.

7. "Tailor based on context."

Every project is unique, and so the success of any project is based on adapting to the unique settings of the project. Then we determine the best methods to get results. Another point to note is that tailoring is iterative process, and it should be continuously applied throughout the project.

8. "Build quality into processes and deliverables."

Focus on delivering products or services that meet or exceed stakeholders' quality expectations. Example: Implementing quality control measures in manufacturing to ensure products meet industry standards and customer requirements.

9. "Navigate complexity."

Complexity can creep into a project, because of human behavior, system behavior, ambiguity, or technical innovation or any other reasons. Project managers should navigate the complexity of a project and help build approaches and plans, to successfully execute the project lifecycle.   

10. "Optimize risk responses."

Identify, assess, and mitigate project risks on project objectives - this is what PMs typically do. BUT, we need to go even further, to MAXIMIZE positive impacts (i.e. opportunities), and MINIMIZE negative impacts (i.e. threats). Example: Developing a risk management plan that outlines potential risks in a construction project and identifies strategies to mitigate them. If we see new business trends, we should strategize to benefit from them. If we see threats in our building processes, we should decouple and replace them accordingly. This is what optimizing of risk responses is.

11. "Embrace adaptability and resiliency."

Be flexible and responsive to change, adapting plans as needed to address evolving project requirements. Example: Using iterative development in construction projects to accommodate changes in design or scope.

Anticipate and prepare for potential disruptions or challenges, building resilience into project plans and processes. Example: Developing a business continuity plan to ensure operations can continue in the event of a natural disaster or other crisis.

12. "Enable change to achieve the envisioned future state."

Projects are undertaken to create SOME sort of change - within products, or within some other objectives. And change is not always welcomed by the people affected. Some people may be inherently resistant to change or they may be risk averse.  The PM should prepare (& enable) those who are impacted, to transition to the new situations created by a project. 

So, these are the 12 principles of project management. You do not have to memorize these principles for the exam, but to deeply understand the intent behind them. And with that, I will end this lesson, and see you in the next!

We have something super interesting lined up for this lesson. We’re going to dive into the "Project Performance Domains" from the PMBOK® Guide – 7th Edition.

--

Now, before you roll your eyes and say “Not another PMBOK framework,” let me tell you, this one is a bit different and it gives you a powerful perspective. Over the years, I’ve learned that successful projects aren’t just about Gantt charts, and earned value formulas. They’re really about people, value, collaboration, adaptability… and that’s exactly what these performance domains capture. They are inter-related, interactive and also interdependent!

--

Each of these performance domains will be treated with great detail in this course going ahead, and you will see them in different projects, with tools, techniques, and pitfalls!

But for now, I’m going to walk you through each of these eight performance domains, not as some theoretical checklist, but from the eyes of someone who's been in the trenches. Are you ready? OK, let’s go.

--

What are Project Performance Domains? A quick definition first: what are these things?

--

According to PMI, a performance domain is “a group of related activities that are critical for the effective delivery of project outcomes.” In simple words, these are the areas you need to focus on to make a project work.

--

Think of it as a steering wheel for your project. These domains don’t tell you EXACTLY how to steer, that’s up to you, but they make sure you’re heading in the right direction. There are eight of them. And together, they shape the way we plan, execute, and deliver value through our projects.

Let’s go through them, one by one.

--

1. Stakeholder Performance Domain.

Stakeholders are our biggest allies, and sometimes… our biggest headaches! This performance domain is all about engaging the right people, at the right time, in the right way.

Here’s what I’ve personally learned: The moment you treat stakeholder management as a one-time activity, you’re in trouble. Stakeholder expectations shift. Their influence changes. And sometimes, a new stakeholder joins halfway through, and throws a wrench into your carefully crafted plan.

--

So the Stakeholder Domain is about:

- Identifying who stakeholders are

- Understanding what stakeholders care about

- Keeping stakeholders informed and engaged — not just in status reports, but in decisions

Real talk: I've heard of one project where a stakeholder nobody even know existed, showed up in the final week, and questioned everything. It really happens!

So map them. Analyze them. Engage them with empathy. And update that stakeholder register like your career depends on it — because, sometimes, it does.

--

2 Team Performance Domain.

Now we’re talking about 'your people'. Your crew. Your team. The Team Domain is all about how your team forms, collaborates, grows, and, let’s be honest, sometimes struggles.

You would have led teams that just clicked on Day 1, and others where it took weeks just to agree on a meeting schedule. But here’s the key: Culture and trust take effort.

This domain focuses on:

-Building shared understanding

-Creating a psychologically safe environment

-Fostering accountability and performance

And you know what else? Celebrating small wins matters. A team that laughs together 'delivers' together.

And here's my performance tip: Don’t just assign tasks. Build OWNERSHIP. Get your team involved in planning, retrospectives, and decisions. You will be amazed how problems shrink when the team owns the outcome.

--

Performance Domain #3: Development Approach, and Lifecycle.

Alright, this one sounds a little jargon-y, but stay with me. This domain is about how you go about delivering the project: your development methodology, and lifecycle.

So, what are you doing:

' Is it Agile sprints?

' or Waterfall?

' or Hybrid?

' or something totally tailored?

--

This performance domain urges you to pick the right approach 'based on the nature of the work, and the environment'. Are you building a mobile app MVP? Then Agile may be great. Or are you building a nuclear power plant? Then you’re gonna want predictive planning!!

--

This domain also touches on the phases, or cycles your project will go through: from initiation to closure. What matters here is consistency, and clarity. Everyone should know what stage you're in, what’s coming next, and how decisions are made along the way.

--

Performance Domain #4: is Planning.

Planning is the HEART of project management.

But PMBOK 7 reminds us: planning is not just about WBS charts, and baselines. It's about creating a roadmap to deliver VALUE. And it is always iterative. It is always Living. Breathing! When you take this perspective to planning, you are on the road to success.

--

The Planning Domain covers: Scope and requirements, Schedule, cost, and resources, Communications, risks, procurement, and stakeholders.

This domain emphasizes tailoring. Because let’s face it, you don’t need a 72-page risk plan for a 2-week internal dashboard project! You have to tailor your plans to your project situations.

Also, involve the team in planning. Planning 'with' them, not 'for' them is the secret, it increases accuracy and buy-in.

And please, plan for change. Things will shift, guaranteed! Your plan should be able to flex comfortably, without breaking.

--

Performance Domain #5, is Project Work.

And this is where the rubber meets the road. The Project Work Domain is about actually doing the work: managing the day-to-day work, resolving issues, and keeping everything moving.

It’s not glamorous. It’s not flashy. But it’s what keeps projects alive.

This domain includes: Coordinating resources, Managing physical and digital work environments, Handling deliverables, blockers, and issues, and at the same time ensuring quality and control.

As a PM, this is where your leadership shines. You’re removing roadblocks, keeping focus, managing scope creep, and keeping the team 'together', especially during crunch time.

What are your tools here? Stand-ups, dashboards, Kanban boards, issue logs, and… sometimes, just good old-fashioned walking around and asking people how they’re doing!

--

Performance Domain #6 is Delivery.

This domain is about what matters most: Are you delivering VALUE?

The Delivery Domain reminds us: It’s not enough to tick off tasks. You must deliver 'OUTCOMES' i.e. products, services,  and features, that solve real problems.

This performance domain emphasizes: Validating deliverables, managing the Acceptance criteria, Transitioning to operations, and Benefits realization.

You should always ask: “What does success look like to the customer?”. Not what it looks like to you. Not to your boss. But to the person who will 'use' the thing you are building.

When delivery is aligned with stakeholder expectations and business needs, that’s when projects feel meaningful. That’s when you get that satisfying “we nailed it” moment.

--

Performance Domain #7: Measurement.

Okay, this one is often misunderstood a lot. Measurement is not about making pretty charts. Rather, it is about making better decisions.

This performance domain includes: Setting performance thresholds and KPIs (i.e. Key Performance Indicators), Using data to track progress, and forecasting, analyzing trends, so that you can adjust as needed.

You’ve got several options to measure: earned value, burndown charts, velocity, performance reviews, and much more. But don’t measure just for the sake of it. Ask yourself:

- “What decision will this metric help me make?”

- “Who needs this data?”

- “How often does it matter?”

An important tip is that: Measurement helps tell the story of your project. So, make it transparent. Allow the data to build trust with your stakeholders.

--

Performance Domain #8: Uncertainty.

Uncertainty is the Project Manager's old friend. This domain recognizes a truth we all know: Things change! Assumptions get invalidated. Risks become issues. Surprise scope comes flying in from left field. And Stakeholders change.

So instead of pretending we can plan everything perfectly, PMBOK 7 tells us to embrace uncertainty.

--

This domain focuses on: Identifying and managing risks, Building adaptability into our plans, Creating contingency strategies, and Encouraging resilience in our teams.

The best PMs don’t eliminate uncertainty. But, they create systems that absorb uncertainty, and then respond to it.

Keep a risk register. Review it often. Encourage your team to speak up when things feel shaky. Uncertainty isn’t the enemy — but ignoring it is the enemy!

--

And now we come to the conclusion of this lesson: “Putting It All Together”.

So, let’s recap.

The 8 Performance Domains of PMBOK 7 are like the 'pillars' that hold up your project:

1. Stakeholders – Engage early, engage often.

2. Team – Foster collaboration, trust, and ownership.

3. Development Approach & Lifecycle – Tailor to how you deliver.

4. Planning – Plan often, and plan with flexibility.

5. Project Work – Keep the engine running, every day.

6. Delivery – Focus on outcomes, and business value. Nothing else.

7. Measurement – Let data guide decisions.

8. Uncertainty – Embrace change, and build resilience.

Unlike the older PMBOK editions which focused heavily on processes, PMBOK 7 is about principles and performance. It’s flexible, people-centered, and value-focused. And honestly? I find that refreshing.

Layer these performance domains into your thinking. They’ll help you tailor your approach, to lead with confidence, and to deliver projects that truly matter.

That’s all for this lesson! Hope you found it useful. In the next lesson, we’ll explore the landscape of PMBOK 6,7, and 8! Until then — keep delivering value, one sprint, one milestone, or one chaotic team sync at a time!

See you in the next lesson.

This lesson will be all about the "Project Management Body of Knowledge (PMBOK®) Guide". It will provide you the background context on the evolution of the PMBOK Guide, and its related practice guides. For the exam, you will NOT be tested on ANYTHING covered in this lesson. However, as a Project Professional, it is very important for you to understand the context of this supremely important publication. In this lesson, you should focus on understanding why the PMBOK exists, how it evolves, and how you can leverage it in practice.

What Is the PMBOK® Guide? The Project Management Body of Knowledge (PMBOK) Guide, is like an Encyclopedia. It is PMI’s flagship publication that codifies best practices, standard terminologies, and guidelines for project management. It is available free of cost to members, and at a small cost otherwise. This Guide represents a consolidated reference of processes, tools, and techniques, organized to help project professionals apply consistent methods and language, across industries.

While the PMBOK Guide itself is not a how-to manual for specific industries or methods, it serves as the foundational lexicon and framework that makes project management consistent, repeatable, and interoperable around the globe.

The PMBOK Guide is created through a rigorous, consensus-driven approach.

Step 1 is Global Participation: PMI calls upon thousands of volunteers: practitioners, academics, thought leaders, etc. to contribute their insights.

Step 2 is Iterative Drafting: Working groups draft new or revised chapters, then release exposure drafts for public comment.

Step 3 is Peer Review & Validation: Subject-matter experts critique, test, and refine content through surveys, workshops, and real-world feedback.

Step 4 is Final Approval & Publication: PMI’s Standards Committee reviews all inputs, ensures coherence, and authorizes publication under the PMI brand.

This painstakingly rigid approach, ensures the PMBOK Guide reflects emerging practices, global perspectives, and industry innovations.

The PMBOK is important because it provides both a foundation, and the scaffolding for Project Professionals. It provides:

1. Standardization: It gives organizations a common language, reducing miscommunication among global or cross-functional teams.

2. Professional Credibility: Citing PMBOK-aligned approaches demonstrates that you follow industry-recognized standards.

3. Foundation for Certifications: The PMP® exam and other PMI credentials are explicitly based on PMBOK content, ensuring exam relevance and career alignment.

4. Continuous Improvement: Evolving editions integrate new trends, Agile, hybrid methodologies, digital tools, so practitioners stay current.

In this slide, you can observe how the PMBOK Editions have evolved over the years, since it's inception. Feel free to pause the video, and read through it.

Observe the number of defined processes has risen over the years. The 6th Edition is generally considered the most comprehensive version. The 7th Edition was a seismic shift, and it is to be used IN CONJUNCTION with the previous version.

The 8th Edition is upcoming. As I record this lesson, it has been opened up for reviews, and it brings back the processes, and a small number of processes have been consolidated together. I will, be updating the course sections, as appropriate, to keep it up-to-date in the future.

1st Edition (1996): The inaugural edition introduced the concept of process groups (Initiating, Planning, Executing, Monitoring & Controlling, Closing) with 17 total processes. It served as a starting point for a common project management framework.

2nd Edition (2000): Building on the initial draft, this edition expanded to 39 processes, clarified process interactions, and better defined outputs. Organizations began adopting it as a standard reference.

3rd Edition (2004): Introduced 10 Knowledge Areas (Integration, Scope, Schedule, Cost, Quality, Human Resources, Communications, Risk, Procurement, Stakeholder) to group processes by topic, making it easier to navigate by domain.

4th Edition (2008): Streamlined content by consolidating redundant processes; refined terminology; improved diagrams. Strengthened guidance on tailoring processes to project size.

5th Edition (2013): Recognized the importance of stakeholders by adding “Stakeholder Management” as the 10th Knowledge Area. Updated guidance on procurement, risk, and communications.

6th Edition (2017): For the first time, Agile and Hybrid practices were explicitly woven into the guide. Also added two new processes (Manage Project Knowledge, Implement Risk Responses), and updated the Exam Content Outline alignment.

7th Edition (2021): A paradigm shift, moved from prescriptive processes to principles-based guidance. Introduces 12 project management principles (e.g., Stewardship, Systems Thinking, Tailoring) and 8 performance domains (e.g., Stakeholder, Team, Delivery). Focuses on value delivery systems rather than detailed ITTO lists. All of these have been covered in the course.

In addition to the PMBOK Guide, PMI publishes specialized Practice Guides that delve deeper into areas such as Agile, Business Analysis, Benefits Realization, and more. These include:

1. Agile Practice Guide: Co-developed with Agile Alliance, provides frameworks, mindsets, and practices for agile and hybrid projects.

2. Business Analysis Practice Guide: Bridges project management and business analysis disciplines.

3. Benefits Realization Management Practice Guide: is on maximizing project and program benefits.

4. Scheduling Practice Guide

5. Strategic Planning & Portfolio Management Guide: Covers aligning projects with organizational strategy.

These guides are complementary resources, offering deeper insights and practical examples for specific contexts.

There are some other relevant concepts to be mentioned in this slide.

ANSI and ISO Standards: PMI’s standards, including the PMBOK Guide, are accredited by ANSI and aligned with ISO 21500 (Guidance on Project Management).

Digital Content: PMI offers online supplements, webinars, and communities of practice that provide timely updates, case studies, and templates.

Tailoring Guidance: Later editions place increasing emphasis on tailoring, selecting which processes, tools, and techniques best fit your project's unique needs.

And now we come to the conclusion of this lesson.

The PMBOK Guide’s journey, from a simple collection of best practices to a modern, principle-centered guide, mirrors the evolution of project management itself. Understanding its editions and related practice guides gives you:

- Perspective on how PM standards have matured.

- Clarity on where to find guidance for specific challenges (Agile, construction, benefits realization, etc).

- Confidence that PMI continuously integrates feedback, and innovation into its standards.

Remember: You don’t need to memorize anything in this lesson for the PMP exam: either the publication dates or process counts, BUT being aware of this landscape helps you appreciate the breadth, depth, and evolution of the project management profession. See you in the next lesson!

Welcome to this new section of the course. From this lesson onwards, the course will become more exciting, and hands-on. We will be starting our 10 project case-studies from the very next lesson. Please pay special attention while I  explain the entire design of the project case-studies very briefly, starting now.

On your screen at this moment, is the comprehensive design for all the 10 projects that we will cover. You can see the 10 project case-studies listed in this column. These projects will cover the entire landscape of Project Management:

1. Initiating & Planning your Project

2. Planning & Integrating your Project

3. Setting up your Teams

4. Executing your Project

5. Managing your Teams

and finally 6. Closing the project in Flying Colours

We will cover a broad spectrum of business domains: Starting with Healthcare/IT, Construction/Infrastructure, Aerospace/Defense, Urban Planning, Financial Services (BFSI), GreenTech/Automotive, Disaster Relief, Construction/Digital, Civil, & Hardware/Software. We will cover LARGE Fortune 500 companies, medium sized companies, small startup companies, and also captive departments involved in R&D. Along the way, we will travel all across the globe, from India, Brazil, France, Japan, USA, UK, UAE, South Africa and Germany!

A very important point: The PMP exam will require you to be completely FLUENT with ALL different Project Management approaches, that are prevalent in the world today: so there will be 3 Predictive (Waterfall) projects, 2 Agile (SCRUM) projects, 2 Agile (Kanban) projects, and the last 3 will be the best of both worlds - Hybrid projects.

--

Please observe, in this column, I have listed the specific PMP ECO Tasks that our individual projects will cover. There are 2 points to understand here: The 1st point is that your PMP Exam will directly map to these tasks, so these are very important. The 2nd point is that we will visit MOST of these tasks twice: Once for Planning, and once more for Managing. That is just the way it is; if you have read through the tasks in the ECO, you will know the tasks encapsulate planning & managing.

--

As we move through the projects, we will NOT repeat the concepts learnt in previous lessons. So, this means, we will enter the projects in different points of time, progressively, in their lifecycle. Otherwise, this course would have been 10 times longer, and 10 times less interesting. The idea is to keep is to keep things crisp, and for you to discuss a new powerful technique every lesson :-)

--

And so now, we arrive at the 1st project of this course. This project will use a traditional Predictive (Waterfall) approach. We will enter the project at an initiation stage. Since predictive projects are top-heavy, this will be the largest project in the entire course. You will see a whole lot of planning documents.

Pack up your bags, tighten your seat-belts, and come with me on this Project Management journey!

WELCOME TO PROJECT ONE!!

In this lesson, I will introduce the first project of this course. The objective of the project is to modernize a large hospital, by implementing an Electronic Health Records (EHR) system. If you are not from the Healthcare industry (like me), I want to give you a brief heads-up on what the EHR systems are. These are fundamentally IT systems designed for hospitals and other institutions, which will enable patient information to be systematically stored and retrieved. EHR systems are very important as a framework on which several other healthcare IT systems (hardware & software) are built upon.

Imagine you are employed by the hospital, and your designation is - Director (Projects). You will NOT require any other domain specific knowledge for this project, don't worry.

Attached with this lesson, will be a text file called "Overview" of the project. Please download the file and read through it. I have it open on the screen now, and I will walk you through the project.

We will be covering 7 important ECO tasks in this project. [Remember the ECO stands for the PMP's Exam Content Outline]. EACH of these ECO tasks will be broken down into one-or-more of the 49 project processes. And then each of those processes will be resolved into very specific tools, techniques and artifacts.

All of this will demonstrate how you apply your PMP knowledge to real life project situations.

You should take some time and read through this entire overview text file. Consider it a very good practice for your reading comprehension skills.

There are 3 important points that I want to show you in this Project Overview file.

1st point: Notice that I have used a certain naming convention for the ECO tasks. For example, D3T2 refers to Domain 3, Task 2 in the ECO document. You can safely IGNORE this naming. But if you are a little extra diligent, you can use this naming to locate the task in the ECO :-) You have to remember the ECO doc is NOT mapped to real life application, so don't expect ECO tasks to be sequential.

2nd point: Notice I have bracketed certain phrases in the ECO tasks. The reason for this is - ECO follows a common format of "Plan & manage" something. For example, "Plan and Manage Scope". Now, at the early part of the project you are only PLANNING. When you get to later stages of the project, you will be doing the "MANAGE" aspects. So, we will revisit almost all of the ECO tasks twice, once for the PLANning and then later to MANAGE! I hope that wasn't too confusing. But, it will become very clear when we jump into the project in the next lesson onwards.

3rd point: I have expanded on each of the ECO tasks as applicable to our project, in the overview file. So that will give you a quick heads-up on what we will be covering in this project.

Okay, that about sums up this introduction. Please read through this overview file before we move to the next lesson, where we will address the first ECO task "Evaluate project benefits and value".

Since we are starting a new Healthcare domain project, let's start with a medical joke.

There is a lot of irony in this joke. The key point is that the doctor's stakeholders, would only care about the OUTCOME of the surgery, and ultimately not anything else.

Now here is the exact same point being made to the world of Project Management, where you and I belong. You might already be starting to get overwhelmed by the process groups, knowledge areas etc.

The point here is NOT that "processes are unimportant".

Consider this question: "Would you want to sit in an airplane, where the pilot doesn't follow all the processes?" No, right?

Rather, the point is, that OUTCOMES are more important than processes.

The Airlines industry follows a phenomenally complicated and efficient machinery of global processes 24*7*365, but the passenger is RIGHTFUL to be concerned about their outcomes - i.e. their destination, their time efficiency, their cost efficiency, safety, comfort, experience, convenience and so on. It is very important that we respect this.

Now, with this background understanding, we launch into our new, and first project.

-The very first ECO task, reads "Evaluate and deliver project BENEFITS and VALUE". Notice I have bracketed the words "(and deliver)" because at the beginning of the project, we will only do the "Evaluate" aspect of this directive. later during execution, we deliver the project value.

The question now is: "How do we apply this directive to our project?".

We will first INVESTIGATE that all the benefits are identified. How do we do this? There are good tools and techniques that PMBOK will recommend, as we will see in the next lesson.

By this time, a very big question will have surfaced in your mind. "Business VALUE is not a precise quantifier. How do I measure or deliver it?"

The answer is: This is NOT a problem. At this point of time, EVERY business domain in the world is investing billions into Artificial Intelligence, in exploratory projects. The benefits are NOT very clear, and the objective itself IS to IDENTIFY the benefits.

Coming back to our project on hand, your first responsibility will be to identify benefits & value, categorize them as quantifiable or not. 

The next step is to appropriately document the benefits and value, into an AGREEMENT. In most industries around the world, this agreement is commonly called the "Project Charter". There will usually be other business documents that will come earlier, but the Project Charter is where the business value will start taking shape and solidifying.

The Project Charter is also the document that authorizes the Project Manager's control of the project. In the next lesson, I will show a realistic Project Charter for our project. After the agreement is signed off, it will be your Numero Uno objective to deliver the VALUE of the project!

The next step is to put in place a mechanism to constantly verify that the project team is in place to track the benefits which are quantifiable in some way. There are several tools and techniques used to measure & track benefits. 'Earned Value Management (EVM)' is a famous technique used in traditional projects. Similarly, "Return on Investment (ROI)" is another universally used parameter. Agile projects use similar concepts such as Burndown, Velocity, Cycle time, etc.

The next question is "How do we DEMONSTRATE or prove the delivery of value, to our stakeholders?".

In our project, this might be in terms of Interim Demos and Prototypes of the EHR system, to demonstrate usability of the project. Both the functional and non-functional requirements are equally important when business values are to be verified. This work typically happens during the planning stages of your project.

The final step is to be continuously engaged with stakeholders, in VALUE PROGRESS through out the project. The key point is that we should try to avoid a "Big Bang" delivery that happens only at the end of the project. Rather, we should seek feedback, act upon it and be proactive in MAXIMIZING benefits & value.

Now we come to the end of this lesson. I have mentioned earlier that there has been a tectonic shift in the PMBOK, and the focus is now on OUTCOMES and not on process. That does not however negate the importance of project processes either in real life or in the exam. And the objective of this lesson was to establish the correct perspective in the very first lesson of the very first project. See you in the next lesson, where we will explore the Project Charter.

In this lesson, we start with the very FIRST project process that you will typically encounter on a project, called as "Develop Project Charter".

On the screen I have the 49 processes table showing up, and you can see that this process is in the intersection of the Initiating process group and the Integration Knowledge Area. This makes perfect sense as we are currently initiating our first project. The Integration knowledge Area is something that is completely owned by the Project Manager themselves.

This is the schematic diagram of the 'Develop Project Charter' process. Business Case document is the most common precursor (i.e input) for the Charter, with any other existing agreements. Most projectized organizations will own templates that can be used. EEFs and OPAs are common to all processes and we have discussed them earlier, so I will not keep mentioning them in the future lessons.

There are several recommended tools and techniques, 'Expert Judgment' being the significant one. Data gathering techniques are used, typically brainstorming, focus groups, and interviews. Interpersonal and team skills will be required, specifically conflict management (because there might be conflict of interest amongst stakeholders), facilitation and meetings.

Finally, there are 2 important outputs of this process, the Project Charter and the Assumption Log. Later in this section, we will examine each of these ITTOs in individual lessons. The best way to understand this process is by viewing a realistic Project Charter and we will do that next.

I have the Charter for our project on the screen now, and it will be attached with this lesson. Please download the 3-page PDF and read through it.

There are a few important points to note about this charter:

1. Notice that Project Objectives (i.e. the BENEFITS and value proposition) is literally the first dimension that is enumerated.

2. The benefits are then translated to 'Project SCOPE'.

3. Scope is then translated to specific Deliverables. In our case, these deliverables are quantifiable and not ambiguous.

4. The Project Sponsor, Project Manager and Project Team have all been identified, and sign-offs will be required.

5. TIMELINE (of 6 months) and BUDGET (USD 10 mil), have both been estimated! A technique called "Expert Judgment" has been used to make these estimations, and we will discuss this in the very next lesson.

6. Project Risks, Assumptions and Constraints, Change Management Process, Communication Plan, Project Closure are the Project Managerial aspects, that have been included, albeit at a very high level.

7. This Charter is neither too complex, nor too simplistic. And it covers all the major aspects to launch a project AND enter the Planning phase.

So what is the Project Charter? It is the FORMAL AUTHORIZATION of a project. The project comes into existence because of the Project Charter. It is a bridge between the "performing", and the "requesting" organizations. These can even be internal departments within an organization.

Who creates the Charter?

The Project Sponsor (i.e the person or entity who PAYS for the project owns the Charter), and it SHOULD BE created with the knowledge and expertise of the Project Manager. Unfortunately, this may not always be true and the PM only gets handed the Charter.

When is the Charter created?

The "Develop Project Charter" process should be considered as the start of the project.

Why is Project Charter so important?

Because of 3 important aspects: 1) A project Manager gets their authority to run the project from the Charter. 2) PM gets RESOURCES allocated through the charter. This can be money, material, machinery, people, time etc. 3) Charter is the bridge between the 'performer' & the 'requester' entities and it will be the reference point through out the life of the project and beyond.

I will end this lesson with a few final points. Not all organizations (or projects), will have clearly written Charters. Some projects may be launched with just an email, or even split across several documents. But if YOU as the Project Professional take the onus proactively of creating a well crafted Charter, then it is highly conducive to the project success, and eventually promotions, and all the other good stuff. In the next lesson, we will dig deeper into the technique of 'Expert Judgment', so I'll see you there.

In this SPECIAL lesson, we’ll unpack the true role of Integration Management; not as a set of processes, but as the project manager’s core responsibility to align everything, from start to finish.

In the vast world of project management, it’s easy to get lost in the countless processes, documents, and expectations. But amidst all the moving parts, there is one Knowledge Area that quietly sits at the very center of EVERYTHING: Project Integration Management. This is the domain that holds everything together. If project management were a symphony, Integration would be the conductor, ensuring all instruments play in harmony, stay in tempo, and deliver a coherent performance.

Integration is often misunderstood because its processes don’t produce shiny deliverables like Gantt charts, or risk registers. Instead, it weaves the entire project together, often behind the scenes. It’s the glue between the Knowledge Areas, and the invisible thread across all five Process Groups. Without strong integration, the entire project risks becoming a disjointed checklist.

At its core, Project Integration Management is about ownership. Specifically, the project manager’s ownership. According to PMBOK, this is a responsibility that cannot be delegated. It is the project manager who sees across silos, connects the dots, and ensures that the scope, schedule, cost, quality, resources, communications, risks, procurement, and stakeholders all align toward the same goal.

This alignment isn’t automatic. And that’s why Integration is so critical.

So, what exactly does this Knowledge Area cover?

At a big-picture level, Integration Management ensures that:

* The project stays focused on its goals

* All parts of the project move together coherently

* Changes are assessed holistically — not just in isolation

* Knowledge flows to the right people at the right time

* Final outputs and outcomes are handed off correctly and responsibly

The processes that fall under this KA include:

* Developing the Project Charter (Initiating)

* Developing the Project Management Plan (Planning)

* Directing and Managing Project Work (Executing)

* Managing Project Knowledge (Executing)

* Monitoring and Controlling Project Work (M&C)

* Performing Integrated Change Control (M&C)

* Closing the Project or Phase (Closing)

Every Process Group touches Integration. It’s the only Knowledge Area that spans all of them. This tells you something: it is never “done.” Integration is ongoing — a constant act of balance, reassessment, and coordination.

In predictive projects, Integration is centralized. The project manager owns the plan, directs the work, controls change requests, and coordinates closure. Integration is highly formal, document-driven, and dependent on upfront alignment.

But in Agile, Integration is distributed. The team self-organizes and continuously integrates functionality, feedback, and change. Product Owners and Scrum Masters take on integration roles. The sprint planning, reviews, and retrospectives are recurring points of integration.

Hybrid approaches fall in between. Integration may begin centrally, with charters and high-level roadmaps — but later shift toward Agile ceremonies for ongoing alignment.

Here’s a practical example: In our Hospital EHR project, the Integration effort was heavy upfront, chartering, stakeholder alignment, Project Management plan, procurement alignment. But in later phases (like training rollout or feedback loops), the team used Agile boards and daily huddles to integrate tasks and feedback in real time.

So while the Integration mindset is constant, its practices flex depending on delivery mode.

In real projects, Integration Management shows up in many subtle ways.

* The PM notices that the timeline is slipping because procurement took 2 weeks longer than expected. She pulls together the vendor manager, scheduler, and lead developer to realign deliverables.

* A key stakeholder changes priorities mid-project. The PM initiates a formal change request and consults with multiple teams to assess impact before approving the update.

* During closure, the PM ensures that open contracts are reconciled, lessons learned are documented, and support teams are prepped for handover.

These are not isolated acts — they are integrative moves. And they require active monitoring, communication, and judgment.

Tip: Most integration breakdowns happen in the gaps — between teams, tools, or process handoffs. Watch those seams carefully.

Pitfall: Project managers sometimes get lost in the weeds — managing schedules and documents — and forget to zoom out and ask, “Is this all coming together?”

Pro move: Build informal check-ins across disciplines. Integration doesn’t always require a meeting or memo. Sometimes, it’s a hallway conversation that reveals misalignment before it becomes damage.

Let’s say a project has detailed schedules, a strong risk register, and clear contracts. But no one is coordinating the pieces.

* The risk response delays procurement.

* The vendor arrives late, triggering schedule compression.

* The testing team misses critical bugs because change logs weren’t updated.

Everything was “managed,” but nothing was integrated.

Strong Integration avoids this domino effect. It’s not a layer on top, rather it’s the foundation underneath.

Project Integration Management doesn’t get much fanfare. It doesn’t produce fancy charts. But it’s the PM’s true craft. When done well, it makes the project feel smooth, aligned, and resilient. When ignored, everything starts to fray.

Whether you're building a skyscraper, rolling out new software, or responding to disaster relief, Integration is the discipline that turns fragmented efforts into a unified project journey.

In future lessons, we’ll dive into each process under Integration, from planning to change control to closure. But always remember this: YOU are the integrator. The one who makes the moving parts make sense all-together.

In this lesson, we explore one of the most misunderstood, and yet most critical topics in modern project management: TAILORING. It’s a term you’ll find everywhere, from PMBOK to real-world conversations, but it’s rarely unpacked properly. In this lesson, I will strip it down to its essence and show how to make it work for you, not against you.

We will explore how tailoring applies to 'Project Integration Management', the only Knowledge Area that no one else but the project manager can own. Integration is all about bringing everything together: scope, time, cost, risk, stakeholders, knowledge, and decisions. But depending on your project’s size, complexity, or constraints, how you manage this integration can, and SHOULD be tailored. I will do these exclusive tailoring lessons, for all the Knowledge Areas at different points in the course, so please look out for these important lessons.

Tailoring this Knowledge Area doesn’t mean doing less, it means doing only what adds VALUE. Let’s walk through the key tailoring dimensions to keep in mind.

The first big tailoring decision is: 'What kind of life cycle does this project need?'. A traditional predictive life cycle might be appropriate for regulated construction projects. On the other hand, an evolving AI product may need an Agile or Hybrid development life cycle. But there is more than just naming the model, you must define what phases make sense, where the gates are, and how rigorously to follow each stage.

Sometimes, tailoring means combining the project life cycle and the development life cycle, so you may be managing a predictive project schedule, but the product itself is being delivered through Agile sprints. If you don’t tailor well at this stage, you might find your planning rhythm completely out of sync with your delivery pace. That is a pitfall.

Once you’ve defined the life cycle, governance becomes your next tailoring focus. 'What kind of oversight is needed?'. A startup might have informal weekly catch-ups, while a government-funded project may require formal gate reviews, compliance audits, and approvals. Tailoring here prevents unnecessary bureaucracy on one hand, and dangerous under-sight on the other.

Change control also deserves tailoring. For high-risk, fixed-scope projects, you might need tight configuration management. But for dynamic environments, a lightweight change log with delegated approvals might do the trick. Integration management must ensure that the 'change process fits the pace and politics' of the project.

And finally, think about the broader 'management approach'. Should you use a centralized PMO-led structure, or a distributed leadership model? Your choice depends on team maturity, team location, and how team decisions are best made and implemented.

In many projects, 'knowledge flows in and out like water from a leaking pipe', unless it is captured, curated, and shared intentionally. Tailoring here means deciding how much emphasis to place on Knowledge Management. Will you maintain a real-time wiki? Will you use regular retrospectives? or Archive documents systematically?

The same applies to lessons learned. In some projects, lessons learned are just checkbox items at the end. In others, you may capture them after every major milestone, or failure. Tailoring this process ensures that knowledge isn't just gathered but it is also 'used', both within the project, and across the organization.

Tailored knowledge practices improve learning, and reduce reinvention. But they require active leadership from the project manager, not just a final report.

Integration Management also includes ensuring that 'benefits are realized, not just deliverables completed'. But how should these benefits be tracked, or reported?

You might tailor your benefits approach, based on who the sponsor is, what the delivery model looks like, or how long the project’s results take to show impact. In product releases, benefits might be tied to user adoption metrics; in public sector projects, to stakeholder satisfaction, or service coverage.

However, not all benefits are immediately measurable. Tailoring helps define 'when', and 'how' to track them. It may mean setting short-term indicators, or deferring benefits evaluation, to a program-level process. Without tailored benefits reporting, projects may appear successful on paper, but they may be irrelevant in practice.

So how do you make all of this work together? Integration is not a process you “perform”, it’s a discipline that you apply. The key is to create a tailored strategy that defines:

* Which processes are needed?

* How deeply each should be applied?

* What balance of planning and flexibility is appropriate?

* Who will coordinate and make the decisions?

The biggest pitfall is: 'Trying to apply every single tool from the PMBOK as-is', even when it doesn't serve the project. Tailoring gives you permission to be strategic! Cut what doesn't add value, and double-down where it matters most.

To wrap everything up: tailoring Integration Management is where the 'project manager’s judgment truly shines'. It’s not just about applying the framework, rather it’s about designing the way your project will work. There’s no "one-size-fits-all" template. There is no silver bullet. Every choice you make, from life cycle to change process to lessons learned, affects your team’s experience, your stakeholders’ engagement, and your project’s outcomes.

Integration is YOUR domain. Tailor it wisely.

In the previous lesson, I mentioned that Expert Judgment is one of the key techniques used in creation of a Project Charter, and in fact it is one of the most useful technique for a Project Manager. So, in this lesson, let's examine this technique called as "Expert Judgment". In the simplest of words, this just means seeking the advice of an unbiased EXPERT. In the context of our ongoing EHR Healthcare project, let's see how Expert Judgment was used to create a good quality Project Charter. This will give you a good understanding of the technique.

When we first started out to create the Project Charter, there were a lot of unknowns. We don't know the full benefits, the challenges, the cost, the timeline etc. we don't know much. So, to gain a deeper understanding of the EHR systems, four (4) initiatives were undertaken, all of which involved Subject Matter Experts (i.e. Expert Judgment):

1. The Project Sponsor, Dr. Sameer Gupta, used their professional network to seek advice from other International hospitals in the USA, Europe and also in Japan. These major hospitals had already implemented EHR systems, and were able to enumerate the BENEFITS accrued from their experiences. A lot of insight was gained regarding Privacy requirements, Safety standards, Product vendor choices, etc were easily received.

2. The Project Manager, Mr. Rajesh Kapoor identified the Top 2 EHR vendors. These vendors provided their PRE-SALES experts for consultation, and 10 different White Paper case-studies of previous implementations in the Middle East and Asia. This gave a lot of comparative knowledge, and hard numbers for us to evaluate.

3. An External Consultant (i.e. an IT Systems Solution Architect) was hired for 2 weeks by the CTO of the hospital, to make estimates on the Project Timeline and Budgetary requirements. This consultant provided insight on the Tech Stack, System Integration challenges, timelines and costs involved.

4. The Delhi State Government Liaison Officer was consulted for government subsidies, legal regulations and constraints.

Now, each of these 4 situations are examples of applying 'Expert Judgment'. In each of the 4 initiatives, people with special knowledge, or education, or training, skill or experience provides the expertise that we required. What did we get out of these initiatives? We received inputs on business strategy, benefits management, technical knowledge, time & budget estimation and risk identification. With all these fantastic inputs, the Project Charter took 4 weeks from start to completion, and all of these expertise was collated together.

I will end this lesson by mentioning that 'Expert Judgment' is THE most common and foundational technique recommended in the PMBOK. It will be used in many processes that the project manager will conduct. In the next lesson, we will discuss another basic technique called 'Brainstorming' used in the 'Develop Project Charter' process, see you there!

In this lesson, we explore the collaborative technique of Brainstorming and apply it to our "Electronic Health Records (EHR)" implementation project. Brainstorming technique is widely used to generate a broad range of ideas, or potential solutions in response to a specific problem or challenge. It typically unfolds in two parts: an energetic, creative phase of Idea Generation, followed by a thoughtful phase of Analysis. This activity is inherently group-based, and is often conducted under the guidance of a trained facilitator.

At its core, the effectiveness of brainstorming hinges on three foundational principles. First, participants are encouraged to speak freely and creatively, without fear of judgment or criticism. Second, quantity is valued over quality during the initial idea generation phase, with the goal of exploring as many perspectives as possible. And third, participants are prompted to build on each other's ideas, allowing for a dynamic interplay that often sparks innovation.

To better understand how brainstorming fits into the fabric of project management, let’s examine a case from our ongoing EHR implementation project. The hospital in question is aiming to enhance patient care, streamline its internal workflows, and modernize its record-keeping infrastructure. To move forward effectively, the project team decides to conduct a brainstorming session.

The planning begins with selecting the RIGHT participants. These include front-line healthcare workers, decision-makers, IT experts, administrative influencers, and stakeholders who are invested in the outcomes. Each one brings a unique perspective and area of expertise. Participants are notified in advance about the session and its intent—namely, to gather as many ideas as possible. Importantly, they are told that the goal at this stage is *not* to judge or evaluate ideas, but simply to contribute.

A facilitator is chosen to lead the session and ensure that the brainstorming remains productive and inclusive. As the session begins, the group is presented with three main challenges the project faces: resistance from medical staff who are used to paper-based systems; the complexity of integrating legacy systems with the new EHR platform; and the need to maintain strict data security while complying with regulatory mandates.

The objective of the session is to surface innovative solutions to these challenges, uncover untapped benefits of the EHR system, and foster cross-functional collaboration among team members and stakeholders.

The brainstorming process unfolds in three stages. First comes preparation. The team defines the session’s scope and objectives, chooses a diverse group of participants, and arranges a conducive physical environment: complete with whiteboards, flip charts, and open seating to encourage idea flow.

Next is the session itself. To break the ice and stimulate creative thinking, the facilitator may begin with a brief warm-up activity like a mind-mapping exercise. The key challenges are then presented clearly and concisely. Participants are encouraged to suggest ideas rapidly and without reservation, while the facilitator ensures that all voices are heard, possibly using techniques like round-robin input or silent brainstorming to engage quieter members.

Ideas are recorded visibly and without filters, often grouped by themes to help spot emerging patterns. The energy of the session is maintained through a mix of enthusiastic encouragement, and structured timing.

The final stage involves analyzing, and refining the ideas collected. The team revisits the full list, identifying common themes, novel solutions, and recurring patterns. Promising ideas are discussed in greater detail, and prioritized based on their relevance, feasibility, and likely impact on project goals. From here, selected ideas are developed into concrete action steps.

These action steps are formally integrated into the Project Charter, or the Project Plan, with responsibilities assigned to specific team members. The implementation of the ideas is continuously monitored. Feedback loops are established to ensure adaptability, and the success of the brainstorming session is evaluated both qualitatively, and quantitatively.

In summary, brainstorming is a powerful tool in any project manager’s armory, especially for complex undertakings like our EHR implementation. By championing openness, inclusivity, and creativity, it unlocks the collective intelligence of the team, and it drives collaboration forward. When structured effectively and followed through with disciplined execution, brainstorming sessions can yield innovative strategies, and practical solutions that significantly enhance project outcomes.

In this lesson, we will discuss a key foundational skill of any project professional - called 'Facilitation'.

In our ongoing Healthcare EHR project, facilitation was one of the key skills used, to create the Project Charter. We will discuss what facilitation is, why it should be learnt, and how it is practiced.

Meetings, committees and group events are universally hated. We consider meetings as distractions, and a waste of time. We make fun of committees and we don't value them.

Why is this? This situation exists because of POOR facilitation skills.

BUT, as project professionals, you and I understand the tremendous power of all group events. We can improve this situation by improving our facilitation skills.

So the million dollar question is: "What is Facilitation?"

The core of the word "Facilitation" is 'facile', meaning 'easy'. Making things easy, & simple.

PMBOK says: "Facilitation is the ability to effectively guide a group event to a successful decision, solution or conclusion."

And you might say: "Easier said than done". True. Facilitation is a skill that needs to be first learnt & then practiced.

In this lesson, I will give you reasons to improve your facilitation skills.

Now, I will quote something incredibly powerful from Mr. Jay Vogt, founder of Peoplesworth company, and an expert facilitator. 

"The way you design a meeting, shapes the behavior of the participants!"

If you design meetings for democratic values, collaboration, mutuality and exchange - then that is exactly what you get!

Else what will happen? you will get disagreement, conflict and hierarchy.

The key is with the meeting facilitator. The key is with YOU.

The art of Facilitation is in designing meetings that brings out the best in us.

People support what they help create. If your committee or group event wholeheartedly creates something, they will support it wholeheartedly. Thus ensuring the success of your project.

HOW should we facilitate? You can't learn to be an expert facilitator just from this lesson. Facilitation has to be practiced on the ground.

But I can tell where it all starts from. You have to create a SAFE ZONE, where people feel safe to communicate. You can create a safe zone, by establishing some basic ground rules.

Basic Ground Rules: <safe zone>

1. One person speaks at a time. Nobody can be allowed to dominate, or intimidate, or overrule others.

2. Speak up but speak briefly. Everybody is encouraged to contribute, but nobody should ramble on.

3. Establish roles in the meeting, like facilitator (that is the leader, you), Reporter (who takes notes), Timekeeper (so that nobody rambles on)

4. Everyone loves stories. Use storytelling to avoid conflict and to establish context.

5. You should aim for finding the common ground in any meeting. [We will discuss a tool called Affinity Diagram, later in this course]. We can't resolve all the issues in a meeting.

These are the most fundamental ground rules. These are the A-B-Cs. You can add a more ground rules, as per your project situation.

I hope this lesson gives you the inspiration to observe yourself, practice more, and constantly improve your facilitation skills. In a future lesson, we will cover 'Meeting Management', and in the next lesson we will explore the artifact called as "Assumption Log". See you there!

Imagine this situation: The ongoing Hospital EHR system project gets completed successfully. Three years pass, and you have moved on to bigger responsibilities. Your hospital gets audited by the Government. Auditors ask you the question: "Why did you choose costlier vendor in the market? There were other bidders to your RFP". How will you answer this question now? I will answer this question at the end of the lesson.

In this chapter, we discuss the artifact called Assumption Log. The Assumption Log is an artifact first created as an output of the "Develop Project Charter" process, and then it is referred to, throughout the project.

First, let us understand: 'What is an Assumption?'

An Assumption is any factor in the planning process that is considered to be true, or real, or certain, without proof or demonstration. Assumptions captures implicit requirements, thereby preventing expensive errors or rework. You DON'T KNOW assumptions to be true, but you ASSUME the factor to be TRUE, so that you can proceed with your work. Without making some educated guesses, you often can not proceed further.

Next question is: 'What is an Assumption Log?'

It is a log of all your assumptions, AND (IMPORTANTLY) your PROGRESS in confirming or testing those assumptions.

The life of the Assumption Log, starts at the very beginning of the project, right alongside the Project Charter, and it is alive throughout the project. Every assumption carries a RISK, because it can turn out to be FALSE. And that is the why, Assumption Log is closely related to the Risk Register (which we will study later).

Now let us look at a real life, well constructed Assumption Log for our ongoing project. Attached with this lesson, you will find an excel file, please download and refer to it.

It is important to keep the Log as simple as possible, so we are recording only the most meaningful narratives.

1. We have an unique ID for each assumption.

2. A CATEGORY to classify assumptions - Strategic, Operational, Financial, Scheduling, Functionality, NFR, technical, Vendor related and so on.

3. Date when it was first logged

4. A description of the assumption

5. A confidence level of the assumption - high, medium or low

6. The OWNER responsible to verify the assumption

7. The RATIONALE (or logic) why the assumption is made

8. The IMPACT of an assumption proven FALSE

9. And finally the current STATUS of the assumption - OPEN, or CLOSED

For even more complex projects, you might record even more data, like different action plans and so on.

So, now we can understand why it is important to log our assumptions.

The first reason, of course is that, without making some educated guesses, we just can not begin even simple projects. It is critical for good governance and transparency. Second reason, is when there is a change of personnel in the project, for example the PM is replaced, or if the expert consultant is run over by a bus, or any such situation, the Assumption log is INVALUABLE.

Now, let's return to the first question from the beginning of the lesson: Auditors are asking "Why did we choose the costlier vendor?"

To answer this question, you have to show the Auditors your Assumption Log. On Line #19, our Assumption calls for a COMPLETE regulatory compliance. All other vendors did not have a full regulatory compliance. Their solutions were not mature enough for us. The ONLY vendor with full compliance was expensive, but we still had to choose them. If we had chosen otherwise, today your company would have to pay a hefty fine. So that's the answer. The assumption log has become our superhero.

And with that I will end this question. In the next lesson, we will start a new ECO Task called "Engage Stakeholders", and it is going to be a lot of fun, so see you there.

Any and every project in the world, is eventually created FOR people, and BY people. Therefore, it is absolutely important for us to understand all the people who are influenced by our project in some way or other. The biggest mistake rookie project managers make is not understanding the people aspect of a project. And on the other hand, the biggest strength of expert project managers is to effectively ENGAGE ALL the people associated with a project.

Over the next 8 lessons or so, we will learn HOW to deeply engage the people associated with our ongoing Hospital Electronic Health Record (EHR) system project. Without this deep engagement, our project can not be successful.

The first question is "Who are Stakeholders?"

Look at this picture here, of a gentleman holding a steak? All of these (at the top), are NOT the 'steak-holders' we are talking about.

Stakeholders are individuals, or groups, or organizations, that may affect, or be affected by, (or even PERCEIVE to be affected by) a project. Stakeholders directly or indirectly influence a project, either a positively or negatively. Your OBJECTIVE will be to maximize the positive impact, and minimize the negative impact.

The next question we must explore is: "What is the impact of Stakeholders on a project?"

Each of these critical elements, can be positively or negatively impacted by stakeholders:

a. Scope: the full requirements needs to be revealed, what features need to be added, or modified, or removed.

b. Scheduling: positively by offering ideas to speed up delivery, or negatively slowing down or stopping delivery.

c. Cost: by helping to reduce planned expenses, or with restrictions that drive up costs.

d. Project Team: access to skills, knowledge, experience & positive culture.

e. Plans: by providing information for plans, or advocating for changes.

f. Outcomes: by enabling or blocking work necessary for desired outcomes.

g. Culture: Peter Drucker, the legendary management guru said "Culture eats strategy for breakfast".

Similarly, Benefits Realization, Risk, Quality, Success are also dependent on stakeholders. We will see all of these elements applied in later lessons.

Now we come to the most important question in this lesson: "HOW do we enage stakeholders?". This is, in fact an ECO task that we will address with a lot of detail, in the upcoming lessons. We will apply different tools and techniques to our ongoing EHR project, with the goal of generating the Stakeholder Engagement Plan.

On the screen now, is the 49 processes table:

Our next steps are to:

1. Identify Stakeholders

2. Plan Stakeholder Engagement

In the next lesson we will identify the key stakeholders for our EHR project, so see you there!

In this lesson, we will discuss the process called as 'Identify Stakeholders'. The primary result of executing this process, will be to create an artifact called as the "Stakeholder Register".

On the screen now, I am showing you the end result - we have identified the primary stakeholders for our Hospital EHR project. There are 10 different stakeholder domains identified. You can understand that this project has a very wide spread of stakeholders!

How did we manage to identify these stakeholder domains, and their key personnel? What do we do next, with these stakeholders? These are the questions that I will answer in the rest of the lesson.

On the screen now is the pictorial diagram of the 'Identify Stakeholders' process. You will immediately notice that there are a lot of inputs, tools, techniques and outputs. But, not to worry, I will simplify this. 

The first point to note is that - this process of identifying stakeholders is NOT a one-time process. Rather, it is likely to be executed throughout the lifetime of the project. Of course, it is done at the beginning of the project as we are doing now, but every time there is change in the requirements, or a change in the personnel, or a change in the regulations etc, this process is repeated. In short, stakeholders will keep changing, and their 'stake' in the project will also change.

The primary inputs to identify stakeholders are the Project Charter, and other business documents. From there we identify the project sponsor, and all other TOP Level stakeholders.

PLEASE NOTE: When we execute this process for the first time, the Stakeholder Engagement Plan will not have been created yet. But still this diagram shows it as an input. How is this possible?? This is because the process can be executed at any point in the project lifetime. You will notice this strange (but perfectly logical) aspect in many of the other processes, so DO NOT be confused by this in the future lessons.

Notice that we have artifacts like the 'Change Log', 'Issue Log' etc as inputs. Again, this is for the same reason. We will study these artifacts later in the course.

Within the 'Tools & Techniques', we have the common ones like Expert Judgment, Brainstorming, & Meetings. But the techniques SPECIAL to this process is "Stakeholder Analysis" and "Stakeholder mapping/representation". I will explain both of these in individual lessons coming right next.

These techniques will help us understand what is the BEST way to engage with our stakeholders. Of course, we don't want to treat all stakeholders in the same way. They will all have different requirements from the project.

The PRIMARY output of this process is the Stakeholder Register. In it's simplest form, this is just a listing of the stakeholders. Any changes to the stakeholders will result in changes to other project artifacts like our communications plan, engagement plan and so on.

And with that, I will conclude this lesson. In the next lesson, we will look deeper into the 'Stakeholder Analysis' technique which results in the listing of stakeholders. So see you there.

In this lesson, I will discuss a special technique called as 'Stakeholder Analysis'. This technique will answer the question I asked in the previous lesson: "How did we identify these stakeholders?". The goal is to create a list of stakeholders, and relevant information such as their position in the organization, roles on the project, their "stakes", expectations, attitudes (i.e. their level of support for the project), and their interest in the information about the project. So, the technique is really to understand the "stake"!

You can consider 5 simple criteria for Identifying Stakeholders:

1. Interest: Find out which individuals and groups will be affected by the decisions or outcomes of the project.

2. Rights & Regulations: Identify all laws and regulations (legal OR moral rights), that will impact the project including privacy issues, ethical issues, environmental sustainability, etc.

3. Ownership: Determine who OWNs important infrastructure of the project, including software, hardware, machinery, web domains, brick & mortar offices, or intellectual property. For example, in our project, the EHR licenses have to be purchased from a vendor.

4. Knowledge: Identify who has the expertise, knowledge, skills or political connections required. Also includes identifying the flag-bearers of your project (people who are advocating your cause, or acting as a buffer for you).

5. Contribution: Determine who provides the necessary capital and human resources, decision-making authority to the project.

These 5 criteria can be your PRIMARY investigation tools to build the stakeholder register and I hope that was helpful to you. In different projects, you might add more criteria, or remove some. As I said before this is just the starting point, and we need to analyze our stakeholders even more because this is a complex project.

In the next lesson, we will discuss several tools used for 'Stakeholder mapping & representation'. So, see you there!

In the previous lessons, we have learned how to identify all the stakeholders for our project. Once we have reasonably identified our stakeholders, the next step will be to get a deep understanding of them. Without this deep understanding of our stakeholders, we will not know how to serve THEIR interests best, and neither can THEY help our project effectively.

There are several analysis tools for stakeholders. In this important lesson, we will learn THREE simple and most powerful MAPPING tools,(which are mentioned in the PMP ECO document. The 1st tool is called the Power-Interest Grid, 2nd is Influence analysis and the 3rd is Impact analysis. We will apply all three tools to our ongoing Hospital EHR project.

The 1st and foremost mapping tool is called Power-Interest grid. Here you essentially map all the stakeholders according to the power they wield, and their interest in the success of our project.

This will result in a 4-quadrant grid. And stakeholders can be mapped to each quadrant. How you will ENGAGE with each quadrant will be different. 

1. Stakeholders with High power and High Interest - Regularly Engage. These stakeholders are THE decision makers, and have the biggest impact on the project success and hence you must engage closely. E.g. Hospital Executive Leadership, Clinical Staff.

2. Stakeholders with High power and Low Interest - Actively Consult. E.g. EHR Implementation Vendor, Regulatory Authorities. These stakeholders need to be kept in the loop, and need to be kept satisfied even though they aren’t highly interested, BECAUSE they wield power. They should be dealt with cautiously as well, since they may use their power to harmful effect if they become unsatisfied.

3. Stakeholders with Low power and High Interest. E.g. Patients and Advocacy Groups. Keep these stakeholders adequately informed (on important milestones), and talk to them to ensure that no major issues are arising. These people can often be very helpful with the project requirements.

4. Stakeholders with Low power and Low Interest - Keep Informed. E.g. Media partners, public relations vendors etc. Monitor these people, but do not bore them with excessive information or communication.

This Power-Interest grid is super-important, and forms the basis for the other two tools coming up.

The next tool is called the 'Influence Analysis'. It is a straight-forward investigation of the INFLUENCE of each stakeholder. This influence can be because of different reasons: their corporate position, or their special experience and knowledge, their political connections, or their control of the resources that you require for your project.

This table is pretty self-explanatory, and you should pause and go through the table.

The final tool in this lesson is called the 'Impact Analysis'. Here we map the stakeholder's impact on the various aspects of the PROJECT SOLUTION that we are executing. For example, to ensure that there is a successful integration of our project with the external participants like labs and clinics, the engagement with Healthcare Industry Partners should be specifically designed.

So again, in a way, this analysis is an extension of the other two preceding tools.

In conclusion, when all three tools are put together, we will be able to formulate a robust & meaningful Stakeholder Register. This is what we will see in the next lesson, so I will see you there.

In this lesson, we discuss one of the most fundamental artifacts of Project Management - the Stakeholder Register. This is a living document, meaning that it GROWS through the lifetime of a project, and it also needs to be PRUNED from time to time.

At the beginning, we will not have enough information to complete the stakeholder register. but, that's OK. As the project gets underway we gain additional information and better understanding about each stakeholder’s requirements,

expectations, classifications and the stakeholder register will come to life.

This document is used by other artifacts, such as the Requirements documentation, Quality management plan, Communications management plan, Risk management plan, Risk register, and importantly the 'Stakeholder engagement plan'.

Please go through all the columns in this table, all of them have been explained in the preceding lessons. The key point that you have to note is: You should TAILOR this template (and all others), as per your project situations. I will give some examples of how you can tailor this document.

1st example: In the case of smaller projects, you might probably skip a lot of these columns such as power-interest grid.

2nd example: In the case of internal projects, you might skip the position, role, contact info, etc.

3rd example for tailoring: You might need completely new columns, in the case of purely exploratory projects.

The point is that you should feel free to own this document, and tailor as you please.

Now that we have a deep understanding of our stakeholders, we should use this to our advantage. We should talk to our stakeholders, and figure out their needs. Then we should proceed to deliver the goods, all the time making sure that the stakeholders continue to be engaged with us. This will not happen by magic. As project managers, we should create a PLAN to engage our stakeholders (armed with all this stakeholder information). In the next couple of lessons, we will proceed to do exactly that. So, I will see you there.

As I have mentioned earlier, projects are run BY the people, and they are FOR the people associated. In short, stakeholders are the critical to your project. So far in the course, we have seen extensively how to IDENTIFY and ANALYZE stakeholders. Now, it is time to ENGAGE with them.

What is the meaning of "ENGAGE with stakeholders?", you might ask. It is the process of INVOLVING stakeholders in the project according to their needs, expectations, interests, and potential impact on the project.

On your screen now is the schematic diagram that represents the engagement planning process. The 1st version is developed early in the project immediately after identifying stakeholders, and then updated regularly as the stakeholder community changes.

Here is a quick view of this process in the '49 process table'.

Typically, we should evaluate & revise the engagement plan, during trigger points such as the start of a new project phase, or if there organizational changes, or industry changes, when new stakeholders join the project, or when you deliver some results, etc.

Now, let's study this process. The most important INPUT to this process is the 'STAKEHOLDER REGISTER', as you would have expected. We saw in the previous lessons that it can hold a wealth of information that is helpful for us to engage effectively with our stakeholders.

WHENEVER there are changes to our assumptions, or changes to the requirements, or some issue materializes, or some new risk comes up, we should also check if it triggers changes to the stakeholder engagement. That's the reason that we have so many project documents as inputs to this process.

The significant & SPECIAL tool for this process is the 'STAKEHOLDER ENGAGEMENT MATRIX'. We will study it in detail in the next lesson. This tool helps us evaluate the current engagement level of a stakeholder and act upon it. There are some of the techniques we have studied earlier such as Expert Judgment, & Benchmarking. Others we will study later.

This process has a single output called as the 'Stakeholder Engagement Plan', and shortly I will show this plan as applied to our ongoing Hospital EHR project.

In conclusion, I want to mention that building an engagement plan, is the bridge between the science and art of project management. Throughout the lifecycle of a complex project, the relative importance of stakeholders changes, and this process gives you the practical techniques to navigate the stakeholder changes. So, I will see you in the next lesson.

In this lesson, we will discuss a powerful tool called as the 'Stakeholder Engagement Assessment Matrix'. This tool helps us analyze the CURRENT engagement level of stakeholders, versus the DESIRED level of engagement.

On the screen, you can see the Matrix being used for our ongoing Hospital EHR project. Every (relevant) stakeholder, is measured on a scale of 5-levels of engagement.

1. The 1st level is UNAWARE: which implies the stakeholder doesn't know much about the project, it's potential value, and their impact on the project.

2nd level is RESISTANT: This is a dangerous state. The stakeholder is aware of the project, but they are resistant to the changes that will ensue because of the project. They are UNSUPPORTIVE of your work, and project outcomes. The reason can be anything.

3rd level is NEUTRAL: these stakeholders are aware of the project, but neither supportive nor obstructive.

4th level is SUPPORTIVE: they are aware of the project, welcoming of the work involved, and project outcomes.

5th level is LEADING: these stakeholders are aware of the project and it's impacts, and they are actively engaged in making sure the project is successful. This is the best state for your stakeholders to be at.

In this matrix, the letter 'C' stands for 'CURRENT STATE', and 'D' stands for 'DESIRED state'.

There are a couple of problems with this tool that you should be aware of:

1. Often the information in this Matrix is confidential, and SENSITIVE. For instance, you don't want any stakeholder to know that they have been identified as Resistant. However, that is the nature of the beast, and you will find yourself working with hostile stakeholders. And these classifications are prescribed by PMI themselves, so this is common enough situation.

The challenge is in keeping this assessment confidential, and protecting access to it. That will be up to you! A common trick is to use a less offensive word, other than 'RESISTANT', just for safety.

2.  The second challenge is that we assume the Project Manager is capable of making this assessment. That is, they should have the emotional intelligence, social, political and communication skills to be able to get a true reading. A common remedy is for the top drivers (PM and their boss), to make this assessment together.

3. The 3rd challenge is that the PM might not have access to all the stakeholders to make a comprehensive assessment.

Now that we have made a comprehensive assessment of the stakeholders engagement, what do we do with this? How do we drive the engagement levels UP? How do we solve the problems with resistant stakeholders? I will answer these questions in the next lesson, where we will examine the Stakeholder Engagement Plan. So, see you there!

Now finally, we have come to the important lesson on Stakeholder Engagement Plan. We first started this journey, with the Stakeholder Register which used a 5-point criteria to identify stakeholders. Then we used the Power-Interest mapping technique to analyze influence areas, impact areas etc. In the next stage we gauged the desired and current levels of engagement of the key stakeholders.

And with ALL this information brought together, we are now ready to formulate an Engagement Plan. What does this plan do? This plan describes the strategies and actions, that we will use to promote a PRODUCTIVE INVOLVEMENT of stakeholders. This plan is super important because this will help you get your resources (i.e. your money, material, machinery, time, people, etc), this will help in your decision making at critical junctions, and finally in executing your project successfully.

So, what is the strategy? To explain the strategy, let's look at the assessment matrix once again.

1. You don't want ANYBODY in the 1st two levels of engagement - i.e. Unaware or Resistant! That is, EVERY stakeholder should be aware of the project, and you don't want anybody to be resistant to the project. Any stakeholder in these two levels is a RED flag! So we have act on everyone in these two levels, immediately.

2. First goal is to get every stakeholder at a MINIMUM of NEUTRAL level, and then ideally move them to SUPPORTIVE or higher levels.

3. Second goal is to get KEY stakeholders into LEADING roles.

4. The third goal is to ensure we keep engaging with stakeholders periodically, so that no one slips down on the levels.

So, this is a simple but effective strategy that can be used on any project. You can see that we have SPECIFIC action described for individual key stakeholders, that addresses their own specific pain points. And that is very important to maximize involvement, rather than cookie-cutter solutions.

In conclusion, I want to say that this is a living document. That means we have to continuously engage with our stakeholders, typically at every milestone of the project. Remember that this is a confidential, internal document and it becomes a part of the Project Management Plan. Next up, we are going focus to Scope and Requirements and we will be starting a new section, on the same ongoing EHR project. So, see you in the next section!

We are starting a new section of the course now, which will focus of the PMP ECO task called as 'Plan and manage scope'. You can locate it in the Domain 2, Task 8 on the ECO document.

This ECO task is mapped to 4 project management processes on our table. Please notice that the processes marked Green are already completed in earlier lessons, and our focus will be on this cell shaded yellow. We will be looking at 4 foundational processes which is normally executed one-by-one: we first Plan Scope Management, then we Collect requirements (within which I will discuss EIGHT different powerful tools & techniques used to collect requirements), then we define scope, and finally create the supremely important WBS (which stands for Work Breakdown Structure).

There are many important points to note about the WBS. Including the fact that it is a misnomer. The WBS is one of the most important artifacts that the Project Manager personally creates and owns, because it will drive the schedule of the project. The concept of the WBS has changed over the previous decades and I will give some 'golden rules' to get it right.

All of these tools, techniques and artifacts, we will apply to our ongoing Hospital EHR project, so you will see them applied in real-life situations. So, I hope this gets you excited about the upcoming sections. In the next lesson, we will jump into scope management with the process called 'Plan Scope Management'. So, see you there!

Before we jump into this lesson, I want to ask you a question. One common ISSUE is creating a problem in 3 different examples, here on this screen.

1st example: A never ending project - every few days, the customer adds new features, changes old specifications, and delivery is delayed by 1 year.

2nd example: A project has been up & running for 1 month, but the team doesn't YET have a common objective, and nobody seems to know exactly what has to be delivered.

3rd example: Customer is furious because they are unhappy with a delivery that arrived after 6 months, and now they refuse to accept it. 

What could be the common factor in all these 3 cases? The answer, as you would have already guessed by now is: Improper Scope Management! Let's understand this better now, and make sure that these issues don't happen with our EHR project.

To understand Scope Management, we must first begin at the PRODUCT level. What is the Product Scope? The Product scope details out the FINAL product, i.e. all the features, the components, bells & whistles that make up the final product, or service, or outcome.

And "what is the PROJECT scope?" All the WORK that needs to be done to deliver the product, is the Project Scope. This includes all your Project Management work, and the ALL work that your team does, which may not show directly on the product itself, for example IT stuff, integration work, quality management etc.

You have heard of the term 'Scope Creep'. What is this? This is a dangerous situation, caused by uncontrolled changes to the scope of a project. In this situation, the constraints of time, cost, quality, risk, resource etc are impacted. A tight scope management plan will help CONTROL this situation.

For your PMP exam, you should clearly understand Product scope, Project scope and Scope creep. We will discuss these more over the next dozen lessons.

Okay, so  we finally arrive to the meat of this lesson - the project management process called 'Plan Scope Management'. The objective is to create a plan to manage scope, and another plan to manage requirements. Remember, 'REQUIREMENTS' are the detailing & expansion of scope. We will document HOW the project & product scope will be defined, validated & controlled. The goal is to PREVENT & AVOID issues like Scope Creep, and other issues I mentioned at the beginning of the lesson.

This is the FIRST process executed in Planning phase, in a traditional Waterfall development. That is the significance of this process. And it can be repeated if mandated by company quality standards, or if you have multiple iterations in project delivery, or any such situations.

The Project Charter is the KEY INPUT to this process. Almost always, you will be inheriting a template from your Organization's process assets.

The tools & techniques used are Expert judgment, Alternatives analysis which we will study later in a different case study, & as you can expect, lots of meetings.

The output is a Scope Management Plan, and a Requirements Management Plan. We will study these artifacts in great detail in the next couple of lessons. You will find a lot interesting aspects in them, so I will see you there!

In this lesson, we will discuss a foundational artifact called as the Scope Management Plan. I will show you an excellent hands-on plan in this lesson. But, before we do that, I will spend a couple of minutes in orienting you in our ongoing Hospital EHR project.

As soon as we sign-off the Project Charter, & start work on elaborating the scope of the project, we are officially into the Planning phase. Now the BIG OBJECTIVE of the planning phase, is to create the 'Project Management Plan'.

Project Management Plan is NOT a single document, but it is made up of about 18 other components. It is a COMPLETE roadmap to the entire project, and it is created and owned by you the Project Professional. Let's take a moment to observe & understand the Project Management Plan.

Notice the FIRST 2 components are the 'Scope Management Plan' & the 'Requirements Management Plan'. BOTH these artifacts are the OUTPUT of the 'Plan Scope Management', which we discussed in just the previous lesson. And they are the FIRST thing we start with when we enter the planning phase, for obvious reasons. Without truly understanding the scope and the requirements, we can not do anything else!

Now, let's dig a little deeper. Notice the NEXT artifact is 'Schedule Management Plan' -- and that is the output of this process - 'Plan Schedule Management'. So, now, I think you get the drift. Every one of the plans is an outcome of a corresponding process in the planning phase.

Or rather, put another way, the process 'Plan Cost Management', generates the 'Cost Management Plan', and so on. And FINALLY, when all the component plans are generated, they are all INTEGRATED into the grand old 'Project Management Plan'. And that happens in this master process called 'Develop Project Management Plan'.

I hope this discussion has given you some insights into how the process table works, and how everything fits in logically. If you want, please re-play this lesson, and make sure you grok this concept really well, as it will make everything else really easy going ahead.

OK, with this understanding under our belt, now let's get back to our topic of Scope Management.

The first question we want to answer is: 'WHAT is Scope Management?'. Scope Management means ensuring that the project INCLUDES all the REQUIRED tasks, and at the same time EXCLUDES everything that is not required. What is 'required' is called 'in-scope', and everything else is called 'out-of-scope'.

The next question is 'How do we do scope management'?

Scope management is performed in 5 steps:

1. Collect Requirements - elicit what product or service or outcomes the stakeholders want. 2. Define Scope - describe the project deliverables, assumptions, constraints, functional & non-functional features. 3. Create WBS (Work Breakdown Structure) - break down the project deliverables into smaller, manageable components for the project team. 4. Validate Scope - i.e. verify from the customer, that they received what they wanted. 5. Control Scope - monitor that only the requirements are being created, and also handle any changes to the scope.

Now, we come to the most important part of this lesson - the Scope Management Plan describes HOW we will perform ALL these 5 processes together! As promised at the beginning of the lesson, I will show the finished Scope Management Plan document for our Hospital EHR project next. You should find the file attached with this lesson.

Please go through this document with some detail. This is how the plan will look AFTER the 5 different scope processes have been completed, so it has all the data, like the Scope definition and scope statement, acceptance criteria, risk assessment, deliverables and exclusions. Please pay special attention to the WBS, as it will feed to ALL the following phases of the project.

Now, a very big question will be troubling you: 'How did all this get created?'. This question will be answered in the following individual lessons, we will address each and every aspect of this plan, including a more detailed WBS creation. But before that, we have to see the 'Requirements Management Plan', which is a sibling of this scope plan. And we will do that in the next lesson, so see you there!

In the previous lesson, we discussed the super important artifact Scope Management Plan, and in this lesson, we will discuss it's younger sibling called as the Requirements Management Plan. You can download the document attached with this lesson. 

So, what exactly is the Requirements Management Plan? Simply put, it is a document that describes HOW we will capture the requirements for a project. It is created by the Project Manager, and as you already know, it is created in the 'Plan Scope Management' process. It is important to note that the Requirements Management Plan DOES NOT hold the actual requirements of a project, but only the guidelines to manage requirements. (The ACTUAL requirements are captured in the Requirements Documentation artifact).

For smaller projects, you will NOT even need a separate document for this, and everything can be clubbed within the Scope Management Plan. But for larger projects we need the Requirements Management Plan, for 2 specific reasons:

1st reason: To document the PLANNING activities such as data gathering, data analysis, prioritization of requirements, product metrics, and defining traceability of requirements.

2nd reason: To document MANAGING activities like configuration management, tracking, reporting, tracing, testing & validating, and so on.

You will find all these aspects, in the attached document for our ongoing Hospital EHR project. Please read through it once. Just remember you have as much flexibility as you want when you create this artifact.

I will conclude this lesson, with some tips for tailoring this artifact:

1st tailoring point: Don't create this doc for smaller projects, it will be an overkill. Just merge any specific points within the Scope Management Plan.

2nd tailoring point: If your project involves Business Analysis, then you must capture it's interaction with project management here in this doc. For example, workflow improvements, cost benefit analysis how these will be measured and tracked.

3rd tailoring point: For smaller projects, if you DO create the Requirements Management Plan, then you can merge testing strategy or test plan here. The goal is to keep documentation as tight as possible. Larger projects will, of course, need separate Test Plans.

4th tailoring point: In AGILE or related adaptive development models, you can document how the Backlog will be used to manage requirements.

And with that I will conclude this lesson. We will now move on to the big big task of collecting requirements. There are lots of interesting tools & techniques coming up which you will enjoy learning! So see you in the next lesson.

In this lesson, we explore the project management process called as 'Collect Requirements'. This is a heavy-duty, industrial grade process because it will typically involve a lot of work, a lot of people, and a lot of tools & techniques. If you get this process right, then you greatly improve your chance of success, but if you get it very wrong, failure is guaranteed.

A couple of lessons back, I showed the Scope Management Plan for our Hospital EHR project. But then, I did not tell you how this was created. Well, it is by collecting requirements from stakeholders, that we create the Scope, and also the detailed requirements.

The next 10 lessons will be dedicated to Requirements management, and I will discuss 8 different tools and 2 artifacts. If you practice these well, you will be loved by all your stakeholders, both internal & external :-)

Okay, now let's look at the 'Collect Requirements' process. As can be expected, we collect requirements once at the beginning of the project, AND whenever some new features are added, or modified.

The key inputs to this process are the Project Charter, Stakeholder Register, Business case, and the Engagement plan. Any of the other project documents might also be inputs at later stages like the Project Management Plan.

There are a lot of recommended Tools & Techniques for this process because the Project Manager has to ELICIT (i.e. extract, derive, deduce) requirements, and foster co-operation from all the stakeholders. Some of these tools are obvious, and we have studied earlier like 'Expert Judgment' and 'Brainstorming'.

The SPECIAL tools & techniques for this process are: Data Gathering techniques using  Interviews, Focus Groups, Questionnaires & surveys. Document Analysis. Visual tools like Affinity diagrams, team skills like 'Nominal group' technique. There are also some other tools like COntext Diagram, and Prototypes which are very useful for this process.

There are two important outputs - first, the Requirements DOcumentation, which is the central repository of all requirements. Second output is the Requirements Traceability Matrix artifact, which traces the life journey of every piece of requirement, from being elicited by the stakeholder, all the way through design, development, testing and into production. We will of course study both these outputs in individual lessons in a short while.

I will now conclude this lesson, by saying that 'Collect Requirements' is a critical process, and you should aim to continuously improve your skills for this process, no matter how good you currently are. Stakeholder's engagement, enthusiasm and co-operation are most important factors for this process. In the next series of lessons, we will address the different skills and artifacts. So, I will see you there!

In this lesson, we will discuss a special meeting technique called as 'Focus Groups'. This technique is specially useful to collect requirements from stakeholders. In this technique we group together pre-qualified attendees (who typically are subject matter experts), and the goal is to learn about their expectations & their attitudes for a proposed approach/solution.

The entire exercise needs a trained moderator, to conduct the group meeting. It will be conducted like an interactive discussion i.e. with questions being asked, and responses being sought from every attendee, but the complete exercise is kept as informal as possible, and conversational.

Let's see an example of focus groups as applied to our ongoing Hospital EHR Project.  A focus group was created to gather detailed requirements related to EHR functionalities, workflows, and user preferences. The intention was to gather early feedback, and eventually create a Steering Committee from this focus group.

Let's map the salient features of focus groups, to our project:

1st step: Pre-qualified attendees, & subject matter experts: The pre-qualification to be a member of this group was - 'previous hands-on experience with Hospital EHR systems'. With the help of HR department, personnel from every department were identified who had previous EHR experience in their past work life. When all the logistics were worked out within their departments, a tight team (with broad spectrum experience) was identified. Doctors, clinical staff, IT experts, and administrative personnel were the key representatives on this group.

2nd step: A Trained moderator: A consultant specializing in corporate communications was hired for the entire exercise. Their responsibility included setting up the team, conducting the day-long meeting, and finally publishing insights to the senior management.

3rd step: The moderator prepared an agenda for the meeting. There were two goals

A. The basic expectations of an EHR system was sought: usability, functionality, accessibility, device compatibility, performance etc.,

B. The attitudes to the proposed technology stack, any privacy concerns, any workflow concerns, general corporate politics etc.,

The plan was to have a structure to the meeting, but the flow should be democratic, relaxed, & conversational.

Standard Meeting etiquette like venue, date, time, meeting agenda was published. The Focus Group continued discussions through several follow-up meetings, connected on a specially created WhatsApp group. Eventually, the focus group renamed itself as the Steering Committee, and helped in arriving to key decisions through-out the project.

So, in this lesson, we have learnt the salient features of Focus Groups and the benefits they deliver. If you are interested more in this topic, I suggest you explore moderating meetings in general, and focus groups in particular. In the next lesson, we will discuss Interviewing techniques for collecting requirements, so see you there.

In this lesson, we discuss a very popular data gathering technique known as the 'Interview'. You have probably watched hundreds of interviews in your life previously. And there would have been instances where you would have appreciated the skills of the interviewer.

An interview is when you talk directly with a stakeholder, typically one-on-one, but it can be in any combination of participants. It can be conducted in a formal setting with prepared questions, or informally with spontaneous questions. The person who conducts the interview is called the interviewer and the person being questioned is called the interviewee.

Interviewing subject matter experts, sponsors, and other executives, can help in identifying and defining the features and functions of the desired project deliverables. Interviews are also extremely important in extracting confidential information.

Conducting effective interviews is a SKILL that has to be practiced, and can be perfected. I will now mention some points, that will be helpful in conducting stakeholder interviews, specifically for collecting requirements:

1. Start slow: You will have to build a rapport with the interviewee first, so take SOME time asking safe questions that will help you understand the person better, and their background. Be respectful of their time though, and let them know that. You may or may not ask simple personal questions, it is a decision you have to make based on the context you are in.

2. Adopt a gentle & unbiased approach: Your goal is to extract information from the interviewee, so your own personal bias or preferences, should not colour the interview. Be conscious of this fact as you walk towards the topics of discussion.

3. Start with open-ended questions: For example: "What is your vision for the EHR Project?". These type of questions help to discover aspects overlapping with other stakeholders, which might otherwise remain undiscovered.

4. There are no dumb questions: One-on-one confidential interviews are a wonderful technique to extract information that the stakeholder might not otherwise reveal in a bigger meeting. Like what they are afraid of, what they are concerned about, what they think might fail, and so on. The way to get to this is by asking foundational "dumb" questions.

5. Yes, there ARE dumb questions: Don't ask repetitive questions, as if you are driving the interview into a certain direction. It can infuriate your interviewee. Also, don't ask questions that have information elsewhere, please do your homework before the interview.

6. Listen actively: It is a normal human trait to start forming responses to questions, even while we are listening. When that happens, a lot of bad things can follow. We might not be paying attention, or we might miss out on important information, or we might frustrate the interviewee.

It is a common practice to record interviews, so just make sure the interviewee is aware of that.

OK, so these are just some pointers to get you interested in learning this skill further. 'Active Listening' is the key skill behind conducting productive interviews.

In the next lesson, we will discuss 'Questionnaires & Surveys' which are tools used to interview a whole lot of people, with the same set of questions. So, I'll see you there!

In this lesson we are going to talk about a technique, that will probably already be a big part of your professional life, or it will soon become after your PMP certification. We are talking about Document Analysis. It's objective is to enhance the accuracy and quality of any project document.

As a project manager, you are the bridge between the internal and external worlds of your project. All documents will flow THROUGH you. And the quality of these documents will reflect upon you, your team and your organization. There are several types of documents that you will be required to analyze, such as: Legal documents, regulatory documents, business docs, design docs, and so on. You will NOT have the wide-range of expertise to create, or review all of them, yet you will be required to COMPREHEND all of them. And you will be responsible for their accuracy and quality.

Here are some foundational best practices that you should use for document analysis:

1. Do not reinvent the wheel. Use templates, or approved formats, or pre-vetted sample documents from other projects and use all other process assets of your organization.

2. Get the documents reviewed - by appropriately qualified personnel, and at multiple levels if possible. Ensure their feedback is incorporated into the document, as required.

3. Use every automation tool available at your disposal - spell check, grammar check, use dictionaries, thesaurus or

any other tools. There are many AI tools that are now emerging for language analysis. 

4. Be especially careful with legal documents and don't double-guess them. Rather make the best use of your organization's legal resources.

5. Avoid ambiguity in all documents. Use quantifiable and qualified parameters wherever applicable.

6. Cultivate 'attention-to-detail'. This requires improving focus and patience. Once you do this, you will start to see patterns in the documents.

I will conclude this lesson by saying that your skills in document analysis will keep getting better with experience in your business domain. And this skill will pay back enormously by mitigating future risks, saving costs, and it will enhance your personal reputation as a project professional. And we will move on to the next lesson, where we will study a data representation tool called as 'Affinity Diagram'. So, see you there!

In this lesson, we discuss the next data gathering technique called as 'Questionnaires & Surveys'. You can use this technique to quickly accumulate information from a large number of participants.

Questionnaires are a written set of questions, that will be asked to an individual. And a 'Survey' is the process of using that questionnaire to collect, analyze and interpret answers from many individuals. They work together, and are a fantastic tool to collect requirements. Questionnaires and Surveys are best used with widely different stakeholders, who might be at different geographical locations. The great advantage of this technique is that it is cost effective, it can be conducted online, and where you want statistical analysis. There are many free online tools available now, that will allow you to conduct surveys, the most popular being 'Google Forms and Surveys'. 

On the screen now, you can see the Questionnaire Survey that was used for our ongoing EHR project. You can download this file attached to this lesson and go through it. There are several types of questions that you are allowed to use on surveys: Multiple choice, Ranking System, Rating scale, Forced Choice, Written comment, and so on. Online survey tools can provide a lot of other question types too.

It must be clear from this example that Questionnaires & Surveys have a lot of advantages when used in data gathering for project requirements. I will conclude this lesson with just a few best practices that you must keep in mind:

1. You should state very clearly & concisely the PURPOSE of the survey, before diving to your questions.

2. If your goal is statistical analysis of the results (in our example it is not), then you should design your questions upfront for the purpose (and also perhaps test it out before you launch the survey).

3. It is possible to MISUSE surveys to drive towards preordained outcomes, because you control the questionnaire. You should be aware of this, and you should avoid this situation.

4. You should determine the confidentiality of the responses, before you launch the survey and protect it accordingly.

So, this was a quick roundup of Questionnaires & Surveys. If you have never used it before, I urge you add it to your tool-belt. And with that we are finished with our data gathering techniques. In the next lesson, we will look at a data analysis technique called as 'Document Analysis'.

In this lesson, we will discuss a simple but very powerful tool called Affinity Diagram. You will also learn the technique to use this tool in a wide variety of applications.

To understand this better, let us continue with our Hospital EHR project. As you will remember, we are currently within the 'Collect Requirements' process. You have now been speaking to all the different departments within the hospital, gathering requirements, understanding the current workflows, collecting new ideas, & also educating the frontline users how the new systems will work.

But then, as you get deeper & deeper, you start facing big problems. The sheer volume of ideas, requirements, workflows, constraints, & dependencies is getting overwhelming. You realize that there are overlapping interests, workflows that span multiple departments, and working knowledge that is trapped within the workers minds. Before going any further, you have to create ORDER out of this CHAOS. You have to get some sort of CONSENSUS within the large number of stakeholders.

And at this point, you decide to deploy a powerful tool in your toolkit - the Affinity Diagram. I will now explain the technique STEP-BY-STEP that you must use:

Step 0 is 'Facilitate': Creating an Affinity Diagram is a GROUP EVENT, you want to get all relevant stakeholders into the same room. Typically anywhere from 2 attendees to a 100 attendees is common. So, you will book a suitable venue, fix a time, and invite all relevant end-users for a 1-day exercise. In our case, 50 end-users will attend from all departments - Doctors & Nurses, Administrators, Finance team, Pharmacy team, Security team, Senior Management etc.

Step 1 is 'Generate': Collect all ideas & requirements, as and when they come in. You will use post-it notes, and a huge whiteboard. This is done iteratively, with periods of silence, and then some discussions. At the end of this step, you have consumed 2 hours for this activity. Take a small break.

Step 2 is 'Organize': Categorize the ideas. That is, group & bundle the ideas. Create a 'Parking Space' category for all the ideas that are not categorized. As you start grouping ideas, better ideas emerge!! You will find duplicates that can be removed. You will start getting consensus ACROSS departments. This is the real beauty of Affinity Diagrams. When we categorize, be create ORDER from CHAOS. Things will simplify and become manageable. You will consume another 2 hours for this activity. After you are done, take a break for 1 hour.

Step 3 is 'Prioritize': This is the final step. Decide which requirements are most important, and which can be postponed. This can be something as simple as re-ordering the post-its. The more important requirements get to the very top. Prune the ideas. This activity will consume another 2 hours.

On the screen now, you can see the end result. Altogether, a whole day has been consumed for creating the Affinity Diagram, but the end result is fantastic. You have a common understanding amongst all stakeholders. They have visibility into the whole system. You have their commitment. You have a concrete set of requirements, that you can take forward.

The advantages of Affinity Diagrams are that they are a very simple concept. It will create a group consensus and BETTER solutions EMERGE.

There are some costs to be paid too. You will need a fantastic skilled moderator to conduct the large meeting, or else massive chaos can be created. A lot of time is consumed. In our case, 50 attendees times 8 hours each is 400 TOTAL hours consumed. But as you can see, it was well worth it.

I will conclude this lesson by saying that Affinity Diagrams are a FOUNDATIONAL & flexible tool of project management. It is one of the "New 7 tools" created during World War 2. It can be used in a lot of different situations, where you want to create order out of chaos. I urge you to read up more about this tool & technique, and practice it regularly in smaller situations first. In the next lesson, I will discuss a similar team skill called as "Nominal Group Technique". So see you there!

In this lesson, I will introduce an advanced brainstorming technique, that is useful in collecting requirements. This technique is called 'Nominal Group', and it brings together a lot of the concepts that we have discussed earlier. Consider a situation where you are brainstorming different requirements with your stakeholders.

Nominal Group Technique (aka NGT), is a higher form of brainstorming, where you use a voting process to prioritize requirements. There are 4 steps to applying the Nominal Group Technique:

In the 1st step: You will present a PROBLEM statement to the group, and ensure everyone understand the problem. Every participant SILENTLY writes down one-or-more solutions (i.e. requirements), within a predefined time (say 10 minutes).

2nd step: You will collect all ideas, on a flipchart. At this stage, only one person speaks at a time, and no questions or discussions are allowed. People are allowed to 'pass' with no input, and may add ideas at later rounds too.

3rd step: Every idea is discussed one-by-one. Ideas can only be canceled if EVERYONE agrees. Discussion is done to clarify meaning of the requirements, to explain logic, and to answer any questions.

4th step: Everyone votes privately, on a scale of 1 to 5, with 1 having least weight, and 5 having highest. Voting takes place in multiple rounds, with solutions being eliminated in each round. After each round, only the highest voted solutions can go to next round.

On the screen now, you can see an example of the NGT applied to the Hospital EHR project, with the goal of prioritizing requirements. Nominal Group Technique brings together several of the concepts from earlier lessons: Brainstorming, Facilitation, Focus Groups, Affinity Diagrams & Voting. We will discuss Voting techniques in more detail in a later lesson.

We should consider using this technique under certain special conditions:

1. When some stakeholders are more dominant or vocal than others.

2. When some stakeholders are subdued, silent, introverted.

3. When you are worried that some stakeholders are not participating.

4. When the group is not generating ideas or solutions.

5. When you have a new group, or new members.

6 (most important). When you are dealing with controversial requirements, or if there is heated conflict in the group.

In all the above situations, Nominal Group Technique is a wonderful solution. It works best with a trained moderator, and the team has been educated on how the technique works. And with that I will conclude this discussion. Next up, we will explore an interesting visual tool called as the 'Context Diagram', so I will see you there!

In this lesson, we will discuss a diagramming technique used in collecting requirements, called as the "Context Diagram". This is used to model the scope of a project. You will have heard of the popular adage "A picture is worth a thousand words". This means that complex ideas, and multiple ideas can be conveyed in a single image. And the human mind is capable of grokking pictures much faster and much more efficiently than words.

Context Diagrams are used to visually depict the scope of a project, by showing the business system (in our case study the EHR system), and how different stakeholders & entities (such as the patients, doctors, administrators, nurses, pharmacies etc) interact with each other. Context Diagrams are a special case of an engineering tool called as the "Data Flow Diagrams", often called as the DFD Level 0.

You can then dig down deeper and deeper into the system, and representing the various inputs and outputs of the system whose scope is being represented. This makes it easier to capture workflows. For example, on the screen now you can see the workflows for the security framework of our Hospital EHR system. This diagram represents a complex 3 level security safeguard with access controls, data encryption, and monitoring systems.

The best aspect of Context Diagrams are that they can be drilled down in top-down approach. Well designed context diagrams become very valuable inputs to the later stages of the project, including technical design, verification and validation.

So, in this lesson, we have had a basic introduction to Context Diagrams. They are a simple concept, but if you are new to them then I recommend you use tools such as Microsoft Visio to practice and use them at every suitable opportunity to share your ideas, and to model the scope of your projects. We will now move on to the next lesson, where we will discuss the super important tool called as "Prototypes". I will see you there!

In this lesson, we will discuss the MOST powerful technique used to collect requirements, called as 'Prototyping'. It is a method of building a small-scale model of the expected product, BEFORE you jump into actually building it. The goal of prototyping is to get early feedback, and acceptance from the customers.

Depending on the industry you are in, and the nature of the project, the prototypes can be small-scale products, or computer generated 2D and 3D models, or it can be mock-up web applications, or Monte Carlo simulations. The latest technical trend is to use 3D printers to build all sorts of models. Prototypes are very big in the Automobile industry, civil & construction industry, Defense, healthcare and very big in the Software & Information Technology fields.

There are several advantages to prototyping. It allows the customers to experiment with real-life & practical models, instead of abstract ideas. Prototypes can massively reduce risks by exposing gaps in our understanding (including the famous 'unknown unknowns'), and exposing technical flaws. Prototypes allow "progressive elaboration", a fantastic technique of collecting requirements.

I will now explain the concept of "Progressive Elaboration". It is a very important concept, both for your professional practice and for the PMP exam.

We begin by creating a "Mock-up", i.e. a prototype. Then we allow the user to experiment with the mock-up. The user documents their feedback - what is OK, what is NOT OK etc. Then the prototype is REVISED based upon the feedback. The cycle repeats again. With every cycle, we are improving our understanding of the requirements. We are getting closer to the target. THIS is called as progressive elaboration.

Now, let's talk about the disadvantages of prototyping. There is one BIG disadvantage to using prototypes in DIGITAL projects. When you demo mock-up websites, or mobile applications, your customers will be very happy, but they will grossly underestimate the time and effort required to create the REAL product. They will think the product is half-ready already :-) This is something you have to be REALLY careful about. There are several techniques to avert this, and I suggest you go deeper into this topic separately. You have to be very good at managing expectations while using prototypes.

A rookie mistake with using prototypes is OVERSELLING. Promising too many features which will make the Project Manager look like a hero. Adding features into a mock-up is easy, but delivering it is a different ball-game. Again, be very careful what you promise to deliver in the mock-up! HINT: make it look like a mock-up, and don't polish it too much.

Prototypes take up cost - i.e. time, effort, and money. Who pays for this? They have to be added into your cost estimations, and if necessary, you have to educate your customers on the benefits of investing in prototypes.

By far, prototypes are the most powerful tools in your toolkit. These are double-edged swords, so you should know well how to wield them :-) Up till now, I have presented 8 tools & techniques for collecting requirements. These tools are used to create 2 important artifacts - the Requirements Documentation, and the Requirements Traceability Matrix. We will explore them in the next lesson, see you there!

In this lesson, we explore the core of planning, and scope definition, within any complex project: The Requirements Documentation. You will find this document attached with this lesson, please download and read through, separately. As the Project Manager for the AIIMS Hospital EHR implementation, you have been entrusted with guiding this transformation in one of India’s most prestigious healthcare institutions. The document you see on the screen is not just a static artifact; it is the living, breathing record of everything we intend to deliver, and the VALUE, we plan to create. Now, I’ll walk through each of its sections, explaining how they come together, and why they are essential to the project's success.

We begin with the 'Overview' section. This sets the stage. In any large-scale project, especially one involving a critical service like healthcare, it is vital to be clear about what the requirements documentation aims to achieve. For the EHR system, the goal is not only to consolidate the diverse range of stakeholder expectations, but also to ensure a standardized, verifiable, and traceable set of requirements that guide every downstream decision. Here, clarity is your best ally. The overview ensures that anyone who opens the document, be it a developer, a vendor, or a senior executive, knows immediately what they are looking at and why it matters. It is surprisingly common to rush through this part, but setting the tone here avoids misalignments later.

Next, we move into the heart of the document: the 'Requirements Table'. This section is where rigor and discipline meet stakeholder empathy. Each requirement here will map to the Traceability Matrix, and it is captured with care. You’ll notice that each requirement has a unique identifier, such as BR001, or SR002, which is not just a numbering system, but a critical link to test cases, deliverables, and acceptance criteria. The table walks us through the requirement itself, the stakeholder from whom it originated, the category, the priority, how we will determine it has been fulfilled (i.e. the Acceptance Criteria), how we’ll test it, and when we plan to deliver it.

Take, for example, BR001: "The system must improve overall operational efficiency." This came directly from business stakeholders, and is a Level 1 priority. To accept this, we’re aiming for measurable reductions in patient wait times and data duplication. This requirement is not just an aspiration; it is linked to a defined test method, and it will be validated against live metrics. By designing each row with such specificity, we prevent vague statements from creeping in, something that plagues many poorly written requirement documents. A vague requirement can NOT be validated, and without validation, it can NOT be said to be delivered. That’s a core risk we mitigate with precision.

Following the requirements table is the 'Source Mapping' section. This often overlooked area is the provenance of our requirements. It tells us where each requirement came from. Did it come from an interview? From a legal mandate? From a benchmarking report? In this case, BR003, which mandates compliance with data privacy regulations, came from the Legal Compliance Report. This matters immensely when we get to change requests. If someone questions the inclusion or relevance of a requirement, we can trace it back to the source and hold a grounded conversation. It also helps in prioritization. Knowing that a requirement stems from the government, or a regulatory body, often changes how it is treated in the backlog.

The next section is the 'Requirements Attributes Summary', which effectively brings order to the diversity of inputs. It codifies the definition of each attribute: what we mean by a stakeholder, how we classify categories, what a Level 1 versus Level 2 priority is, and so on. This might seem repetitive if you have already filled the table, but don’t skip it. The reason we include this is that multiple people, often from different organizations, will refer to this document. By defining attributes, we eliminate assumptions. In my experience, assumptions about priority, or acceptance criteria are among the top sources of miscommunication in project execution. Clarity here builds consistency later.

Then comes a crucial expansion: 'Tailoring Considerations'. For our project, which uses a Predictive approach, this section helps shape how we evolve the requirements over time. For example, some requirements may be tied to specific releases. This section tells our teams how to handle variance. It subtly, but powerfully introduces flexibility into a formal document, acknowledging that projects don’t always unfold in a straight line. Tailoring, in my view, is what separates a rigid requirement document from one that’s actually usable.

Moving further, we address 'Inputs and Outputs Cross-References'. This optional section ties our documentation to the broader ecosystem of project artifacts. Requirements don’t live in a vacuum. They receive information from documents like the Project Charter, the Assumption Log, and the Stakeholder Register, and in turn, they inform the Scope Baseline, the Risk Register, the Communications Plan, and more. This is where integration begins to show its value. One of the biggest pitfalls I’ve observed in similar projects is treating requirement documentation as an isolated activity. But when you weave it into the planning fabric, it becomes a linchpin that influences risk, quality, procurement, and stakeholder engagement.

With that context, we come to the 'Alignment and Consistency' section. This is not just a checklist. It is a quality gate. The requirements must be aligned with other foundational documents such as the Quality Management Plan and the Benefits Management Plan. For instance, SR003, our requirement to provide strong reporting and analytics, must align with the strategic KPIs in the Benefits Management Plan. When we enforce alignment, we make sure that every requirement serves a bigger strategic picture. This guards against scope creep, and ensures that what we build delivers measurable value.

Next, we introduce the 'Non-Functional Requirements (NFRs)'. These are the EXTREMELY important heroes of system design. While functional requirements describe what the system must do, non-functional requirements (NFRs) dictate how well it does it. In the EHR project, performance, availability, accessibility, and auditability are all covered. Consider NFR001, which sets the expectation that system responses occur within 2 seconds. This is not a cosmetic preference. It directly affects clinical decision-making. Similarly, accessibility standards like screen reader support ensure we’re not designing for the average user, but for all users. The pitfall here is in under-scoping non-functional requirements because they are hard to measure. That’s why we define them very clearly, and tie them to specific validation steps.

Our next stop is the 'Data Requirements'. Healthcare systems are data-intensive, and that data must be accurate, secure, multilingual, and long-lasting. We’ve defined requirements such as structured data formats (JSON or HL7 XML), input validation for demographics, retention for 10 years, and dual-language interfaces. The importance of this section is often underestimated. Poorly defined data requirements lead to downstream issues in reporting, compliance, and even legal disputes. For example, our DR002 ensures that vital demographic fields are validated at entry. This may seem procedural, but for a major hospital, it is a frontline defense against incorrect diagnoses, billing errors, and administrative chaos.

The section that follows is 'Interoperability Requirements', This is a defining feature of modern EHR systems. In a connected healthcare ecosystem, no system can operate as a silo. Here we define our conformance with HL7, and FHIR standards, the availability to integrate with NDHM APIs, import data from lab devices, and send encrypted referrals externally. For India, where NDHM (National Digital Health Mission) is building a national health grid, this isn’t just a technical necessity, it is a strategic alignment with national policy. Missing out on interoperability isn’t just a risk; it is a guarantee of obsolescence. And yet, many projects underestimate the complexity required here. We ensure clarity in our documentation so that integration engineers know exactly what’s expected.

Finally, we arrive at the 'Conclusion' section of the document. This is where we reflect and prepare. Requirements documentation is not an end in itself—it is a beginning. The conclusion reiterates this by confirming the document’s role in guiding design, development, testing, and change management. It reaffirms that this is a living document, not a relic. As a PMP, I’ve learned that closure with clarity is just as important as initiation with inspiration. The conclusion ensures that teams understand the document’s utility beyond its creation. It reminds everyone involved—from developers to testers to stakeholders—that requirements evolve, but their documentation must remain a source of truth.

And so, as I close this lesson, remember that requirements documentation is not a formality, rather, it is your map and your compass. When done thoughtfully, it enables alignment, supports validation, and prevents failure. When ignored or treated as paperwork, it becomes the silent cause of missed deadlines and unsatisfied users. In the Hospital EHR Project, this document is more than words on paper—it is our commitment to delivering meaningful, measurable, and mission-aligned outcomes.

Keep this approach close as you lead your own projects. Requirements, after all, are not just statements—they are promises. And every promise deserves to be honored with clarity, structure, and diligence.

In this lesson, we will discuss one of the most versatile, & powerful tool of project management - the Requirements Traceability Matrix, (aka the RTM). If I had to choose a single favorite tool to manage projects, this would be a strong choice. Let us understand why this tool is so awesome.

The concept is very simple. We take every single unit of the requirements (from the Requirements Documentation), and track it all the way, from the beginning, to the end of the project. When you do that, you ensure that every requirement is justified by Business objectives, that it has been designed properly, tested properly, and finally delivered properly. You are well aware that stakeholders change their minds on what they need. The RTM helps you navigate a complex maze of changing requirements.

on the screen now, we have the RTM for our EHR project. In this, we have pulled in all the requirements from the Requirements Documentation created earlier. I will go through these columns, one-by-one, so you can see the logic involved.

Every unit of requirement is linked to:

1. the Unique Identifier from Reqts Doc.

2. a description of the Requirement

3. Source - The stakeholder that identified the requirement, and where this requirement originated from, you can add any references like meeting details, email reference etc.

4. Category - The category of the requirement, as defined in the previous lesson. Examples are: functional, non-functional, business requirement, stakeholder requirement, etc,

5. Business Objectives, we link every requirement explicitly to the business

6. Project objectives - how we intend to link the requirement to the technology or project objectives. This is the practical manifestation of the business objective in the project. This helps in budget justification. For example, when you have to purchase something for your project, this is  very helpful.

7. Deliverable - How this requirement will actually be delivered - in a website, or a physical product, or a result etc

Then the remaining columns test plan, test cases etc should be tailored i.e. customized to how you will verify and validate your product. So this is the logic of the RTM. When you apply this to your project, you should feel free to totally own the design yourself, modify as you want.

By the way, I have a small task for you. "What is the difference between 'Verifying', and 'Validating'?" How do you do this in your industry, and in your project? Answer this in  the Q&A section of this course, with the subject line in this format: <your name:><Verify vs Validate>. You should answer  within 10 sentences.

Okay, and with that we come to the end of this lesson. At this point, we have successfully completed one of the lengthy processes of project management - "Collect Requirements". In the next lesson, we will learn how to define the scope of the project, with precision and clarity. It will be simple and straightforward, so I will see you there!

With this lesson, we start a new process called as 'Define Scope'. We have just finished 'Collect Requirements' process, and now we start to 'Define Scope'. It involves the development of a detailed description of the project, and the product. And very importantly, we will also define how the project will be accepted by the stakeholders and this is called as the Acceptance Criteria.

OK, on the screen now is the data flow diagram for the 'Define Scope' process. I will explain the ITTOs.

The 'Requirements Documentation', which we had created earlier is the key input for this process. You will be directed (or guided), by the 'Scope Management Plan' and the 'Project Charter' artifacts. As always, your organization might provide you the template to be used (i.e. OPA).

Next up, let's look at the tools & techniques. There are some recommended techniques - Alternatives analysis, and Multicriteria decision analysis. We will study these techniques later at a more appropriate time in the course. The special technique for this process is called as 'Product Analysis'. We will discuss it in the very next lesson.

And finally, the most significant output of this process is the 'Project Scope Statement'. This is not just a simple statement as the name implies, but it will be the guiding light for your project. It is like the highly distilled truth that emerges out of the requirements documentation. A couple of lessons later, I will show the detailed scope statement for our ongoing EHR project.

During project initiation, a very high level description of the project is created. But that will not be precise enough to create a project. And that's why in the planning phase, we start  by collecting requirements from all stakeholders. We have been doing that for previous 10 lessons or so. BUT, all requirements might not get included in the project. Some requirements might not be approved, or it might not be in budget, some requirements might not be reasonable or feasible, some requirements might get deferred for later - and so on.

NOW, in the 'DEFINE SCOPE' process, we will actually decide what goes into the project, and what will NOT. Similarly, we uncover constraints in the project, we discover new assumptions that are made, and some of the old assumptions will get falsified, existing risks may materialize and new ones might be discovered. All of this will get attached to the scope statement.

In iterative lifecycle projects, a high level scope is determined at the beginning. And later on, scope is detailed out, one iteration at a time. Detailed planning for NEXT iteration happens when work is executed for current iteration. That is scoping is done, one iteration ahead of time.

And with that, I will conclude this lesson. Coming next is the technique called as 'Product Analysis', see you there!

In this lesson, we discuss a tool called as Product Analysis. In our ongoing Hospital EHR project, a 3rd party International vendor is supplying the software EHR product. This software framework will form a major part of the solution. So, we can use product analysis technique in our project at several milestones - to evaluate competing vendor solutions, and NOW to build the Project Scope Statement, and also later for technical implementation and testing purposes.

The question now is: "How do we conduct Product Analysis?". The technique can be explained like this: Every application area of the product, in our case an Electronic Health Records software system, is analyzed by asking questions about the product, and forming answers to describe the use, distinguishing characteristics, and other relevant dimensions of what is going to be delivered. I will show a detailed example shortly. You should enroll different experts to orchestrate such an analysis, including technical experts, finance professionals, and business analysts, as suitable.

PMBOK mentions the following analysis techniques that can be considered:

1. Product breakdown

2. Requirement analysis

3. Systems analysis

4. Systems engineering

5. Value analysis

6. Value engineering

so these are some of the techniques that can be used.

On the screen now, you can see the Product Analysis design that was used to evaluate the different vendors products. You will find it attached with this lesson, please download and have a quick look through it. I will quickly explain each of these sections:

1. We start with a Product Breakdown, and this includes the Key Components of the EHR system, and the high level expected functionality.

2. Second section is for Requirements Analysis, and we just reference to our extensive Requirements Documentation artifact. Whenever possible, you should use this method of referring to the appropriate sources. However, in this section we detail out the key Non-Functional Requirements (NFRs), because they are useful for the rest of this document. This is followed by the Technical Requirements of the product. These are closely related to the NFRs.

3. Third section is Systems Analysis - our existing Hospital already has some different software running in different departments. So, here we summarize our Current System, and also present a Gap Analysis (i.e. what is missing in our current experience).

4. Fourth section is Systems Engineering, where we document the systems-level expectations of the solution - modularity, scalability, interoperability, etc.

We also analyze how the expected system has to be rolled out in the Implementation Plan, detailing out a phased approach, user training, quality assurance, and change management.

5. Fifth section is for a Value Analysis, including Cost Benefit Analysis and Return-on-Investment (i.e. ROI). We will discuss these tool later in the course.

6. Sixth and final section is Value Engineering. This is a systematic study done to improve the VALUE of a solution, by decreasing costs and improving quality. In our project, various optimization strategies are considered such as process improvement, resource allocation, continuous improvement, vendor management & feedback loop.

And with that I will conclude this lesson. Product Analysis is a very specialized technique. It will be used in a lot of different situations. We are using it to analyze the EHR system to define the scope of the project. And in the next lesson, we will see the final Project Scope Statement artifact, so see you there!

In this special TAILORING lesson, we explore how to tailor Scope Management to fit the unique contours of your own project. Unlike textbook boundaries, real-world projects rarely follow a rigid path. Scope evolves, shifts, and expands, or shrinks, depending on how you define, validate, and govern it. Tailoring this Knowledge Area is about asking the right questions before scope problems ask them for you.

Most scope-related disasters don’t arise from poor planning, they arise from assuming that one plan fits all. That’s why tailoring is your secret weapon for making Scope Management realistic, resilient, and responsive.

Start by asking: 'How does your organization handle knowledge and requirements?'. Is there a formal knowledge base, or do things live in spreadsheets, inboxes, and memories?

* If the environment is structured, your job is to plug in, not reinvent.

* If it’s informal, you’ll need to establish repeatable practices to avoid scope ambiguity and rework.

* You may even need to build a repository for reusable requirements in long-running programs.

Here's the trick: capturing what people *need* isn’t the same as what they *say* they need. Tailoring Scope means defining how deep, formal, and iterative your requirements gathering must be to succeed in *this* environment.

Every project needs validation, but how it’s done varies widely.

* Are there pre-approved checklists, templates, or gates?

* Or is quality more ad hoc, based on the experience and intuition of domain experts?

Tailoring here means defining how much structure your validation processes require. Highly regulated industries will demand rigor. In other settings, you might validate scope through informal demos, peer reviews, or walkthroughs.

The pitfall is assuming validation happens naturally. It doesn’t. Tailoring ensures you don’t miss that final sign-off moment, or worse, build something no one actually wanted.

If your organization leans toward Agile, tailoring scope means embracing evolution over precision. Requirements are expected to emerge. You’ll define scope in increments, through epics, features, or user stories, and validate continuously.

In a predictive model, you define 100% of the scope upfront and manage it against a baseline. Tailoring here means choosing the right amount of formality: a full WBS for construction? Or just milestone-level deliverables for a startup MVP?

And if your world is hybrid, as most are, you’ll need a layered scope approach. Some elements fixed, others fluid. Tailoring helps you segment that landscape consciously.

Governance is the backbone of how scope is defined, controlled, and escalated.

* Do you need approvals at every stage?

* Are there gate reviews, internal audits, or compliance boards?

* Or is governance minimal, limited to stakeholder check-ins?

Tailoring Governance in Scope Management means aligning your documentation, change management, and stakeholder reviews with whatever oversight the organization expects.

Never underestimate this layer. Strong governance can prevent scope creep. Weak or vague governance nearly guarantees it.

Tailoring Scope Management isn’t about creating a new process, it’s about calibrating existing ones to match your organization’s strengths, constraints, and priorities.

Ask:

* How formal is our environment?

* How stable are our requirements?

* Who has the power to approve or change scope?

Then, build your scope processes around *these realities*, not around what a textbook says. The result? Less friction, more alignment, and better control.

A well-tailored Scope Management plan is your strongest defense against chaos. It ensures expectations are aligned from the start and remain aligned all the way to delivery.

In the end, tailoring is not about complexity, it’s about fit. Fitness to the team, the client, the stakeholders, and the culture. Nail that, and you’ll never have to chase scope, you’ll be leading it.

This lesson is dedicated to the 'Project Scope Statement'. This is an artifact that contains a description of the scope, all key deliverables, the criteria for project acceptance, risks, assumptions and constraints. And as you remember from a previous lesson, it is the key output of the 'Define Scope' process. Scope Statement is significant because it provides a common understanding for every stakeholder of the project. It is used by the project team to do detailed planning, to build a schedule, to build a test plan etc.

On your screen now is the Scope Statement for our ongoing project - Hospital EHR system implementation. You can download this file attached with this lesson. This artifact will eventually be integrated into the Project Management Plan. I urge you to take a couple of minutes, and read through this document.

Many learners wonder "Why do we need the Scope Management Plan, if we already defined the scope in the Project Charter?"

The Project Charter contains ONLY a very high description of the project. But the Scope Statement is built after collecting, analyzing, and refining requirements. On the screen, you can see a comparison of the Project Charter contents vs. the Scope Statement. Pause the video if you want.

OK, now let's visit each section one-by-one.

The first section is the "In-scope" list. It will elaborate the characteristics of the solution. It can contain tangible and intangible value-driven objectives. This guides the entire project.

Second section is the important 'Acceptance Criteria'. You will already be familiar with EVERY section of this artifact, except maybe the Acceptance Criteria. Please pay very special attention to this section. These are the CONDITIONS that have to be met by YOU (the Project Professional), for your project to be accepted by your customer. All the conditions have to be met without exception, and they are not optional.

Next up is the Risk assessment: Only the top-level risks are generally included at this stage.

This is followed by the Project Deliverables: It is important to note that deliverables include not only the product scope, but they include the ancillary project scope such as project reports, design documents, UI mockups, demos, test reports, suchlike.

Next come the Project Exclusions. What we explicitly cite will NOT be delivered in this project. The reason why this is included is to manage expectations. You should never leave out this section, as it helps establish the boundaries of the project.

This is followed by the Project Constraints: These typically include time, cost, and resource constraints. At all times, you should be very realistic, and practical about this section.

The rest of the document is made up of Dependencies (which are useful for building the schedule), Project Success Measures (which are results that you can actually measure), and Project assumptions. Feel free to add any other meaningful sections to the document.

And with that I will conclude this lesson. This scope statement has been created with a lot of effort, foresight & design. It will form the foundation of your project and the Project Management Plan. All the hard work you do at this stage as the Project Professional will pay rich dividends all through the course! I will see you in the next lesson, where we will start a new process called 'Create WBS'. I will see you there!

In this lesson, we discuss the 'Create WBS' process. You can see it here in the 49 processes table. This is incidentally, one of the most misunderstood processes of all. I will explain why, a little ahead in the lesson. In this process, we divide the product deliverables, and the project work into smaller and smaller components, so that they are more manageable.

--

What is the 'WBS'? It stands for 'Work Breakdown Structure'. The WBS is a hierarchical decomposition, of the total scope of work required to be done, to achieve the project objectives, and create the required deliverables. We start with a breakdown of the DELIVERABLES. And the lower levels will contain the 'work packages'.

On the screen, you can see a classic (and very good), example of WBS for a bicycle. Observe that we breakdown the Bicycle into it's major components, progressively at every level. Also notice that in this example, we have only shown the deliverables, and not the ACTIVITY required to create the bicycle. As I mentioned earlier, there is/was some misunderstanding about this process. Earlier text books would place the emphasis on WORK breakdown, but the now the emphasis is on DELIVERABLES. I will discuss this more in the next lesson where we will see several breakdown examples.

--

Now, let us look at the process diagram for 'Create WBS'.

1. Requirements Documentation, and Project Scope Statement are the most important inputs for this process, because that's where you will identify all the deliverables.

2. A special technique called as "Decomposition" is used for this process. The very next lesson is dedicated to understand this technique. I will show many examples, and of course, we will apply decomposition technique to our ongoing project.

3. The most important output of this process is called as the "Scope Baseline". This is actually made up of three components: the approved Scope Statement, the WBS, and the WBS Dictionary. Again, we will see all this in a separate lesson coming up.

--

And with that I will conclude this lesson. The WBS should represent all product and project work, including the project management work. The lowest level of the WBS represents the planned work packages, at a level suitable to be estimated, scheduled, and monitored. We will study these topics in great detail later. The very next lesson however is for Decomposition, so I will see you there!

In this lesson we learn an important technique called as 'decomposition'. Decomposition is used to repeatedly divide (i.e. breakdown) the project scope & deliverables into smaller, more manageable parts. The lowest level of breakdown is called as a "Work Package". At the lowest level, we have transformed the SCOPE & DELIVERABLES into work.

Why should we DECOMPOSE? When we decompose the deliverables, only then are we able to estimate the work involved, only then we can decide which resource has the ability (and availability) to execute this work, and only then we will be able to work within the budget allocated. So, decomposition is essential for building a schedule and managing the project.

5. How is decomposition done?

Here is a 5-step algorithm, you can follow to decompose the project SCOPE into work packages.

Step 1. Identify deliverables from the Scope Statement and Requirements Documentation, or from Agile Epics.

Step 2. Structure WBS. There are several ways (or designs) you can structure the WBS, explained in the next slide.

Step 3. Decompose the current level into lower level.

Step 4. Assign an unique ID to every component.

Step 5. Verify granularity, i.e. verify that you have broken down appropriately. Neither too large, nor too small. I will explain this later in this lesson.

You can use different approaches to design the WBS structure. I will only show two of the MOST POPULAR designs. On the screen you can see example 1, where the WBS is structured by PROJECT PHASES. Notice that Project Management is always added into the WBS. We have Requirements gathering, Detailed Design, Construction, Testing etc. Each of these phases is subsequently broken down to a manageable Work Package.

--

In the second example that you see on the screen now, the WBS structure is created from the major DELIVERABLES of the project. Every deliverable is broken down iteratively until we arrive at the work packages. There is no single prescribed way to structure your WBS, or as the idiom goes "there is more than one way to skin the cat". You should study your organization's templates, previous projects, industry guidelines etc.

At this point, a question will be troubling you: "When should I stop decomposing?". I will answer this in the next slide.

"How much should I breakdown?" or "When should I stop decomposing?".

This is a classic Goldilocks situation. Your final work-packages should neither be too big, nor too small. It should be just right for your conditions. Understand that the more you breakdown, the more manageable your project becomes. How much control you want of the project, that much you must divide. For example, small projects often break-down to size of APPROXIMATELY 8-16 hours effort per work package. Large projects, often break down 40-80 hours of effort per work package. This is a thumb rule called the '8-80 rule'.

There are a couple of problems associated with Decomposition that you should be aware of. Excessive decomposition is another face of "Micromanagement". Decomposing too much, will make you (the Project Manager) unproductive. It leads to loss of team morale, inefficient resources, and great difficulty in tracking the project, and many other similar issues! You should totally avoid excessive decomposition.

The second problem is that you (or your team), might just not know enough to decompose. This is specifically for deliverables that are far away in the future. In such a situation, we defer the decomposition UNTIL we get better clarity on the deliverable that needs to be broken down. This technique of waiting is called as "Rolling Wave planning".

And with that I will conclude this lesson. WBS decomposition is a critical part of project planning and there are several best practices to be understood and followed. I will present them in the next lesson, so I will see you there!

In this lesson, we will discuss a FOUNDATIONAL concept of project management, known as the 'Baseline'. A baseline is the reference point, on which all project performance measurements are based. Baselines are the basis of comparison upon which your decisions will be made - to accept, or to change, or to take preventive or corrective actions. I will explain this concept with a very simple example.

Assume that you have been assigned a new project. You will study the requirements and come up with a plan. According to your plan, the project will run for 5 months. You will consume 100 dollars every month. And you will make linear progress of 20% every month, on the SCHEDULE. You will take this plan to your sponsor and they will approve it.

This table shows your plan - the ESTIMATED cost, and ESTIMATED schedule for every month, until completion. Now THIS table is your BASELINE for cost and schedule. You can use it for comparing your actual progress and spending, while you are executing your project.

You will start executing the project now. For the sake of simplicity & brevity, I will only focus the schedule progress.

1. At the end of Month 1, your target was 20% progress, but you achieve 25% progress, and everyone is elated. [Keep following up with chart also].

2. Next month however, reality hits the schedule. You show up 3% short of your target. But, there are no alarm signals yet with your sponsors.

3. At the end of 3rd month there is a 10% slippage. It is recognized that the project is fast losing control. Your senior management asks you to take corrective and preventive actions.

4. At the end of 4th month, there is 15% overall slippage. The corrective actions you have put in place are slowly bearing fruit, and improving the situation.

5. In the 5th month, there is significant improvement, some extra (overtime) work is consumed, some extra (buffer) money is spent, and with some good luck, you manage to hit the schedule deadline successfully.

Now, the moral of the story is that, if we did not have this baseline to compare against, we would have been lost. The key point here is COMPARISON. To be able to compare, you should BOTH have a baseline, and you should be actively tracking your project! :-) In this example, we only looked at the schedule, but all the other key constraints of the project can be baselined (like cost & scope).

There are four primary baselines: scope, schedule, cost, and performance measurement baselines. All the four baselines are components of the Project Management plan. Depending on the size, complexity and priorities of your project, you can choose which baselines you will maintain for your project.

Our focus in the next lesson will be on the 1st baseline that is created for a project - The Scope Baseline. This consists of 3 components - scope statement, WBS, and WBS Dictionary. The WBS Dictionary I have not mentioned so far. It is just a simple repository of extra details that we uncover about the work packages (such as cost, effort estimate, resource requirement, or some constraints, or some dependencies etc). 

A final point I want to make is that Baselines should be version controlled. That is, changes can not be made to the baseline, without formal change control process. This is perfectly logical because you use it comparison, and there is no point if you keep changing it! In the next lesson, I will show the Scope Baseline for our ongoing EHR project and it will be very interesting. So, see you there!

This lesson is very important, because we will discuss the SCOPE BASELINE, and some very important aspects of the WBS. You should pay special attention to this lesson because a tremendous amount of knowledge is packed in. We discussed the importance of 'baselines' in the previous lesson. The 'scope baseline' is a significant milestone in predictive (waterfall) projects because (1)it is the first baseline that we create, and (2) because it means that we can next move to scheduling the project.

The Scope Baseline has 3 components - the APPROVED scope statement, the WBS, and the WBS Dictionary. We have already covered the scope statement in a previous lesson, so we will only focus on the WBS components in this lesson.

On the screen now, you can see the WBS, and WBS Dictionary for our ongoing EHR project. You can download this artifact attached with this lesson. I have kept this file very simple, because there are many points that I will cover now.

I will mention 10 important "THUMB RULES", on how to design a WBS. These points were first created in my bestseller course on Microsoft Project, because I saw that many learners struggled with creating the WBS. These rules are extremely popular with my learners, so I added them to my book and to other courses. These are not hard-and-fast rules, but they are only to help you create fantastic and usable WBSes. So here goes:

Rule 1: Always create the WBS with your team, i.e. the people who will actually construct the project. By doing this you are tapping into all their expertise, and more importantly you will be buying their commitment to the project!

Rule 2: A WBS should have at least 3 levels. Complex projects can decompose 8-10 levels also. The minimum recommended is 2 levels for small projects.

Rule 3: A WBS is NOT a task list, so don't mistake it for one. You are currently in Scope management, you are NOT YET defining tasks. That happens in the next step of scheduling. Your WBS should NOT focus on tasks, but rather on DELIVERABLES of all kinds, tangibles and intangibles.

Rule 4: Create identifiers for all the components of your WBS. Don't use (avoid) VERBS in your WBS, because they are action words.

Rule 5: "The 100% rule", is an important and mandatory rule. It states "every level of decomposition should represent 100% of the higher level parent component. And conversely, if a component is decomposed, then it's lower level child sub-components should represent all of the work involved (100%)". This rule ensures that - Nothing new is added as a result of decomposition (i.e. scope creep), and nothing is subtracted or lost due to decomposition (i.e. translation loss).

Rule 6: The 'mutual exclusion' rule: This is a significant corollary to the 100% rule. This rule states that there should be no overlap of functionality between the components of a WBS. Every component should be mutually exclusive. If you do not follow this rule, the result will be duplication.

Rule 7: The iterative design rule. A WBS must be created with multiple iterations, until adequately elaborated. This ensures the whole project achieves a similar level of decomposition. It is common human tendency to decompose MORE something that we know very well, and ignore unknown sections. :-) You have to decompose equally.

Rule 8: Always include Project Management in the WBS. This is the Golden Rule! You can assume roughly 10-15% of deliverables (effort / cost) should be for Project Management. These deliverables might be interim, or internal in nature. But do not ignore them in the WBS!

Rule 9: The lowest level component of the WBS should be a "work package". This is how you translate the 'deliverables' to 'work'. A hint for you is that these work packages will be further broken down in the next stage when we get to project scheduling. These work packages translate to summary tasks in Microsoft Project.

Rule 10: The last one is called the 8/80 rule. This is another important and practical rule of thumb. This rule helps you decide when to STOP decomposing. Your final work-packages should neither be too big, nor too small. It should be just right for your conditions. The more you breakdown, the more manageable your project becomes, to a limit. For example, small projects often break-down to size of APPROXIMATELY 8-16 hours effort per work package. Large projects, often break down 40-80 hours of effort per work package. Your team's reporting cycle should match your work package size to a 1x or 2x factor.

So these were the 10 rules of the WBS. The WBS is a make-or-break for your project, so I hope you found all of this interesting and helpful. By creating the scope baseline, we are finished with planning scope, and next we will move on to planning the schedule. So, see you in the next lesson!

In this lesson, we are starting with a new ECO Task, "Plan and Manage Schedule". However, at this stage of the course, we are only looking at the 'PLAN' aspects, and the 'manage' aspects will come at the later time. Over the next 30 lessons or so, we will have an intricate look into schedule planning.

'Project Schedule Management' in PMBOK, includes 6 processes which are required to manage the TIMELY completion of the project. Notice the 6 processes here. 5 of these processes - Plan Schedule Management, Define Activities, Sequence Activities, Estimate Activity Duration, Develop Schedule are in the Planning Process Group, and we will be covering them now. The 6th process, 'Control Schedule' is for later, when we are executing the project.

In this section, I will be covering 12 special tools & their techniques, and 10 different useful artifacts. As you can expect, we will be hands-on with our ongoing Hospital EHR project, so you will see these being applied to real-life situations, in a simple and relatable fashion.

Now comes the real important part. Let us look at the key concepts of Schedule Management.

What is a schedule? A "schedule" is a detailed plan, that represents HOW and WHEN your project will deliver the scope. It is your PRIMARY tool for communications, managing expectations, controlling the team, reporting, etc. The next question that we ask is: "HOW do we create a Project Schedule?". The project schedule is created by getting together three components:

1st Component is the Scheduling Method. You might choose the Critical Path Method (CPM), or some Agile variant approach.

2nd Component is the Scheduling Tool. You might choose any tool such as Microsoft Project, Primavera, Excel, JIRA etc.

3rd Component is the specific Project Information - such as your WBS, activities, resources, durations, constraints, calendars, milestones, dependencies, lags etc.

When these three components are put together, the schedule is created. We call it a "Schedule Model", because it is a model, it is JUST a PREDICTION, or an ESTIMATION. You will have to track it against the Actuals. You can represent the schedule in many different visual formats, such as an Activity List, Gantt Chart, or a Network Diagram. It is important to note that so much of rigor, is NOT required for smaller projects. In ALL cases, your focus should be on flexibility of design, adjusting for new knowledge that will come later, and for risks that will materialize. That is, your schedule should be as FLEXIBLE as possible, because of Murphy's Law :-)

Now, let us a quick look at some of trending new kids on the block :D. Even though these techniques are more than 3 decades old, they are still 'new', considering project management is thousands of years old. These new approaches are driving almost the entire internet economy, so they are not small by any measure.

1st new approach: is "Iterative with Backlog". Take the case of a product development team using Agile. They will use Rolling Wave technique for planning, and User Stories for Requirements. They will use Timeboxing for development, and incrementally deliver value over time.

2nd new approach: is "On-demand scheduling", popularly called as KANBAN. This technique does not rely on a predesigned schedule. Rather, work is PULLED out of a board (or a queue). This technique is used on products which are operational (or in sustainable environments). Tasks are typically similar to each other, in scope & size.

We will work hands-on on such projects, later in the course.

Every project is UNIQUE. You should tailor how you apply all the [49] process. There are 4 primary aspects you should consider for tailoring:

1st tailoring point is: What is the best lifecycle for your project? Waterfall, or Iterative or Hybrid?

2. What is the quality, quantity, and availability of your people, your machinery, and your budget?

3. How complex is your project, how much risk you have? etc.

4. What is the tech stack your company supports for building schedule? For example Microsoft Project Server solution is quite expensive for smaller projects.

And now we have come to the conclusion of this lesson. We discussed the big picture view of planning a schedule. Over the next 30 lessons or so, we will examine the 5 processes that are used in building a schedule, with some powerful tools and artifacts. So I will see you in the next lesson!

We will discuss the process called 'Plan Schedule Management' now. Before we jump into creating a schedule for our project, we will lay down the 'rules of the game', so to speak. These rules of scheduling, will be in the 'Schedule Management Plan' (obviously :-)). The objective of this process, is to create this plan with all the scheduling rules & practices. Typically, your organization would have a plan template ready for you, which you have to customize for your project. However, some of the key decisions will have to be taken by the project team. In the next lesson, you will see a realistic plan.

Now let us look at the ITTOs for 'Plan Schedule Management', one-by-one.

The Project Charter is an input, and it will typically provide milestones, which will drive your schedule. What is a milestone? It is a date marker on which something significant should be accomplished on your project. The Charter will have some high-level milestones defined in them.

The Development Approach is an artifact that we have not covered YET in this course. As the name suggests, it is a justification document for the development approach that we will adopt for the project. It is very important for the schedule because it will impact everything on your schedule. For example if you choose some Agile approach, then the iterative release dates, estimating techniques, scheduling tools, techniques all will be mostly be different than if you choose a traditional Waterfall approach.

The enterprise factors impacts what resources your project will get. Which people will join your team, their skills, budgets, what technology you will use, commercial databases, and so on.

The organizational assets will provide you templates, historical knowledge, lessons learnt, guidelines, etc.

You should always seek expertise advise from anyone with special knowledge, experience, or training in scheduling projects similar to the one that you are working upon.

Alternatives Analysis is an important technique in scheduling. You can draw up different schedules, and then analyze them for anything you want, like optimal performance, reduced costs, risk resiliency, etc.

The output of this process is of course the Schedule Management Plan. We will discuss it's contents in the next lesson, applied to our running project. So, I will see you in the next one!

We will now look at the "Schedule Management Plan" artifact, created for ongoing Hospital EHR Project. This plan will explain how we will develop, monitor and control the project schedule. The Schedule Management Plan will eventually become a part of the Project Management Plan. Depending on the size, and complexity of your project, this plan can be formal or informal, it can be open-ended, or highly detailed.

The example that we see now on the screen is fairly simple, but it will cover all the major aspects of scheduling. I will walk you though all the key sections of the plan one-by-one, so we can see what such a plan typically contains.

--

We start with a very brief description to the Schedule Management Plan, justifying the need to create this artifact.

The 1st section details the Schedule Methodology: It is very important, and we state that Critical Path Methodology (CPM) will be used for this project. This critical decision is significant, and will impact all the other major aspects of scheduling our project. It is elaborated on how CPM will be best for the project. Also please observe that some of the new development sections like reporting, and other 3rd party integration, will be developed in Agile methodology. We justify the reasons for this dual approach also, in this section.

2nd section is for the Scheduling Tools: Here we will list all the tools required for our scheduling. Microsoft Project will be the primary scheduling tool, and it supports the CPM scheduling algorithms. We have also identified and justified other tools which will be used: Tableau, and Microsoft Power BI for reporting, Git or SVN are tools that will be used for configuration management, Jenkins or Gitlab will be used for Continuous Integration. Slack, or Microsoft Teams will be used for team management, and collaboration. We will justify our reasons for selecting these tools, as briefly as possible. You can also note that all these tools are compliant with each other, and on the same compatible technology stack.

3rd section is for the Level of Accuracy that we will maintain on our schedule: This determines the minimum granularity for activity duration estimates. This is important as a common guideline for all the team members who will be estimating their work. Every team member should use the same granularity Units for estimation. Remember the 8/80 rule. Here I have also included a table that establishes a common definition for the duration estimates of Day, Week, Month, and Year, mapped to work hours. It includes paid holidays and it is very useful in making work estimates.

4th section is for Units of Measure: This is useful when you want to establish a guideline across full time employees, vendors, contractors and other 3rd party team members.

5th section is for Variance thresholds: This is used as a guideline to determine WHEN a task (or the entire project) requires preventive action, or is late and requires corrective action. This is also called as a "Control Threshold". It is important that all the team members are aware of this component of the schedule.

6th section is for the Schedule Reporting formats: What will be the schedule information required for status, and progress reporting? How should the team members report back to the project manager? We will also include simple templates for weekly, and monthly reporting.

In the final section, we define how the Schedule will be tracked and updated: We give a brief process for updating the schedule, including the update (i.e. tracking) frequency, permissions, and version control. Also included are some guidelines for maintaining baseline integrity, and for re-baselining.

This has been a very simple Schedule Management Plan, but it has been pretty comprehensive. For the sake of simplicity, I did not include the Agile aspects of our project in here, but if you were working on a Hybrid project, you should include those details also, mapping to each of the individual sections that we covered just now. And with that, I will conclude this lesson. Coming up next, we will explore how the WBS work packages will be broken down into activities (aka 'Tasks'). We will be looking into several techniques and concepts, so see you there!

In a previous lesson where we created the WBS, we studied how every deliverable of the project is decomposed into "Work Packages". And that is where the WBS decomposition is stopped. And now, we have to create a schedule for the project. So, we will now continue to decompose every work package, even further into 'Activities'. Activities are also popularly called as 'Tasks'. This process of decomposing the work packages into tasks, is known as 'Define Activities' in the PMBOK.

--

On your screen now, is the ITTO diagram for the Define Activities process. Let us look at the key ITTOs, one-by-one. Starting with the inputs,

- The Schedule Management Plan will help define the schedule methodology (for e.g. CPM or Agile), the granularity of work breakdown etc.

- Scope Baseline will give you the WBS (i.e. deliverables & work packages), and the Acceptance Criteria.

- EEF provides the scheduling software, and other tools.

- OPA provides scheduling templates, procedures, guidelines etc that you must follow.

In the Tools & Techniques,

- Expert Judgment is recommended, and you consult SMEs if required, and you should get your work reviewed by experts.

- Decomposition (of course), is the technique you will use to breakdown the work packages. You will divide, and subdivide, until you reach the required granularity. This is exactly similar to the 'Create WBS' process we studied earlier.

- 'Rolling Wave planning' is the SPECIAL technique we will study in the next lesson. This technique is not required in every circumstance. It is only used in situations where we don't have much clarity on the work. More about this later.

- Meetings, as you can expect will be needed, mostly with team members, and with other subject matter experts.

Now, coming to the Outputs, there are 3 SPECIAL artifacts used specifically for this process - Activity List, Activity Attributes, and Milestone List. I will discuss all three in individual lessons, to give it the extra attention it needs. The Activity List is nothing but a list of the tasks that we will use to create the schedule, but it will have some more characteristics. More about this later in subsequent lessons.

As a result of this process, we might uncover some changes to the project requirements, resulting in Change Requests and possibly changes to the Schedule Baseline, and Cost baseline.

--

So, that's it about this process. In the upcoming lessons, I will go further into these special techniques, & outputs. So without further ado, I will see you there!

"Rolling Wave Planning" is a special type of planning technique. It is used in projects where the OVERALL SCOPE is well known at a strategic level, BUT there is not enough clarity for detailed planning. Consider an example, where the project involves the development of a Prototype early in the project. Stakeholders are expected to provide feedback on the prototype, and then we will take up detailed design BASED ON THE FEEDBACK, and execute the project. This might also result in going back to the design-board again, and building more prototypes. Rolling Wave planning is a good candidate in situations like this.

Planning happens in "Waves". Rolling Wave planning is a form of progressive elaboration (which I have mentioned in earlier lessons). The work that is to be completed in the NEAR TERM is planned in sufficient detail, and the work that is far in the future is only planned at a high level (for example, only the milestones are listed). This type of planning is viable for Agile projects, BUT it can ALSO be used in Waterfall approach.

When Rolling Wave is used in Waterfall, work will exist at different levels of elaboration and development, but the whole project will not move to testing or release until all the work is eventually developed. This is likely to result in changes to the Costs of the project. Now, let us look at the advantages of using Rolling Wave Planning, specifically from a Waterfall perspective:

1. Exploratory projects are those which you (or your Organization) has never executed before. In such projects, you will not even know how Design will unfold, and Rolling Wave technique is a great choice in such projects.

2. Rolling Wave gives you wiggle room. That is, it gives you some ability to recover from (time, scope and cost) decisions that you are not 100% sure of.

3. When there are a lot of risks, or 'unknown unknowns', rolling wave enables you to handle uncertainties.

4. If your project is under extreme time constraints, using rolling wave enables you to start development, even while you are designing other work that comes later.

5. Rolling Wave increases your adaptability with resourcing issues (whether it is with people, machines, raw materials, or budgets). It gives you some extra time for innovation.

So, these are some of the major advantages of Rolling Wave planning. The concept is simple. But before I end this lesson, here is a word of caution. It should only be used in projects where you can't plan in any other way! You should only use it in situations of uncertainty and time constraints that I have mentioned just now. In the next lesson we will continue with our project, and look at the artifact called "Activity List". See you in the next lesson!

In this short lesson, we will understand the "Activity List" artifact. This artifact is just a list of the ACTIVITIES (also called as 'tasks', or 'actions'), which are needed to complete the project, and produce the project deliverables. We get these activities, by decomposing the Work Packages from the WBS. That is, the Work Packages are divided, and sub-divided, until we arrive at the appropriate granularity of activities.

On the screen, you can see the Activity List for our ongoing Hospital EHR project. Instead of starting from scratch, the recommended technique is to use the WBS and extend it to the Activity List, as I have done here on the screen.  Every Activity should be identified with an unique ID. You can see these Activity IDs are highlighted in BOLD in our artifact. The ID need not be hierarchical, but it is a good practice to do so.

Who should do this breakdown of the Work Packages? That is, who identifies the tasks required to execute the Work Package? The answer is the 'Project Team'. The Activity List is ideally constructed by the person who owns the Work Package. It should NOT be the Project Manager. The Team Lead typically provides the technical guidance, and mentors the team member to generate the Activity List. The Project Manager should collate all the activities, curate it, edit as required, and create the final Activity List.

As you might have already guessed, this activity list will go on to form the schedule. We will do this in upcoming lessons, but there are a few salient points that I want to mention before we move on:

1. If the 'Work Package' itself is small enough (or granular), it can be retained as an activity without breaking it further.

2. You should ensure that there are no duplicated activities with same functionality, even if the activity name is replicated sometimes.

3. You should ensure that there is no overlapping activity. That is, multiple activities should not overlap each other on functionalities. This will cause confusion and conflict with team members.

4. You should go to the lowest possible item on each branch of work package. That is, you should try to achieve a comparable granularity amongst the activities.

5. At THIS stage of the project, you are not required to sequence the activities, that will come later.

6. Notice that VERBs are used in the Activity names, as a best practice. Verbs are the 'action words' in English language.

These are all 'rules of the thumb', and not hard rules.

Now, a question might have popped in your mind: "How can we design the activity list in Rolling Wave planning?". For projects that use Rolling Wave planning, or Agile techniques, you should update the activity list iteratively, according to the progress of the project. Even in many Waterfall projects, you might NOT be able to define all the activities at this stage, as some elements will be exploratory. In those situations, you can only decompose as best as you can, using some buffer placeholders. BUT, make sure this is clearly documented in the 'Activity Description'.

After we create the Activity List, the next step will be to analyze the activities to flesh out as much details about them as possible. These details are called as 'Activity Attributes'. These attributes will be important to create a realistic and efficient schedule, and we will study them in the next lesson. So, see you there!

In this lesson, we will discuss the Activity Attributes Artifact. This is how you expand the meaning of an Activity, by describing it with more details. Remember that an "activity" is just an individual task in your schedule. In the previous lesson, we discussed the 'activity list', please revisit it if you want a refresher. So, what do we mean by "Attributes" of an Activity? 'Attributes' are just the descriptive components of an Activity. Let's consider a simple example to make this crystal clear.

Imagine that you have created an activity in the Activity List, called as "Bake a cake". Naturally, several questions will then pop-up for this activity.

- WHO should bake the cake? WHEN should the cake be baked? HOW should the cake be baked? WHAT kind of a cake should be baked?

ALL of these questions can be answered by attributes, that you add to the original Activity. You might want to add EVEN more details: For example you might want to allocate 1kg of sugar, 1kg of butter, 1kg of flour as raw materials to this activity. You can do that too, with attributes.

You can go further than this, and say, "BEFORE you bake the cake, perform another activity: buy the materials from the shop". This becomes a 'predecessor activity'. Similarly, you can also say, "AFTER you bake the cake, prepare the lemonade". This becomes a successor activity.

--

On the screen now, I have listed 6 of the MOST COMMON attributes used with Activities - Duration, Start time, Finish time, Predecessor activity, Resource allocated, and Cost. These are not the only attributes that you can use, by any means! The very important point to note is this: These attributes change over time. Or rather, the attributes 'evolve' over time. For example, if one activity is delayed, then it may cause delays in other activities, i.e. a change in the start and finish times. Similarly, the person allocated to an activity might change over time. That is, attributes evolve over the duration of the project.

From this point onwards in the course, I will be showing a little bit of Microsoft Project; specifically for the project scheduling topics. This is just so that you build some familiarity with the most popular tool in the project management universe. I will not go any deep into the features and usage. If you are interested in learning Microsoft Project, please join my bestselling course on Udemy.

Returning back to our topic of Activity Attributes, let us see how they look in Microsoft Project. What you see here is an actual SCHEDULE. Every line here represents an 'Activity'. (It is just called as 'Task' in Microsoft Project terminology).

For example, in line 61, 'Review FSD' is an activity. It is followed by all the common attributes that I mentioned earlier: Duration, Start, Finish, Predecessor, Resource Name allocated to this activity, Cost.

In fact, Microsoft Project allows 100s of pre-defined attributes that you can use. Some of these attributes are used for TRACKING the schedule during execution, some others are used for Baselining, others can be custom designed for any data that you want to store, and so on!

And with that I will end this lesson. We have had a brief introduction to Activity Attributes. They are the descriptive components of an Activity, and help you define the activity as precisely as you choose to. Attributes evolve over the duration of a project. At the early stages, you will not have much details, but you should add more and more activity data as and when it becomes available. In the next lesson, we will discuss the concept of Milestones, so I will see you there!

Now we have arrived at the last lesson of the currently running 'Define Activities' process - and we will discuss the 'Milestone List' artifact in this lesson. But first, let us understand what a 'Milestone' is. A 'Milestone' is an important event, or a significant point in your project.

If you can imagine the schedule of your project to be like a roadmap, then milestones are the road-stones that show significant points of your journey. Milestones are used to monitor your progress, detect potential issues, and also ensure that you stay on track for a successful completion of your project. 

Here on the screen, you can see that we have identified 10 milestones for our Hospital EHR project. It is a common practice to use the same document as the Activity List, as we have done so. Milestones are CHECKPOINTS that are typically visible to both the internal project team, and also to the project sponsors. You can use Milestones to demonstrate your team's accomplishments, to manage all stakeholders expectations. You can also use milestones to signal issues and risks as they materialize on your project.

Milestones can be designated as Mandatory or Optional. Contractual obligations, regulatory requirements, and anything else that you deem as crucial events are MANDATORY milestones. Some milestones can be deemed OPTIONAL, when they are wishlisted (that is for 'nice to have' features).

Now let us see how Milestones are represented in modern scheduling tools such as Microsoft Project. Here on Line 20, you can see a Milestone. It is represented as a Diamond shape, differently than other normal activities. The very important point to note is that Milestones are a SPECIAL TYPE of activity. Milestones are activities with a ZERO duration. This makes perfect sense because they are symbolic markers representing certain events, and they should not have any work-related duration. This point is specified in the PMBOK also!

And with that I will conclude this lesson. We have had a brief introduction to the concept of Milestones. We saw the milestones for the EHR project, and we also saw how they are represented in Microsoft Project. They are used to highlight significant events, and accomplishments in your schedule, as a technique to track progress and expose risks. Be judicial in your use of milestones, don't overdo it. Milestones should be very specific, and not for some vague accomplishments.

In the next lesson, we will be starting a new process called as 'Sequence Activities'. This is the important process that leads to the creation of a schedule, from the activity list. We will learn some very interesting techniques, concepts, and a diagramming artifact. So see you in the next lesson!

In this lesson, we start with a new process called "Sequence Activities". This is the process in which we will identify the relationships among project activities. In the previous process, we had identified all the activities into an 'Activity List', and now we will define the LOGICAL sequence of work. Sequencing activities means, deciding which work will be executed first, what follows next, what work will be running in parallel, and so on. You will see later that there are a lot of logical rules and techniques that can be employed to create efficient schedules.

We should sequence the Activities to achieve the greatest efficiency, under the existing project constraints. Our goal will be to maximize resource utilization, and minimize cost, and time consumed. We will have to achieve the project objectives with the quality desired. It will also be to reduce risks, and issues.

On the screen, we have the ITTO diagram for the 'Sequence Activities' process. Let's look at them one-by-one:

1. The most important INPUTS to this process, as you would have already guessed are the Activity List, Activity Attributes, and the Milestone List. We have covered all these artifacts in the recently preceding lessons. The Assumption Log also will be important because it will contain any dependencies, constraints recorded during the Requirements analysis phase.

2. Coming to the Tools & Techniques, there are a bunch of powerful concepts we will be exploring. I will guarantee these will explode your scheduling powers exponentially. First, comes the 'Precedence Diagramming method' - where we will learn 4 UNIVERSAL relationships between activities. Second comes the 'Dependency determination and integration' - quite a mouthful - where we study the attributes of these activity relationships. 'Leads and Lags' are the next technique used to build realism into your schedule. Remember the more realistic your schedule is, the more engagement you will have with your team. The Project Management Information System (abbreviated as the PMIS) is just your scheduling software. In our case we are using Microsoft Project.

3. Finally, we come to the OUTPUTs of this process. The most important output is the 'Project Schedule Network Diagram'. The Network Diagram is universally recognized as the mathematical representation of a schedule.

We will explore all of these special ITTOs in individual lessons, and apply our learning to the ongoing Hospital EHR project. I will also be demonstrating everything in Microsoft Project. These lessons will be exciting, and highly packed with powerful information. So, let's get started in the next lesson, where we will jump into the first technique, so see you there!

This is a SUPER IMPORTANT lesson, where we discuss the technique called as 'Precedence Diagramming Method', abbreviated as 'PDM'. This is the core technique used to create the Schedule Model for your project. On the screen you can see a very simple example of such a model. Here the Activities are represented as 'nodes', and they are logically linked to one-another with arrows. These 'arrows' or 'directional links' are called as 'relationships', and they show the sequence in which the activities are to be performed.

The way to interpret this simple diagram is: Activity 1 will be the first to be started. And AFTER it is completed, only then is Activity 2 started - and completed. And finally, Activity 3 is executed. So, logically, Activity 2 is dependent on Activity 1. Activity 3 is dependent on Activity 2.

Activity 1 does not have a predecessor. It has one successor, which is Activity 2. Similarly, Activity 3 does not have a successor, but it has a predecessor. Activity 2 has a predecessor and a successor. A key point to note, is that we have to avoid redundant relationships.

--

Now, here is a realistic example of how such a schedule model will look in scheduling software such as Microsoft Project. This is exactly the same logic from the previous slide. The screen is split in two parts. On the left are the activities (aka 'Tasks'), and on the right are the same tasks represented as nodes which are graphically linked to each other with directional arrows.

--

Precedence Diagramming Method (PDM) includes 4 types of universal relationships. You can apply this foundational logic to any schedule in the world. I will show this logic within Microsoft Project. I will refer to our ongoing EHR project for all the examples to follow. As I give these examples, observe the links and activities.

1. The 1st type of relationship is called Finish-to-Start (FS). Here, the successor activity can not start, until the predecessor has finished. For example, we have to finish the staging server trials, BEFORE we start the production servers. This logic is the simplest to understand and most common in the real world. The activities will run one after another serially.

2. Second type of relationship is called Start-to-Start (SS). Successor activity can not start until predecessor activity has started. For example, new branding for the EHR can not start until the consumer data migration has started, but then it can run in parallel.

3. Third type of relationship is called Finish-to-Finish (FF). Successor activity can not finish until the predecessor activity has finished. For example, we can not consider Production Testing as completed, until the Production server infrastructure is fully setup. Here too, the activities can run in parallel.

4. Fourth type of relationship, and the strangest & rarest of them all, is called as Start-to-Finish (SF). The successor activity can not finish, until the predecessor activity has started. For example, the new EHR application has to be launch properly BEFORE we shutdown the older legacy hospital applications, thereby ensuring zero downtime.

So, these are the four horsemen of the PDM technique. These are foundational concepts and you should digest this thoroughly. The FS relationship is MOST common, applicable perhaps 90% of the time. The SF is the rarest and you should never use it unless the situation demands it. If you use SF, you will be demanded an explanation from whoever reviews your schedule!

A couple of final points before I wind up this lesson:

1. Sometimes, two activities can have multiple relationships, for example SS and FF can exist together. But as a rule, you should AVOID multiple relationships because it constrains your automatic scheduling. In that situation, you should choose any one relationship that best fits the logic.

2. You should NEVER have a closed loop in your relationships. Fortunately, modern tools like Microsoft Project prevent this happening in the system.

Okay, and with that I will close this lesson. Coming next up, we will learn about 'Dependency determination and Integration' technique which will give you a strong real life understanding of logical dependencies.

In this lesson, we discuss the technique of 'Dependency Determination and Integration'. As we have seen in the previous lesson, activities are linked by dependencies (also called as 'links', or 'relationships'). To build a realistic schedule, it is critical that we understand the true nature of these dependencies. And we will do that in this lesson.

Any dependency has four attributes, but two of them can be applicable at the same time, like this: Mandatory External dependencies, Mandatory Internal dependencies, Discretionary External dependencies and the last one is Discretionary Internal dependencies. Let us understand what these core attributes are, one-by-one:

1. Mandatory dependencies are those stipulated by contract, or government regulations, or it is inherent in the work itself. For example, if you are building some sort of a software project, then it has to run on some hardware processor. It is a mandatory dependency. If you are constructing a house, you have to build the foundation first. If the laws require that a bridge has to be constructed in a certain way, then it should be done so. These are all examples of mandatory dependencies. Mandatory dependencies are also commonly called as 'Hard Logic', or 'Hard Constraints'. But, an important point to note is that mandatory dependencies are not the same as Scheduling Constraints, that you find in tools such as Microsoft Project. Constraints (on the other hand) allow you to put boundaries on the flexibility of scheduling algorithms.

2. Discretionary dependencies, in contrast are also called as 'Preferential Logic', or 'Soft Logic'. These are dependencies that originate from DOMAIN KNOWLEDGE. These are the dependencies that arise from best practices, or expert knowledge. Discretionary dependencies will recommend a particular sequence of work amongst many alternate acceptable sequences. For example, the so-called 'Smoke Testing' is done on new software builds, before embarking on heavier testing. Another example from the construction industry recommends that plumbing work should be done BEFORE electrical work. But this is not mandatory. Sometimes both works may happen in parallel, or other times it may even get reversed. But following the best practices will reduce project risk, or reduce costs, or provide some other benefits.

Discretionary dependencies should be thoroughly documented, because it may limit your scheduling flexibility. If your project gets into difficulties, then these dependencies can be modified. It is the responsibility of the project team to determine which discretionary dependencies will be used in scheduling.

3. External dependencies are relationships between project activities and non-project activities. For our Hospital EHR project, government clearance might be required for data protection & privacy policies. The project team might not have much control over the dates on these dependencies. Another example is when you are expecting hardware vendors to release certain features to develop software upon. The project team should decide how they will work around external dependencies.

4. Internal dependencies are the relationships amongst tasks, which are WITHIN the control of the team. For example the EHR team can not demo to the stakeholders until they setup a working prototype. This becomes an internal mandatory dependency.

So, these are the 4 attributes of dependencies. Any two of them will be applicable at a given time. This analysis will help you build a realistic schedule. Always make sure you document the decisions taken in your scheduling software. Realistic schedules will not necessarily be the most efficient. But they will offer other benefits such as reducing risk, improving quality etc. In the next lesson, we will look at another related scheduling technique called as 'Leads & Lags'. So, I will see you there!

In this lesson, we will discuss the technique called as 'Leads & Lags'. This technique is used to increase the realism of your schedule. Your schedule should reflect the ground realities of your project. Leads and lags help you do this. This technique is best understood with some examples, and we will look at a few in the upcoming slides.

A lag is the amount of time that a successor activity is delayed, with respect to the predecessor activity. Lags are usually unavoidable. For example, consider you are sending a technical document for expert review. As you very well know, reviews never happen instantly; they take time. Fig 1 shows the activity diagram if reviews happened instantly.

Figure 2 shows a realistic picture, with a LAG of 5 days applied between the two activities. Modern scheduling tools with Critical Path Method (CPM) algorithms, will allow you to add lags into the schedule. And you should do so, whenever applicable. The most common textbook example for lags is from the construction industry, where a lag of some days is recommended for curing concrete, after laying it.

The opposite of a lag, is a LEAD. This is used in circumstances when you can advance an activity BEFORE it's predecessor is even completed! Consider the example on the screen: First task is to build a prototype, and second task is to test it. This is shown in Figure 1. However, in our EHR project, we have different components in the prototype, so that we can start testing some parts even before the entire prototype is built out. This is how a Lead is applied in Figure 2. The obvious advantage of doing so, is extra time gained on your schedule. However, you have to be a bit careful with leads. If both the activities are assigned to the same person, then obviously they will become overallocated, and you manage it carefully!

I will conclude this lesson with some key points:

1. A Lead is a negative Lag. A Lag is represented with a positive number. For example if we have a 5 day delay, it will be represented as "+5 day Lag". A similar 5-day lead is represented as "-5d Lead".

2. Leads and Lags can technically exist with all types of dependencies - FS, SS, FF, & SF.

3. Lags are often enforced upon you, but leads are often optional.

In the next lesson, we will bring together all the scheduling concepts we have discussed so far in the artifact called as 'Schedule Network Diagram'. This is the foundation of designing a full fledged schedule. So, see you in the next one!

In this lesson, we will discuss the 'Project Schedule Network Diagram Technique'. This technique is used as a foundation for schedule design, schedule analysis, and other lot of other techniques such as the Critical Path Method. We will be going into depth into all these other topics in upcoming lessons. So, it is very important that you understand THIS lesson well. The Schedule Network Diagram is a graphical representation of activities, and their logical relationships. 

On the screen, you can see the Network Diagram for our ongoing Hospital EHR Project. <Show different views here>. The activities are represented by rectangles. The dependencies are represented by the arrows linking the activities. Start and Finish Nodes are mandatory, and I have used milestones to represent them. Network Diagrams can be created manually, or using software tools. Network Diagrams can include full project details, or they have only work packages, or some combination of both. Remember Work Packages from the lesson on WBS. The Microsoft Project terminology for Work Packages is 'Summary Task'.

If your project is complicated enough to justify network analysis, then you should describe the basic approach taken to sequence the activities. (For example, why have you used SS, or FF links etc). Every major sequencing decision should be compulsorily documented, ideally within the tool that you use. In Microsoft Project, you can add Notes to any task. Any unusual sequences should be fully described.

Modern tools, such as Microsoft Project allows you to automate every aspect of creating a Network Diagram. I have actually created this diagram by starting with a high level Gantt Chart, and then switching views to study the Network Diagram. I will go to and fro between multiple views, until the schedule is perfected. Once the basic design is satisfactory, then the activity list is further broken down with smaller and smaller tasks. And the process is repeated again, until we reach the desired granularity. 

Okay, so what is special about this Network Diagram?

1. The longest path in this diagram (from start to finish nodes) is the Critical Path - it will tell the duration of the entire project. Microsoft Project is based upon the Critical Path Methodology.

2. There are two special types of nodes - Convergence path nodes & Divergence path nodes, that you should pay special attention to. Notice 'Node 2' is a divergence node, because it has multiple successors. It is risky node because it can impact multiple activities. It needs special protection by the project manager. Similarly, 'Node 22' is a convergence node, because it has multiple predecessors. This is also risky because it can be impacted by several other activities!

Okay, and with that I will conclude this lesson. This has only been a brief intro to Network Diagrams. Schedules are essentially analyzed as Networks, i.e. a part of mathematical graph theory. Please do not be alarmed by the math involved, because I promise to make it SUPER SIMPLE. Moreover, the use of modern software tools will mean that you never have to do any of this math manually. Another good news is that the PMP exam no longer has math questions for this analysis, like it used to in the earlier versions.

But you should have a SOLID grip on the logic that is involved, and we will cover everything in simple examples. We will do that in the upcoming sections. From the next lesson onwards, we will be moving on to ESTIMATION techniques. This is another of our project managerial super-skills. A lot of estimation techniques will be discussed, so I see you there next!

Currently for the ongoing EHR project, we are working on creating a realistic, and efficient schedule. So far, we have studied how to define activities, and then how to sequence the activities into a network diagram. The next logical step will be to ESTIMATE the effort & duration required to execute every individual activity. This will be done in the 'Estimate Activity Duration' process. We will take a deep dive into several important estimating techniques in the upcoming lessons.

On the screen now, you can see the ITTO diagram for 'Estimate Activity Duration' process. The key benefit of this process is that it will provide the amount of time each activity will require. You will be performing this process throughout the project lifetime. Let's look at the ITTOs one-by-one:

*The most important inputs, as you would have guessed, will be the Activity list and the Activity Attributes. There is a very important point to note here: the work estimate is to be made w.r.t to the Resource assigned to it. For example, if a task is assigned to a highly skilled resource, you might assume the duration will be lesser, than if it is assigned to lesser skilled resource. Similarly, if the task is assigned 2 resources, you might assume it will execute faster than if it is assigned to 1 resource. I know a lot of questions will be popping up now, but I will address them later in this lesson. For now, the point you have to note is that estimations are done with resources in consideration. Due to this reason, there are some other important RESOURCE-related inputs to this process: Resource requirements, Project Team assignments, Resource Breakdown Structure (RBS, which is similar to the WBS), & Resource Calendars. We will study them in much detail a little ahead in the course.

*Now, let's move on to the Tools & Techniques. There are 4 important estimation techniques that we will study in detail in the following lessons: Analogous estimating, Parametric estimating, 3-Point estimating, and Bottom-up estimating. Needless to say, these are super-important skills because you can apply these not only to Work estimations, BUT also to COST estimations! If you learn these 4 techniques, you will be able to face an extremely broad range of estimation situations in real-life project management.

*There are 2 important Outputs of this process, the Duration estimates & the Basis of estimates. Both are related to each other and we will later look at examples of these artifacts for our EHR project.

Estimation is a core-skill for the project manager. It is a mixture of about 80% Science, and 20% Art. And BOTH are forms of magic :-) In this slide, I want to give some insights into the estimation process. Effort and Duration estimates are determined from several key factors

- scope: what is the complexity involved, & whether your team has already handled similar projects?

- resource type & skill: do your resources have the required qualifications and what is their skill levels?

- number of resources: do you have access to the optimal number of resources that you require to deliver the project within the deadlines?

- resource calendar: when will the resources be available to you? what are their annual holiday plans? when will they be pulled out for other projects?

- constraints: what are the inherent constraints imposed on the project? For example, work might be halted in the monsoon season!

In all situations, it is important to note that estimations are progressively elaborated. It should always be done with consultation of the people who will actually do the work.

There are a few other important but subtle factors to be considered:

1. Law of Diminishing returns: If you keep adding resources to a project, you will NOT get a linear reduction in the duration! In fact, after a certain point, adding more resources will be detrimental to the project due to the communication and management overheads! This was famously brought to light in the seminal book: "The Mythical Man-Month", way back in 1975.

2. Advances in technology: harnessing the latest tech tools might give you exponential reduction in duration and resource requirements.

3. Motivation of staff - Student Syndrome is procrastination. Resources might tend to apply themselves only at the last minute. Parkinson's Law states that work will expand to fill the time allocated for it's execution.

All of these factors are extremely real situations you will face, and you should be prepared for. Keeping all these factors in mind, we will next study the actual techniques used for estimation. So, I will see you in the next lesson.

We will now begin our discussion of 4 estimation techniques, the first of which is 'Analogous Estimating'. The word 'analogous' means 'Similar or equivalent in some respects, though otherwise dissimilar'. This should immediately give you a hint how this technique is applied.

Analogous estimation can be used for duration (or cost) estimation of a single activity (or for the whole project), using HISTORICAL data based on similar activity or project. Let's consider an example: When discussion for our Hospital EHR project began, the vendors were asked for ballpark estimations for time and cost to delivery. The vendor then referred back to their historical data of past implementations of similar size and came back with analogous estimate of USD 8 million cost, and 6 months duration. These numbers were useful for initial discussions.

The vendor compared the current project parameters, with their database of past project parameters such as size, complexity, duration, & budget as the basis for estimation. This technique is a 'gross value' estimating approach, with adjustments made for the known differences in project complexity.

The advantage of Analogous Estimating is that it is very quick, it is cheap to perform, and it gives a quick feedback loop to the stakeholders. But it is also less accurate than all the other techniques that we will study. Analogous estimating is very intuitive, and you might have used it in your real life very often. Analogous estimating CAN be very accurate if the previous activity is factually similar to the current activity, AND if the project team members have experience executing the activity. If either of these are NOT true, then we should further refine the estimation in later stages, using other techniques.

And with that I will conclude this lesson. Analogous estimating is a quick and practical solution, used at early stages. Sometimes, a ballpark number is required for feasibility analysis or similar purpose, where you don't want to spend too much time or cost - and in those situations, Analogous Estimating is the correct technique to use. Remember, it is to be based upon historical data. In the next lesson, we will look at the next technique called as 'Parametric Estimating', where the accuracy will increase. So, see you in the next lesson.

The next technique that we explore is called 'Parametric Estimating Technique'. In this technique we apply a simple formula (or algorithm), to calculate the time (or cost), needed to implement an activity or the entire project. This technique is more accurate than analogous estimating.

To make this simple to understand, let us consider an example from our ongoing Hospital EHR project. The IT team has been asked to estimate the time required to install the Client software on desktop computers, all across the hospital campus. This client software connects to the EHR server, and provides access to all the different departments of the hospital. Approximately 100 computers at 40 different locations have been identified.

The IT department, in response, has prepared the Parametric Estimation that you now see on the screen. They have used a combination of historical and statistical data to create a simple formula. This table consists of a breakup of the functionality, the UNIT time required for individual tasks, and the parametric value (i.e the quantity). Simple multiplication and summation, will give us the total estimated hours for the entire exercise.

This is a perfect and simple example, of how you can use Parametric Estimating. It is extremely popular across all business domains. It is important to note that BOTH analogous and parametric estimating techniques use some sort of historical information. But analogous is considered less reliable than parametric, because it is more of a judgment call. Parametric on the other hand defines a correlation between the functionality and the final estimation. Parametric estimates can be applied to sections of a project like we have done here, or sometimes to the entire project.

And with that, I conclude this lesson. Next upcoming, we will discuss the very interesting 3-point estimating technique, so I will see you there!

In the previous lessons, we discussed the Analogous, and the Parametric estimating techniques. These are examples of what is called as 'single point estimates', because they essentially consider a single number estimate. 'Bottom-up' is another technique which is also a single point technique we will discuss in the next lesson.

We can improve the accuracy of any such single-point estimation technique, by considering the associated risk & uncertainty in the project. This technique is called the Three Point Estimating Technique. I will explain this technique by extending our example from the previous lesson.

A quick recap: The IT team has come up with an estimate of 400 hours, as the time required to implement client software for all desktop points in the Hospital campus. They had arrived at this number using parametric estimating in the previous lesson. We will take this 400 hours, to be our 'Most likely estimate Tm'.

But now, the IT Director decides to review the estimates. He points out that certain parts of the installation CAN be automated with scripts. And this would be a better approach for future maintenance. IF automation can be achieved, total time taken would be 300 hours. This will be our 'Optimistic estimate To'.

On the flip side, many computers have not been serviced from the past 1 year, and are pending software updates, since they are running legacy applications. If these systems are found to be incompatible, the estimates will shoot up to 800 hours. This is the worst case scenario. This will be our 'Pessimistic estimate Tp'.

So there we have have our 3 points of estimation - the most likely, the optimistic, and the pessimistic. What we do with these three estimates, will be revealed in the next slide.

Okay, there are many fancy formulas for this final calculation. But we will use the simplest method, which is in the PMBOK called as 'triangular distribution'. All we have have to do is add up the 3 estimates and divide the sum by 3. The work estimate so derived is 500 hours, which is a 100 hours higher than the parametric estimation from previous lesson, but it takes care of the risk and uncertainty in the work. And THIS is the 3-point estimate for our objective.

And with that I will conclude this lesson. Coming up next is the Bottom-up estimating technique, considered as both the most expensive, and most accurate estimating technique. So, see you in the next lesson!

In this lesson, we will discuss the fourth estimating technique called as Bottom-up Estimating. This technique is easy to understand, we drill down the WBS to the lowest level of activities where it will be possible to estimate, and then aggregate back to the work packages, all the way back to the top. This technique is the most accurate of them all, and also the most expensive to use in terms of the time, and effort consumed.

Observe the WBS example shown on the screen. The design happens from a Top-down fashion, we start by breaking down the top-level deliverables into work-packages. Then the work-packages are broken down into Activities. Once we reach the prescribed granularity (remember the 8/80 rule) of activities, then we can start estimating the duration for every activity. Aggregation however happens in the reverse direction, and we will work all the way up to the topmost layer, where the aggregate will give us the total duration for the whole project.

By the way, Aggregation of durations will not just be a simple case of summing up individual tasks. This is because activities can run in parallel. If you are doing this manually, you will have to draw up a Gantt Chart or something similar.

However, modern tools like Microsoft Project can automate everything for you. Here you can see a realistic example of a complex project schedule, where Bottom-up Estimating is used. These lines in BOLD are called Summary Tasks, and they automatically AGGREGATE the constituent tasks, using Bottom-up estimating technique. Summary tasks are a tree-like hierarchy, and they will aggregate all the way back to the entire project level.

Here you can see at Line 0, is the Bottom-up Estimation for the ENTIRE project. Just be aware that this Duration is not a simple summing-up, since tasks can run in parallel. This technique is applicable for Duration, or Costs, or Resource requirements, all three can be estimated accurately with Bottom-up Estimating technique.

A lot of tough decisions have to be made by the Project Manager while creating the schedule. These will include the development approach to be adopted, how the phases will be designed, how the activities will be broken up, the design of the schedule, which resource will be assigned to what tasks, and so on. The important point here is that PM should avoid unilateral decisions, and rather get the consensus of the team on technical aspects. This will ensure a proper buy-in from the project team.

In this lesson, we will discuss a decision making technique called as 'Fist to Five'. This is a variation of the simple voting method. In this method, the Project Manager asks the team members to show their 'Level of Support' for a certain decision to be made. Each team member can show their level of support from 6 choices:

A closed Fist means: 'I vote NO', or it indicates a strong opposition to the decision.

1 finger means: 'I will barely go along'. It indicates non-agreement but does not want to block a decision.

2 fingers means: 'I don't like this very much, but I will go along with what the others want'.

3 fingers means: 'I'm in the middle.' It can also mean 'I don't know enough eith sides to make a decision'.

4 fingers means: 'I am fine with this decision'.

5 fingers means: 'I like this decision very much, it is the best possible decision'.

The major advantage of the 'Fist to Five Voting Technique' is that it moves a team from QUANTITY voting to QUALITY voting. If any team member holds up lesser than 3 fingers then there are given an opportunity to discuss their objections with the team. The PM continues the discussion until a consensus is reached by the whole team, or they agree to move on to the next decision. This technique can be used in both Agile and Traditional development approaches.

We are currently within the 'Estimate Activity Durations' process. Using the 'Activity List' as an input, we have applied various estimating techniques to determine the duration estimates of all the individual activities. All these estimates are brought together into the artifact called as the 'Duration Estimates' document. You will find this sheet attached with this lesson. The Project Manager will typically collate this sheet together from different team members, who will estimate their own activity responsibilities.

There are three important points that have to be noted, at this point in our lesson:

1st point: Roughly 50 lessons back, we had discussed the Project Charter of our current Hospital EHR Project. The target Duration we had aimed for was 6 months (approx 120 working days). We have managed to achieve this target in the design, so far. There is still a lot of work yet to go into the schedule, but so far, so good.

2nd point: We have to understand the terminology 'Work effort' vs 'Duration'. There is a subtle pitfall here that has to be clarified. Typically in real life situations, you will start from the 'Work Effort' hours required to complete an activity, then divide it by the number of resources assigned to the activity, to determine the calendar working days - i.e. Duration. THIS is the duration we are talking about in the lesson, and not the work effort hours. Of course, if you have only 1 resource assigned to the activity, the effort hours and duration hours will be same numerically.

3rd point: It is a good practice to ask your team members for a confidentiality level of the estimates. All of these numbers are essentially estimates, and estimates are probabilistic in nature.

It is also a very good practice to explain how the estimates were determined, especially for the critical deliverables of a project. This is called as the 'Basis of Estimates', and we will discuss this in the next lesson. So, see you there!

In this lesson, we will discuss the artifact called as 'Basis of Estimates'. This is a document that will record the logic how every activity duration was estimated. As you might have guessed, all this applies equally well, to both resource estimates, and cost also. But I will only mention 'duration' for the sake of brevity.

Recording the 'Basis of Estimates', will probably be considered as an overkill of process, for small & medium, non-critical projects. But I urge you to follow this practice as a self-improvement exercise. Duration estimates are extremely hard to get right as a practicing project manager, and conscientious documentation will go a long way for you!

So, on the screen now, I have a simple but powerful example of the 'Basis of Estimates' for our ongoing EHR project. What are the key basis that you want to record for every estimation?

1. How was it developed? What logic was applied? Which estimating technique was used? Which resource provided you this data? Record all relevant data.

2. The key Assumptions that impact estimations, if any.

3. Any known constraint that might impact execution of the task.

4. The range of possible estimates, if there is a range of values.

5. Similarly the confidence level of the estimate and any key reasons.

6. Any key risks influencing the estimates.

These are just an indicative list of what you might include in the basis of estimates. What you document should be help you when you are executing the project, it should help any reviewer who is trying to make sense of the estimates, and finally these should help you estimate even better in the future. And with that I will conclude this lesson. We have completed all the background work required to develop the actual schedule, and we will be doing exactly that, starting with the next section. See you in the next lesson.

Starting with this lesson, we embark on creating the Schedule Model, using all the data from the earlier processes. We are starting a new process called as 'Develop Schedule'. You can see it here in our processes table. This will be the most complex, most important, and most critical process that you will perform, as the Project Manager. It will have a direct impact on the success of the project.

The important goal of the 'Develop Schedule' process is to create the 'Schedule Model' for the project. As depicted on the screen, you will use Activity Sequences, Durations, Resource requirements, and Schedule constraints to build the Schedule Model. Many learners and practitioners also, get confused with the terminology used here. What is the 'Schedule Model', and how is it different from the 'Project Schedule'?

The 'Schedule Model' is like a prototype of the schedule, that you can work with and experiment, until you are satisfied with the result. Once you have pieced all the data together, and ensured that it is most optimal schedule under the given conditions, then the resulting schedule alongwith actual calendar dates, is called as the Project Schedule. This will be the PRIMARY OUTPUT of this process.

On the screen now is the ITTO diagram for the 'Develop Schedule' process. This is a very busy diagram with lots of information, but since we have covered all the background information in previous lessons, I will directly cut-to-the-chase here and go directly to the important points.

1. As you would have already expected, the key INPUTS to this process are: the Activity List, Duration Estimates, and the Project Schedule Network Diagrams. There are also the resource-related inputs, which we are not focusing on right now, just to keep a check on the complexity of our examples. We will dive into those topics a little ahead in the course.

2. Moving to the Tools & Techniques, there are some super-important techniques we will be discussing in the lessons coming next: Schedule Network Analysis, Critical Method, Resource Optimization (some concepts I will introduce), and 'What-if Scenario Analysis'.

Schedule Compression is an important technique I will showcase in an upcoming different project, we will see in action, instead of just telling you the theory.

PMIS - is the tool that we use, and we are using Microsoft Project.

3. Moving to the Outputs, the important artifacts are: the Project Calendar, Schedule Data, Project Schedule, and the Schedule Baseline. All these artifacts, I will show you within the Microsoft Project context - so you will see Industry practices.

And with that, I will conclude this lesson. There is a lot of jam-packed lessons coming up. You should tighten up your seat-belt, but be rest assured, I will make it very palatable with easy examples and concepts. See you in the next lesson.

Schedule Network Analysis is a pivotal technique in project management that generates the project schedule model, ensuring that all tasks are identified, sequenced, and scheduled effectively. This analysis is essential for understanding the relationships and dependencies between activities, helping project managers to create a realistic and achievable project timeline. Within the PMBOK framework, Schedule Network Analysis employs several techniques, including the Critical Path Method, Resource Optimization, Modeling Techniques, and other analysis methods.

Using examples from our Hospital Electronic Health Record (EHR) implementation project, let's explore the key components of Schedule Network Analysis.

1. Critical Path Method (CPM):

The Critical Path Method is a crucial technique used to determine the longest sequence of activities in a project, which dictates the shortest possible duration to complete the project. Identifying the critical path helps YOU focus on the tasks that directly impact the project’s finish date.

For the EHR project, activities such as system design, development, testing, and training might form the critical path. Delays in any of these tasks will directly impact the overall project timeline. We will explore the CPM, in very next lesson.

2. Resource Optimization:

Resource Optimization involves adjusting the schedule to balance resource demand and supply. It includes techniques such as "resource leveling" and "resource smoothing".

For the EHR Project, if key IT staff are also involved in other hospital projects, resource leveling might be necessary to allocate their time effectively without overburdening them, even if it means extending the project duration slightly.

3. Modeling Techniques:

Modeling Techniques include "what-if analysis" and simulation (Monte Carlo simulation) to evaluate different scenarios and their potential impacts on the project schedule. For the EHR Project, by conducting a what-if analysis, the project team can understand the implications of delayed hardware or software delivery and plan contingencies accordingly.

4. Other Analysis Methods:

Additional analysis methods focus on understanding path convergence and divergence, path risk analysis, and overall project schedule feasibility.

Path Divergence and Convergence: Examines points where multiple paths split or merge, identifying potential bottlenecks or areas of increased risk.

Path Risk Analysis: Assesses the risk associated with different paths, particularly the critical path, to identify activities that might require additional focus or contingency planning. These are pretty advanced topics from the PMP perspective and we will not go any deeper on these mathematical analysis methods.

Now we come to the conclusion of this lesson. Schedule Network Analysis is an overarching technique that integrates various methods to develop a comprehensive project schedule model. By employing various techniques, project managers can create realistic, achievable schedules and mitigate potential risks. For the EHR implementation at All India Medical Sciences Hospital, these techniques are instrumental in ensuring the project is completed on time and within budget, ultimately leading to a successful deployment of the new system. An effective Schedule enables the project manager to foresee and mitigate risks, ensuring smooth project execution and delivery.

<CPM Intro>

We will now discuss the 'Critical Path Method' (CPM). It is an important technique that is used to calculate all the activity dates, project completion date, and different float (or slack) on individual activities.

-- <n/w diagram intro>

Nodes represent activities of the project,

dependencies,

parallel activities,

paths

just take a pen & paper, draw this diagram in freehand.

-- <calculate critical path>

intro

- there are 2 paths in this diagram - ABCE & ABDE

- the longest path is the Critical Path.

- This path determines the Total Duration and the Finish Date of the entire project.

- no loops

- Points of Convergence and Divergence

- Slack

Special Points:

- this is the FORWARD PASS because we went from Start to Finish

- Forward pass is used to calculate Critical Path

- there is also the Backward PASS

--Float

The Float of an activity is the amount of time it can be delayed, without impacting the total duration of the project. You have some precious bandwidth while executing the project.

At this point in our journey of developing an optimal schedule, it is time to discuss a couple of popular techniques related to Resources. As the Project Manager, your goal is to make optimal usage of resources while scheduling. Resources are always in short supply, and there are several common problems that you will face while assigning resources to the activities. Resources can be people, machinery, raw materials, or even budgets.

You will often find that critically required resources - are shared among different projects, so you have to plan the work according to their time availability! Or there may a limited quantity of resources available, so you can not deploy as many resources as you want to. In other situations, the same resource might be required to perform multiple tasks at the same time. Apart from these, there are many other domain-specific resource issues, that you will face in scheduling your project. In this lesson, we will discuss some techniques to resolve these.

Most resource problems will show up on the schedule, as an Over-Allocation. In this slide, I will first explain what an overallocation is. Later we will see a technique to resolve it.

On the screen, we have a Gantt Chart representing a small snippet of the schedule. There is a problem hidden in this schedule-model. Let's observe this diagram a little closer:

1. Notice that there are 3 activities - Activity 1, Activity 2, Activity 3. Activities 1 and 2, run parallel on the same day i.e. Day 1. Activity 3 is dependent on these two activities and runs on the next day.

2. If you observe here carefully, you will see the problem is that Beth is assigned 16 hours of work on ONE regular 8-hour day. This is an overallocation, where a resource is allocated more work than they can handle. Unfortunately, this type of issue is very common in design, and can be due to simple oversight, or due to any other issues mentioned previously. Next up, we will see a technique to resolve this.

One popular technique to resolve the overallocation is called 'Resource Leveling', and you can see the solution on the screen now. Activity 2 has been pushed to the next day, thus relieving resource Beth. As a result, the overallocation is resolved. The common side effect of this technique is to change the original Critical Path of the schedule. An extra day has been added to the schedule, in this example. You can, and should make use of any available float while you use this technique.

This example may look very simple, but in real-life projects with hundreds or thousands of activities to manage, it will be very difficult to detect & resolve optimally. And this is where modern scheduling tools like MS Project will make your life very easy. The builtin algorithms of Microsoft Project will take into consideration the Critical Path, the slack on individual activities, and on the total schedule, and different types of schedule calendars, to determine Resource Leveling.

I urge you to take a couple of minutes and study this Gantt Chart & the technique to become familiar with it.

The next technique is called "Resource Smoothing". This technique is not used to solve Overallocations. Rather it is used in situations where resources have predefined limits. For example, when a critical resource can only contribute a few hours per week, then you will want to schedule around their availability. Another situation is when you want to ensure your team members are distributed with equal work. In these situations you will use "Resource Smoothing".

Resource Smoothing technique is exactly the same logic as Resource Leveling - EXCEPT that we will take care NOT to impact the Critical Path. Tasks which are NOT on the critical path are adjusted so that their floats are used. This technique might not give optimal results, OR it might not solve all the problems, BUT this is acceptable.

And with that, we come to the conclusion of this lesson. Resource Leveling is used in more critical situations, for example when you have overallocation on the Critical Path. The resolution usually involves manipulating the end dates of the entire project.

Resource Smoothing on the other hand, involves manipulating end dates of individual activities (and not for the entire project). Both techniques are used in tandem. In the next lesson, we will look at another scheduling technique called as "What-If Analysis". So, see you in the next lesson!

In this lesson, we discuss a technique called as the, "What-If? scenario" analysis. While creating the schedule, you will have to make many decisions, based on hypothetical situations. "What if Scenario X happens?". "What if Y happens?" and so on.

You will be faced with evaluating different scenarios, to predict positive or negative effects on the project goals. Some of the common situations you will find yourself in are: evaluating different ways to build a schedule, change requests in the project, changes to resources in the team or to the allocations you have made, delays to major components, etc.

Now the big question is, how do I conduct the "What-If?" scenario. The answer is: Every scenario is to be analyzed by Network Analysis. You have to plan out the different scenarios, and compute all the parameters. Without the use of modern tools for scheduling, this is a difficult analysis to perform. But with tools like Microsoft Project, it is very simple.

On the screen now, I have the ACTUAL work-in-progress schedule for our ongoing Hospital EHR project. Microsoft Project will make "What If?" analysis, relatively simple for you.

Now, observe the task on Line #12: "Design EHR System Architecture". Imagine that the EHR Vendor gets back to you and says, we don't have to do this task, as a readily packaged architecture can be used". This is where yo will have to perform a "What-If" analysis, i.e. a Network Analysis has to be done. For this situation, it is as simple as just inactivating the specific task.

Instantly, you can see the network re-aligns automatically, thanks to Project's algorithms. The new Critical Path will show up automatically. Now you can make your decision. We just saw a very simple example, but you can perform all kinds of similar experiments, to evaluate different schedule designs, different resource allocations, studying impact of change requests, and so on.

And now we come to the conclusion of this lesson. The goal of 'What If' analysis is to:

1. Study project Outcomes under different scheduling conditions

2. To prepare for, and to justify schedule reserves. If you want extra budgets, extra resources etc on your project, present a powerful "What-If" analysis to your management and to your customers.

3. Finally, to prepare for different risk response plans, What-If analysis is unbeatable.

The Project Schedule will contain a list of 'start' and 'finish' dates, of all the activities required to deliver the project. To make sure these dates can be computed accurately, we need to maintain a "Project Calendar".

For projects which are smaller in duration and in resources, the minimum you have to incorporate in the Project calendar is your corporate Holiday List. So that you don't accidentally schedule the GoLive date on Christmas Day!

For larger projects with a great many resources and long duration, a lot of calendar work is required and it is foundational information in your schedule. I will also assume that you will be using some software scheduling tool. Here is a list of calendar-related factors you have to consider. I will go through them one-by-one:

1: First and foremost, is your own organization's Holiday List. Corporations will typically have around 10 national holidays mandated, and these need to be incorporated into your project calendar.

2nd factor: You have to configure the Work-Week. Because, roughly speaking, only half the world uses the default Mon-Fri work week. Your country or your client, might follow a different convention, so you might have to configure weekdays properly.

3rd factor: The standard work hours are 8 hours per day, 5 days in a week, and 40 work hours in a week. If your country mandates different conventions, please adjust your project schedule accordingly. If your team works in shifts, you have to configure that in the calendar.

4. You should also incorporate vacation plans of all key resources. If you need special machinery, or some special raw materials, you should also factor these into the Project Calendar.

5. Are there any special dates that are relevant to the Customer, for example if they are in different countries? You should incorporate them into the Calendar.

6. Are there any task-specific dates that need to be considered? For example, if a task is to be performed in a different time-zone?

So, this is a fairly comprehensive list of calendar-related factors that you need to consider for larger projects. Correspondingly, scheduling tools like Oracle Primavera and Microsoft Project provide you multiple stack-able calendars that you can configure.

On the screen is Microsoft Project's calendar architecture. Specifically, every schedule in Microsoft Project automatically inherits a BASE Calendar. Subsequently, you have customize it into a Project Calendar. Beyond that, you can OPTIONALLY customize further for specific resources, and for specific tasks. Primavera also has a similar architecture.

And with that, I will conclude this discussion on Project Calendars. In the next few lessons, we will discuss other artifacts associated with scheduling. See you in the next lesson.

When we talk about the project schedule, the first thing that comes to mind is the Gantt Chart. But there will usually be a  lot of other supporting data. In this lesson, we will discuss these other supporting data, and in the next lesson we will see the actual Gantt Chart for our EHR project. There are 3 major types of supporting schedule data - resource requirements, costing information, and alternative schedule designs.

Resource Loading is that aspect of project management which deals with how you assign and manage resources on your schedule. For larger projects, you have to minimize resource downtime, and then release the resources back to the resource pool, as soon as your work is completed.

On the screen you can see various design-patterns, in which resources are allocated to a project. These patterns are called as 'Work Contours'. They show the 'number of resources assigned' vs. 'time'. You can pause now, and take a moment to understand the different patterns.

The 'Flat' pattern, is mostly inefficient and used in smaller projects, with captive teams. The 'Bell Curve' pattern is most popular, and it is suitable for most projects.

Costing information for a project, is directly connected to the resource allocation, and work hours assigned. On the screen, you can see the costing information from a typical project in execution. If your project requires costing information to be monitored and controlled, you will typically start with the 'standard hourly cost' for every resource allocated to the project.

It is a best practice to document all the alternative schedules that you analyzed during the planning phase (remember: what-if analysis technique). This will typically include the best case and worst case scenarios, schedule design without resource loading, or without any customer imposed timelines.

In this lesson so far, we have discussed supporting data that is generated and documented with the project schedule. Apart from these major types of data that we have discussed, some other items will be cash-flow projections and other financial data, delivery schedules, training programs and so on. Okay, so now in this section, we have covered all the techniques and artifacts that leads up to the most important part of this section - the project schedule! In the next lesson, we will cover the project schedule, so I will see you there...

Finally, we have arrived at the lesson on "Project Schedule". What we see in this lesson is the culmination of 4 previous processes, lots of effort, dozens of tools and techniques. The Project Schedule will set a pulse to the whole project.

This view is called as a "Gantt Chart", invented by Henry Gantt, and made popular during World War 1 (more than a century back). I will assume you are already familiar with it. The Gantt Chart shows "What needs to be done? How long it will take? Who has to do the work?? When is the work to be done?" Correspondingly, you can see the same information visually graphed against the dateline.

Earlier Gantt Charts were drawn on paper, and they had to be manually re-calculated & re-drawn, every time there was a change in schedule. And we know how many changes will come in during execution :-)

Scheduling tools will automate all this work for you. Let me show a quick example. Observe this activity on Line #8, "Perform Stakeholder Analysis" . It is currently estimated for 5 days of work. The total project duration is 119 days. I will now increase the duration of this activity by 1 day, watch carefully what happens. 

You can see that the whole schedule automatically re-calculated and re-drew itself. The total duration is now 120 days, and you can see by the light blue colour in these cells, that a whole lot of activities were affected by the small date change. I will now revert the change, with a "Ctrl + Z".

Now, let's do one more experiment. Here, on line #23 is a activity called "Perform Quantitative Risk Analysis", and it is currently 3 days in Duration. I will increase the duration of this activity by 2 days. WHAT do you think this change will do to the Total Duration of the project? It is currently 119 days. Think of an answer before you proceed.

Okay, I will now make the change, 3 days to 5. There. You can see the change DID NOT make any major impact to the schedule. In fact, the total duration of the project did NOT change, it is still 119 days. Can you guess the reason why this did not change?

If the words "Critical Path", came to your mind, then you are absolutely on the right track!

<turn on the critical path>

On the Gantt Chart I have now highlighted the Critical Tasks. All the tasks on the Critical Path are now in PINK colour. You can see the task I modified was NOT on the Critical Path. It had some Total Slack. When we increased the duration, some of the Slack got eaten up, and it did not impact the whole schedule. I will now revert the change.

Now, I will change to a different view, which gives you the Critical Path information for all tasks. This fantastic view shows you all the information we calculated in the previous lesson manually - the Late Start, Late Finish, Free Slack, Total Slack. Microsoft Project gives you literally hundreds of views to analyze your schedule.

For our task on Line #23, you can see that there was a Total Slack of 5 days available, which is why it did not impact the total project duration. If all this is not making sense to you, you should watch the earlier lessons!

Once the project start execution, you can then TRACK the project inside the same file! I will now show a project schedule that is being tracked. Here is a different schedule that is in progress and being tracked for progress. The Percentage Complete for every activity can be tracked with a great deal of flexibility.

When tracking the progress of a schedule, we will always need a starting point to compare against. Without something to compare against, you can not track performance deviations. Microsoft Project allows you to create different snapshots of the schedule to compare progress against. These snapshots of the schedule are called as BASELINEs.

In this lesson, I have given you a very high level functional view of a realistic and modern Project Schedule created within a scheduling software tool. If you are interested in learning Microsoft Project, please join my course which has been a bestseller for

In the very next lesson, we will cover the last topic related to schedule planning - called as "Baselines". It is a very important lesson, so I will see you there!

In this lesson, we will discuss what the Project Manager will do immediately after creating the Project Schedule. The immediate next step will be to Baseline the schedule. We have discussed the concept of Baselines earlier in the course, so I will not repeat it now. Earlier, we had created the SCOPE Baseline, and now we will create the Schedule Baseline. A Schedule Baseline is a snapshot of your schedule. Baselines are needed to evaluate the VARIANCE of 'actual' versus 'planned' parameters.

You should create a Schedule Baseline, immediately after it is approved, and before you start tracking progress. You can create a baseline very easily in Microsoft Project. On the Project tab, you have the 'Set Baseline' button. In the dialog box that opens, you should choose the 'Baseline' option. Observe that there are 10 extra slots you can use to create additional baselines later on, if there are significant changes to your schedule during execution. When you click OK, the first baseline is created, and Project will store a lot of data for every single activity.

If you were NOT using Project, then you would manually store different files and call them 'ver 1', 'ver 2' and so on. That will be extremely tedious!!

Now, I am going to open a DIFFERENT project schedule and show you how baselines will help you monitor and control your project. Observe that we have a very simple schedule on the screen.

This schedule already has had some variation during execution - BUT you can't see that on the schedule. The only way that I can track deviations on the schedule is through baselines. And fortunately for us, this schedule already has multiple baselines saved.

First step - I will make the FIRST baseline visible on the Gantt. Notice the gray colored boxes on the Gantt? They show how the activities were ORIGINALLY scheduled. You can see that the activities have slipped during execution.

I will make the slippage visible now. Observe the additional lines in Black color show the slippage of each activity on the Gantt.

There are several other tools to analyze your schedule IF you have a baseline. For a fast and concise information, you can open the Project Information dialog box. This will give you a high level Variance for the entire project.

Then you can load the variance table, and it will show you the Start Variance and Finish Variance for every activity.

In this lesson, we have learnt that as soon as the schedule is approved, it should be BASELINED. Modern scheduling tools will allow you to create baselines within the software itself. If you DON'T create baselines, you will have NO way to analyze variance that occurs on your schedule. That's why it is SUPER CRITICAL that you create baselines. You can create more baselines too, during the execution of the project if there are significant changes.

And with that, I will end this lesson. We will next be moving on to a NEW SECTION, where we will discuss how to plan the QUALITY of your deliverables. See you in the next lesson!

We are now starting with a new ECO Task, "Plan and Manage quality of products / deliverables". At this stage of the course, we are only looking at the 'PLAN' aspects, and the 'MANAGE' aspects will come later. Over the next 10 lessons or so, we will have an intricate look into Quality planning.

'Project Quality Management' in PMBOK, includes 3 processes which are required to manage the overall quality standards of the project. Notice the 3 processes here. 1 of these processes - "Plan Quality Management" is in the Planning Process Group, and we will be covering it now. The 2 other processes, 'Manage Quality', and 'Control Quality' are for later, when we are executing the project.

First and foremost is the question: "What is "Quality"? We all inherently understand the meaning of the word "Quality". In simple words, it is the degree to which the deliverables fulfill requirements. Quality applies to ALL projects, irrespective of the nature of the deliverables. However Quality management techniques will be different for different projects. For example, how you manage 'software' quality, will be different from those you use to build a 'military submarine'.

In this important slide we will discuss some key concepts, which are unique to Quality Management.

1st concept is generic: 'Quality of a product', and 'Grade of a product' are not the same. A product might be available in different 'grades', which just means different functionalities or different technical characteristics. For example, Apple offers lower grade iPhones at lower prices. Higher grade products at higher prices. BOTH products might have the same high quality. 'Low grade' just means 'lesser functionality'. A Low Grade product with High Quality is acceptable. A High Grade product with Low Quality is always unacceptable.

The next 3 concepts should be understood by your team, according to your domain, industry and project.

2nd concept: 'Prevention' means keeping errors out of the development process, and in contrast, 'Inspection' means keeping errors out of USER's hands. There is a big difference.

3rd concept is tricky to understand: 'Attribute sampling' only checks for go/no-go (i.e. only conform or non-conform). On the other hand, 'Variable sampling' measures conformity on a continuous scale (that is, a measure of conformity).

4th concept: The term 'Tolerance' specifies a range of acceptable results. On the other hand, the term 'Control Limit' identifies the boundaries of variation, in a process.

We will come across these terms later in the lessons ahead.

Quality Management has 5 Levels of Effectiveness.

- The Most Expensive quality management is to allow customers to find your defects. You will lose customers, or have warranty issues, recalls, loss of reputation, rework etc.

- Quality Control is the next level, which is to "detect and correct" before sending deliverables to the customers. It is still pretty expensive with appraisal costs, and internal failure costs.

- The next level Quality Assurance is better. It means you are correcting and improving the PROCESS, and not the deliverables.

- The next better level is incorporating Quality into the planning and design of the deliverable itself. You prevent defects even getting born.

- Ultimately, the most effective and least expensive quality management, is to create a organizational culture of quality, into every process & product of the company.

The final topic I want to mention on this slide is called the "Cost of Quality". It is the sum of every single quality related cost incurred over the lifetime of the product.

In this last slide, I will quickly go through the current trends and emerging practices in quality management, over the previous 1-2 decades.

Customer Satisfaction is prioritized, by ensuring NOT ONLY conformance to requirements, BUT a "fitness for use". That is, ensuring that the product or service satisfies the REAL NEEDS of the customer.

Continuous improvement of processes using the Plan-Do-Check-Act (PDCA) cycle. There are other popular initiatives such as Total Quality Management (TQM), Six Sigma, Lean Six Sigma etc, that belong to this approach.

Quality is NOT just the responsibility of the quality team. Senior Management has to participate and be responsible for quality. It has to provide adequate resources, at adequate capacity.

Finally, in this modern world of project management, we recognize that our organization and our suppliers are inter-dependent. It is ONLY by mutually beneficial LONG TERM relationships that we are able to provide joint support to the customer's needs and expectations.

And with that, I will conclude this lesson. We are starting with a new PMP ECO task 'Plan and Manage Quality of Products and Deliverables'. There will be interesting tools and techniques and I will continue with our EHR project, to show you hands-on examples. See you in the next lesson.

"Plan Quality Management" is the next process that we explore in this lesson. Using this process we will IDENTIFY quality requirements for the project. Then we will DOCUMENT how the project will DEMONSTRATE compliance to the same quality standards. This process will provide GUIDANCE & direction to the project team, on how quality will be managed and verified throughout the project.

On the screen now is the ITTO diagram for the Plan Quality Management process. Let us discuss the key components one-by-one:

Starting with the inputs, there are no surprises here. The Requirements Management Plan, the Risk Management Plan and the Requirements Traceability Matrix are usually the key inputs to this process. The important point to note here is that Quality planning (that we are doing now), is to be performed IN PARALLEL with all the other planning processes. Changes to other plans will often trigger a change to the Quality planning too.

Moving on to the 'tools and techniques'. Expert Judgment is a key tool used to design the quality assurance, quality control, quality measurements, improvements and other quality systems for the project.

There are 7 different techniques we will be studying in more detail later for this process. Benchmarking is a data gathering tool. There are two data analysis tools we will study - Cost Benefit Analysis and I have briefly mentioned 'Cost of Quality' in the previous lesson.

There will be 3 data representation tools that will be useful in this process - Flowcharts, Logical Data Model, and Matrix Diagrams. We will cover Mind-mapping later in a different project. We will also study 'Test and Inspection planning' as a technique.

Moving on now to the Outputs now. The most important output of this process is (of course) the Quality Management Plan (abbreviated QMP). This will often be accompanied by the Quality Metrics artifact.

So, this process ITTO has been pretty straight-forward. And with that I will conclude this lesson. Immediately next, we will be diving into the detailed lessons, there are many new skills to be investigated. I will see you in the next lesson!

Over the next 7 lessons or so, we will discuss different powerful techniques used in Quality Planning. The first and foremost technique is called "Test and Inspection planning". It is used to determine how to test and inspect, the deliverable. The goal is to meet the stakeholder's expectations, and also ensure performance and reliability.

Tests and Inspections are Industry dependent. For example, software projects have different types of testing such as - Unit Testing, Smoke testing, Black Box testing, Functional Testing, Integration Testing, and so on.

Construction Industry projects has it's own well established set of testing, such as Soil test, Concrete compression test, Durability tests and so on.

Engineering projects will include different types of fields tests and nondestructive tests.

Similarly Manufacturing projects also will include appropriate testing, and they will also prioritize Inspection to ensure defects do not reach the customer.

For all types of projects, a common best practice is to design a comprehensive Test Plan for the entire project. Your test plan will include "Test Cases" for different aspects of your project. In the next slide, I will show how a classic Test Case will look in a software project.

On the screen now, you can see a pretty well designed 'Test Case' example, for our ongoing Hospital EHR project. The objective of this specific test case is to ensure that a new patient can be added to the EHR system, successfully.

The preconditions to testing are carefully detailed here. We will also list out every step of how the test is to be conducted. The important point is that you should be able to replicate the test exactly, every single time.

The Expected Results are listed out, so that the tester has a clear idea of what is the correct behavior of the system. A key aspect in this specific test case is that valid data is received in the mandatory fields. To make things even more crystal clear, we include the Pass/Fail criteria.

And with that, I will now conclude this lesson. 'Testing and Inspection planning' is a primary tool that is included in ALL projects, irrespective of the domain, industry, size or complexity of the project. In the next lesson, we will take an in-depth look at an extremely popular technique, called as "Benchmarking". See you in the next lesson!

In this lesson, we are going to discuss the extremely popular and versatile technique called as "Benchmarking". The concept is very simple. Benchmarking involves the comparison of our project with OTHER comparable projects. We learn a great deal by proactive, and productive comparison. The goal is to adapt new best practices, make quality improvements, and increase performance. Instead of re-inventing the wheel, we will first seek to learn from what is already available in the market.

Benchmarking is a versatile technique. It can be used for a broad spectrum of applications, such as business process benchmarking, financial benchmarking, performance benchmarking, operational benchmarking and so on. In this lesson, our context is Quality benchmarking.

Let us take our current Hospital (Electronics Health Records) EHR project as the backdrop for Quality Benchmarking.

Since this project is a first time (greenfield) implementation for our Hospital Quality Team, they need a starting point to design the Quality Expectations. They will need to understand what can be anticipated in terms of performance, accessibility, reliability, security, and other relevant parameters.

The simple solution for this challenge is to benchmark with other Hospital's EHR system implementations. The Quality team performs a benchmark study for these parameters, and establishes the Quality guidelines for the project.

Benchmarking technique can be summarized in 4 simple steps. The first step will be to a deeply understand what we currently have on hand. We start with an analysis of the existing quality of the product. This is where we recognize the parameters that will be benchmarked. The second step is to identify what products to benchmark against. We might benchmark internally, or externally against competitor products. The trick is to benchmark against the BEST of the best. You will not want to benchmark against substandard or defective, products or services. The next step is to act upon the learnings gained from benchmarking. We will incorporate the best practices into our own product. The final step is to review, & re-calibrate our product. What impact did the changes do to our product? Have we added value to the product? We have to ask these relevant questions and prepare to benchmark once again, if necessary!

And with that I will conclude this lesson. All of us are deeply familiar with benchmarking. It is prevalent in our Educational system, in our sports, and very much present in our corporate life. Online shopping sites like Amazon allow you to easily benchmark different products within minutes. In this lesson, we have seen the value of Benchmarking technique within the Quality aspect of our project.

We will continue our journey of Quality related techniques in the next lesson, where we will discuss a data analysis technique called as Cost-Benefit analysis. See you in the next lesson.

In this lesson, we will discuss a technique called as Cost-Benefit Analysis (often abbreviated as CBA). It is a technique to systematically study the strength-weakness of alternatives. This technique is generic, and can be applied to a wide variety of applications, but we will apply CBA to the Quality aspect of our ongoing EHR project.

On the screen now, you can see the Cost-Benefit Analysis performed on all the various Quality activities of the EHR project. There are 10 quality activities in the project, and every one of them has been evaluated for the estimated cost to perform, versus the total benefit they accrue to the product. 

Investing in quality comes at a cost, but there are several benefits that can be accrued. These benefits for our project are: Rework reduction, productivity improvement, stakeholder satisfaction, and an increase in profitability. These values estimated by expert judgment.

On the other hand, the costing for every quality activity is pretty straightforward. It is the cost per resource hour, multiplied by the total work involved. These values are based upon the schedule.

This Cost-Benefit analysis, has two major applications:

1. Determine if an investment is meaningful, secure and safe - and by HOW MUCH benefits outweigh the costs. 

2. To provide a basis for comparing investments (or decisions).

For example, suppose you you were forced to cancel any one these activities, which one would you choose? Alternatively, if you had extra cash to invest in quality, which activity would give you more bang-for-the-buck? You can make such decisions based on this Cost-Benefit Analysis.

You can find the analysis attached with this lesson. A brief write-up of every quality activity analysis is also provided in the same document. The final upshot of this analysis is that there is a 235% Return-on-Investment on the Quality Activities that we perform on this project.

And with that, I will now conclude this lesson. Cost-Benefit Analysis is a technique that has documented usage from more than a 100 years. It is a generic and versatile technique, that has a lot of applications. In this lesson, you have seen it applied to Quality activities of the project. In the next lesson, we will study yet another data analysis technique called as the 'Cost of Quality'. See you in the next lesson!

If we analyze every single cost, that is incurred on Quality in ANY project, we will see that they can be categorized into the following three types:

1. Prevention costs: These are the costs associated with preventing errors (i.e. building a high quality product). This includes training, documentation, high quality equipment, and the extra time required to do everything right.

2. Appraisal costs: This is the money we spend on quality resources (i.e. people, machinery, software etc), which required to measure, test, audit, and evaluate.

3. Failure costs: These are the costs related to failure which can occur Internally (within the organizational network), or Externally (within the hands of the customer). Internal failure costs include rework and scrap. External failure costs include liabilities, warranty work, and lost business.

Prevention cost and Appraisal cost together, is the money spent during the project TO AVOID FAILURES. So, this is called as the 'Cost of CONFORMANCE'.

Similarly, Internal and External failure cost is the money spent because of failures, both during and after the project. So these are called the 'Cost of NON-CONFORMANCE'.

The grand total cost, of conformance and non-conformance is called 'Cost of Quality', often abbreviated as 'COQ'. In the next slide, I will explain why it is important to know the COQ, and how to manage it.

Now that we have understood the concept of 'Cost of Quality', let us understand the technique of 'Optimal Cost Of Quality'.

Mathematical models demonstrate that there is an 'Optimal Cost of Quality', where money spent on ADDITIONAL prevention or appraisal costs, will not add value to the project. Additional conformance costs will neither be beneficial, nor cost effective. We can say that cost of quality is optimized when the sum of the conformance costs and the non-conformance costs is as small as possible.

And with that I will conclude this lesson. The 'Cost of Quality' technique is used to detect problems as early as possible, to anticipate potential failure costs, and prepare to handle all the quality issues on a project. Starting from the next lesson, we will learn about some data representation tools & techniques. See you in the next lesson.

In this lesson, we focus on FLOWCHARTs, used as a data representation tool. Flowcharts are so incredibly popular that I do not have to do a detailed introduction to them, and I will keep this lesson very short. Flowcharts are versatile and powerful because they can be used to show activities, decision points, branching loops, parallel paths, and the overall sequencing - all using different visual shapes.

The PMBOK briefly mentions a special type of flowchart diagram, called as the 'SIPOC'. You can use this special type of flowchart to study the value chain of an organization, as it will represent Suppliers, Inputs, Processes, Outputs and Customers in a single diagram. You will not need to memorize any of this for your PMP exam. You just have to  be aware of this type of a special flowchart called SIPOC.

Flowcharts are invaluable in Quality planning process, and therefore you should be well-versed in using flowcharts as a tool. You can see an example on the screen. In a previous lesson, we had discussed the 'Cost of Quality' aka COQ. The COQ is an estimated total of every quality cost of a project, including conformance and non-conformance cost.

Flowcharts are used in calculating the COQ. Cost related information is derived by using workflow branching logic, and it's associated relative frequencies. This will then be used to estimate the expected monetary value for the conformance and non-conformance work.

I will conclude this lesson by mentioning that flowcharts are also used to represent the steps in a quality process, and such diagrams are called as 'Quality Process Flow Diagram'. These diagrams are used for process improvement, and to identify where quality defects can occur. In the next lesson, we will discuss another related data representation tool called as the 'Logical data model'. See you in the next lesson!

In this lesson, we will explore another data representation technique called as the "Logical Data Model". In the simplest words, this is a visual drawing of the 'entities' that the business organization wants to collect data about, and the relations between these entities.

On the screen now, you can see a typical Logical Data Model for a Hospital EHR system. Observe here the entities that we will want to store data about are represented in the boxes: Patient, Problem, Observation, Treatment, Physician, Department etc.

Entities have descriptive attributes, listed within the boxes. For example, Patient entity has 'PatientID', which is also an identifier of the entity. All entities, similarly have atleast 1 attribute.

Entities are related to one-another, by 'Relationships'. These are the lines that join the boxes. You can represent different types of relationships such as: One-to-one, one-to-many etc.

This has been a high-level view of the Logical Data Model, and I will not go further into the description. Modern software tools allow you to create such a model, and then translate it into automagically into a physical data model. But this model, by itself, is database agnostic, and it is described in a business-compatible language.

Okay, now the million dollar question is: How is this model used in Quality Planning? The answer is that, this model can reveal where data integrity issues can arise. So, this logical data model is typically used in the quality planning phase. It serves as a perfect bridge to translate business logic to a technical language.

And with that, I will conclude this lesson. Coming next up, is the 3rd data representation tool called as 'Matrix Diagrams'. See you in the next lesson!

Matrix diagrams are powerful tools used to visualize, and evaluate complex relationships between multiple groups of information. Matrix diagrams can help you visually process a great deal of information, quickly and efficiently.

On the screen now, is an example of a Matrix Diagram. The mathematical definition of a 'Matrix' is a rectangular array, set out by rows and columns, like you see here. This example is a very special type of Matrix Diagram, called as the R.A.C.I Matrix (pronounced as 'racy'). Such a matrix diagram helps identify the people who are Responsible, Accountable, Consulted, and Informed, for a list of activities.

This is in fact, the simplest and most common form of a Matrix Diagram, called as an 'L-shaped diagram'. It is used when you want to compare 2 groups of items (or 1 group against itself). However, there are other (more complex) forms of Matrix Diagrams, and we will have a quick look at them in the next slide.

There are advanced forms of Matrix Diagrams, used to compare more than 2-groups of information.

The Y-shaped matrix is used to compare 3 groups of information. For example, when you want to compare Product features, development cost, and security.

The C-shaped matrix is another variation, which is ALSO used to compare 3-groups of information, but it is used when you have a larger dateset.

The T-shaped matrix is yet another variation, also used to compare 3-groups, but where 2 of these groups are unrelated to each other, but have to be compared against a common comparison list. It is essentially, 2 L-shaped matrices, connected by a single list.

Finally, we have the X-shaped matrix which is used to compare 4-groups of items. An example for this matrix is when you want to compare features, products, prices, and market shares.

And with that, I will conclude this lesson. Matrix diagrams are an extremely popular tool, and you will already be using it in a wide range of applications. We have also seen the advanced forms of Matrix diagrams in this lesson. With this lesson, we are now concluding the tools and techniques used in the 'Plan Quality Management' process. In the the next lesson, we will witness the most important output of this process, called as the 'Quality Management Plan' artifact. So, I will see you there!

Now, we have come to the most important lesson of this section, where we will see the 'Quality Management Plan (QMP)' Artifact for the EHR project. The QMP will become an important component of the Project Management Plan. The QMP will establish HOW the quality objectives of the project will be achieved. It will describe the activities that will be undertaken, and the resources required.

The QMP can be a formal or informal, it can be highly detailed, or it can be framed broadly. These factors will depend on the expectations of your key stakeholders. In all cases, the QMP should be thoroughly reviewed by competent individuals to ensure everything planned is accurate. 

On your screen now is a well-defined Quality Management Plan, created for our ongoing Hospital EHR project. Please feel free to download and have a detailed look at it. I will now go through the components of this artifact, which are all in compliance with the PMBOK.

The Quality Management Plan begins with a very brief summary paragraph. It is a brief introduction to the QMP document.

We begin with a listing of the Quality Standards that are expected to be met by the project. Since this is a Healthcare project, there are stringent quality expectations. This includes the relevant ISO standards for Medical Devices, Health Insurance portability requirements, etc. Notice that the PMBOK is referred here, for project management best practices.

The next section is for the 'Quality Objectives' of the project. We have taken care to ensure the objectives are measurable wherever possible, for example the system uptime is defined at 99.9%, data accuracy to 100%, software defects to less than 5 'major' open bugs etc. Your goal will be to keep these objectives PRACTICAL and achievable.

In the next section, we define all the Quality Roles (and their associated responsibilities). You should ensure the roles are well-defined, and they will cover all the interfaces between Quality department and the rest of the project. For example, we have defined the Project Manager, QA Manager, QC Analyst, Tech Lead etc.

Section #5, will explicitly list out the specific Project deliverables and processes, which are subject to quality review. This is done to establish the scope of the Quality Team.

Expanding further in this direction, section #6 will list out the specific Quality control activities planned for the entire duration of the project. This will include all the different types of Testing that will be conducted, such as Code reviews, Usability testing, Performance Testing, Integration testing, and finally going all the way to End-User sessions.

In the next section, we will list out the Quality tools that will be used for the project; If any of these tools need to be procured, that process should begin now. In this section, we can include our Project Management related tools too.

The final section will list out all the major Quality Procedures relevant for the project, such as - how we will deal with non-conformance, what are the corrective actions procedures, and what are the continuous improvement procedures. Please note that you are welcome to TAILOR any or all aspects of this artifact, MEANINGFULLY.

And with that, I will now conclude this lesson. You have seen a Quality Management Plan for the EHR project, which is based upon the PMBOK recommendations. The next lesson, will briefly go over the Quality Metrics artifact, which accompanies the QMP. And it will be the last lesson of this section, so I will see you there!

In this lesson, we will discuss the concept of Quality Metrics. These are specific project (or product) characteristics, that we can use to verify quality compliance. Let's take an example. For a racing car, the top speed achieved can be a quality metric. Quality metrics are extremely important for your project, because they can guide decision making, promote continuous improvement, and they can help you exceed customer expectations. Quality metrics are especially crucial in healthcare, customer service, manufacturing and other types of real-time projects.

On the screen, we have 21 Quality Metrics identified for our Hospital EHR project. They have been categorized into 9 types namely: Outcome metrics, Process metrics, Performance, Standards Compliance, Cost, User, Innovation, Environmental, and Health & Safety. Of course, all the metrics by definition, should be measurable with clarity. In this document, we have also included how the Metric is to be unambiguously measured. A short description is also provided here, to explain why the metric is identified and why it is relevant.

I would like to mention that Project Management also has Quality Metrics that can be tracked and studied. Schedule variance, Cost variance, and Earned Value (EV) are some of the most popular project management quality metrics. We will cover these later in the course, in a different project.

And with that, I will conclude this lesson. Please download this artifact and go through it. We have completed Quality Planning for the current project. Next up, we are moving into the exciting domain of Resources and Costs, so I will see you in the next section!

We are now starting with a new ECO task called as 'Plan and manage budget and resources'. A quick reminder, ECO stands for the PMP's official Exam Content Outline document, and it describes 35 tasks which form the basis of the PMP exam. This task is from the Process domain.

Like we have been doing previously, we will now unpack this task, and map it to the 49 process' table from the PMBOK. The focus of this task is on two key aspects of project management - BUDGET and RESOURCES. Currently, we will only be looking at the PLANNING aspects and the MANAGING aspects we will address a little later in the course.

On the screen now is the process' table from PMBOK. Again a quick reminder, we currently have 49 processes in the PMBOK (at the time of recording), but this may be altered slightly in the future, one or two processes might get re-aligned. It will not make any major differences, as this is currently an extremely stable design.

The boxes marked in GREEN, have already been covered in the course, so far. Our focus in this new section will be on the YELLOW boxes, which represent the PLANNING phases for RESOURCES and COST. The most important point for you to note and understand is that - RESOURCES and COST are always tied together for the Project Manager. All the costs are calculated from resourcing.

So, we will tackle the Resource Planning part first - there are 2 processes, 'Plan Resource Management' and 'Estimate Activity Resource'. Typically, in a project situation, we will execute these processes in parallel to building the schedule.

As a direct consequence to resourcing, we will also execute Cost planning, and there are 3 relevant COST planning processes that we will address in this section - 'Plan Cost Management', 'Estimate Costs', and 'Determine Budget'.

And, with that, I will conclude this lesson. I will again repeat that, as far as project management is concerned, Resourcing and Costing are tied to each other. The associated processes are closely tied to each other, and our starting point will be with planning resource management for the project. This is what we will do starting with the next lesson, we will study the process called 'Plan Resource Management'. There are a whole lot of new tools, techniques and artifacts coming your way, buckle up your seatbelt!

In this lesson, we will explore the process called 'Plan Resource management'. This is the very first process related to Resources that we are dealing with in this course. Before we go any further, let us first understand the meaning of the word 'Resources', as pertaining to project management.

We need resources to execute projects. Projects can not be run on thin air. From a project management perspective, there are three fundamental types of resources.

1st type is called as 'Work resources'. People (i.e. all your team members), and machinery, are examples of work resources. These resources are NOT consumed by the project. That is, after you complete one project, these work resources are still available to you for the next project.

2nd type of resources are called 'Material resources'. These are the 'raw materials' required for your project. For example, you might need cement, wood, paint, bricks, pipes, steel, software licenses, etc. These are resources that are CONSUMED by the project. They are not available for your next project, once you have used them up in this project.

The 3rd and last type of resources are 'Cost resources'. These are the extra monies required to execute your project. For example, you might need to take a trip to New York for a site visit. You might need to book meeting rooms, hotels, or seminar halls etc. This is the budget reserved for that specific purpose. Typically, this budget is linked to some set of tasks.

Plan Resource Management is the process where we will estimate, acquire, manage and utilize all these resources for our project.

On the screen now is the data flow diagram for Plan Resource Management. Let us begin by looking at the key inputs to this process.

The most important inputs here will be the Project Schedule, and the Quality Management Plan. These will be supplemented with all the usual suspects - planning artifacts.

Moving on to the Tools & Techniques, expert judgment (of course) will play an important part in planning resource as a lot of business domain expertise and negotiation will be required to get the resources we need.

We will be studying Hierarchical Charts and Responsibility assignment matrix in a later project. However, the most important tool at this stage is a strong understanding of 'Organizational Theory'. We will briefly discuss this in the very next lesson.

Okay, next up are the Outputs of this process. As you can surmise, the key output will be the 'Resource Management Plan'. Coming up later, I will show an actual artifact that you can download.

For significantly larger projects, we will also create a 'Team Charter'. This will document the underlying principles, and guidelines for managing resources, such as team values, conflict resolution process etc. Again, I will soon show you an actual artifact for Team Charter.

And with that, I will conclude this lesson. Many project managers often find Resource Management challenging, especially if they are new to people management. Understanding this section will be very rewarding to such PMs. In the next lesson, we will get an oversight of Organizational Theory, so I will see you there!

In this lesson, we will do a high level overview of Organizational Theory. I will begin by saying first that this is NOT a single theory, but a broad subject made up of interrelated concepts, that has evolved over roughly two centuries. Organizational Theory is a SOCIOLOGICAL study of structures, operations, and performance of formal social Organizations. That is the high level definition.

Let's ask the million dollar question first: "Why should you learn Organizational Theory"?

PMBOK makes it very clear that when we apply the common techniques identified in Organizational Theory, it will reduce the time, cost and effort required to both PLAN and MANAGE resource requirements. It will also help in improving all round efficiency, & your personal leadership in resource management.

So, these are the reasons why you should strengthen your knowledge of Organizational Theory.

If we consider the huge landscape of Organizational Theory, there are 3 broad categories:

1st up is the 'Classical organization theory': This originated from the Industrial Revolution. It views the organization as a MACHINE, and employees as cogs in the machine. There have been several famous thinkers who have expounded different aspects of this theory, such as 'Scientific Management' by Frederick Taylor, 'Administrative Management' by Henri Fayol, and 'Bureaucratic Management' by Max Weber.

Even to this date, many megalithic organizations, and governments are run on the principles first expounded by the Classical Organizational Theory, even though there are several criticisms of this theory.

2nd we have the Neo-classical Organization Theory. This injected the much-needed Humanistic approach to the classical theory. Human relations are important because this theory views organizations as a combination of both formal, and informal groupings. A famous experiment called as "Hawthorne studies", conducted by Elton Mayo in the 1920s was the foundation for this theory. Important concepts such as 'Employee Morale', and 'Leadership skills' were brought into prominence.

3rd up, we have the Modern Organization Theory, which as you can guess is the most recent iteration starting from the 1960s. This theory adopts SYSTEMS-THINKING approach, viewing the Organization as a complex system in it's totality. Several new concepts are emphasized such as flexibility, adaptability, culture and the interdependence of sub-systems.

Lastly, I would like to mention that the global pandemic from 2019 has had a tremendous impact on how Organizations function. Work from home with flexible timings is now a global phenomenon. In parallel, technology has made meteoric progress with internetworking, mobility, large data, and the latest being artificial intelligence.

These factors have impacted the way we view organizations, and also resource management. At this point of time we are only studying the impact of these factors and it can be predicted that there will be tectonic shifts to the way Organizational Theory will evolve in the future.

And with that I will conclude this lesson. The learning objective of this lesson is to encourage you to study Organizational Theory in much greater detail. This promises an all-round improvement in resource management, and it will also prepare you for the changes coming fast in the future. In the next lesson, we will move on to the "Resource Management Plan" artifact.

In this lesson, we will see an actual "Resource Management Plan" Artifact, for our ongoing Hospital EHR project. This Resource Management Plan, will eventually become a part of the Project Management Plan, and it will provide guidance on HOW resources will be managed on our project, from start to finish.

On the screen now, you can see the Resource Management Plan. I will now go through each section and explain as we go along. You can download this document and read through it.

1. We will start the artifact, as always with a brief Executive Summary of the relevance of this artifact.

2. The next section, titled 'Identification of resources', describes different methods that can be used for identifying, and quantifying all the team and physical resources required. This includes techniques such as expert judgment, historical data, and creating a Resource Breakdown Structure (RBS). I will show the RBS artifact for this project, in the next section. As you might have guessed, this will be a hierarchical structure like the WBS.

At this stage, we will also identify the key resources for this project, both Human resources and Physical resources.

3. The third section provides guidance on how to Acquire the resources that we need. This can include internal and external recruitment, Vendor procurement for both human resources, and physical resources.

4. The next section is very important because we will explicitly DEFINE the Roles and Responsibilities of team members.  For each and every Role, we will state the Authority given, Responsibility expected, Competency required!

It will be upto the Project Manager that these expectations are communicated clearly to the team members.

5. The 5th section is a visualization of the 'Project Organization Chart'. This is an organization chart at the project level. It should reflect the reporting structure, and it should clarify the escalation chain for all stakeholders.

6. The next section, deals with team resource management. This is guidance on how team resources should be defined (i.e. allocation and sizing), staffing (i.e. recruitment & On-boarding), managing (i.e. communications, performance monitoring and conflict resolutions), and eventually how resources are released.

7. Section #7 is dedicated for the training strategy. It summarizes the whole training lifecycle, from a 'needs assessment', to customization, delivery, schedule, and finally training evaluation.

8. Next up is 'Team development strategies'. These are the recommended steps to create a cohesive, high performing team.

9. The last and final section is the is for 'Resource control'. These are methods for ensuring adequate physical resources are available as needed, and that the acquisition of physical resources is optimized. We will control the inventory, allocations, budget, and contingency planning for shortage, or delays of resources.

Okay, and with that, we will conclude this lesson. We have seen a 1st hand example of Resource Management Planning. This artifact has been very elaborate, but brief at the same time. As you will very well surmise, this level of planning is only justified for large projects with a suitable budget, large number of resources, and a long duration. For more modest projects, you should only pick and choose the aspects that you want and which make sense on your project!

In the next lesson, we will continue on the resourcing journey and see the 2nd output of the current process called as the 'Team Charter'. See you on the next lesson!

In this lesson, we discuss the Team Charter artifact. This document is similar to a Project Charter, but it is meant for the Team that will execute the project. Just like the Project Charter, it sets a high level direction. And ideally it should be much less formal than the Project Charter.

A team charter is like a "game plan" for a project team. It helps everyone know what they’re supposed to do (and also "not do"), and also how to work together. Here is a breakdown of the main components expected in a Team Charter:

Why? Why We’re Here together as a team: This explains the main purpose of the team. Ideally, it should read like an short elevator pitch. Easy to memorize.

Big Goals: What we hope to achieve for the stakeholders, in this project and in the long run.

Specific Targets: Clear, measurable things we want to accomplish.

What We Can, and We Can’t Do: The Team's rights, and the limits of our team’s power and responsibilities. Also describe the conflict resolution process.

Who Does What: A list of each team member’s job and duties.

Key folks, Important People: Key people inside and outside the team who are involved in the project.

How We Decide Things: The process for making decisions, and for solving disagreements.

and lastly, How We Communicate: The best ways and times to talk to each other.

Creating such a Team Charter together, helps everyone stay on the same page and work smoothly. It makes sure everyone knows their role and how to get things done. This type of a document is especially relevant in a "work from home" environment. And, with that I will conclude this lesson. In the next lesson, we will be starting a new process, so I will see you there!

In this lesson, we will start with a new process called as "Estimate Activity Resources". As the name suggests, this is the process where we estimate the people, the raw materials, machinery & equipment, and other supplies, required to execute the project. In the previous process, we had planned how to manage resources and now we will do the estimations.

At this stage, I would like to re-iterate the fact that, resource estimation is always performed in parallel with costing process, such as 'Estimate Costs'. For the sake of simplicity, we will study the processes one-by-one, but in real life, you will be estimating the resources and their costs together.

Okay, now we will move on to the ITTO diagram for this process.

The most important inputs to this process will be the 'Activity list', and the 'Resource Management Plan' document, which we created in the previous process. These artifacts will be augmented by several other closely related project documents that we have created earlier.

In the tools & techniques section, there will be several important estimation techniques that we will be using, such as 'Bottom-up estimating', 'Analogous estimating', and 'Parametric estimating', just to name a few. We have covered all these techniques earlier while estimating activity durations, so I will not repeat them. And moreover, these same techniques will prove useful when we estimate costs also, ahead in the course.

We will study an important data analysis technique called 'Alternatives Analysis' in the next lesson. This technique is important because it has a wide variety of applications, and you can apply this technique throughout the project lifecycle.

Moving on to the Outputs section, there are 3 artifacts we will study (in individual lessons) - Resource Requirements, Basis of estimates and the Resource Breakdown Structure (abbreviated as the RBS).

And with that, I will conclude this lesson. 'Estimate Activity Resources' process is typically performed throughout the project, as and when required. The key objective of this process is to determine the type, quality, quantity, and characteristics of the resources we require to execute the project.

In this lesson, we will discuss one of the most common situation a Project Manager finds themselves in, and the corresponding generic technique called "Alternatives Analysis".

When you are estimating resources for activities, you will find that there are multiple options to accomplish the activity. For example, you might have the option of using one of the internal resources on your team who is less experienced, versus hiring an external consultant who is highly skilled but very expensive. This is the classic situation where you have to ANALYZE the ALTERNATIVES and make the best decision possible.

Another example is the famous "Build-Buy-or Rent" decisions regarding resources. Consider an example where you are building a software project. You need a small tool for your project. You will then have to take a decision whether you will buy the tool from a Vendor, or you will expend your own resources and build it yourself.

There is no single one-size-fits-all solution for this type of a situation. You will have to perform a Alternatives Analysis, as required for the situation on hand. You will consider the different factors that affect the situation, such as the discretionary budget available, operational cost, risks, effectiveness, and so on.

Alternatives Analysis ultimately helps in giving you the best possible solution, under the constraints you are under. One of the guiding principles will be that you do not outsource your team's core competencies. Everything else can be evaluated for alternatives that will benefit you.

In this lesson, we will discuss the Resource Requirements Artifact. It helps you document the type, and quantity of every resource for every work package in your project schedule. You will use it for procuring resources, justifying budgets, & calculating costs.

On the screen you can see the Resource Requirements captured in a tabular form. The first column identifies every Work Package. In Microsoft Project, the Work Package is typically a 'Summary Task'.

The second column is the Resource Type. In this column, you will capture all Work resources (i.e. Personnel, Machinery, equipment, etc), Material resources (i.e. raw materials), and any other Budget resources (such as extra monies required for travel, training etc).

The 3rd column is for the quantities of each resource that you require. You should be careful to specify units correctly, such as 'licenses, copies, rooms' etc.

The next column is a brief description. This will often be used as the account narrative, so be as brief and precise as possible.

The final column is for key assumptions made for the estimation. Remember that all the requirements here are essentially estimations. In the future, you might have to change these estimates, so it is a good practice to track your assumptions.

This is a well designed Resource Requirements document, and you will it attached with this lesson. Please download and check it out. In the next lesson, we will be moving on to another document, which will explain how we arrived at these estimations. It is called the 'Basis of Estimates'. So, I will see you there!

In this lesson, we discuss the 'Basis of Estimates' artifact. This type of an artifact is used to support ANY estimates we create during project planning. There are atleast 3 common instances when the basis of estimates will be useful - first when we are estimating Activity Durations, second when we are estimating Resource work, and third when we are estimating costs. I have already covered the 1st instance in an earlier lesson, with a downloadable sample. Now, we will explore the common techniques of estimating Activity-Resource work.

The GOAL of this document is to provide a clear and complete understanding of how resource estimates were derived (in the Resource Requirements document, that we saw in the previous lesson);

1. What is the METHOD used for estimation? For example, it could be Analogous estimation from similar earlier projects, or Parametric estimation, or any such methods.

2. What special information was used to create the estimates? for example, this could be historical data about productivity, or it could be machinery specifications.

3. What assumptions have been made to derive the estimates? For example, the Project Calendar with resource holiday list is one of the key assumptions.

4. What are the known Constraints embedded within our estimates? For example, every domain will have an ideal team size, which can not be increased without significant overheads.

5. Any estimate will be more meaningful when we provide a RANGE of estimates. That is, what is the best case estimate, and what is the worst case estimate? How much deviation from the estimate can be tolerated meaningfully by the business? All this information will give a RANGE of estimate.

6. What is the CONFIDENCE level of the estimate? If we have executed 100s of similar projects earlier, our organizations confidence level will be close to 100%. However, if this is a purely exploratory project, there will be UNKNOWN UNKNOWNS. That is, confidence level of the estimates will be much lower.

7. Last but not least, are the risks that are influencing the estimates. These could be key resources leaving the project. Old machinery that might breakdown. Or it could be dependence on rare and difficult to acquire raw materials.

All of these factors, (and anything else applicable to your project) should be considered while creating the Resource estimates. The 'Basis of Estimates' should then document all these factors. As you execute the project, it is very likely that you will revise your estimates and ask for more resources, OR release unused resources.

And with that, I will conclude this lesson. Next up, we will discuss the final artifact of this process, called as the 'Resource Breakdown Structure'. See you in the next lesson!

Now, we have arrived at the most interesting artifact of this process - the Resource Breakdown Structure (RBS). This is quite analogous to the Work Breakdown Structure (the WBS). Just like the WBS, the RBS also is a hierarchical breakdown, often visualized in a tree structure, like you see on the screen here. The WBS breaks-down all the Deliverables of the project, and the RBS breaks-down ALL the RESOURCES required to deliver the WBS.

On the screen, you can see the RBS visualized for our ongoing Hospital digitization EHR project. The KEY POINT to note here is that every category of resource is included in the RBS. Notice here that we have 5 categories in the whole project - Personnel, Materials, Equipment, Facilities, and External Services.

The same RBS is typically transferred to a hierarchical list form, as you can see in this spreadsheet. There are 3 further points to observe:

1. Every line has a simple unique identifier. This identifier also indicates the depth of the resource in the tree.

2. In this particular RBS, there are a maximum of 4 levels of resource classification. This is quite common in large projects, and sometimes you might go to level 10 also, specifically in the material resources.

3. We have not indicated the QUANTITY of resources in the RBS, but that is also perfectly fine. For very large projects, a separate RBS dictionary is also maintained. This will hold a lot of additional resourcing information can be added.

And with that I will end this lesson. This is fairly simple concept, especially since we are already familiar with the WBS structure. The key benefit is that the PM can visualize and plan the complete expanse of resources required to execute the project. This will be extremely useful in planning, budgeting, requisitioning, tracking, controlling Resources on the project. In the next lesson, we will be starting a new process, see you there!

In this lesson, we are starting with a new process called "Plan Cost Management". We will PLAN how all project expenses will be estimated, budgeted, managed, monitored & controlled. The objective of this process is to provide guidance on managing costs throughout the project lifecycle. This process is performed once during the planning stage (where we are at currently), and optionally at other predefined milestones in the project.

On the screen now is the ITTO diagram for the "Plan Cost Management" process. I want to re-iterate an important point here, which I have mentioned in earlier lessons also. TYPICALLY, all the project costs that the Project Manager has under their control, are directly or indirectly related to RESOURCES. This will be people & machinery costs, raw material costs, & and other activity-related expenses, such as training cost, travel cost and so on. This point is important because, the PRODUCT related costs (such as advertising, marketing etc) are typically NOT included in this process.

Okay, with that out of the way, let us look at the ITTOs, one-by-one:

1. The key input to this process, will be the Schedule Management Plan. The Risk Management Plan (abbreviated as the RMP), is also an important input because risk mitigation and contingency planning will also contribute to the costs, and they have to be justified into our plans. Of course, we have not yet covered the RMP in this course yet, and we will be doing that in the NEXT project.

2. Coming to the Tools & Techniques section, expert judgment plays a very important role in planning because experience from previous projects, industry information, cost estimating techniques specific to the domain, all come into play here. Many large projects use a technique called as 'Earned Value Analysis' and we will cover it in latter half of this course. Alternatives Analysis technique is used very frequently in planning comparing different approaches and resources.

3. There is a single output of this process, and as you should have expected it is the Cost Management Plan artifact. I will show a sample of this document in the very next lesson.

And with that, I will end this lesson. This is the first cost-related process we have encountered in the course. In real life situations, this process will be performed in-tandem with resource planning. I will see you in the next lesson!

In this lesson, we will investigate the very important 'Cost Management Plan' Artifact. This is the document that will specify precisely how the project costs will be estimated, structured, monitored, and controlled.

On your screen now is the Cost Management Plan for our ongoing Hospital EHR project. This plan typically includes the following information:

1. As always, we will start with a very brief introduction (or an executive summary).

2. Immediately next, we will establish the 'Level of accuracy for cost estimates'. You can see here, an accuracy level of +/-10% is set for all cost estimates, and we also recommend a contingency reserve of 15% on top of all the cost estimates, to account for unforeseen expenses and risks.

3. We will establish the 'Units of measure' for Currency, Time and Material Quantities.

Section 4 is for Variance thresholds. This answers the question "At what point of cost deviation should we initiate corrective action?". Management approval will be required. A brief 'action plan' is also put in here.

Section 5 is for the 'Rules for performance measurement'. We establish that Earned Value Management (abbreviated as EVM) will be used in the project to measure performance. This is a special technique of measuring performance covered later in the course. There are 5 metrics that we will measure and monitor. I will not go into these metrics for now, but they are briefly explained here.

Section 6 is for the 'Cost reporting information'. There will be 4 cost-specific reports generated on a monthly basis, and communicated to the key stakeholders.

Section 7 is very important as it explains our 'Process for estimating costs'. We explain how information will be gathered from different sources such as historical data, vendor quotations, expert judgment, and risk assessments. We also specify the different estimation techniques that will be used.

Section 8 will explain how time-phased budget will be developed. This is a mapping of costs to the schedule timeline. The cost estimations, after approval, will be baselined, for future tracking. Corresponding to this, we will project cash flow requirements for the remaining parts of the project.

Section 9 describes how costs will be monitored and controlled for the entire project. This will include periodic cost monitoring, change control, variance analysis for deviations, and corresponding corrective actions.

Finally, the cost management plan includes information on the level of authority associated with cost and budget allocation and commitment, funding limitations, and options and guidelines on how and when costs get recorded for the project.

And with that I will conclude this lesson. I urge you to download and read through this document. This document forms the foundation for Activity cost estimates, the super important Cost baseline, and also to the Risk register. In the next lesson, we will be moving on to the next process called 'Estimate Costs'. So, I will see you there!

In this lesson, we will investigate the Cost Estimate process. The OBJECTIVE of this process is to determine (i.e estimate), the money (i.e the monetary resources) required for the project. You will typically perform this process throughout the project, as and when it is required.

A 'Cost Estimate' is actually a prediction. It is based on the information that is known at THAT point of time. Such predictions should always be accompanied by the costing alternatives that you should have considered and studied.

Cost estimates should always be expressed by some suitable Units. Such as the 'currency of choice' - USD, INR, Dinars, Pounds, Euros, etc). If you have a captive in-house project team (i.e. Full Time Employees), then you might likely NOT estimate in monetary terms. In that case, you should choose to estimate in terms of 'person-hours', or 'person-days'.

Cost estimating process has a long-tail. You do not just END the cost estimating process. Throughout the project, you should keep refining your cost estimates. This will be possible when you TEST your assumptions. For example, you might have estimated that a certain technical training will cost USD 10K. During project execution, it might turn out that the training cost is hiked up to 100K.

From this example, it is also clear, that as we progress through the project, our estimate will become more and more accurate. In the case of a start-up, the accuracy might be as less as 25%. In more mature organizations, with many similar projects under the belt, the accuracy levels might be 75% and higher.

The final point is that your estimates should be all-inclusive. Do not forget to include not only the human resources, but also the raw materials, equipment, services, facilities, hardware, software etc. In the case of large projects, you might even factor in Inflation, currency exchange rates, risk contingency costs, the cost-of-financing, and other such advanced factors which are time-sensitive.

Okay, now let us move on to the ITTO diagram for this process.

The Project Schedule is the most important INPUT to this process. It will provide all the core information required to estimate the project costs. It will include the type, quantity, duration, of the team & all other resources active on the project. The cost & quality management plans will provide all the guidelines that form the  Estimation framework.

You can use all the estimating tools & techniques in this process. We have covered all of these earlier. In the very next lesson, we will study a new technique called as 'Reserve Analysis'.

Moving on to the Outputs, the Cost Estimates artifact will (of course) be the key output. We will see this as an artifact for our ongoing EHR project. We will also cover the Basis of Estimates specific to Cost estimations. You will find all of these techniques and artifacts pretty interesting. So, let's meet in the next lesson!

In this lesson, we discuss the "Reserve Analysis" technique. Specifically, we will discuss the "Contingency Reserve", which is under the purview of the Project Manager. The basic concept is very simple to understand - we will add an extra budgets to handle risks.

This technique is typically initiated in the 'Estimate Costs' process, where our objective will be to estimate the costs for the entire project. As you already know, this cost estimation will be conducted by breaking down the project into constituent activities, and then estimating the costs from the bottom-up.

The big question that we will face at this stage is, 'How do we handle risks'? That is, our project budget should NOT get derailed even if risks materialize. The answer to this question lies with 'Reserve Analysis' technique.

The first thing that we have to understand is that Risks can be of 2 types. First type are those risks that we have identified, also called as the 'Known Unknowns'. The MOST common example for this type of a risk is 'REWORK'. In most projects, we can take it for granted that there will be 'some' rework, though we will not know EXACTLY how much rework there will needed.

The technique used to handle this well-known situation, is to INCLUDE some extra cash (or time), in the budget to deal with this KNOWN risk. You might handle this situation perhaps by analyzing historical project data, and adding (say) 7% extra buffer cost for certain activities. This extra budget is called as a 'CONTINGENCY RESERVE'.

The 2nd type of risk are those which are 'unknown unknowns'. These are for risks we are not even aware of (at this point of time). In this case too, the solution is to add some extra cash (or time).

The difference between these two 'reserves' is that, the contingency reserve is under the control of the Project Manager, and it is added on top of the Cost Estimates and INCLUDED into the Cost Baseline. The 'Management reserve' (on the other hand), is under control of the Steering Committee, or the PMO. Everyone will know that is purely a guesstimate. It is a 'finger in the air' kind of an estimate. :-)

If you do not add these reserves, then every time there is a deviation in the plan, you have to go back to the sponsor, and convince them to release more money. With a little extra bandwidth, the negative risks might even out with positive risks too, eventually!

The MAIN ADVANTAGE of the Management reserve is that it has more flexibility. It is not sized by any quantitative methods. An exploratory project will require more reserves. Smaller projects might have Management reserve set at the engagement level, or department level, instead of at a project level.

And with that last point, I will end this lesson. It is a very good best practice to champion the cause of Contingency and Management Reserves. Projects are inherently bumpy roads, and these reserves are the shock absorbers of our project. Okay, in the next lesson, we will move to the 'Basis of Estimates' lesson. See you there!

In this lesson, we will discuss the different factors upon which the Cost Estimates are based. We will apply these techniques on the Hospital EHR project and create the 'Basis of Estimates' artifact.

We first start by documenting all the known costing ASSUMPTIONS. For our project this will include major assumptions we have made regarding the scope, vendor pricing, technical feasibility, and resource availability.

Then we move to the Known Constraints of the project, which will factor in the maximum budget cap, timeframes, compliance requirements, and the ongoing operations of the hospital. We should not disturb the running operations, nor the current & future patient support etc.

Then we have to factor in the known RISKS. This will enable us to justify, and plan for the Contingency reserves (which we have discussed in the previous lesson).

The estimates are not a single number. There will be a range of cost - ranging from the optimistic scenario to the pessimistic scenario. What we will be interested in is the 'Most likely scenario', which should be the benchmark for the project. The difference from the pessimistic number, can be the Contingency reserve (i.e. the extra cash that is pre-approved, and available for the duration of the project, to handle known risks).

The final point for the basis will be the confidence level in different aspects of the costing estimate. You can express overall confidence in percentage, and if required mention other confidence levels such as for labor costs, for technical challenges, and ongoing operations & maintenance. This will be important information to the project sponsor to plan the Management Reserves.

On the screen now is the 'Basis of Cost Estimates' artifact. You can download it attached with this lesson. I would like to mention that cost estimates are greatly influenced by the domain of your project. So you should feel free to customize and add any other relevant factors, & best practices of your project domain.

The technique we have discussed in this entire lesson, is called the 'Basis of (cost) Estimates' technique. This will be the foundation for the 'Cost Estimates' artifact which we will see in the next lesson. So, I will see you there!

OK, so finally we have arrived at the interesting, and important "Cost Estimates" for the project.

On the screen now is what is called the "Cost Estimating Worksheet". You will typically use such a worksheet, when you are using Quantitative methods, such as parametric estimation, analogous estimation, or 3-point estimations. We have covered all these techniques a little earlier.

The main question will be "How much granularity?". The granularity will depend on what stage of planning and decomposition you are at currently. This is going to be an iterative process. As you uncover more and more details, the costing will become more accurate.

Sometimes, when you have a captive team of Full Time Employees (FTEs), you might choose to calculate in terms of work-hours (instead of monetary costs).

Now I will go through all the columns and briefly explain them. You will be familiar with all these concepts from our previous lesson on the basis of cost estimates.

The 1st column is WBS Identifier. So we are tracking back to the WBS.

In the 2nd column we identify the Resource. This is tracked back to the 'Resource Requirements' artifact.

3rd column is for the Human Resource cost.

4th Column is for Physical costs such as raw materials tangible, & intangible (like software & licenses & cloud hosting in our case).

5th column is reserved for the Contingency Reserve - i.e. cash allocated for risk mitigation.

6th column shows the actual estimated monetary amount for every WBS work package. It includes the reserve cost.

7th column mentions the estimation technique used. Notice the different techniques used, as appropriate.

8th column states the primary underlying Assumption and/or Constraint for the estimation.

9th column explains the main basis for the estimation. For example it may be based upon hourly contract rates, or historical data from previous projects.

10th column is for the range of estimation, the optimistic to the pessimistic numbers, as and where applicable.

11th column is a personal approximation of our Confidence Level on the estimates. You can see from our numbers that we have pretty high confidence on the estimates.

All these numbers are with the understanding that EHR software and licenses are provided by the Software Vendor. The entire implementation will be maintained and operated by the Hospital IT team. The costs include project implementation plus 3 years of maintenance.

And with that, I will end this lesson. It has taken us a lot of effort, domain knowledge, and specialized project management techniques to arrive at such a simple breakdown of cost estimates. Once this cost estimate is APPROVED by the sponsor, we will then create a "Cost Baseline". We have already covered Scope baseline, & Schedule baseline. In the next process, our objective will be to create the Cost baseline.

In this lesson, we will discuss the next cost process called "Determine Budget'. The key objective of this process, is to determine the 'COST BASELINE' for the project. We will need this 'cost baseline' to monitor, and control project performance.

But before we jump into the new process, we have to first understand what really makes up the 'Project Budget'. What I will explain now, is necessary for running LARGE projects, in large organizations. Smaller projects will not need this level of detailing, so you can just tailor the process as needed. Okay, let's get into it now.

Observe this diagram on the screen. When we first start estimating costs, we will take a 'Bottoms-Up' approach. We will estimate costs for individual activities, and add Contingency Reserves at an Activity level. We have done all of this in the previous few lessons.

In the next step, we AGGREGATE activity costs into 'Work Package Costs', in exactly the same fashion. This will become necessary in large projects, to make it more manageable. You might probably have different team leaders, managing different vendor work packages. So far so good.

At the work package level, we will have different risks. So, once again, we can add another round of Contingency Reserves to manage risks. Every Work Package, plus it's own contingency reserve (if required), will be called as 'Control Account'. These control accounts can then be integrated into your Company's financial software, and thus tracked by the project sponsor, the finance team, the steering committee, and so on.

The Budget at this stage has to be formally approved by the Project Sponsor, or the Steering Committee. This approved budget model is called as the 'COST BASELINE'. Any further changes to the cost baseline, will require separate approvals, and version control.

As the FINAL STEP, the Management has power to add ANOTHER extra discretionary budget on top of this, called as the 'Management Reserve'. This is a contingency buffer for unknown unknowns. We discussed this earlier in the 'Reserve Analysis' lesson. This final budget model will be the "Project Budget".

So, this is the technique of building up the project budget with all checks & balances in place. You can tailor this template (for smaller projects), by dropping out any extra steps that you don't need, and adding anything else relevant to your project. Always maintain traceability.

The Project Manager thus uses 'Determine Budget' process, to create the Cost Baseline.

On the screen now, is the familiar ITTO diagram. In this process, we will be aggregating activity costs into Work Package costs, for every item on the WBS, or the Project Schedule.

Let's start with the Inputs. The 'Activity Cost Estimates' will be the MOST relevant input for this process. ALL the other project data we have uncovered thus far, can be used for reference.

We will discuss new techniques - Cost Aggregation, Historical Information Review, Funding Limit Reconciliation, and Financing. We will be very brief, and not delve too deep into the financial waters, limiting ourselves just to the PMP exam perspective.

Moving on to the Outputs, the key objective of course, is the Cost Baseline. This is, just the approved version of cost estimates, put under change control. Project Funding requirements is also another important output. But it is not consequential to the PMP exam.

And with that, I will now conclude this lesson. In the next lesson, we will take up the technique called 'Cost Aggregation' , so I will see you there!

In this lesson, we will discuss a fundamental and simple technique called as 'Cost Aggregation'. This is primarily used to determine the budget for a project. The concept is very simple to understand - by using a 'bottoms-up' approach, we will start with Activity-level costs, and start aggregating upwards into Work Packages, all the way to the top, for the project level costs.

Modern scheduling software tools, such as Microsoft Project (on your screen now) and Oracle Primavera, automate this entire process of cost aggregation, so it is no longer a tedious and manual process. Moreover, aggregation is something that is always available to you, and you can see the costs building up as you create a schedule.

Within Microsoft Project, the cost aggregation is always available at the Summary Task. There are many benefits to using a scheduling tool like this, because you get aggregation not only at the planning stage, but also during project execution, you can aggregate the actual costs, and all kinds of variances (such as cost variance, duration variance and so on). You can download this file, attached with this lesson. You will be able to open this file and play with it if you have Microsoft Project installed or you can view it on Planshare.ai website.

Aggregation is necessary not only for the costs, but also for all the other parameters such as work, duration, start & finish dates. But, not all parameters are a simple summation like the cost. Specifically, 'Duration' is NOT a simple summation like 'Cost'. Can you guess the reason WHY, duration is not a simple summation? Neither are the 'start' and 'finish' dates. 

I want you to answer this question in the Q&A section of the course. Create a new discussion, with the title 'Why duration is not a simple summation?', and present your answer to this question. I will give you a hint: think serial and think parallel.

Okay, and with that, I will end this lesson. Aggregation is a vital technique (not only for costs, but for all activity parameters), BUT modern tools can automate it completely. HOWEVER, you should understand perfectly how the different parameters are treated, not everything is a summation. In the next lesson, we will move on to another technique used in determining budgets, called as 'Historical Information Review', so I will see you there!

'Historical Information Review' is a technique that is the foundation of three other important techniques - Analogous estimation, Parametric estimation, and Mathematical Modeling. "Historical Information" means any details or data from past projects, that can help a project team or PM make better decisions on their current project.

This information includes things like designs, reports, project files, emails, notes, old contracts, and other artifacts from past project events or activities. These resources give the team a better understanding of what happened before, and help them plan for the future. This information can be vital to determine project budget. The technique is to extract INSIGHT, and BACKGROUND from historical information.

There are 2 pitfalls with this technique: it will cost you valuable time (and other resources) to conduct this historical review. And the second pitfall is that you might sometimes not know, how accurate the data is!

To avert these pitfalls, there are 3 key aspects that you should consider first:

1st aspect: What was the OUTCOME of the past project that you are reviewing? Does it align with your own objectives? To state the obvious, you should check the outcomes of the project first before you jump into a full historical review. Ensure that your objectives match the previous project's outcomes! Else, you might end up in the wrong direction.

2nd aspect: Are the parameters QUANTIFIABLE, and therefore replicable? Sometimes projects succeed due to unpredictable market configurations, unique weather conditions, extraordinary resources, or other such situations. These special conditions MAY NOT show up in the project artifacts you are reviewing, so you should be actively looking out for such conditions in your review.

3rd aspect: Are the learnings SCALABLE? What are the boundary conditions to the lessons learnt from previous projects? Will they apply to your large project? Or are they constrained only to a certain size of projects?

As you have been experiencing in our ongoing EHR project, a wealth of useful information can be transmitted via artifacts to the similar future projects, of Hospital EHR implementation. Historical Information Review is a very valuable technique, and it helps in the maturity and evolution of organizations. In the next lesson, we will briefly discuss project financing. So, I will see you there!

In this lesson, we discuss the technique called as 'Project Financing'. This involves acquiring funds for the project. If a question pops up in your mind "Why should the Project Manager be responsible for financing? Is it not the responsibility of the Project Sponsor?".

Well, the answer is that it will not be true in all situations. Large projects, specifically for long-term infrastructure (like highways, bridges, tunnels, airports etc), large scale industrial projects, and public service projects (such as railways) will commonly seek external funding. And it will be expected of the Project Manager to provide the necessary technical support to Financing. And this is the reason that financing is included as a technique in the PMP exam. This will not be necessary in smaller or internal projects.

When you work on large projects that require external funding, then you will typically be part of a team that seeks funding. It may include Subject Matter Experts (SMEs), Architects (software architects, building architects, solution architects etc), Business unit heads, CXOs etc. Your critical input to this team will be that you would have determined the resources required and budget required for the project. Remember we are currently within the 'Determine Budget' process.

As a final point, it should be noted that, external funding will come with it's own extra set of requirements that have to be met. These extra requirements will depend really on the type of Financier you have approached. For example, if the Government is the financier, they may set some deadlines and quality standards that have to be met. Other types of financiers might seek equity in the new product, or a share of the profits. In all cases, the Project Manager will have to factor in these extra requirements by the financier.

And with that I will conclude this lesson. In the next lesson, we will discuss a related topic called as 'Funding Limit Reconciliation', so I will see you there!

In this lesson, we will talk about a financial technique called as 'Funding Limit Reconciliation'. This is a technique that is used to ensure the release of project budget, MATCHES the project execution. This is called as 'reconciliation'.

The best way for you to understand this technique is through an example. On the screen now, you can see the schedule of a project that is under execution and it is actively being tracked. You are seeing the Gantt chart in this view. Please observe that we are tracking the costs of every task, and costs are being rolled up at the work package level (in the summary tasks), and also at the entire project level.

Now, I am going to show a special financial chart that shows the cumulative costs incurred on the project, versus project progress. The estimated total budget for this project is roughly half-a-million dollars.

There are some important points to observe at in this chart:

1. Most Waterfall projects will have this typical 'S-shaped' curve. There will be a slow gradual ramp-up of resources at the beginning of the project, and hence required costs also will be lower at the beginning.

2. When the project completes planning phases, and enters into execution phase, the cumulative costs will shoot up, since this phase is when the maximum resources will be loaded on the project.

3. After execution, as the project approaches deployment, the resources will gradually get released from the project, and you can see a corresponding slow down in the cost burn.

You will already be very familiar with this nature of Waterfall projects. 

Now, the big question is, how do you ensure that the budget is released to you, matching this nature of cost burnup? The answer lies in 'Funding Limit Reconciliation' technique.

There are 2 aspects to this technique:

1. Firstly, you should ensure that the Payment Terms for budget release should match this cost burn, in the contract. For example, you might ask for $50K to be released for Planning. Next 300K for development, and the final payment ~100K for deployment.

2. The second aspect is a little tricky, you should ensure that you DO NOT burn more cash than what has been released. The prescribed way to do this is by using Date Constraints in the schedule. You will thus ensure that your schedule progress matches the budget released. Scheduling tools such as Microsoft Project have different date constraints built into it, that you can use. Or you can manually constrain the project to match the budget that is released.

So, this is how Funding Limit Reconciliation works. You will first ensure that appropriate budget is released for your project engine to run smoothly. Secondly, you will control the speed of execution (using date constraints), to match the cash fuel does not burn out too quickly.

And with that, I will conclude this lesson. The next lesson will be on 'Cost Baseline', and it will be the last cost-related topic in the current hands-on project. So, I will see you there!

In this important lesson, we will discuss the "Cost Baseline". I will keep it extremely simple, so that we focus on the logic, and we are not lost in the technicalities.

First and foremost, let's revisit the concept of a BASELINE. When we are in the planning stages of a project, we are making a lot of predictions about the future of the project. Specifically, there are 3 major predictions - the Scope baseline, the Schedule baseline, and the Cost baseline.

When we start to actually execute the project, real world forces will push and pull our plans. At that time, it is our Baselines that provide us the direction. We will want to stick with our plans as closely as possible. But changes are inevitable, in any real life project. When changes occur, we measure them against our baselines. It is like a GPS map, showing the direction and distance to our destination.

The important point to understand is that all baselines should be APPROVED by senior management, and it should be under formal change control.

--

On the screen are 2 charts. BOTH of these diagrams explain different dimensions of the Cost Baseline. I have explained both of these charts and concepts in previous lessons, so I will keep it brief for this lesson.

The diagram on the left shows how the cost baseline is constructed. It begins from the Activity level costs. The 'Cost Baseline' is just the APPROVED version of our predicted Cost Estimates. It can include various levels of contingency reserves, at the activity level and work package level. But it does not include the Management Reserve.

--

The diagram on the right, shows a typical time-phased view of the cost baseline. That is, the predicted cumulative costs incurred on the project. For projects based on predictive methodologies, this will form the famous S-Curve. This is covered in the previous lesson.

Large organizations running mega-projects, will use this same S-curve with an advanced technique called as 'Earned Value Management', and it will be referred to as the 4th Baseline - 'Performance Measurement Baseline'. This will become relevant only during project execution.

And with that, I will conclude this lesson. Scheduling tools like Microsoft Project provide excellent automated support for the Cost Baseline. For example you will be able to save 10 different versions of the main baseline, for changes that might occur during the project! Also, you can track deviations in the actual costs to the original predicted costs.

In the next lesson, we will be starting the last section of the EHR project, and we will be covering Project Communications. There are new interesting concepts and techniques to learn, so I will see you there!

Now, we will begin with a new PMP ECO task called as, 'Manage Communications'. A quick reminder that ECO stands for PMI's 'Exam Content Outline' document. Like all the other similar ECO tasks, this also should have been named 'Plan and Manage Communications'. But, this is just a small misnomer. And also, we are only focusing on the 'planning' aspects of the project now, and we will be covering the 'managing' aspects of communications, a little ahead in the course.

Communications form a very large part of the Project Manager's time & responsibility. It is not an exaggeration to say that the entire project will hinge on the effective 360° communication by the project manager.

There are 2 parts to project communications. The 1st part is to develop a strategy to ensure effective communications. The 2nd part is to actually implement the activities required by that strategy. Our current focus will be on the 1st part - i.e. to develop an effective communications strategy. This strategy will be documented in the 'Communications Management Plan' artifact.

But before we jump into developing a strategy, there are some foundational concepts of communications, that we will touch upon next, in this lesson.

Project Managers spend most of their time communicating with team members, vendors, and other stakeholders. So, they will need to be excellent communicators. Effective communications can build BRIDGES between diverse people from different cultural, technical, and educational backgrounds. But, poor communications can burn those same bridges!

Effective communications have different dimensions that have to be considered, for example:

1. Is the communication Internal (i.e. within the team, or within the organization), OR is it external?

2. Are you going to communicate over email in written form, or is this a face-to-face spoken communication?

3. Is this a formal, or informal communication?

4. In all forms of communication, the tone of voice, and signaling (gesture) is an important concept.

5. There are many ways to express an idea. So, the choice of words used in a communication can trigger subtle nuances in the message.

6. Are you communicating Upwards (to senior management), or Downwards (to your team & others), or Horizontal (your own peers).

All of these are different aspects that you have to consider to bring about effective communications, and reduce miscommunications.