Author: Rodolfo Ambriz

Rodolfo Ambriz, PMP, is a Microsoft Project expert and runs Latin American operations for International Institute for Learning (IIL). Ambriz has provided services to a wide range of clients, including Banamex/Citigroup, PEMEX, Hewlett Packard, TELMEX, and IBM/Tecnosys. He consults in the areas of business analysis and Microsoft Office Enterprise Project Management, and has created customized courses in Spanish for clients in Mexico, Latin America, and Spain. Ambriz is also a tenured professor in the engineering department of La Salle University, in Mexico City.

Three Rules for a Happy Life with Project 2007

Here are three rules we urge you to memorize and follow when you enter or change assignments. If you do, Project 2007 will become your obedient servant. If you don’t, Project 2007 will inevitably recalculate values that you don’t want changed. You can even end up in an endless loop, where you change a value, it changes a value, you change a value.etc. Here are the rules: 1. Enter the duration estimate or work estimate and fix that number by setting the task Type accordingly. This prevents Project 2007 from changing the number. If you enter a duration estimate, set the task Type to Fixed Duration. If you enter a work estimate, set the task Type to Fixed Work. 2. Provide the second value in the formula, Duration * Units = Work, and let Project 2007 calculate the third value. Always provide only two of the three values! If you created a fixed duration task, assign the resources you need, and let Project 2007 calculate the work. If you created a fixed work task, assign the resources and let Project 2007 calculate the duration. If you entered the duration and the work, Project 2007 only needs to know who will do the task and it will calculate the number of resources needed (units). 3. Before making a change to any of the three values in the formula, reconsider the task type by asking yourself: What type of task do I need for this particular change? More on this next. Enter the work or duration estimate, then set the fixed task Type (select the Effort Driven choices, if needed), then assign the resource and let Project 2007 calculate the third variable. Changing an Assignment Before you change any of the three values in the formula D * U = W, you should always first think about the task type you need for that change. With every change, Project 2007 will recalculate one other value, and it may not recalculate the one you want. Changes that will trigger Project 2007 to recalculate the formula D * U = W include, among others: Changing the duration of a task by editing the value or by stretching the task bar with the mouse. Adding a resource to a task or removing a resource from a task changes the Units (U). Also, changing the 100% allocation to a different percentage changes the Units. Changing the work of a task or of one of its assignments The task Type and the Effort Driven attribute determine how Project 2007 will react. We suggest these steps when you change an assignment: 1. Choose and set the task Type first. Determine the appropriate task type by asking yourself: I will change this value in the formula; which one of the other two values do I want to keep the same?  The answer to this question will tell you which task type you need. For example, if you want to keep the assigned units the same while you change the work, you should set the Type to Fixed Units. If you want to keep the total amount of work on the task the same while you change the duration, you need Fixed Work. 2. Ensure Effort Driven is set to No except for Fixed Work tasks. Fixed Work tasks are effort driven by definition; Fixed Duration and Fixed Units should not be effort driven. 3. Then edit the value that you want to change on the assignment. Project 2007 will recalculate the third value. For example, if you change the Work on a Fixed Units task, Project 2007 will recalculate the Duration. Note that you never change the value that you fixed with the task type. For example, you never change the duration when the task type is Fixed Duration. If you do this, you are not controlling what Project 2007 recalculates; it could adjust the Units or the Work. You have to change the task type first to keep one of the other two variables the same before making the change. Before you change a variable, set or change the task Type and Effort driven choices, accept that change, and then change the variable. The task Type is not something you set once and never look at again. You continue to monitor it in order to control what Project 2007 calculates. If you reconsider the type of task first before every change, you will be able to predict and control Project 2007’s recalculations. This article is excerpted from Dynamic Scheduling with Microsoft Office Project 2007, published by J. Ross Publishing. Reprinted with permission from the publisher.  

The Work Breakdown Structure

