Elements of a Project Charter

We all know that a Project Charter is the official document that formally authorizes a Project Manager to start work on a project. In other words, a project starts or kicks off only after a formal project charter is created and approved. A typical project charter has many elements. They are:

1. Business need - Describes the business reason for initiating the project, specifically stating the business problem that the project will resolve
2. Measurable objectives and success criteria - Defines the measurable business goals and objectives and factors that are deemed critical to the success of a project. These criteria are used to measure what must be done for the project to be acceptable to stakeholders
3. Project requirements - Describes what is needed to perform the work to the required specifications
4. Product scope description - Describes the product to be delivered and establishes the boundaries of the project
5. Milestones and deliverables schedule - Describes the deliverables which are a set of outputs for each milestone delivery date. This information provides checkpoints for monitoring project progress and validating work
6. Summary budget - Provides an itemized forecast of estimated or intended expenditures
7. Approval requirements - Describes the quality objectives for each deliverable in terms of output standards and approval requirements. This includes all the product-related reviews and processes that will be carried out during the project
8. Nominated project manager - Establishes the authority of the named individual to make decisions and lead the project, and identifies this person's main responsibilities and their authority level
9. Project sponsor approval - Names the person who has ultimate responsibility for the project and who has the formal authority to approve the project charter

Depending on the organization where the charter is being prepared, it may have some more details but the list above is the bare minimum requirement that any project charter is expected to contain in order to serve its intended purpose.

Points to Remember: Before the PMP Exam

1. Make sure to get a good night’s sleep before you take the PMP exam. And make sure you eat something! It can take up to four hours to complete the exam. That’s longer than you expect, and you don’t get a snack break.

2. The first thing you see when you sit down to take the computerized version is a 15-minute tutorial on how to use the software. You won’t need much time to go through it, because the software is very intuitive. Use this time to relax.

3. Seriously. Relax. Everyone taking the exam gets jittery. A good thing to do is look at the 15-minute countdown timer for the tutorial and breathe. Take a whole minute and use it to breathe. If your heart is still pounding, take another minute. You’ll be glad you did.

4. Don’t click away from that tutorial yet! You’ll get some sheets of scratch paper to use. Write down every formula before you click the button to start the exam. That way they’ll be there for the questions that need them—and you won’t be nervous about forgetting them. The formulae may seem straightforward to recollect during this time, but can be quite a feat to remember them during the pressure of the exam.

5. The exam software lets you mark a question for review. If you’re at all unsure of a question, mark it. Sometimes a later question will help trigger your memory, so when you come back to it, the answer will suddenly “come” to you. This really works!

6. Don’t get too stuck on a question as you’re going through—better to take your best guess, mark it for review, and move on. You can go back to it as many times as you need.


Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility

Points to Remember: Ethics & Professional Responsibility

Ethics and professional responsibility questions make up 10% of the exam. That’s good news because these questions are really easy if you understand the ideas behind the PMP Code of Professional Conduct.

In general, there are a few kinds of problems that the code of ethics prepares you to deal with.

1. Follow all laws and company policies.
2. Treat everybody fairly and respectfully.
3. Have respect for the environment and the community you’re working in.
4. Give back to the project management community by writing, speaking, and sharing your experience with other project managers.
5. Keep learning and getting better and better at your job.
6. Respect other people’s cultures.
7. Respect copyright laws.
8. Always be honest with everyone on the project.
9. If you find that another person has done something to damage the PMP credential in any way, you must report them to PMI.

Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management

Points to Remember: Project Procurement Management

Sometimes you need to hire an outside company to do some of your project work. That’s called procurement, and the outside company is called the seller.

The PMP exam is based on contracting laws and customs in the United States. If you are someone who hasnt spent time in the states or worked with a customer from the states, it would be useful if you visit http://www.acquisition.gov/ and gather some knowledge about the same.

Procurement is pretty straight forward, and the Procurement Management processes follow a simple order that you can figure out with just common sense. First you plan what you need to contract; then you plan how you’ll do it. Next, you send out your contract requirements to sellers. They bid for the chance to work with you. You pick the best one, and then you sign the contract with them. Once the work begins, you monitor it to make sure the contract is being followed. When the work is done, you close out the contract and fill out all the paperwork.

Teaming Agreenents are partnership documents that describe the relationship between a buyer and a seller when they’re working together as a team. When a buyer and a seller have a teaming agreement in place, they act as partners. They make management decisions together, and both have an increased stake in the outcome.

Contracting adds an extra dimension of risk to your project because your seller will have different management and policies. So managing risks is especially important!

force majeure - is a kind of clause that you’ll see in a contract. It says that if something like a war, riot, or natural disaster happens, you’re excused from the terms of the contract.

The point of total assumption is the point at which the seller assumes the costs. In a fixed price contract, this is the point where the costs have gotten so large that the seller basically runs out of money from the contract and has to start paying the costs.

You always put together procurement documents and source selection criteria before you start talking to individual sellers who want your business.

Buyer-conducted performance reviews let buyers check all of the work that the sellers are doing.

Whenever you see “inspection” or “audit” it means that you’re looking at the products that the seller delivered to see if they meet your standards.


Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Risk Management
Ethics & Professional Responsibility

Points to Remember: Project Risk Management

A risk is any uncertain event or condition that might affect your project.

Not all risks are negative. Some events (like finding an easier way to do an activity) or conditions (like lower prices for certain materials) can help your project! When this happens, we call it an opportunity… but it’s still handled just like a risk.

Risk Breakdown Structure (RBS) is a great tool for managing your risk categories. It looks like a WBS, except instead of tasks it shows how the risks break down into categories.

It’s important to come up with probability and impact guidelines to help you figure out how big a risk’s impact is. The impact tells you how much damage the risk will cause to your project. A lot of projects classify impact on a scale from minimal to severe, or from very low to very high. The plan should also give you a scale to help figure out the probability of the risk. Some risks are very likely; others aren’t.

All four of the Risk Management processes are in the Planning process group—you need to plan for your project’s risks before you start executing the project.

The goal of all of the risk planning processes is to produce the risk register. That’s your main weapon against risk. It’s a list of all of the risks and some initial ideas about how you’d respond to them.

The risk register is built into the Risk Management Plan. Updates to the risk register are the only output of the Identify Risks process.

Perform Qualitative Risk Analysis helps you prioritize each risk and figure out its probability and impact. The only output of Perform Qualitative Risk Analysis is the updated risk register.

Sometimes you’ll find that some risks have obviously low probability and impact, so you won’t put them in the main section of your register. Instead, you can add them to a separate section called the watchlist, which is just a list of risks. It’ll include risks you don’t want to forget about, but which you don’t need to track as closely. You’ll check your watchlist from time to time to keep an eye on things.

The first step in risk management is Identify Risks, where you work with the whole team to figure out what risks could affect your project.

Qualitative and quantitative analysis are all about ranking risks based on their probability and impact.

Qualitative analysis is where you take the categories in your risk plan and assign them to each of the risks that you’ve identified.

Quantitative analysis focuses on gathering numbers to help evaluate risks and make the best decisions about how to handle them.

Decision Tree Analysis is one kind of Expected Monetary Value analysis. It focuses on adding up all of the costs of a decisions being made on a project so that you can see the overall value of risk responses.

To calculate EMV, be sure to treat all negative risks as negative numbers and all opportunities as positive ones. Then add up all of the numbers on your decision tree.

Don’t forget watchlists. They let you monitor lower-priority risks so that you can see if triggers for those risks occur and you need to treat them as higher priorities.

