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