Before you enter tasks in Project 2007, you need to decide what your project tasks are. The starting point for this is to develop a Work Breakdown Structure (WBS). We strongly suggest that you start by creating a WBS and use that as the basis for creating your schedule. According to PMI, a Work Breakdown Structure (WBS) is “a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables.”1 Whew! Let’s look at a couple of the key phrases of this definition. A WBS is “Deliverable-Oriented” A deliverable is “any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase or project.”2 Deliverables are the products the project is going to produce: both final deliverables that you hand off to your client, (e.g., a completed computer program, building, or relocation) and interim deliverables that your stakeholders use during the project (e.g., a weekly status report). The WBS should cover 100% of your project’s scope and capture all of your key deliverables. It is generally accepted project management practice that work that is not in the WBS is not within the scope of the project. You need to establish this understanding early with your project stakeholders: if the client requests a deliverable during project execution that is not in the WBS, it is out of scope. Use your WBS as the baseline for integrated change control: if the requested deliverable was not agreed upon and included in the WBS, it must be negotiated under the project’s change control procedures as an addition to the project. The work described in the WBS is also the basis for estimating, scheduling, and assigning responsibilities on the project. It is the means for tying project objectives and requirements to the work required to deliver them. A WBS is a “Hierarchical Decomposition” When we say that a WBS is a hierarchical decomposition, it simply means that your WBS should break down (decompose) your primary deliverables into smaller, more manageable parts, and that this decomposition should be organized in a logical (hierarchical) way. Shown below is a portion of a simplified WBS: Figure 1: A portion of a simplified WBS. As you can see, the sample WBS: Contains the project deliverables (e.g., “2.1 Software Requirements”, “2.2 Initial Software Design” and “2.3 Final Software Design” are all deliverables). Has deliverables that are decomposed into smaller parts. Is organized in a logical manner to identify the work required to produce the deliverables. Organizing Your WBS There are many ways to organize your WBS, e.g., by key deliverables, physical components, chronological phases in the project life cycle, functional specialties, or in a program by project and sub-project. In our sample WBS above, we organized the WBS by deliverables. Here’s the same WBS, organized by phases—requirements phase, design phase, etc. Figure 2: Organizing the WBS by deliverable. Notice that both examples contain the same deliverables. Regardless of how you organize your WBS, it should be deliverable-oriented, i.e., it should explicitly contain all of the key deliverables for your project. According to PMI, a WBS with phases and activities only and no deliverables is not a WBS! Every phase, activity, or task must have one or more deliverables. Including deliverables in your WBS makes sense: The WBS should be an elaboration of the deliverables promised in the project’s Scope Statement. A deliverable-oriented WBS makes it easier to track work back to the Scope Statement. Because many of your deliverables are the key products you’ll be delivering to your client, your client will find it easier to understand a deliverable-oriented WBS. Deliverables are often tangible and easily understood when making team assignments. Imagine that you were made responsible for either “researching requirements” (an activity) or for delivering the “list of requirements” (a deliverable) for a project. The latter is a concrete deliverable; it is verifiable and therefore creates a firmer commitment. A deliverable-oriented grouping enables you to get useful reports from Project 2007, like an effort or cost by deliverable report. Once you identify and describe deliverables, it is easier to identify, estimate, and schedule the activities needed to create those deliverables. Our definition of a deliverable includes the phrase: a deliverable is “any unique and verifiable product, result, or capability.3” By describing each deliverable identified in the WBS, you create verifiability in the project: you clarify what you are going to produce at each step of the way. When you ask your client to sign off on the WBS and the definition of deliverables, you have established how task and project completions will be verified. This practice of identifying and describing deliverables early in the project will decrease misunderstandings that can become fatal if not surfaced until near the end (when they typically result in nasty disputes or litigation). You may not be used to thinking in terms of deliverables, and it can take practice to learn to identify them. However, it’s important to put some effort into this. After all, if you can’t define the deliverables, how will you and your stakeholders ever agree upon what needs to be done? It’s a common view that if you can’t identify the deliverables for a project, you don’t have a project. Phases in the WBS Often the WBS is organized by phases — distinct periods in the life of a project such as requirements, analysis and development. If you organize by phase, it’s important to identify the deliverables for each phase. For example, the requirements phase may produce requirements definition, the analysis phase designs, and the development phase software modules. These interim deliverables are necessary in many projects to enable a controlled process with checkpoints between phases. While phases can establish a chronology for the project, it’s important to note that the focus during WBS development should be on identifying, defining, and decomposing deliverables; not on sequencing and scheduling. This comes later. Chronological breakdowns in your WBS can make it harder to manage iterative (repeating) processes. Iterative processes are common in projects, often as a result of the progressive elaboration of project requirements and designs as the product is developed. For example, you might create a requirements document during the requirements phase, refine it in the analysis phase, and finalize it in the development phase. If your WBS is organized by chronological phases, work on your requirements document will be scattered across all three phases, making it more difficult to track progress on the deliverable, a finalized requirements document. In a deliverable-oriented WBS the work on the requirements document will all be listed in a single section and you can add activities with ease. Indented List or Organization Chart Format? You can build your WBS either as an indented list or in a format similar to an organization chart, with the summary tasks — generally the largest or most important deliverables — toward the top and the detail tasks underneath. The Bottom Line There are times when organizing your WBS by phase makes perfect sense. We recommend that in large projects you consider using a combination of phases and deliverables in your WBS. Just make sure that if you do use phases in your WBS, you’ve also captured all your deliverables. Notes: 1 PMBOK® Guide − Third Edition, PMI, 2004, p. 112. 2 Ibid., p. 232. 3 Ibid. This article is excerpted from Dynamic Scheduling with Microsoft Office Project 2007, published by J. Ross Publishing. Reprinted with permission from the publisher.