All of the processes in Risk Management are Planning or Monitoring & Controlling processes. There are no Executing processes here. Since the goal is to plan for risks, there is no need to focus on actually doing the work. By then, it’s too late to plan for risks.

Your risk register should include both threats and opportunities. Opportunities have positive impact values, while threats have negative ones. Don’t forget the plus or minus sign when you’re calculating EMV.

Plan Risk Responses is figuring out what you’ll do if risks happen.

Risk monitoring should be done at every status meeting.

The better you prepare for risks, the more secure your project is against the unknown.


Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Procurement Management
Ethics & Professional Responsibility

Some Nice Questions - Part 3

31: How do you know your Quality Benchmarks before you start building?

That’s what your Organizational Process Assets are for. Since your company keeps a record of all of the projects that have been done over the years, those projects’ quality measurements can help you get a gauge on how your project will perform too. If your company knows that all of the
projects in your division had a cost of quality that was 40% of the cost of the overall cost of development, you might set 40% cost of quality as a benchmark for your project as well. Your company might have stated a goal of having a schedule variance of plus or minus 10% on all projects for this calendar year. In that case, the schedule variance is a benchmark for your project

32: I don’t really have good requirements for my projects because everyone on the team starts out with just a good idea of what we’re building. How do I handle quality?

You should never do that. Remember how you spent all that time collecting requrements in the Collect Requirements process? Well, this is why you needed them. And it’s why it’s your responsibility to make sure that the project starts out with good, well-defined, and correct requirements. If you don’t have them, you can’t measure quality—and quality is an important part of Pproject management. Without requirements, you have no idea what the product is supposed to do, and that means you can’t judge its quality. You can learn a lot about a product by testing it, but without knowing its requirements, a product could pass all of its tests and still not do what the customer expects it to do. So having good requirements really is the only way to know whether or not your product is high quality.

33: If I am trying to prevent quality problems, why can’t I just test more?

You can find a lot of problems by testing. If you find them during testing, then you have to go back and fix them. The later you find them, the more expensive they are to fix. It’s much better for everybody if you never put the bugs in the product in the first place. It’s much easier to fix a problem in a specification document than it is to fix it in a finished product. That’s why most of the Plan Quality process group is centered around setting standards and doing reviews to be sure that bugs are never put into your product and, if they are, they’re caught as early as possible.

34: Is the RACI chart really necessary?

Yes, definitely! Sometimes people split up responsibilities in ways that aren’t immediately obvious just from people’s titles or the names of their roles on the project—that’s one of the big advantages of a matrixed organization. RACI charts help everyone figure out their assignments.

35: Can the “halo effect” really affect my projects?

The halo effect is something that happens when you’ve got a team member who’s very good at a job—especially a technical job, like computer programmer or engineer. It’s easy to forget that just because someone is very good at one job, it doesn’t mean he or she has the skills to do another,equally hard job. This happens a lot with functional managers: the top programmer will often get promoted to a management position… but if she doesn’t have management or leadership skills, then the company just lost their best programmer and gained a lousy manager.


36: Per the PMBOK, it sounds like compromise is a bad thing. But I’ve been told that when people are fighting, I should always look for a middle ground!?

Yes, as little kids a lot of us were told that we should always look for a compromise. And that probably is the right thing to do on the playground. But when you’re managing a project, you’re judged by the success of your final product, not by how happy your team is. When you forge a compromise instead of really figuring out what’s causing the problem, you’re usually taking the easy way out.

37: What do I do with lessons learned after I write them?

The great thing about lessons learned is that you get to help other project managers with them. You add them to your company’s process asset library, and other project managers then use them for planning their projects.

38: Do I have to know everything that will be communicated to build a plan?

No. As you learn more about the project you can always update the plan to include new information as you learn it. Pretty much all of the planning processes allow for progressive elaboration. You plan as much as you can up front, and then put all changes through change control from then on. So, if you find something new, put in a change request and update the plan when it’s approved.

39: What’s the difference between active and effective listening?

Some of the communications ideas do have names that are a little confusing. But don’t worry, they’re really easy concepts for you to understand.

Active listening just means when you’re listening to something, you keep alert and take specific actions that help make sure you understand. It includes both effective listening and feedback.
Effective listening is a way that you do active listening—it means paying attention to both verbal and nonverbal communication. Feedback means doing things like repeating back the words that you were told in order to make sure you understood them, and giving your own nonverbal cues to show the speaker that you got the message.

40: Are nonverbal and paralingual communication the same thing?

They are very similar, but they’re not exactly the same. Nonverbal communication is any kind of communication that doesn’t use words. That includes things like changing your body language, making eye contact, and using gestures. Paralingual communication is a kind of nonverbal communication—it’s changing your tone of voice or intonation, finding ways to communicate things above and beyond just the words that you’re saying. For example, the same words mean very different things if you say them sarcastically than if you say them in a normal tone of voice.

41: What if people disagree on how to rank risks?

There are a lot of ways to think about risks. If a risk has a large impact on your part of the project or your goals, you can bet that it will seem more important to you than the stuff that affects other people in the group. The best way to keep the right perspective is to keep everybody on the team evaluating risks based on how they affect the overall project goals. If everyone focuses on the effect each risk will have on your project’s constraints, risks will get ranked in the order that is best for everybody.

42: How do I know if I’ve got all the risks?

Unfortunately, you never know the answer to that one. That’s why it’s important to keep monitoring your risk register throughout the project. It’s important that you are constantly updating it and that you never let it sit and collect dust. You should be looking for risks throughout all phases of your project, not just when you’re starting out.

43: What’s the point in even tracking low-priority risks? Why do we need the Watchlist in the first place when the risks are low priority?

Actually, watchlists are just a list of all of the risks that you want to monitor as the project goes on. You might be watching them to see if conditions change and make them more likely to happen. By keeping a watchlist, you make sure that all of the risks that seem low priority when you are doing your analysis get caught before they cause serious damage if they become more likely later in the project. The conditions that cause a risk are called triggers. So, say you have a plan set up to deal with storms, and you know that you might track a trigger for lightning damage, such as a thunderstorm. If there’s no thunderstorm, it’s really unlikely that you will see lightning damage, but once the storm has started, the chance for the risk to occur skyrockets.

44: I can figure out how much the risk costs using EMV, or I can do it with Decision Tree Analysis. Why do I need two ways to do this?

That’s a good question. If you take a really careful look at how you do Decision Tree Analysis, you might notice something... it’s actually doing exactly the same thing as EMV. It turns out that those two techniques are really similar, except that EMV does it using numbers and Decision Tree Analysis spells out the same calculation using a picture.

It turns out that there are a lot of EMV techniques, and decision tree analysis is just one of them. But it’s the one you need to know for the test, because it’s the one that helps you make decisions by figuring out the EMV for each option. You can bet that you’ll see a question or two that asks you to calculate the EMV for a project based on decision tree like the one on the facing page. As long as you remember that risks are negative numbers and that opportunities are positive ones, you should do fine.

45: Why do we do risk audits?

Risk audits are when you have someone from outside your project come in and review your risk register—your risks and your risk responses—to make sure you got it right. The reason we do it is because risks are so important that getting a new set of eyes on them is worth the time.

46: Do I always need to hold a bidder conference whenever I do procurement?

No, you don’t always need a bidder conference. Sometimes your company has a preferred supplier who you always deal with, so you don’t have to advertise for sellers. And sometimes there’s a sole source for a particular service or part—there may only be one company that provides it. In that case, advertising and bidder conferences would be pointless.

The bidder conference has two goals. The first is to make sure that you answer all of the questions from potential sellers. But the other is to make sure that all potential sellers are treated equally and have access to the same information.

47: Once a contract is signed, does that mean it’s never allowed to change?

