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
Showing posts with label project management professional. Show all posts
Showing posts with label project management professional. Show all posts
Friday, July 22, 2011
Friday, July 15, 2011
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
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
Wednesday, July 13, 2011
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
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
Saturday, July 9, 2011
Chapter 94: Introduction to Professional Responsibility
As the name of the certification suggests, you are going to become a project management professional. A professional is an individual who practices an occupation with professionalism, which is a bond that binds a professional with the code of conduct for that occupation. Professionalism is not Einstein’s theory of relativity. You might need to learn a few things in the beginning, but during the course of practicing a profession, professional conduct (a.k.a professionalism) becomes common sense. All professions share the essence of professionalism. It is as simple as doing the right thing. As a project manager, remember one golden rule: Deal with unprofessional situations directly, openly, and fairly, rather than ignoring them. Professionalism starts with individual integrity, which is based on truth, honesty, and openness.
We will learn more about individual integrity, interaction with clients and project stakeholders, and core values of ethical and professional conduct in the next few chapters.
Prev: Important Terms - Closing the Project
Next: Ensuring Individual Integrity
We will learn more about individual integrity, interaction with clients and project stakeholders, and core values of ethical and professional conduct in the next few chapters.
Prev: Important Terms - Closing the Project
Next: Ensuring Individual Integrity
Thursday, June 2, 2011
Chapter 38: Developing the Project Schedule
In the previous chapters, we calculated the resource requirements for the project and estimated the duration to complete each activity. Once we know how many people are required and how long the project is going to take to complete, the next step would be to create the project schedule. This is exactly what we are going to learn in this chapter.
So, lets get started!!!
The Project Schedule:
The project work is composed of several individual activities. By using the data we gathered in the previous chapters, you must work out a few schedule-related pieces at the activity level, which come together as the project schedule when you run them through the schedule development process, formally called Develop Schedule. Until you have a realistic project schedule, you do not have a project. A project schedule has schedule activities sandwiched between the project start date and the project finish date.
As always, we have inputs to the develop schedule activity, use some tools and techniques and produce the output. Look at the picture below:
Input to Schedule Development
The following output items from the schedule-related processes discussed in the previous chapters directly support the schedule development process:
Project scope statement - The assumptions and constraints in the project scope statement can affect the project schedule and therefore must be considered in developing the schedule. The following two types of time-related constraints should get special attention.
Enterprise environmental factors and process assets – The environment in which the project is executed and the processes followed in the organization can have a profound impact on the schedule. You can learn more about these by clicking here
Tools and Techniques for Schedule Development
Once you have the network diagrams for the activities, as well as the activity duration estimates, you are well equipped to start scheduling the project. The remaining main concerns include:
The tools and techniques discussed in the following paragraphs can be used to address these concerns while you are finalizing the project schedule.
Schedule Network Analysis
Schedule network analysis is a technique used to generate a project schedule by identifying the early and late start and finish dates for the project. The analysis accomplishes this task by using various analytical techniques, such as critical path method, critical chain method, what-if analysis, and resource leveling.
All these techniques will take into consideration a project network diagram. Remember the network diagram we saw in the Sequencing Activities chapter?
We will be using this for our discussion in this chapter as well.
Critical path method - This is the schedule network analysis technique used to identify the schedule flexibility and the critical path of the project schedule network diagram. The critical path is the longest path (sequence of activities) in a project schedule network diagram. Because it is the longest path, it determines the duration of the project and hence the finish date of the project given the start date. The boxes in the image above represent activities, such as Activity A followed by Activity B, and so on. For simplicity lets assume that each activity is going to take 5 days to complete.
Let us look at how long it will take to complete these activities based on the different paths we can take:
This means that if we start the project on 1st June 2011 and take the 1st path (A-B) it will take 10 working days and the project will be over on June 14th EOD (considering the two weekends that come in between)
The second important feature of the critical path method is to identify the flexibility in the project schedule by calculating the early and late start and finish dates of each activity on each path. The schedule flexibility of an activity is measured by the positive difference between the late start date and the early start date for the activity and is called float time or total float.
Let us take the same network diagram above. Since A is the first activity on the path, its early start is Day 0. But, because B depends on the completion of A and A takes 5 days to finish, the early start date for B is the early start date of A + the duration of A, i.e., 0+5 = 5.
The late start and finish dates are calculated using the backward-pass method, which means you start your calculations from the finish point. The project finish date determined by critical path is for ex Day 12, given that the project start date is Day 0. Because Activity B has duration of 5 days, it must be started no later than Day 7 (12-5). Therefore Day 7 is the late start date of Activity B. Now, activity A has duration of 5 days. So, given that B must start on Day 7, A must start no later than Day 2 (7-5). Therefore the late start date for activity A is Day 2.
The float times are calculated as follows:
Note: Each activity on the critical path will always have a float time of ‘0’. This is because we have calculated the early/late start dates based on the critical path estimate and the other paths obviously don't take that much time and hence can afford the float time whereas the critical path activities cannot.
Critical chain method - This is an alternative schedule network analysis technique that takes into account the uncertainties of the activity durations due the uncertainty of the availability of resources. It uses schedule network diagrams to identify the critical paths and the schedule flexibility, just like the critical path method. The only difference is that in this technique, you work from more than one network diagram. For example, the durations in the first network are based on the planned scenario regarding the availability of resources. You can draw another network diagram based on the pessimistic scenario regarding the availability of resources. The durations of some activities in the second diagram will be longer than the first diagram, and the second diagram might even have a different or an additional critical path. The extra durations in the second diagram are called duration buffers. So, the focus of the critical chain method is on managing the duration buffers and the uncertainties in the availability of resources applied to the planned schedule activities.
Resource leveling - Resource leveling is not an independent schedule network analysis method. It is applied to the schedule that has already been analyzed using other methods, such as the critical path method or the critical chain method. The resource leveling technique is applied to address the resource needs of activities that must be performed to meet specific delivery dates. Resource leveling involves taking a part of the resources from one activity and assigning it to another. This will change the activity durations and can also result in a change of critical paths.
What-if scenario analysis - The purpose of what-if scenario analysis is to calculate the effects of a specific scenario on the schedule. For example, how the schedule will be affected if a vendor does not make the delivery of a major component on the promised date. Because a what-if scenario by definition represents uncertainty, this analysis often leads to risk planning, which might include changing the schedule or changing the network diagram to get a few activities out of harm’s way if possible.
To Summarize:
• The critical path method is used to develop a schedule for given resources
• The critical chain method factors in the uncertainty of the availability of the resources
• The resource leveling technique is used to move the resources around to meet the resource needs of the activities that must be accomplished on a specific date.
In an ideal scenario in which the required resources are guaranteed, you do not need the critical chain method and resource leveling; just the critical path method will do.
Let’s say you have used critical path method to determine the project schedule. You have also applied other techniques like critical chain method and resource leveling. The final realistic schedule that you came up, has a number that is unacceptable (simple example, your manager doesn't approve of the time). What can you do? The Schedule Compression Technique comes to our rescue!!!
Schedule Compression
Schedule compression is an attempt to shorten the project schedule without changing the project scope. It may be necessary in order to deal with schedule-related constraints and objectives. It is true that you, the project manager, build the schedule through cold, hard mathematical analysis, and you don’t just accept whatever schedule goals come down the pipeline from elsewhere (usually the top), such as from the customer or the project sponsor. However, once you have the schedule built through analysis, you can attempt to accommodate some critical stakeholder expectations or hard deadlines, such as a predetermined project finish date.
In the previous section we already saw about Resource Leveling that can be used to accommodate hard deadlines for certain activities. There are two other techniques that can be used for compressing the project schedule. They are:
Crashing - This is a project schedule compression technique in which cost and schedule tradeoffs are analyzed to decrease the project duration with minimal additional cost. A number of alternatives are analyzed, including the assignment of additional resources. Approving overtime pay for project resources is another example of crashing.
Fast tracking - This is a project schedule compression technique used to decrease the project duration by performing project phases or some schedule activities within a phase in parallel that would normally be performed in sequence. For example, testing of a product can start when some of its components are finished, rather than waiting for the whole product to be completed.
Other Tools and Techniques
In addition to the main techniques to develop the project schedule, there are some other tools and techniques for developing the project schedule. They are:
Applying leads and lags - Just like in the activity sequencing process, leads and lags can be applied during the development of project schedule. If you applied some leads and lags during the activity sequencing process, it is time to consider whether you need to adjust those. This adjustment might be necessary to create a realistic schedule.
Project management software - After you have the data for the schedule development created by the processes discussed in this chapter, it is a common practice to use project management software to build the actual schedule. Because they are automated, the scheduling tools expedite the scheduling process and reduce the probability of errors in the schedule.
Output of the Schedule Development Process
The output of the schedule development process include:
Project schedule - The project schedule includes a planned start date and a planned finish date for each schedule activity. The schedule will be considered preliminary until the resources have been assigned to perform the activities according to the schedule. Although a schedule for a simple project might be presented in a tabular form, typically a project schedule is presented in one of the following graphical formats:
• Project schedule network diagram - These diagrams present the schedule activities on a timescale with a start and a finish date for each activity and hence show the dependencies of activities on each other. Because they show the dependencies or the logic, they are also called logic charts.
• Bar chart - In these charts the activities are represented by bars, with each bar showing the start date, the finish date, and the duration of the activity. They are easy to read and are often used in presentations.
• Milestone chart - These are typically the bar charts representing only the milestones, not all the schedule activities.
Schedule data - This is the supporting data for the project schedule and consists of the following:
• The essential data consists of schedule activities, schedule milestones, activity attributes, and documentation of all identified assumptions and constraints.
• Resource requirements by time periods.
• Alternative schedules. For ex:, schedules based on best-case and worst-case scenarios.
• Schedule contingency reserves.
Schedule baseline - This is a specific version of the project schedule that is accepted and approved by the project management team as a baseline against which the progress of the project will be measured. This version of the schedule is developed from the schedule network analysis described earlier in the chapter.
Updates to project documents - During the process of developing the schedule, updates to the following documents may happen:
• Resource requirements - The schedule development process might change the initial estimate for the types and quantities of required resources.
• Activity attributes - Resource requirements or any other activity attributes that have changed must be updated.
• Project calendar - Any update to the project calendar must be documented. For example, each project may use different calendar units in the project schedule.
Project schedule development is an iterative process. For example, it might be necessary to review and revise the duration and resource estimates for some activities to create a project schedule that will be approved. The approved project schedule will act as a baseline against which project progress will be tracked.
Prev: Estimating Activity Duration
Next: Project Communication
So, lets get started!!!
The Project Schedule:
The project work is composed of several individual activities. By using the data we gathered in the previous chapters, you must work out a few schedule-related pieces at the activity level, which come together as the project schedule when you run them through the schedule development process, formally called Develop Schedule. Until you have a realistic project schedule, you do not have a project. A project schedule has schedule activities sandwiched between the project start date and the project finish date.
As always, we have inputs to the develop schedule activity, use some tools and techniques and produce the output. Look at the picture below:
Input to Schedule Development
The following output items from the schedule-related processes discussed in the previous chapters directly support the schedule development process:
• Activity list and activity attributes
• Project schedule network diagrams showing the dependencies among activities
• Activity resource requirements and resource calendars
• Activity duration estimates
Project scope statement - The assumptions and constraints in the project scope statement can affect the project schedule and therefore must be considered in developing the schedule. The following two types of time-related constraints should get special attention.
• Hard deadlines for start and finish dates - Some activities or work packages might have constraints on their start or finish dates. For example, there might be a situation in which an activity cannot be started before a certain date, or must be finished before a certain date, or both. Where do these date constraints come from? They can come from various sources, such as a date in the contract, a date determined by the market window, a date determined by delivery of material from an external vendor, and so on.
• Time constraints on deliverables - These constraints can come from the customer, the sponsor, or any other stakeholder in terms of deadlines for certain major deliverables or milestones. Other projects inside or outside your organization might be depending on these constraints. So, once scheduled, these deadlines are constraints and can only be changed through the approval process.
Enterprise environmental factors and process assets – The environment in which the project is executed and the processes followed in the organization can have a profound impact on the schedule. You can learn more about these by clicking here
Tools and Techniques for Schedule Development
Once you have the network diagrams for the activities, as well as the activity duration estimates, you are well equipped to start scheduling the project. The remaining main concerns include:
• The actual start date
• Uncertainty of the availability of resources
• Identification of and preparation for activities on the critical path
• Risks involved or what-if scenarios
• The hard start/finish dates for activities or for the project that came down the pipeline from very important stakeholders
The tools and techniques discussed in the following paragraphs can be used to address these concerns while you are finalizing the project schedule.
Schedule Network Analysis
Schedule network analysis is a technique used to generate a project schedule by identifying the early and late start and finish dates for the project. The analysis accomplishes this task by using various analytical techniques, such as critical path method, critical chain method, what-if analysis, and resource leveling.
All these techniques will take into consideration a project network diagram. Remember the network diagram we saw in the Sequencing Activities chapter?
We will be using this for our discussion in this chapter as well.
Critical path method - This is the schedule network analysis technique used to identify the schedule flexibility and the critical path of the project schedule network diagram. The critical path is the longest path (sequence of activities) in a project schedule network diagram. Because it is the longest path, it determines the duration of the project and hence the finish date of the project given the start date. The boxes in the image above represent activities, such as Activity A followed by Activity B, and so on. For simplicity lets assume that each activity is going to take 5 days to complete.
Let us look at how long it will take to complete these activities based on the different paths we can take:
1. Start – A – B – Finish = 10 days
2. Start – C – D – E – Finish = 15 days
3. Start – F – H – I – finish = 15 days
This means that if we start the project on 1st June 2011 and take the 1st path (A-B) it will take 10 working days and the project will be over on June 14th EOD (considering the two weekends that come in between)
The second important feature of the critical path method is to identify the flexibility in the project schedule by calculating the early and late start and finish dates of each activity on each path. The schedule flexibility of an activity is measured by the positive difference between the late start date and the early start date for the activity and is called float time or total float.
Let us take the same network diagram above. Since A is the first activity on the path, its early start is Day 0. But, because B depends on the completion of A and A takes 5 days to finish, the early start date for B is the early start date of A + the duration of A, i.e., 0+5 = 5.
The late start and finish dates are calculated using the backward-pass method, which means you start your calculations from the finish point. The project finish date determined by critical path is for ex Day 12, given that the project start date is Day 0. Because Activity B has duration of 5 days, it must be started no later than Day 7 (12-5). Therefore Day 7 is the late start date of Activity B. Now, activity A has duration of 5 days. So, given that B must start on Day 7, A must start no later than Day 2 (7-5). Therefore the late start date for activity A is Day 2.
The float times are calculated as follows:
Float time for A = late start − early start = 2−0 = 2
Float time for B = late start − early start = 7−5 = 2
Note: Each activity on the critical path will always have a float time of ‘0’. This is because we have calculated the early/late start dates based on the critical path estimate and the other paths obviously don't take that much time and hence can afford the float time whereas the critical path activities cannot.
Trivia:
Each activity on a critical path has zero float time and therefore poses a schedule risk. So, you must monitor the activities on all critical paths very closely during the execution of the project.
Critical chain method - This is an alternative schedule network analysis technique that takes into account the uncertainties of the activity durations due the uncertainty of the availability of resources. It uses schedule network diagrams to identify the critical paths and the schedule flexibility, just like the critical path method. The only difference is that in this technique, you work from more than one network diagram. For example, the durations in the first network are based on the planned scenario regarding the availability of resources. You can draw another network diagram based on the pessimistic scenario regarding the availability of resources. The durations of some activities in the second diagram will be longer than the first diagram, and the second diagram might even have a different or an additional critical path. The extra durations in the second diagram are called duration buffers. So, the focus of the critical chain method is on managing the duration buffers and the uncertainties in the availability of resources applied to the planned schedule activities.
Resource leveling - Resource leveling is not an independent schedule network analysis method. It is applied to the schedule that has already been analyzed using other methods, such as the critical path method or the critical chain method. The resource leveling technique is applied to address the resource needs of activities that must be performed to meet specific delivery dates. Resource leveling involves taking a part of the resources from one activity and assigning it to another. This will change the activity durations and can also result in a change of critical paths.
What-if scenario analysis - The purpose of what-if scenario analysis is to calculate the effects of a specific scenario on the schedule. For example, how the schedule will be affected if a vendor does not make the delivery of a major component on the promised date. Because a what-if scenario by definition represents uncertainty, this analysis often leads to risk planning, which might include changing the schedule or changing the network diagram to get a few activities out of harm’s way if possible.
To Summarize:
• The critical path method is used to develop a schedule for given resources
• The critical chain method factors in the uncertainty of the availability of the resources
• The resource leveling technique is used to move the resources around to meet the resource needs of the activities that must be accomplished on a specific date.
In an ideal scenario in which the required resources are guaranteed, you do not need the critical chain method and resource leveling; just the critical path method will do.
Let’s say you have used critical path method to determine the project schedule. You have also applied other techniques like critical chain method and resource leveling. The final realistic schedule that you came up, has a number that is unacceptable (simple example, your manager doesn't approve of the time). What can you do? The Schedule Compression Technique comes to our rescue!!!
Schedule Compression
Schedule compression is an attempt to shorten the project schedule without changing the project scope. It may be necessary in order to deal with schedule-related constraints and objectives. It is true that you, the project manager, build the schedule through cold, hard mathematical analysis, and you don’t just accept whatever schedule goals come down the pipeline from elsewhere (usually the top), such as from the customer or the project sponsor. However, once you have the schedule built through analysis, you can attempt to accommodate some critical stakeholder expectations or hard deadlines, such as a predetermined project finish date.
In the previous section we already saw about Resource Leveling that can be used to accommodate hard deadlines for certain activities. There are two other techniques that can be used for compressing the project schedule. They are:
Crashing - This is a project schedule compression technique in which cost and schedule tradeoffs are analyzed to decrease the project duration with minimal additional cost. A number of alternatives are analyzed, including the assignment of additional resources. Approving overtime pay for project resources is another example of crashing.
Fast tracking - This is a project schedule compression technique used to decrease the project duration by performing project phases or some schedule activities within a phase in parallel that would normally be performed in sequence. For example, testing of a product can start when some of its components are finished, rather than waiting for the whole product to be completed.
Trivia:
Crashing usually involves assigning more resources and hence increases the cost. However, guard yourself against the misconception that additional resources will linearly improve the performance. For example, if one programmer can develop a program in eight days, it does not necessarily mean that two programmers will develop the same program in four days, because there will be overheads, such as the initial less-productive stage of the newly assigned resource, the time taken to reallocate the work, the interaction among the resources, and so on. Remember the example from one of the previous chapters, 10 girls cannot deliver a baby in 1 month.
Other Tools and Techniques
In addition to the main techniques to develop the project schedule, there are some other tools and techniques for developing the project schedule. They are:
Applying leads and lags - Just like in the activity sequencing process, leads and lags can be applied during the development of project schedule. If you applied some leads and lags during the activity sequencing process, it is time to consider whether you need to adjust those. This adjustment might be necessary to create a realistic schedule.
Project management software - After you have the data for the schedule development created by the processes discussed in this chapter, it is a common practice to use project management software to build the actual schedule. Because they are automated, the scheduling tools expedite the scheduling process and reduce the probability of errors in the schedule.
Output of the Schedule Development Process
The output of the schedule development process include:
Project schedule - The project schedule includes a planned start date and a planned finish date for each schedule activity. The schedule will be considered preliminary until the resources have been assigned to perform the activities according to the schedule. Although a schedule for a simple project might be presented in a tabular form, typically a project schedule is presented in one of the following graphical formats:
• Project schedule network diagram - These diagrams present the schedule activities on a timescale with a start and a finish date for each activity and hence show the dependencies of activities on each other. Because they show the dependencies or the logic, they are also called logic charts.
• Bar chart - In these charts the activities are represented by bars, with each bar showing the start date, the finish date, and the duration of the activity. They are easy to read and are often used in presentations.
• Milestone chart - These are typically the bar charts representing only the milestones, not all the schedule activities.
Schedule data - This is the supporting data for the project schedule and consists of the following:
• The essential data consists of schedule activities, schedule milestones, activity attributes, and documentation of all identified assumptions and constraints.
• Resource requirements by time periods.
• Alternative schedules. For ex:, schedules based on best-case and worst-case scenarios.
• Schedule contingency reserves.
Schedule baseline - This is a specific version of the project schedule that is accepted and approved by the project management team as a baseline against which the progress of the project will be measured. This version of the schedule is developed from the schedule network analysis described earlier in the chapter.
Updates to project documents - During the process of developing the schedule, updates to the following documents may happen:
• Resource requirements - The schedule development process might change the initial estimate for the types and quantities of required resources.
• Activity attributes - Resource requirements or any other activity attributes that have changed must be updated.
• Project calendar - Any update to the project calendar must be documented. For example, each project may use different calendar units in the project schedule.
Project schedule development is an iterative process. For example, it might be necessary to review and revise the duration and resource estimates for some activities to create a project schedule that will be approved. The approved project schedule will act as a baseline against which project progress will be tracked.
Prev: Estimating Activity Duration
Next: Project Communication
Wednesday, May 4, 2011
Chapter 5: Understanding a Process
In the previous chapter we learnt what progressive elaboration is. At the end of it, we saw that every project needs to follow a set of processes. In this chapter, we are going to understand them in detail.
So, lets get started!!!
What is a Process?
Processes are the heart of project management. If you want to think of project management like a project management professional, think in terms of processes. Almost everything in the world of project management is done through processes. Any good project manager respects and follows the processes properly. In the short term, skipping a process might sound like a time saving option but the reality is, following them would give you more benefits than the time you save by skipping them.
To understand more about processes, we must first define them. Look around you, you will see processes everywhere, not only in project management. For example, if you want to make an egg omlette, you first let the pan heat up in the stove, sprinkle a little oil on it, crack open the egg and beat it with salt and pepper in a bowl, add a little onions for taste and then pour the beat up egg in the pan. You let it cook for a minute and then flip it over until both sides are a golden brown. And voila, a tasty omlette is ready for you to eat.
Here, the pan is the tool and how you make the omlette is the process. The output is a plate of fresh egg omlettes for you to feast on.
So, a process is a set of interrelated activities performed to obtain a specified result.
Every process has 3 elements:
• Input
• Tools
• Techniques
In our case:
• Oil, salt, pepper, onions and egg are the inputs
• The frying pan and the stove are the tools
• The cooked omlette is the final output
This is just a real-life simple example of a process. You would be using so many processes in real life without even realizing the fact.
Processes in Project Management:
In project management, you use processes to accomplish things like developing a project schedule, directing and managing project execution, developing and managing the project team and so on…
From the project management perspective, the 3 elements of a process would be:
• Input - The input to a process consists of the raw data that is needed to start the process. For example, the list of activities that need to be scheduled is one of several input items to the process that will be used to develop the schedule of a project.
• Tools and techniques - Tools and techniques are the methods used to operate on the input to transform it into output. For example, project management software that helps to develop a schedule is a tool used in the schedule development process.
• Output - The output is the outcome or the result of a process. Each process contains at least one output item; otherwise, there would be no point in performing a process. For example, an output item of the schedule development process is, well, the project schedule.
Now that you understand what a process is, you likely realize that you will be using different processes at the different stages of a project, such as planning and execution.
Every project has a lifecyle and you will be using numerous processes as part of each of those stages in a projects lifecycle. This is what you will be learning in the next chapter…
Previous: Progressive Elaboration
Next: Project Lifecycle
So, lets get started!!!
What is a Process?
Processes are the heart of project management. If you want to think of project management like a project management professional, think in terms of processes. Almost everything in the world of project management is done through processes. Any good project manager respects and follows the processes properly. In the short term, skipping a process might sound like a time saving option but the reality is, following them would give you more benefits than the time you save by skipping them.
To understand more about processes, we must first define them. Look around you, you will see processes everywhere, not only in project management. For example, if you want to make an egg omlette, you first let the pan heat up in the stove, sprinkle a little oil on it, crack open the egg and beat it with salt and pepper in a bowl, add a little onions for taste and then pour the beat up egg in the pan. You let it cook for a minute and then flip it over until both sides are a golden brown. And voila, a tasty omlette is ready for you to eat.
Here, the pan is the tool and how you make the omlette is the process. The output is a plate of fresh egg omlettes for you to feast on.
So, a process is a set of interrelated activities performed to obtain a specified result.
Every process has 3 elements:
• Input
• Tools
• Techniques
In our case:
• Oil, salt, pepper, onions and egg are the inputs
• The frying pan and the stove are the tools
• The cooked omlette is the final output
This is just a real-life simple example of a process. You would be using so many processes in real life without even realizing the fact.
Processes in Project Management:
In project management, you use processes to accomplish things like developing a project schedule, directing and managing project execution, developing and managing the project team and so on…
From the project management perspective, the 3 elements of a process would be:
• Input - The input to a process consists of the raw data that is needed to start the process. For example, the list of activities that need to be scheduled is one of several input items to the process that will be used to develop the schedule of a project.
• Tools and techniques - Tools and techniques are the methods used to operate on the input to transform it into output. For example, project management software that helps to develop a schedule is a tool used in the schedule development process.
• Output - The output is the outcome or the result of a process. Each process contains at least one output item; otherwise, there would be no point in performing a process. For example, an output item of the schedule development process is, well, the project schedule.
Now that you understand what a process is, you likely realize that you will be using different processes at the different stages of a project, such as planning and execution.
Every project has a lifecyle and you will be using numerous processes as part of each of those stages in a projects lifecycle. This is what you will be learning in the next chapter…
Previous: Progressive Elaboration
Next: Project Lifecycle
Chapter 4: What is Progressive Elaboration
In the previous chapter, we understood in detail what a project is. In this chapter, we are going to see what Progressive Elaboration is.
So, lets get started!!!
What is Progressive Elaboration
Projects may be temporary endeavors but they cannot be conceived in a day and for sure cannot be executed/completed in a day (unless you define going to the grocery store as a project)
Usually there is a concept first and then a broad vision for the end product, i.e., the outcome or result of the project.
The clearer vision you have of the unique product that you want from the project, the more accurate the project plan will be. So, you move toward the final project plan in incremental steps as the ideas about the final product are refined and as you get more and more information about the requirements in a progressive fashion. This procedure of defining (or planning) a project is called progressive elaboration.
Example of Progressive Elaboration:
Let us imagine the following:
You are the Managing Director of Honda Motors and you wake up one fine day with an idea to reassert Honda as a leading car manufacturer. You intend on doing that by creating a super fast sports car that is going to give the Ferraris and the Lamborghinis a run for their money. How do you do it?
You first conceptualize your car, how you want it to look, how much you want to price it, the kind of speed you want it to reach, the kind of luxury & safety features you want in your car, the list is endless. Going back to the first line of this paragraph, you cannot list down the whole set of requirements in a day.
You first define a set of basic guidelines like:
I want my car to touch 300 kmph and not exceed $250,000. It must be one of the most luxurious drives a car aficionado can get his hands on. It must have top of the line safety features.
The next step would be to call for a meeting with your top designers and engineers and kick start the cycle. They will now take your basic guidelines and start building on it. Once all the requirements of your dream sports car is ready, you go to the next big step.
How are you going to do this?
Here you are referring to the project plan. By now, you could have understood that a project plan is a detailed step by step explanation of how you intend on completing a project. All the resources involved (men, money, time etc) will be taken into account and steps will be outlined that the people involved in the development of the project will follow to take the project to success.
What will be the Result?
A product, a super fast sports car that will take the markets by storm…
Progressive elaboration, in general, means developing something in incremental steps. The project plan will be broadly defined to start and will get more accurate, detailed, and explicit in an incremental fashion as better understanding about the project deliverables and objectives develops. It involves successive iterations of the planning process resulting in a more accurate and complete plan.
Even after you have an approved final project plan and the project starts executing, progressive elaboration continues to some extent.
Each stage of a project is managed by performing a set of processes. And the process is what we will learn in the next chapter…
Previous: Understanding Projects
Next: Understanding Process
So, lets get started!!!
What is Progressive Elaboration
Projects may be temporary endeavors but they cannot be conceived in a day and for sure cannot be executed/completed in a day (unless you define going to the grocery store as a project)
Usually there is a concept first and then a broad vision for the end product, i.e., the outcome or result of the project.
The clearer vision you have of the unique product that you want from the project, the more accurate the project plan will be. So, you move toward the final project plan in incremental steps as the ideas about the final product are refined and as you get more and more information about the requirements in a progressive fashion. This procedure of defining (or planning) a project is called progressive elaboration.
Example of Progressive Elaboration:
Let us imagine the following:
You are the Managing Director of Honda Motors and you wake up one fine day with an idea to reassert Honda as a leading car manufacturer. You intend on doing that by creating a super fast sports car that is going to give the Ferraris and the Lamborghinis a run for their money. How do you do it?
You first conceptualize your car, how you want it to look, how much you want to price it, the kind of speed you want it to reach, the kind of luxury & safety features you want in your car, the list is endless. Going back to the first line of this paragraph, you cannot list down the whole set of requirements in a day.
You first define a set of basic guidelines like:
I want my car to touch 300 kmph and not exceed $250,000. It must be one of the most luxurious drives a car aficionado can get his hands on. It must have top of the line safety features.
The next step would be to call for a meeting with your top designers and engineers and kick start the cycle. They will now take your basic guidelines and start building on it. Once all the requirements of your dream sports car is ready, you go to the next big step.
How are you going to do this?
Here you are referring to the project plan. By now, you could have understood that a project plan is a detailed step by step explanation of how you intend on completing a project. All the resources involved (men, money, time etc) will be taken into account and steps will be outlined that the people involved in the development of the project will follow to take the project to success.
What will be the Result?
A product, a super fast sports car that will take the markets by storm…
Progressive elaboration, in general, means developing something in incremental steps. The project plan will be broadly defined to start and will get more accurate, detailed, and explicit in an incremental fashion as better understanding about the project deliverables and objectives develops. It involves successive iterations of the planning process resulting in a more accurate and complete plan.
Even after you have an approved final project plan and the project starts executing, progressive elaboration continues to some extent.
Trivia:
Uncontrolled changes that make their way into the project without being properly processed are called scope creep. Do not confuse progressive elaboration with scope creep. And don't worry about scope creep just yet. We are just getting started. We will deal with this bad boy in detail very soon.
Each stage of a project is managed by performing a set of processes. And the process is what we will learn in the next chapter…
Previous: Understanding Projects
Next: Understanding Process
Chapter 3: Understanding Projects
Well, we have taken the first baby step towards getting our PMP Certification. In the previous chapter, we learnt what a Project is and many other important terms that are essential for us to know in our quest of the elusive PMP title.
In this chapter, we are going to get a better understanding of what a project is and what a project lifecycle is.
So, lets get started!!!
What makes Projects Different?
You might have been wondering, what makes projects different. From the previous chapter, we learnt that the project is a temporary endeavor to accomplish a defined task. You might ask me, any organization might have so many activities that are executed on a daily basis. What makes projects different?
The activities taken up by any organization fall into two distinct categories:
1. Projects &
2. Operations
An Operation is an ongoing and repetitive set of tasks like cleaning the washrooms daily, or maintenance of the power back up in the building once every month etc. It has no end (unless the company goes bust) whereas; a Project has a lifecycle, a beginning and a definite end.
Understanding a Project
A project is a work effort made over a finite period of time with a start and a finish to create a unique product or service or result. Because a project has a start and a finish, it is also called a temporary effort or endeavor. In other words, a project is a temporary endeavor taken to create a unique product, service or result. So, a project has two defining characteristics: It is temporary, and it creates a unique result.
Let’s try to understand these two defining concepts: temporary and unique.
Temporary - The temporary nature of projects refers to the fact that each project has a definite beginning and a definite end. A project can reach its end in one of two possible ways:
• The project has met its objectives—that is, the planned unique product has been created or the results achieved.
• The project has been terminated before its successful completion for whatever reason.
The temporary nature of projects can also apply to two other aspects:
• The opportunity to market the product that the project will produce is temporary—that is, the product needs to be produced in a limited timeframe; otherwise, it will be too late.
• A project team is temporary—that is, the project team is disbanded after the project ends, and the team members may be assigned to other projects eventually.
However, remember that the temporary nature of a project does not refer to the product it creates. The results or outcomes of a project are usually long lasting. Go back to the building your home example. Even though the construction process ends after say 9 months, your house is going to stand forever (Unless you plan on renovating or rebuilding it from scratch, which by themselves will be separate projects)
The second defining characteristic of a project is that it must create a unique product.
Unique product - The outcome of a project must be a unique product, service, or result.
How do these 3 terms differ from one another?
• Product - This is a tangible, quantifiable artifact that is either the end item or a component of outcome. The LCD TV in your living room or the fast BMW Car you drive or the nice diamond pendant you got your wife on her birthday are some examples of products.
• Service - Actually, when we say a project can create a service, we really mean the capability to perform a service. For example, a project that creates a website for a bank to offer online banking has created the capability for the bank to offer the online banking to its customers.
• Result. This is usually the knowledge related outcome of a project—for example, the results of an analysis performed in a research project.
We might use these 3 terms product or service or result interchangeably during the course of our study and remember that, though they might be 3 different things, from a project perspective, they all signify one thing – the project is completed successfully.
In the previous paragraph, we had seen the fact that projects are different from operations and we even saw a simple example. In order to manage projects efficiently you must first be able to identify if an activity is a Project or an Operation. To do that, you must be able to distinguish the two clearly.
Distinguishing a Project from an Operation
An organization executes a wide variety of activities as part of its work to achieve its business objectives. Some of these activities are to support projects and others are to support what are called operations. An operation is a set of tasks that does not qualify to be a project. In other words, an operation is a function that performs ongoing tasks: It does not produce a unique product and nor does it have a beginning or an end or both.
For example, Building your house is a project, whereas maintaining/cleaning it regularly is an operation.
It is important to understand that projects and operations share some characteristics, such as the following:
• Both require resources, including human resources (people).
• Both are constrained to limited, as opposed to unlimited, resources.
• Both are managed—that is, planned, executed, and controlled.
• Both have objectives.
The distinctions between projects and operations can be made by sticking to the definition of a project—that it is temporary and unique. Operations are generally ongoing and repetitive. Although both projects and operations have objectives, a project ends when its objectives are met, whereas an operation continues toward attaining a new set of objectives when the current set of objectives has been attained.
Go back to our example, building your house is a one time activity (Project) whereas, cleaning the house once every week to keep dirt and rodents away is a recurring activity (Operation) that has to be done every week, unless you intend on sharing your residence with rats and cockroaches!!!
Some Example Projects:
Projects can be performed at various levels of an organization; they vary in size, and accordingly can involve just one person or a team. Some examples are:
How do projects come into existence? In other words, how do you come up with a project? Sure, you have an idea, a concept of some final product, but how exactly do you write it down and declare it as a project? A project is born and brought up through a procedure called progressive elaboration. This is what we are going to learn in the next chapter!!!
Previous: Introduction to Projects
Next: What is Progressive Elaboration
In this chapter, we are going to get a better understanding of what a project is and what a project lifecycle is.
So, lets get started!!!
What makes Projects Different?
You might have been wondering, what makes projects different. From the previous chapter, we learnt that the project is a temporary endeavor to accomplish a defined task. You might ask me, any organization might have so many activities that are executed on a daily basis. What makes projects different?
The activities taken up by any organization fall into two distinct categories:
1. Projects &
2. Operations
An Operation is an ongoing and repetitive set of tasks like cleaning the washrooms daily, or maintenance of the power back up in the building once every month etc. It has no end (unless the company goes bust) whereas; a Project has a lifecycle, a beginning and a definite end.
Understanding a Project
A project is a work effort made over a finite period of time with a start and a finish to create a unique product or service or result. Because a project has a start and a finish, it is also called a temporary effort or endeavor. In other words, a project is a temporary endeavor taken to create a unique product, service or result. So, a project has two defining characteristics: It is temporary, and it creates a unique result.
Let’s try to understand these two defining concepts: temporary and unique.
Temporary - The temporary nature of projects refers to the fact that each project has a definite beginning and a definite end. A project can reach its end in one of two possible ways:
• The project has met its objectives—that is, the planned unique product has been created or the results achieved.
• The project has been terminated before its successful completion for whatever reason.
The temporary nature of projects can also apply to two other aspects:
• The opportunity to market the product that the project will produce is temporary—that is, the product needs to be produced in a limited timeframe; otherwise, it will be too late.
• A project team is temporary—that is, the project team is disbanded after the project ends, and the team members may be assigned to other projects eventually.
However, remember that the temporary nature of a project does not refer to the product it creates. The results or outcomes of a project are usually long lasting. Go back to the building your home example. Even though the construction process ends after say 9 months, your house is going to stand forever (Unless you plan on renovating or rebuilding it from scratch, which by themselves will be separate projects)
The second defining characteristic of a project is that it must create a unique product.
Unique product - The outcome of a project must be a unique product, service, or result.
How do these 3 terms differ from one another?
• Product - This is a tangible, quantifiable artifact that is either the end item or a component of outcome. The LCD TV in your living room or the fast BMW Car you drive or the nice diamond pendant you got your wife on her birthday are some examples of products.
• Service - Actually, when we say a project can create a service, we really mean the capability to perform a service. For example, a project that creates a website for a bank to offer online banking has created the capability for the bank to offer the online banking to its customers.
• Result. This is usually the knowledge related outcome of a project—for example, the results of an analysis performed in a research project.
We might use these 3 terms product or service or result interchangeably during the course of our study and remember that, though they might be 3 different things, from a project perspective, they all signify one thing – the project is completed successfully.
In the previous paragraph, we had seen the fact that projects are different from operations and we even saw a simple example. In order to manage projects efficiently you must first be able to identify if an activity is a Project or an Operation. To do that, you must be able to distinguish the two clearly.
Distinguishing a Project from an Operation
An organization executes a wide variety of activities as part of its work to achieve its business objectives. Some of these activities are to support projects and others are to support what are called operations. An operation is a set of tasks that does not qualify to be a project. In other words, an operation is a function that performs ongoing tasks: It does not produce a unique product and nor does it have a beginning or an end or both.
For example, Building your house is a project, whereas maintaining/cleaning it regularly is an operation.
It is important to understand that projects and operations share some characteristics, such as the following:
• Both require resources, including human resources (people).
• Both are constrained to limited, as opposed to unlimited, resources.
• Both are managed—that is, planned, executed, and controlled.
• Both have objectives.
The distinctions between projects and operations can be made by sticking to the definition of a project—that it is temporary and unique. Operations are generally ongoing and repetitive. Although both projects and operations have objectives, a project ends when its objectives are met, whereas an operation continues toward attaining a new set of objectives when the current set of objectives has been attained.
Go back to our example, building your house is a one time activity (Project) whereas, cleaning the house once every week to keep dirt and rodents away is a recurring activity (Operation) that has to be done every week, unless you intend on sharing your residence with rats and cockroaches!!!
Some Example Projects:
Projects can be performed at various levels of an organization; they vary in size, and accordingly can involve just one person or a team. Some examples are:
| Project | Project Outcome |
|---|---|
| Constructing Your House | Product |
| Running an election campaign | Results: win or lose; Products: documents |
| Developing a website to offer online banking | Service |
| Setting up a new Office | Service |
| Moving your office to a new building | Result: office is moved |
| Study the genetic makeup of a new species of birds in a forest | Results (of the research); Product: research paper |
Previous: Introduction to Projects
Next: What is Progressive Elaboration
Tuesday, May 3, 2011
Chapter 2: Introduction to Projects
Well, I am very excited to start writing this series of articles to help us prepare for the PMP Certification. We will be taking small steps one after the other and slowly reach our goal of the PMP certification. This is the first step in our pursuit.
So, lets get started!!!
What is a Project?
Anything and everything around us can be considered a project. For ex: building a nice home for you and your family is a project, same is the case if a government is trying to build a big power plant in your city. Irrespective of the size or the amount of money involved, both of them are projects.
What is common between these 2 examples? Your house and a power plant? Both involve, people, money and time. They both have a start and end and most importantly someone has to supervise the whole way to ensure that the project proceeds as planned and is completed on time and within budget.
The important point to note here is – someone has to supervise the whole way!!!
Yes, you read it right, any project has to be managed and controlled by an expert if it has to be a success. Failing which, the project will most probably be a failure.
Before we proceed any further, let me give you the technical definition of what a project is:
The definition is simple, isnt it? Now recollect, building your house is a project. You start it with a Grihapravesham (The Initial Pooja’s you do before beginning the construction), then you identify a builder, start buying raw materials like cement, steel, bricks etc, and go step by step and at the end of 9 months, voila your new and beautiful house is ready.
Since, you will no longer be building your house after 9 months, it is a temporary Endeavour and has a finite end at the end of construction.
Now I guess you understand the definition :-)
What is meant by Managing a Project?
Managing a project means managing the lifecycle of the project, starting from the beginning (initiating) and going to the end (closing); this is accomplished using processes, which constitute what are called project management knowledge areas. Although you use your knowledge in terms of processes to manage the projects, the management will be greatly influenced by the environment in which the project runs, such as the structure and culture of the performing organization.
If you want a quick synopsis of the various stages in the life of Managing a Project, just go back to the previous chapter and read it…
Terms you need to understand to begin your preparation:
Well, we have started our preparation for the PMP Exam. In the course of this and subsequent articles, we will be using various important terms. Each has a meaning and purpose. Now, let us go through each of them one by one.
• Organization
What is a Portfolio:
A portfolio is a set of projects, programs, and related work that is managed in a coordinated fashion to obtain business objectives in the strategic plan of the organization.
Portfolio management is the centralized management of one or more portfolios that includes identifying, authorizing, prioritizing, managing, and controlling projects, programs, and other related work in order to obtain specific business objectives in the strategic plan of the organization.
Now that we know the key terms that are required to continue our preparation, lets move on to the next topic…
Previous: Main parts in Managing a Project
Next: Understanding Projects
So, lets get started!!!
What is a Project?
Anything and everything around us can be considered a project. For ex: building a nice home for you and your family is a project, same is the case if a government is trying to build a big power plant in your city. Irrespective of the size or the amount of money involved, both of them are projects.
What is common between these 2 examples? Your house and a power plant? Both involve, people, money and time. They both have a start and end and most importantly someone has to supervise the whole way to ensure that the project proceeds as planned and is completed on time and within budget.
The important point to note here is – someone has to supervise the whole way!!!
Yes, you read it right, any project has to be managed and controlled by an expert if it has to be a success. Failing which, the project will most probably be a failure.
Exam Trivia:
Miracles do happen. But, in terms of the PMP Exam, Miracles are like the UFOs. Everyone has a doubt, but no one will risk their life to prove their existence. Similarly, there might be a rare case where an ill managed project becomes successful, our goal is to manage a project properly and as per the guidelines laid down by the PMI Institute to ensure that the project we are managing is a Success.
Before we proceed any further, let me give you the technical definition of what a project is:
A project is a work effort made over a finite period of time with a start and a finish to create a unique product, service, or result. Because a project has a start and an end, it is also called a temporary effort or endeavor
The definition is simple, isnt it? Now recollect, building your house is a project. You start it with a Grihapravesham (The Initial Pooja’s you do before beginning the construction), then you identify a builder, start buying raw materials like cement, steel, bricks etc, and go step by step and at the end of 9 months, voila your new and beautiful house is ready.
Since, you will no longer be building your house after 9 months, it is a temporary Endeavour and has a finite end at the end of construction.
Now I guess you understand the definition :-)
What is meant by Managing a Project?
Managing a project means managing the lifecycle of the project, starting from the beginning (initiating) and going to the end (closing); this is accomplished using processes, which constitute what are called project management knowledge areas. Although you use your knowledge in terms of processes to manage the projects, the management will be greatly influenced by the environment in which the project runs, such as the structure and culture of the performing organization.
If you want a quick synopsis of the various stages in the life of Managing a Project, just go back to the previous chapter and read it…
Terms you need to understand to begin your preparation:
Well, we have started our preparation for the PMP Exam. In the course of this and subsequent articles, we will be using various important terms. Each has a meaning and purpose. Now, let us go through each of them one by one.
Exam Trivia:
All these terms are simple and very important. You need to understand them in order to make sense of the subsequent topics. So pay attention!!!
• Organization
An organization is a group of individuals organized to work for some purpose or mission. Computer companies, telephone companies (to whom you pay your phone bills), and cable companies are examples of organizations. An organization might offer products, such as books, or services, such as Internet access or online banking. A project is usually performed inside an organization. Organization is a very broad concept that includes groups for profit and nonprofit, public and private, and government and nongovernment.• Project stakeholder
A project stakeholder is an individual or an organization that can be positively or negatively affected by the project execution. A project can have a wide array of stakeholders, like the project sponsor, the customer for whom you are executing the project, the end user who is going to use the system etc.• Process
A process is a set of related tasks performed to manage a certain aspect of a project, such as cost or quality. Each process belongs to a knowledge area and corresponds to a process group. There are a bunch of set guidelines that can help you achieve a goal and they are usually termed as processes.• Knowledge area
A knowledge area in project management is defined by its knowledge requirements related to managing a specific aspect of a project, such as cost, by using a set of processes. PMI recognizes a total of nine knowledge areas, such as cost management, human resource management etc.• Performing organization
The performing organization is the organization that is performing the project.• Project management
Project management is the usage of knowledge, skills, and tools to manage a project from start to finish with the goal of meeting the project requirements. It involves using the appropriate processes. Remember the Supervisor who is going to oversee your house construction• Program
A program is a set of related projects managed in a coordinated fashion to improve overall efficiency and effectiveness and to obtain benefits and control that would not be obtained by managing them individually. For example, a program could be delivering a product (or service) that consists of sub-products (or service components) delivered by the constituent projects. Also, a program might include related work that is not included in the scope of any of the constituent projects.• Program management
Program management is the centralized, coordinated management of a specific program to achieve its strategic goals, objectives, and benefits.• Program management office (PMO)
The program management office is an entity in an organization that is responsible for providing centralized, coordinated support to the program managers managing programs and unrelated projects.• Project management office
Project management office (PMO) refers to an entity in an organization that is responsible for providing centralized coordinated management and support for projects in the organization.
Exam Trivia:
Although both have the same abbreviation, PMO, the project management office and program management office are not identical. For example, only an organization that runs programs will have a program management office, whereas an organization that runs individual projects can have a project management office.
What is a Portfolio:
A portfolio is a set of projects, programs, and related work that is managed in a coordinated fashion to obtain business objectives in the strategic plan of the organization.
Portfolio management is the centralized management of one or more portfolios that includes identifying, authorizing, prioritizing, managing, and controlling projects, programs, and other related work in order to obtain specific business objectives in the strategic plan of the organization.
Now that we know the key terms that are required to continue our preparation, lets move on to the next topic…
Previous: Main parts in Managing a Project
Next: Understanding Projects
Sunday, May 1, 2011
Tips to get PMP Certified
Below are some tips I picked up from various books about taking the PMP Certification Exam.
1. PMI has a very formal way of naming processes, process groups, knowledge areas, and even documents. However, just like in real life, do not expect that the exam will always refer to these names in a formal way. Try to know both the formal and informal representation of each key term. To help you further, I will try to obtain both those terms and use them in this blog.
2. The questions in the PMP exam can be wordy and might include unnecessary information to distract you from the real question/information related to the real question. So, you need to read the questions carefully and patiently and figure out what is relevant and what is nonsense.
3. Get comfortable with the idea that there will be some questions that you will not be able to answer correctly. In such a situation, just believe in yourself and your experience, and select the answer you feel would be the nearest match. If you are still not sure, just leave it for now and proceed to the next one. you can always come back to review them if you have time in the end.
4. There will be tricky questions to weed out candidates who might have project management experience, but who do not have an in-depth understanding of the discipline of project management from the perspective of PMI. Make sure you are cautious and catch hold of such questions and answer them appropriately.
5. There will be questions for which you will need to choose between an innocent way of skipping the formal process to save time and following the formal project management process. In almost all cases, the correct answer will be to follow the process.
6. There will be questions for which you will need to choose between facing the problem head on or taking an easy way out, such as dodging a thorny issue, ignoring a challenging problem, or postponing a difficult decision. Almost always, the correct answer is to meet the problem head on in a professional manner.
7. To answer some questions correctly, understand that in the world of project management as seen from the perspective of PMI, project managers communicate directly and clearly and do not say things between the lines. For example, if you have a problem with a team member, you talk to the team member face to face rather than going to the member’s manager, which you might need to do eventually if you can’t solve the problem by directly dealing with the team member.
8. Understand clearly the roles of the key stakeholders of any project, such as the project manager, project sponsor, and customer. Especially understand your responsibilities as a project manager. You need to be proactive to make decisions and manage the project, influence the factors that contribute to changes rather than waiting for the changes to occur, and have up-to-date information about the project.
All the very best for your exam!!!
Previous: About the PMP Exam
Next: Main Parts in Managing a Project
1. PMI has a very formal way of naming processes, process groups, knowledge areas, and even documents. However, just like in real life, do not expect that the exam will always refer to these names in a formal way. Try to know both the formal and informal representation of each key term. To help you further, I will try to obtain both those terms and use them in this blog.
2. The questions in the PMP exam can be wordy and might include unnecessary information to distract you from the real question/information related to the real question. So, you need to read the questions carefully and patiently and figure out what is relevant and what is nonsense.
3. Get comfortable with the idea that there will be some questions that you will not be able to answer correctly. In such a situation, just believe in yourself and your experience, and select the answer you feel would be the nearest match. If you are still not sure, just leave it for now and proceed to the next one. you can always come back to review them if you have time in the end.
Remember - Dont get frustrated.
4. There will be tricky questions to weed out candidates who might have project management experience, but who do not have an in-depth understanding of the discipline of project management from the perspective of PMI. Make sure you are cautious and catch hold of such questions and answer them appropriately.
5. There will be questions for which you will need to choose between an innocent way of skipping the formal process to save time and following the formal project management process. In almost all cases, the correct answer will be to follow the process.
Remember - Never ignore the process, atleast from the certification point of view.
6. There will be questions for which you will need to choose between facing the problem head on or taking an easy way out, such as dodging a thorny issue, ignoring a challenging problem, or postponing a difficult decision. Almost always, the correct answer is to meet the problem head on in a professional manner.
Remember - Ignoring a problem today might cause the same one to magnify and it will for sure come back to haunt you at a later date. So it is always better to handle problems then and there
7. To answer some questions correctly, understand that in the world of project management as seen from the perspective of PMI, project managers communicate directly and clearly and do not say things between the lines. For example, if you have a problem with a team member, you talk to the team member face to face rather than going to the member’s manager, which you might need to do eventually if you can’t solve the problem by directly dealing with the team member.
8. Understand clearly the roles of the key stakeholders of any project, such as the project manager, project sponsor, and customer. Especially understand your responsibilities as a project manager. You need to be proactive to make decisions and manage the project, influence the factors that contribute to changes rather than waiting for the changes to occur, and have up-to-date information about the project.
All the very best for your exam!!!
Previous: About the PMP Exam
Next: Main Parts in Managing a Project
About the PMP Exam
The Project Management Professional Certification is one of the most respected Certifications in the Software Development Industry. Getting PMP Certified is not easy and any individual with this certification is respected by everyone in the industry. This is what makes this a valuable addition to your resume if you are interested in Project Management as a Career.
A person with a PMP Certification represents the fact that, he/she is an established project manager and has the experience and expertise to manage projects effectively and make them a success.
Eligibility Requirements in order to take the PMP Exam:
Minimum Educational Background:
Minimum Project Management Experience:
Minimum Formal Project Management Education:
Details of the PMP Exam:
The PMP Exam is a Multiple Choice type of Exam which will contain 175 questions and an additional 25 pretest questions.
Remember that the scores for these 25 questions do not affect your final score.
Getting PMP Certified:
Step 1: Register in the PMI Website
Step 2: Register for the 35 hour Project Management Training
Step 3: Read the PMBOK Guide and any other book (And my blog if you like) to prepare for the PMP Certification
Step 4: Decide your Exam Date and prepare properly
Step 5: Crack your exam and get your Certification
About this Blog:
This blog is an attempt to help you get PMP Certified. I am no Project Management expert either. I am currently preparing for my PMP Certification and reading many big books on the topic like the PMBOK Guide and others. The sequence of chapters in this blog are all based on my understanding of the topics learnt during my study.
This blog will be split into 5 sections each of them covering the various topics covered by the PMP Exam. Below are the % of questions that can be expected from the various topics in the PMP Certification.
Total works out to 100% doesn’t it :)
For the most up-to-date information regarding these examinations, please visit the certification section of PMI’s website at www.pmi.org.
Next - Tips to Get PMP Certified
A person with a PMP Certification represents the fact that, he/she is an established project manager and has the experience and expertise to manage projects effectively and make them a success.
Eligibility Requirements in order to take the PMP Exam:
Minimum Educational Background:
Category 1 – Bachelors Degree Category
Category 2 – High School Diploma
Minimum Project Management Experience:
Category 1 – 4500 Hours
Category 2 – 7500 Hours
Minimum Formal Project Management Education:
35 Contact Hours for both Category 1 and Category 2
Details of the PMP Exam:
The PMP Exam is a Multiple Choice type of Exam which will contain 175 questions and an additional 25 pretest questions.
Remember that the scores for these 25 questions do not affect your final score.
Getting PMP Certified:
Step 1: Register in the PMI Website
Step 2: Register for the 35 hour Project Management Training
Step 3: Read the PMBOK Guide and any other book (And my blog if you like) to prepare for the PMP Certification
Step 4: Decide your Exam Date and prepare properly
Step 5: Crack your exam and get your Certification
About this Blog:
This blog is an attempt to help you get PMP Certified. I am no Project Management expert either. I am currently preparing for my PMP Certification and reading many big books on the topic like the PMBOK Guide and others. The sequence of chapters in this blog are all based on my understanding of the topics learnt during my study.
This blog will be split into 5 sections each of them covering the various topics covered by the PMP Exam. Below are the % of questions that can be expected from the various topics in the PMP Certification.
Initiating the Project – 11%
Planning the Project – 23%
Executing the Project – 27%
Monitoring and Controlling the Project – 21%
Closing the Project – 9%
Professional & Social Responsibility – 9%
Total works out to 100% doesn’t it :)
For the most up-to-date information regarding these examinations, please visit the certification section of PMI’s website at www.pmi.org.
Next - Tips to Get PMP Certified
Subscribe to:
Posts (Atom)
Popular Posts
-
So far, we have been talking in terms of projects only. There are two other terms that are closed linked with projects and project manageme... -
In the previous chapter , we took a look at Expected Monetary Value or EMV Analysis . The Decision Tree Analysis is another tool/technique ... -
In the previous chapter, we saw how to create the Project Scope Document. The next step in planning for a projects scope is to create the Wo... -
In the previous chapter, we saw the project lifecycle in detail. In this chapter, we are going to take a look at the Project Management Kno... -
In the previous chapter we learnt how to create the project human resource plan. To get resources you need to spend money (Cost) and you can... -
In the previous chapter , we learnt the basic details about Continuous Distributions. In this chapter, we are going to take a detailed look... -
In the previous chapter we learnt that the risk register is going to be constantly updated as we progress through the various processes in... -
Expected Monetary Value Analysis or EMV Analysis in short is the 2nd tool and technique in the Quantitative Risk Analysis and Modeling Tech...
-
In the previous chapter, we saw that an organizations policies and culture can have a significant impact on a project. Towards the end we al... -
In the previous chapter, we took a look at how to sequence the activities based on the requirements and dependencies. The next step would be...