No. This confuses some people, because when you sign a contract, it’s legally binding—which means you must abide by the terms of the contract. But that doesn’t mean those terms can’t change. If both the buyer and the seller agree to make a change to the contract, then they have every right to do so. That’s why you have a contract change control system—so you can Pmake sure these changes are made properly. But you can’t always assume that you have the ability to change a contract that you’re not happy with. Once your company has agreed to a contract, then you’re absolutely required to meet its terms and complete your side of it. If you want to make a change to it, you need to negotiate that change, and it’s possible that the seller won’t agree to it—just like you have every right to refuse an unreasonable change that the seller requests.

48: What is the difference between a performance review and an audit?

The difference is that performance reviews are about the work, while inspections and audits are about the deliverables and products. You’ll use a performance review when you want to make sure that the team at the seller is doing every activity that they should. For example, if you have a contract that requires the seller to perform certain quality control or project management tasks, you might conduct a performance review where you observe the team and verify that they do those tasks. On the other hand, if you want to make sure that the products that the team is producing meet your requirements and standards, you’ll send out an auditor to inspect the products that the seller is making to verify that they meet the requirements.

49: Do I Really need to follow all these Ethics & Professional Responsibility ideas outlined by the PMI?

Yes, absolutely. Being a PMP means you are a cut above the rest of the people who may do project management and one of the key distinctions is the expectation that a PMP Certified individual will be fair in his practices and work with honesty and integrity. Though accepting/giving a bribe or taking a short cut may not mean much harm, the point here is that, are you doing the right thing? When you ask yourself this question "Is this correct and legal?" and the answer is "NO" then you are not supposed to do it. I do agree that in real life situations there may be more than one reason to make a decision, but the most important should always be "Is this Ethical & Legal" irrespective of the situation and that is what PMI encourages.

If you have any more questions, dont hesitate to leave it as a comment and I shall try to answer them!!!

Some More Questions:

More Questions - Part 1
More Questions - Part 2

Some Nice Questions - Part 2

16: Is product analysis the same as requirements gathering?

Not exactly. When people gather requirements, they’re trying to understand what needs the product should fill. Requirements are the contents of the
product. When you use product analysis to define the scope of the work to be done, you’re figuring out what deliverables the team needs to work on in order to build your scope statement. So product analysis is concerned with how the work will be done, not what’s in it.

17: What if a stakeholder can’t tell me how to measure his needs?

That can get kind of tricky. Sometimes stakeholders know that they want things to get better, but they don’t know how to tell when they’ve
succeeded. You need to work with them to find something that can be measured in their ideas about project success. Without a way to measure your success, you won’t know whether or not you are accomplishing your goals.

18: What if I don’t know enough to estimate the cost of a work package? What do I add to the WBS Dictionary?

The WBS Dictionary should only contain information that you can fill in when you create it. A lot of the time, you’ll know all of the information that needs to go into it. If you have an estimate and know the resources that should be used, then put it in. But if all you have is a statement of work and an account code, then that’s all the information you’ll be able to add to the entry.

19: What happens if I need to change the scope?

You need to put it through change control – just like a change to the product scope. As you’re building the product, it’s always possible that some work will pop up in an P unexpected place. It could be that the initial technical design is inadequate or buggy. Or maybe you just think of a better way to do things while you’re working. In either case, you have to determine the impact to the schedule, the budget, the scope, and the quality of the product and put the proposed change through change control. That’s what it means to look at the project constraints every time there’s a change.

Once everyone understands the impact and approves the change, you need to go back and adjust your scope baseline to include the new work. If your budget or schedule are affected, you’ll need to change those baselines too and integrate all of them into the project management plan

20: How do I know when I have decomposed the work to a small enough work package?

The short answer is that you should decompose that work until it is manageable. You need to be careful when you come up with the work packages for
your WBS. If you decompose to the most granular level, you could end up wasting everybody’s time trying to figure out exactly how much effort goes into, say, “writing up meeting minutes” for each and Pevery meeting in your project. So, you should break down the work to small enough packages that everybody can understand what’s being done and describe it in the dictionary… and no further.

21: Can you explain the difference between the Scope Management Plan and the Project Management Plan?
Remember how the Project Management Plan was divided into subsidiary plans? The Project Management Plan tells you how to manage all of the different knowledge areas, and it has baselines for the scope, schedule and budget.

The Scope Management Plan is one of those subsidiary plans. It has really specific procedures for managing scope. For example, it tells us which stakeholders we need to talk to when gathering requirements. It lists what tools and techniques we are planning to use when we use the Scope Definition to define the scope. And when there’s an inevitable change because even the best project manager can’t prevent every change, it gives him procedures for doing Scope Management. So even though the Scope Management Plan is created in the Develop Project Management Plan process, it’s used throughout all of the Scope Management processes.

22: Is Control Scope always about work and project scope? Can it ever be about deliverables and product scope?

No. The Control Scope process is always about the work that the team does, because the whole Scope Management knowledge area is about the project scope, not the product scope. In other words, as a project manager, you manage the work that the team is doing, not the things that they’re making. Now, that doesn’t mean you should never pay attention to deliverables. You still need to pay attention to the scope of the product, too, since the two are pretty closely related. Any time you make changes to the project scope, it affects the product scope, and vice versa.

23: What if a change is really small? Do I still have to go through all of this Change Control Process?

Yes. Sometimes what seems like a really small change to the scope—like just adding one tiny work package—turns out to be really complex when you take a closer look at it. It could have a whole lot of dependencies, or cause a lot of trouble in other work packages. If you don’t give it careful consideration, you could find yourself watching your scope creep out of control. Each and every change needs to be evaluated in terms of impact. If there is any impact to the project constraints—time, cost, scope, quality, resources, or risk, you have to put it through change control. No Exceptions here.

24: What if I need a resource that isn’t available when my project needs it?

This is one of the reasons that project management is a tough job! When you need a resource that isn’t available, you need to negotiate for it. Your project depends on getting this resource, and without it your project won’t get done. You need it, or you’ll face delays! You have to do whatever you can to get that resource for your project. You can look in the other departments of your company or hire a contractor or hire a person from another company. At the end of the day, your job is to staff resources for your project and how you do it, is entirely upto your discretion. (Of course, dont forget management & budgetary approvals before hiring contractors or people from other company's)

25: Since reserve analysis lets me use buffers, why can’t I just put everything I don’t know about into the reserve?

The idea behind reserve analysis is that there are always unknowns on any project, but you can account for these unknowns by taking your best guess at what’s going to go wrong and inserting a buffer. But you can’t just make an enormous reserve, because then there’s no reason to ever do any estimation! The entire project becomes one big unknown, and that’s not particularly useful to anyone.

26: What if there’s a path that’s not critical, but where even a small slip in one activity would delay the project?

This is exactly why it’s important to know the float for each of your activities. When you’re managing your project, it’s not enough to just pay attention to the activities on the critical path. You need to look for any activity with a low float. And don’t forget that there may be some activities that aren’t on the critical path but still have a float of zero! These are the ones where you really want to pay attention and watch out for potential resource problems.

27: Would I really use this critical path stuff in real life, or is it just something I need to memorize for the PMP exam?

Yes, critical path analysis really is important in real life! Sure, for a small project with a dozen or so activities, it’s pretty easy to figure out which activities are critical and which can slip by a little bit. But what happens if you’ve got a project with dozens of team members and hundreds of activities?

That’s where critical path analysis can come in very handy. For a project like that, you’d probably be using project management software rather than calculating the critical path yourself, and the software will be able to highlight that path for you. Pay special attention to all of the activities that are on the critical path—those are the ones that could potentially delay the project.

28: Don’t we need to go through change control before we update the resource requirements or the activity attributes?

No. You need to go through change control if you are requesting changes to, say, your cost management plan. But while you are working on creating your schedule, everything you have created as part of the Time Management knowledge P area is fair game.

As you work your way through your network diagram and figure out new dependencies, you are going to find that you need more resources for some items or that the activity itself has changed. That’s why this process gives you the freedom to refine your earlier idea and make all of the time management documents in sync with your new understanding. The Develop Schedule process is about taking all of the information you are able to think of up front and putting it into a schedule that is realistic. When you are done with this process, you should have a really good idea of what you are going to do, who will do it, and how long it will take.

29: We always want to do our projects as quickly as we can. Why don’t we always fast-track and crash our schedules?

Because crashing is expensive and fast-tracking is risky. While it may look good on paper to add a lot of resources to a project that is running late, it often adds so much management overhead and training issues that Pthe project just comes in later.

Even though it might seem like some predecessors are really unnecessary, you usually planned them for a reason. So when you break your dependencies to fasttrack your project, you can significantly compromise the quality of the work that gets done. That means you might have to redo it altogether—which would probably take a Plot of time. While fast-tracking and crashing might work sometimes, they always add both risk and cost to your project.

30: In my job I am just handed a budget. How does estimating help me?

In the course of estimating, you might find that the budget you have been given is not realistic. Better to know that while you’re planning, before you get too far into the project work than later. You can present your findings to the sponsor and take corrective action right away if your estimate comes in pretty far off target. Your sponsor and your project team will thank you for it.

Some More Questions:

More Questions - Part 1
More Questions - Part 3

Points to Remember: Project Communication Management

90% of a project manager’s job is communication

Communications Management makes sure everybody gets the right message at the right time.

Stakeholder Analysis is a critical tool in Project Communication Management process. You need to interview all of the stakeholders you can find for your project and find out the value the project has for them. As you sit with stakeholders, you’ll identify more people to interview. During Stakeholder Analysis you can divide your stakeholders into groups based on their level of involvement and need for communication. When you understand what motivates all of your stakeholders, you can come up with a strategy to make sure that they’re told about the things that they find important, and that they’re not bored with extraneous details.

It’s not enough to know who your stakeholders are – you need to understand what motivates them, and what it will take it to make the project a success for each of them. That’s where the Stakeholder Management Strategy comes in.

Be careful about when you use different kinds of communication. Any time you need to get a message to a client or sponsor, you use formal communication. Meetings are always informal verbal, even if the meeting is to say something really important. And any project document—like a project management plan, a requirements specification, or especially a contract—is always formal written.

You do most of the project communication when you’re performing the Distribute Information process

It’s important to write down the good things you learned on the project, too. That way, you can be sure to repeat your successes next time. Another important aspect of this action is the fact that, other projects can learn about the best practicies from your experience and implement them.

There are only four communication types; formal written, informal written, formal verbal, and informal verbal. For the test, you need to be able to tell which is which.

Report Performance takes the outputs from the Executing process in Distribute Information and turns them into Performance Reports and Forecasts.

Performance reports and forecasts are a lot easier than they look—because you already know all about them! In the chapter on Project Cost Management, you learned how to use CPI and SPI to measure your project’s performance, and you used EAC and ETC to forecast when the project would be complete. Now you’re just taking that information and communicating it!

A kickoff meeting is a great way to get your project team and stakeholders on the same page.

You should add all of your performance reports to the Organizational Process Assets so that project managers on future projects can use them as historical information.


Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility

Points to Remember: Human Resource Management

In the Develop Human Resource Plan process, you plan out exactly which resources you’ll need, what their roles and responsibilities are, and how you’ll train your team and make sure they stay motivated.

Everything you do with your team—acquiring them, developing them, and managing them—depends on a good Staffing Management Plan.

You develop your project team by keeping them motivated, and you do this all the way through your entire project.

McGregor’s Theory X and Theory Y

A Theory X manager will micromanage the team, looking over everyone’s shoulder all the time and making them feel like they aren’t trusted.

It’s much better—and easier—to be a Theory Y manager. If you trust the team to do their jobs, they won’t let you down!

Project managers use their general management skills (“soft skills”) to motivate and lead the team.

In a matrixed organization, the project manager doesn’t have legitimate power, because the team doesn’t directly report to the project manager.

The most effective forms of power are reward power, where the project manager sets up rewards and recognition for the team, and expert power, which means the team respects the project manager’s technical expertise.

Referent power is power that’s based on identifying with or admiring the power-holder.

Punishment power is the least effective form of power. The project manager should never punish a team member in front of peers or managers!

Project managers should be familiar with modern theories of motivation and management.

McGregor’s Theories X and Y state that there are poor Theory X managers who don’t trust their teams, and good Theory Y managers who do.

Maslow’s Hierarchy of Needs is the theory that says that people can’t achieve “self-actualization” (full potential) or esteem (feeling good and important) until lower needs like safety and security are met.

Herzberg’s Theory says that it’s difficult to motivate people unless hygiene factors like a paycheck and job security are already in place.

Expectancy Theory holds that people only respond to rewards that are tied to goals they feel they have a realistic chance of achieving.

Bruce Tuckman’s five stages of team development are forming (the team still finding their roles), storming (the team forming opinions), norming (adjusting work habits to help the team), performing (working like a well-oiled machine), and adjourning (closing down the project).

Over half of all conflicts in projects are caused by resources, priorities, and schedules. Personality conflicts are actually the least likely cause.

The best way to resolve a conflict is to confront the problem: do your research, figure out what’s behind it, and fix the root cause. When you confront the source of the conflict head-on and work with everyone to find a solution that actually fixes the reason that conflicts happen, then the problem is most likely to go away and never come back!

Never ignore a conflict. That is the worst way of handling a conflict. The equally worse way is Forcing wherein you decide the resolution to a conflict by virtue of your authority as the PM. This may solve the conflict but may cause motivation issues on your team.

The best way to solve a problem is to confront it, which means doing your research, figuring out what’s causing the problem, and fixing it.

Withdrawal happens when someone gives up and walks away from the problem, usually because they’re frustrated or disgusted. If you see a team member doing this, it’s a warning sign that something’s wrong.

Don’t be fooled by questions that make it sound like “confronting” is a bad thing. Confronting is just another word for problem-solving.

Smoothing is minimizing the problem, and it can help cool people off while you figure out how to solve it.

You should only compromise if you can’t confront the problem.

Forcing means making a decision by simply picking one side. It’s a really ineffective way to solve problems.


Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Project Communication Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility

Points to Remember: Project Quality Management

Quality is the measurement of how closely your product meets its requirements.

Whenever we talk about quality the following 3 terms invariably pop up. They are:

1. Customer satisfaction is about making sure that the people who are paying for the end product are happy with what they get. When the team gathers requirements for the specification, they try to write down all of the things that the customers want in the product so that you know how to make them happy. Some requirements can be left unstated, too. Those are the ones that are implied by the customer’s explicit needs. In the end, if you fulfill all of your requirements, your customers should be really satisfied.

2. Fitness for use is about making sure that the product you build has the best design possible to fit the customer’s needs. Which would you choose: a product that’s beautifully designed, well constructed, solidly built, and all-around pleasant to look at but does not do what you need, or a product that does what you want despite being really ugly to look at and a pain in the butt to work with? You’ll always choose the product that fits your needs, even if it’s seriously limited. That’s why it’s important that the product both does what it is supposed to do and does it well.

3. Conformance to requirements is the core of both customer satisfaction and fitness for use. Above all, your product needs to do what you wrote down in your requirements specification. Your requirements should take into account both what will satisfy your customer and the best design possible for the job. In the end, your product’s quality is judged by whether you built what you said you would build.

Quality Vs Grade

People often confuse Quality with Grade. Lets take a simple example: Watches...

Lets say Brand A is a popular brand of watches in India which costs Rs.2500 to Rs. 10000/- per watch whereas Brand B is an even popular brand which costs Rs.25000 to Rs.50000/-. Both brands make high quality watches but they are of different grade. As per their cost, people will value Brand A to be much lesser in monetary value than Brand B is. Hence Brand B is of a higher grade than Brand A. Nonetheless, if your Brand B watch fails to work after 3 days, its supposed to be of bad quality even though it is of very high grade.

Grade has nothing to do with quality. They are both two not-so-related terms which people tend to confuse often. As PMP Certified Project Managers, we must be able to tell them apart...

Now get the picture?

There are three processes in the Quality Management knowledge area, and they’re all designed to make sure that you and your team deliver the highest quality product that you can.

1. Plan Quality is like the other planning processes you’ve learned about—you create a Quality Management Plan to help guide you and your team through quality activities.
2. Perform Quality Control is the Monitoring & Controlling process where you look at each deliverable and inspect it for defects.
3. Perform Quality Assurance is where you take a step back and look at how well your project fits in with your company’s overall quality standards and guidelines.

Cost of quality is what you get when you add up the cost of all of the prevention and inspection activities you are going to do on your project. It doesn’t just include the testing. It includes any time spent writing standards, reviewing documents, meeting to analyze the root causes of defects, rework to fix the defects once they’re found by the team—absolutely everything you do to ensure quality on the project.

Metrics tell what and how you are going to measure your product’s quality. They give you some objective measures to help you make better judgments about it.

Validated deliverables and validated changes are two of the most important outputs of Perform Quality Control. Every single deliverable on the project needs to be inspected to make sure it meets your quality standards. If you find defects, the team needs to fix them—and then those repairs need to be checked, to make sure the defects are now gone.

Inspection means checking each deliverable for defects. That means checking your specs and your documentation, as well as your product, for bugs.

The better your Plan Quality, the less inspection you need.

Ishikawa diagrams help you to pinpoint the causes of defects.

The rule of seven means that any time you have seven data points in a row that fall on the same side of the mean on a control chart, you need to figure out why.

When data points fall above the upper limit or below the lower limit on a control chart, the process is out of control.

For the test, using any of the seven basic quality tools is usually a good indication that you are in the Quality Control process.

Ishikawa, fishbone, and cause-and-effect diagrams are all the same thing.

Scatter charts help you look at the relationship between two different kinds of data.

Flowcharts help you get a handle on how processes work by showing all of the decision points graphically.

Grade refers to the value of a product, but not its quality. So, a product can be low-grade by design, and that’s fine. But if it’s a low-quality product, that’s a big problem

Quality Audits are reviews of your project by your company. They figure out whether or not you are following the company’s process. The point is
to figure out if there are ways to help you be more effective by finding the stuff you are doing on your project that is inefficient or that causes defects. When you find those problem areas, you recommend corrective actions to fix them.

Process Analysis is when you look at your process to find out how to make it better. You use your process improvement plan to do this one.


Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility

Points to Remember: Project Cost Management

Analogous Estimating is sometimes called “Top-Down Estimating”. Take a minute and think about why it would be called “top-down.” When you’re doing bottomup estimating, first you break it down into pieces, estimate each piece, and add them up. Analogous estimation is the opposite: you start with the whole project (without breaking it up at all), find other projects that were like it, and use those projects to come up with a new estimate.

Cost of Quality is how much money it takes to do the project right.

Benefit cost ratio (BCR): This is the amount of money a project is going to make versus how much it will cost to build it. Generally, if the benefit is higher than the cost, the project is a good investment.

Net present value (NPV): This is the actual value at a given time of the project minus all of the costs associated with it. This includes the time it takes to build it and labor as well as materials. People calculate this number to see if it’s worth doing a project. Money you’ll get in three years isn’t worth as much to you as money you’re getting today. NPV takes the “time value” of money into consideration, so you can pick the project with the best value in today’s dollars.

Just because you plan out a budget in your Cost Performance Baseline, that doesn’t mean your project is 100% guaranteed to fall inside that budget. It’s common for a company to have a standard policy for keeping a management reserve to cover unexpected, unplanned costs. When you need to get your project funded, that funding has to cover both the budget in your Cost Performance Baseline and the management reserve.

Parametric Estimation is used in Estimate Costs and Determine Budget.

Cost Aggregation is rolling up costs from the work package level to the control account level so that the numbers can be followed down through the WBS hierarchy.

Control Accounts are highlevel WBS items that are used to track cost estimates. They do not represent activities or work packages. They represent the cost of the work packages and activities that appear under them in the WBS

The main output of Estimate Costs is the Activity Cost Estimate and the Basis of Cost Estimate. The main output of Determine Budget is the Cost Performance Baseline and Project Funding Requirements.

You will get questions on the exam asking you to select between projects using Net Present Value (NPV) or Benefit Cost Ratio (BCR). Always choose the project with the biggest NPV or BCR!

Lifecycle Costing means estimating the money it will take to support your product or service when it has been released.

Rough Order of Magnitude Estimation is estimating with very little accuracy at the beginning of a project and then refining the estimate over time. It’s got a range of –50% to +50%.

If the SPI is below 1, then your project is behind schedule. But if you see a CPI under 1, your project is over budget! SPI and CPI are just ratios! If SPI is really close to 1, then SV will be really close to zero—and it means that my project is going as planned! And when your CPI is really close to 1, it means that every dollar your sponsor’s spending on the project is earning just about a dollar in value.


Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Scope Management
Project Time Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility

Points to Remember: Project Time Management

Resources are people, equipment, locations, or anything else that you need in order to do all of the activities that you planned for. Every activity in your activity list needs to have resources assigned to it.

Bottom-Up Estimating is a technique that you may have used before without even knowing it! It means breaking down complex activities into pieces, and working out the resource assignments for each of those simpler pieces using the other four tools and techniques.

Almost all of the outputs of Estimate Activity Resources are immediately used as inputs for Estimate Activity Durations, which is where your estimates come from.

Three-Point Estimates are when you come up with three numbers: a realistic estimate that’s most likely to occur, an optimistic one that represents the best-case scenario, and a pessimistic one that represents the worst-case scenario. The final estimate is the average. There is a formula associated with how you get the final value, but for simplicity sakes, remember that it is an average of these 3 numbers.

The Formula is:

Expected Duration = (Optimistic Duration + 4 times Most Likely duration + Pessimistic Duration) ÷ 6

Why 6? you are going to find the average of 6 numbers and hence 6. How 6? 1 Optimistic + 1 Pessimistic + 4 Most likely which means 1 + 1 + 4 = 6

Develop Schedule brings everything you’ve done in the other time management processes like Sequence Activities, Estimate Activity Resources, Estimate Activity Durations etc into one final schedule. All of the outputs from the other time management processes are inputs to Develop Schedule.

The Critical Path is the string of activities that will delay the whole project if any one of them is delayed.

The float for any activity is the amount of time that it can slip before it causes your project to be delayed. You might also see the word “slack” – it’s the same thing.

Early start - Is the earliest time that an activity can start. An activity near the end of the path will only start early if all of the previous activities in the path also started early. If one of the previous activities in the path slips, that will push it out.

Early finish - Is the earliest time that an activity can finish. It’s the date that an activity will finish if all of the previous activities started early and none of them slipped.

When you find the early start and early finish for each task, you know exactly how much freedom you have to move the start dates for those activities around without causing problems.

Late start - Is the latest time that an activity can start. If an activity is on a path that’s much shorter than the critical path, then it can start very late without delaying the project – but those delays will add up quickly if other activities on its path also slip!

Late finish - Is the latest time that an activity can finish. If an activity is on a short path and all of the other activities on that path start
and finish early, then it can finish very late without causing the project to be late.

Figuring out the late start and late finish will help you see how much “play” you have in your schedule. An activity with a large late start or late finish means you have more options.

Calculating the early start (ES) of an activity isn’t hard. All you need to do is look at the early finish (EF) of the previous activity and add one. If there’s more than one predecessor, then you take the largest EF and add one.

It’s just as easy to calculate the late finish (LF). Look at the following activity, take its LS (late start), and subtract one. If there’s more than one following activity, use the one with the lowest LS.

The float for an activity is the amount that its duration can slip without causing the project to be delayed. The float for any activity on the critical path is zero.

Managing schedule change means keeping all of your schedule documents up to date. When your schedule changes, you need to take performance measurements so you can keep your stakeholders up to date.

Remember: Gantt charts — the bar charts you make with MS Project, are just one tool for scheduling. You may use them a lot in your day-to-day work, but they’re only one piece of time management. And remember, on the exam they’re called bar charts, not Gantt charts!

Any time you generate data about your project, you should add it to your organizational process assets so you can use it for future projects.


Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Scope Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility

Points to Remember: Project Scope Management

Relationship between Product Scope & Project Scope

Product scope means the features and functions of the product or service that you and your team are building. The product scope is all about the final product—its features, components, pieces. When people talk about scoping out their products, a lot of times they’re talking about figuring out the features of the product, not the work that goes into it.

Project scope is all of the work that needs to be done to make the product. When we talk about scoping a project, we mean, figuring out all the work that needs to be done to make the product. THIS is a big part of what the project manager is concerned with and the work the team has to do.

A single product may include multiple projects and the work done in each of these projects are all part of the high level scope of the product.

Scope management means figuring out what’s OUT OF scope, not just what’s part of it

The five Scope Management processes

Each of the Scope Management processes was designed to help you avoid the kinds of scope problems that cause a lot of projects to go off track. One of the best ways to remember these processes for the exam is to understand why they’re useful, and how they solve the kinds of problems that you’ve seen on your own projects.

Collect Requirements - In this process, you find out all of the stakeholder’s needs and write them down so that you know what to build and your requirements can be measured and tracked.

Define Scope - Here’s where you write down a detailed description of the work you’ll do and what you’ll produce. When you do this right, the stakeholders are never unpredictable because you already understand their needs.

Create WBS - The work breakdown structure (or WBS) organizes all of your team’s work into work packages—or discrete pieces of work that team members do—so that you can keep the momentum of the project going from the start.

Control Scope - We already know how important it is to control changes on your project. When scope changes aren’t controlled, it leads to the most frustrating sort of project problems. Luckily, you already know about change control, and now you can use it to manage your project’s scope.

Verify Scope - Once the work is complete, you need to make sure that what you’re delivering matches what you wrote down in the scope statement. That way, the team never delivers the wrong product to the customer.

Gathering Requirements:

Three Useful Tools for Gathering Requirements:

Interviews are important ways to get your stakeholders to explain how they’ll use the product or service your project is creating. By talking to people one-on-one, you can get them to explain exactly what they need so that you can be sure that your project can meet its goals.

Focus Groups are another way to get a group of people to discuss their needs with you. By letting a group discuss the end product together, you can get them to tell you requirements that they might not have thought of by themselves.

Facilitated Workshops are more structured group conversations where a moderator leads the group through brainstorming requirements together. In facilitated workshops, misunderstandings and issues can get reconciled all at once because all of the stakeholders are working together to define the requirements

Making decisions about requirements:

A big project usually has a lot of stakeholders, and that means a lot of opinions. You’ll need to find a way of making decsions when those opinions conflict with each other. There are four major decision-making techniques you can choose from.

Unanimity means everyone agrees on the decision.

Majority means that more than half the people in the group agree on the decision.

Plurality means that the idea that gets the most votes wins.

Dictatorship is when one person makes the decision for the whole group.

The Requirements Document:

The Requirements Document needs to list all of the functional and non-functional requirements of your product. Functional requirements are most of the kinds of things that you think of right away; new features, bug fixes, new or different behavior. Non-functional requirements are sometimes called “quality attributes” because they’re things that you expect from your deliverables, but aren’t specific features. Some examples of non-functional requirements are: performance, reliablity, error handling, and ease of use.

Defining the Project Scope:

The Create WBS process is the most important process in the Scope Management knowledge area because it’s where you actually figure out all the work you’re going to do. It’s where you create the Work Breakdown Structure (or WBS), which is the main Scope Management output. Every single thing that anyone on the project team—including you—will do is written down in the WBS somewhere.

Creating the WBS:

Each of the entries in the WBS is called a work package. It’s a unit of work that you and your team use to organize the stuff you’re going to have to do to get the project done. The work package is the lowest level on a WBS; the higher levels are used to categorize the work packages. When you roll them all up into one big WBS, you get a complete picture of everything that the team will do over the course of the project.

The WBS Dictionary contains the details of every work package. It’s a separate output of the Create WBS process.

Important Points Reg. Creating the WBS Process:

1. The Create WBS process is a really important process on the PMP exam.
2. The WBS is created by decomposing large work products into work packages.
3. To finalize the WBS, control accounts are established for the work packages.
4. The WBS Dictionary is a description of each work package listed in the WBS.
5. The inputs to WBS creation are the outputs to the Define Scope and Collect Requirements processes: the Requirements Document, and the Project Scope Statement.
6. As you decompose the work, you find new information that needs to be added to the Requirements Document and the Project Scope Statement. That information is treated as a change and goes through change control. Once it’s approved, it can be added into the document, and that kicks off the planning cycle again.

Controlling Scope & Verifying Scope:

Variance Analysis:

This means comparing the data that can be collected about the work being done to the scope baseline. When there is a difference between the two, that’s variance. This tool of Control Scope is all about analyzing the difference between the baseline and the actual work to figure out if the plan needs to be corrected. If so, then you recommend a corrective action and put that recommendation through change control.

There’s no “right order” for the Control Scope and Scope Verification processes:

If you’ve got a copy of the PMBOK® Guide handy, take a look at how it presents the Scope Management processes. Did you notice how the section on the Verify Scope process comes before Control Scope? But, in real time, we may do Control Scope even before we do the Verify Scope. That’s not because the PMBOK® Guide is wrong! We could do this because there is no “right” order: Control Scope can happen at any time, because project changes can happen at any time. Verify Scope is usually the last Scope Management process that you’ll do in a project. The trick is that sometimes you’ll find a scope problem while you’re verifying the scope, and you’ll need to do Control Scope and then go back and gather new requirements,
rebuild the WBS, etc. So the Control Scope process can happen either before or after Verify Scope.

The stakeholders decide when the project is done

As you deliver the stuff in your scope statement, you need to make sure that each of the deliverables has everything in it that you listed in the scope statement. You inspect all of your deliverables versus the scope statement, the WBS, and the Scope Management Plan. If your deliverables have everything in those documents, then they should be acceptable to stakeholders. When all of the deliverables in the scope are done to their satisfaction, then you’re done. However, you need a formal acceptance to conclude that the Project is done. Formal acceptance means that you have written confirmation from all of the stakeholders that the deliverables match the requirements and the project management plan. Sometimes PMs try to close off a project just with the verbal confirmation of the key stakeholder. Though, the stakeholder may not go-back on his words and claim that you did not deliver things properly, the point here is, what if he does? What proof do you have to confirm that you have done all the work as per the scope of the project? This is where the Formal Signed Approval comes to our rescue. When a Stakeholder signs-off that he/she is happy with the deliverables, all they can do is request for some changes but not demand them because, they have provided their sign-off and that means you have delivered what you planned or promised.


Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility

Points to Remember: Project Integration Management

Integration Management Knowledge Area:

The Integration Management knowledge area brings all of the process groups together. A project manager has to integrate the work of everyone on the team through all of these major activities to keep the project on track:

1. Being authorized by the project charter to control the budget and assign resources
2. Planning all of the work that’s going to happen throughout the project.
3. Directing the work once it gets started
4. Monitoring the way the work progresses and looking for potential problems
5. Looking out for changes, understanding their impacts, and making sure they don’t derail the project
6. Closing out the project and making sure that there are no loose ends when it’s over

Initiating a Project:

1. The project charter officially sanctions the project. Without a charter, the project cannot begin.
2. The sponsor is the person (or people) responsible for paying for the project and is part of all important project decisions.
3. Develop Project Charter is the very first process performed in a project.
4. The project charter gives the project manager authority to do the project work, and to assign work or take control of project resources for the duration of the project. It also gives the project manager authority to spend money and use other company resources.
5. The business case tells everyone why the company should do the project. The project charter tells everyone that the project actually started, explains what it’s going to deliver, and authorizes the project manager to do the work.
6. The project charter does not include details about what will be produced or how. Instead, it contains the summary milestone schedule.
7. Two inputs to Develop Project Charter are the contract and the statement of work. The contract is what you agreed to do, although not all projects have a contract. The statement of work lists all of the deliverables that you and your team need to produce.
8. Enterprise Environmental Factors tell you how your company does business. An important one is the work authorization system, which determines how work is assigned, and makes sure that tasks are done in the right order.
9. Organizational Process Assets tell you how your company normally runs projects. One of the most important assets is lessons learned, which is where you write down all of the valuable historical information that you learn throughout the project to be used later.


Planning a Project:

1. Remember that the project management plan is formal—which means that it’s written down and distributed to your team.
2. You may get a question on the exam that asks what to do when you encounter a change. You always begin dealing with change by consulting the project management plan.
3. The work authorization system is a part of your company’s Enterprise Environmental Factors, and it’s generally part of any change control system. It defines how work is assigned to people.
4. The project management plan includes baselines: snapshots of the scope, schedule, and budget that you can use to keep track of them as they change.


Project Management Plan — Subsidiary Plans and Baselines:

The project management plan is the core of Integration Management. It’s your main tool for running a project. It consists of many subsidiary plans and baselines that will be used throughout the life of your project.

1. The scope management plan describes how scope changes are handled—like what to do when someone needs to add or remove a feature to a service or product your project produces.
2. The requirements management plan describes how you’ll gather, document, and manage the stakeholders’ needs, and how you’ll meet those needs with the project deliverables.
3. The schedule management plan shows you how to deal with changes to the schedule, like updated deadlines or milestones.
4. The cost management plan tells you how you’ll create the budget, and what to do when your project runs into money problems.
5. The quality management plan deals with problems that could arise when a product doesn’t live up to the customer or client’s standards.
6. You use the human resource plan to deal with changes in your staff, and to identify and handle any additional staffing needs and constraints you might have in your specific project.
7. The communications management plan lists all of the ways that you communicate with your project’s team, stakeholders, sponsors, and important contacts related to the project.
8. The risk management plan is about detailing all the bad things that might happen and coming up with a plan to address each risk when and if it occurs.
9. The procurement management plan focuses on dealing with vendors outside of your company.

There are three baselines in the project management plan.

1. The scope baseline is a snapshot of the scope, which helps you keep track of changes to the work that you’ll be doing and the planned deliverables you’ll be building.
2. The schedule baseline does the same for the project schedule, and
3. The cost performance baseline does the same for the budget.


The Monitor and Control Phase of a Project - Up Close

1. You start with information about how the work is being performed.
2. Next you figure out any changes that have to be made to the plans, and repairs that have to be made to the deliverables. Here, you let stakeholders know about the changes, and make sure everyone is in the loop with what you’re doing.
3. Once the changes and repairs are approved by the CCB, you send them back to the team to put them in place.

A change control board (CCB) is a group of people—usually including the sponsor—that approves or rejects changes. Any time a change goes through Integrated Change Control, the CCB decides whether or not it should be made. When they approve the change, you send it on to the team to implement.


Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility

Points to Remember: Relation Between Knowledge Areas & Process Groups

Knowledge Area	Initiating Process Group	Planning Process Group	Executing Process Group	Monitoring and Controlling Process Group	Closing Process Group
Project Management Integration	Develop Project Charter	Develop Project Management Plan	Direct and Manage Project Execution	Monitor and Control Project Work Perform Integrated Change Control	Close Project or Phase
Project Scope Management	-	Collect Requirements Define Scope Create WBS	-	Verify Scope Control Scope	-
Project Time Management	-	Define Activities Sequence Activities Estimate Activity Resources Estimate Activity Durations Develop Schedule	-	Control Schedule	-
Project Cost Management	-	Estimate Costs Determine Budgeting	-	Control Costs	-
Project Quality	-	Plan Quality Management	Perform Quality Assurance	Perform Quality Control	-
Project Human Resources Management	-	Develop Human Resource Plan	Acquire Project Team Develop Project Team Manage Project Team	-	-
Project Communications Management	Identify Stakeholders	Plan Communications	Distribute Information Manage Stakeholder Expectations	Report Performance	-
Project Risk Management	-	Plan Risk Management Identify Risks Perform Qualitative Risk Analysis Perform Quantitative Risk Analysis Plan Risk Responses	-	Monitor and Control Risks	-
Project Procurement Management	-	Plan Procurements	Conduct Procurements	Administer Procurements	Close Procurements

Points to Remember - Other Topics:

Introduction to Projects & Project Management
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility

Points to Remember: Introduction to Projects & Project Management

Introduction to Projects & Project Management

1. Knowledge, performance, and personal skills are the three areas that project managers focus on to get better at their jobs.
2. When you’re talking about things like the people in your organization, the market you compete in, your company’s risk tolerance, and standards that your company needs to meet (like government-imposed standards for any contractor bidding on a government project), you’re talking about Enterprise Environmental Factors.
3. A program is a collection of projects that should be managed together in order to achieve a specific goal or benefit to the company.
4. A portfolio is a collection of projects or programs.
5. A project gathers a team together to do work that’s temporary, creates a unique result, and is progressively elaborated.
6. An operation (or process) is work that’s done in a way that’s repeatable and ongoing, but is not a project.

Organizational Structure

1. Functional managers have all the power in a functional organization. Project managers have the power in a projectized organization.
2. If a question on the exam doesn’t state an organization type, assume it’s referring to a matrix organization. That means the PM is responsible for making budgets, assigning tasks to resources, and resolving conflicts.
3. Project coordinators and expediters don’t exist in a projectized organization.
4. A project expediter keeps track of project status only.
5. A project coordinator has some authority, and usually reports to someone higher up in the company. Neither role has as much power or authority as a real project manager, even though an expediter or coordinator may have “Project Manager” written on their business cards.

Project Management Knowledge Areas

There are a total of 9 Knowledge Areas as per the PMBOK Guide. They are:

Integration Management: Coordinating all of the work so that it happens correctly. Making sure changes are approved before they happen.
Scope Management: Figuring out what work needs to be done for your project. Making sure your end product has everything you said it would.
Time Management: Figuring out the time it will take to do your work and the order you need to do it in. Tracking your schedule and making sure everything gets done on time.
Quality Management: Making sure you work as efficiently as you can and don’t add defects into the product.
Cost Management: Knowing how much you’re able to invest in the project and making sure you spend it right.
Human Resource Management: Getting the people to work on the team and helping them stay motivated. Rewarding them for a job well done and resolving conflicts that come up
Communications Management: Making sure that everybody knows what they need to know to do their job right. Tracking how people talk to each other and dealing with misunderstandings or miscommunications if they happen.
Procurement Management: Finding contractors to help you do the work. Setting the ground rules for their relationships with your company.
Risk Management: Figuring out how to protect your project from anything that could happen to it. Dealing with the unexpected when it does happen.

Points to Remember - Other Topics:

Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility

Some Nice Questions - Part 1

1: What are the differences between a project coordinator and a project expediter?

They’re actually pretty similar. A project expediter is somebody who keeps track of status but has no decision-making authority on a project at all. A project coordinator is someone who does pretty much the same thing, but does get to make some of the minor decisions on the project without having to run them by the functional manager. Coordinators usually report to somebody who is pretty high up in the organization, while expediters are more like assistants to the functional manager. Both of them usually exist in weak-matrix or functional organizations.

2: Does the PMP exam favor any kind of organization?

When you’re taking the PMP exam, if you see a question that mentions a PM, then you should assume that the question is asking about a matrix organization if it doesn’t say up front which kind of organization is being described. Functional organizations are usually painted in a negative light because they tend to give less authority to project managers.

3: what’s the difference between process groups and knowledge areas?

The process groups divide up the processes by function. The knowledge areas divide the same processes up by subject matter. Think of the process groups as being about the actions you take on your project, and the knowledge areas as the things you P need to understand. In other words, the knowledge areas are more about helping you understand the PMBOK® Guide material than about running your project. But that doesn’t mean that every knowledge area has a process in every process group! For example, the Initiating process group only has two processes, and they both show up in the Integration Management knowledge area. The Risk Management knowledge area only has Planning and Monitoring & Controlling processes. So the process groups and the knowledge areas are two different ways to think about all of the processes, but they don’t really overlap.

4: Can a process be part of more than one process group?

No, each of the processes belongs to only one process group. The best way to figure out which group a process belongs to is to remember what that process does. If the process is about defining high-level goals of the project, it’s in Initiating. If it’s about planning the work, it’s in Planning. If you are actually doing the work, it’s in Executing. If you’re tracking the work and finding problems, it’s in Monitoring & Controlling. And if you’re finishing stuff off after you’ve delivered the product, that’s Closing.

5: Do you do all of the processes in every project?

Not always. Some of the processes only apply to projectized organizations or subcontracted work, so if your company doesn’t do that kind of thing, then you won’t need those processes. But if you want to make your projects come out well, then it really does make sense to use the processes. Even a small project can benefit from taking the time to plan out the way you’ll handle all of the knowledge areas. If you do your homework and pay attention to all of the processes, you can avoid most of the big problems that cause projects to run into trouble!


6: At a high level, the initiating & planning process groups look very similar. Are they really different?

Initiating is everything you do when you first start a project. You start by writing down (at a very high level) what the project is going to produce, who’s in charge of it, and what tools they need to do the work. In a lot of companies, the
project manager isn’t even involved in a lot of this. Planning just means going into more detail about all of that as you learn

more about it, and writing down specifically how you’re going to do the work. The Planning processes are where the project
manager is really in control and does most of the work.

7: What are Enterprise Environmental Factors?

Enterprise Environmental Factors tell you about how your company does business. There’s a lot of information about your company that will be really useful to you when you’re planning your project. You need to know how each of the different departments operates, the market conditions you’re working in, the company’s overall strategy, any policies you need to work with, your company’s culture, and all about the people who work at the company.

8: What are Organizational Process Assets?

Organizational Process Assets tell you about how your company normally runs its projects. Every company has standards for how to run their projects. There are guidelines and instructions for managing projects, procedures you need to follow, categories for various things you need to keep track of, and templates for all of the various documents that you need to create. These things are usually stored in some sort of library. One of the most important organizational process assets is called lessons learned, which is how you keep track of valuable historical information about your project. At the end of every project, you sit down with the project team and write down everything you learned about the project. This includes both positive and negative things. That way, when you or another project manager in your company plans the next project, you can take advantage of the lessons you learned on this one.

9: How is the Business Case different from the Project Charter?

The business case is a description of what your company is trying to get out of the project—like how much money you’re planning on making from the project, how it will benefit parts of your organization, and future business you might gain from the project.P PT he project charter is a high-level description of your project. It tells you—and anyone else who needs to know about your project—what you’ll be delivering, including a really high-level description of what it is that you’ll build. A really important difference between them is that the project charter is what authorizes the project manager to do the work, while the business case helps give justification for the project. You can think of the business case as the background research that had to be done in order to make sure the project was worth doing, and the project charter as the thing that formally announces the decision to do it.

10: Do Project Sponsors really type & create the Project charter? Usually Sponsors are people in high positions in a company and do they do such tasks as well?

This is actually a very nice question. Sponsors are important people in an organization and that’s exactly why the project sponsor will often delegate the actual creation of the charter to the project manager. For the exam, though, keep in mind that the sponsor is ultimately responsible for creation of the charter irrespective of whether he types the whole thing or delegates it to someone else.

11: Isn’t a project plan just something I get out of Microsoft Project?

No. The project management plan is not the same thing as a project schedule. You’ll use a tool like Microsoft Project when you’re doing Time Management to build the project schedule. (It’s also useful for other knowledge areas as well.) But you’ll use your project management plan as a guide to help you develop that schedule. It will tell you what tools to use when you develop it, and how changes will be handled.


12: What is a performance baseline and what do I do with it?

A performance baseline is a snapshot of your project’s scope, schedule, and cost. When you plan out the work you’ll do on a project, you write it down all of the activities you’ll need to do and save that understanding as your scope baseline. You’ll do the same with your understanding of the project’s schedule and its cost. That way, you can always compare your actual
performance to your plan. Every time a change is approved, that means the plan has changed. So you have to update your baseline to include the new work (or cost, or schedule).

13: Can you explain Project Integration Management in one line?

Integration Management means making sure that all of the processes work together seamlessly to make your project successful.

14: Does the project manager care only about the project scope? Doesn’t he care about the product scope?

No, you still need to think about your project’s final product. You can never ignore product scope, because most projects have changes to the product scope along the way. You’ll have to change your product scope to include the work that’s caused by
product scope changes. Changes like that will probably have an impact on time and cost, too.

For Ex: Lets saty, you are the project manager who manages a project that is part of the scope of Product X. If somebody asks for a new feature in Product X, the first thing the team needs to do is understand how much work is involved to accommodate it, and what that scope change will do to the cost and schedule. As a project manager, your main concern is understanding that impact, and making sure everyone is OK with it before the change gets made. It’s not your job to decide which is the best feature for the product, just to help everybody involved keep their priorities in mind and do what’s best for the project.


15: How do I know when I am done collecting requirements?

That’s a good question. Your requirements need to be measurable to be complete. So it’s not enough to write down that you want good performance in your product. You need to be able to tell people what measurement counts as good performance for you. You have to be able to confirm that all of your requirements are met when you close out your project, so you can’t leave requirements up to interpretation. You know your requirements are complete when you’ve got a way to verify each of them once they’re built.

Some More Questions:

More Questions - Part 2
More Questions - Part 3