Project costs not adding up correctly?

One possible cause is that you have inadvertently included fixed costs somewhere in the plan. The summary cost includes fixed costs for subordinate tasks, which can make your summary and total project costs look incorrect.

Here is the symptom - the total cost for a summary task or the project is greater than the sum of the costs of the subordinate tasks:



You can check to see if fixed costs are the cause by showing the fixed costs column in the Gantt or Task Sheet view:


Fix the problem by deleting the fixed cost or by entering zero for the fixed cost (you can enter fixed costs in a summary task).

BCWP vs. ACWP

I received a comment on this post requesting an explanation of the difference between BCWP and ACWP. So here is a simple example to help show the what these values represent and how they are used.

First the definitions:

• BCWS = Planned Value (also called PV). It means: What is this thing worth to us? It is often used as a synonym for "planned cost".
• BCWP = Earned Value ( also called EV). It means: What have we received for our money?
• ACWP = Actual Cost (also called AC). It means: How much did we spend to get what we received?

So the short answer is that BCWP means value received or "earned," while ACWP means amount spent. The difference between BCWP and ACWP gives you your cost variance.

Now the example:

Let's say you contract with a painter to paint your house. He estimates that he can paint all four walls at a rate of one wall per day, over a total of four days. You agree to pay him $100 at the end of each day, or a total of $400 for the entire project.

At the end of the first day, one wall is completed.

• Your BCWS = $100 since you planned to have one wall complete at the end of day 1.
• Your BCWP = $100 since the wall was actually completed.
• You pay the painter the agreed $100, so your actual cost, or ACWP is $100.

We can use these values to understand the project schedule and cost variance.

• Schedule Variance (SV) = Earned Value - Planned Value = BCWP - BCWS = $100 - $100 = $0. Your project is right on schedule.
• Cost Variance (CV) = Earned Value - Actual Cost = BCWP - ACWP = $100 - $100 = $0. Your project is on budget.

The Bus Factor

http://en.wikipedia.org/wiki/Bus_factor

Using a mind mapping tool to develop the WBS

I used Freemind to develop a WBS for a recent project.

Go here to learn about mind mapping if you are not already familiar with it, but basically, it is a way of hierarchically structuring your thoughts on any topic.

For project planning, you can structure your mind map to show deliverables, and then attach activities to the deliverables, as discussed here.

Freemind proved to be a useful tool, having most of the functionality I thought necessary. The main challenge was saving the output in a format that was useful to others on the project, and that could be used to develop the project schedule.

It turns out that Freemind supports exporting to an XML format that can be read by MS Project. You'll need an XML translation file (e.g., "filename.xsl") which can be found here:

http://freemind.sourceforge.net/wiki/index.php/Import_and_export_to_other_applications#To_MS_Project

Follow these steps to export your file and read it in to MS Project:

1. Copy the XSL code from the Freemind SourceForge page and save it to a file such as mm2project.xsl.
2. If you want to save notes from Freemind into your MS Project file, you'll need to modify the XSL file slightly to include some additional lines. Read the comments on the Wiki page for the details.
3. In Freemind, select File --> Export --> Using XSLT ...
4. Browse for the XSL file (mm2project.xsl) in the "choose XSL file" field.
5. Browse to your target folder and name the exported file, such as project.xml. Note: The filename must have a .xml extension.
6. Press the Export button to create the export file.
7. Open the file with MS Project (using File --> Open ...).
8. Follow the MS Project dialog to open the file.
9. "Save as" to the standard .mpp format.

A Note on Start-to-Start Dependencies

Introducing a Start-to-Start dependency between schedule tasks does not mean that the tasks can start at the same time.

It means that the successor task can not start until the predecessor task starts.

If you want two tasks to start at the same time, model them as successors of a common task, with a Finish-to-Start relationship. Then when the common task is finished, they will both start simultaneously (assuming that there is no other constraint, such as resources).

Notes on the Work Breakdown Structure

The WBS is a systematic way of decomposing a project into specific deliverables in order to establish a common understanding of project scope. It defines logical relationships between deliverables, and is normally depicted as a hierarchical or outline structure in order to make the relationships clear. It also allows traceability between the project scope statement and the project schedule and is therefore a key input into project time management activities (scheduling).

My rules for developing the WBS:

Nouns, not verbs - The WBS describes deliverables. It is results oriented, not activity oriented. The project scope statement or requirements document(s) define the project goals. Goals break down into deliverables which go into the WBS. Goals are nouns. Verbs are the activities needed to deliver the nouns. They go into the project schedule, not the WBS.

The 100% rule - The WBS contains 100% of the project scope. If it's not in the WBS, it's not in scope. Any expected deliverables that are not in the WBS represent a quality risk. Conversely, the WBS does not contain any extras. If it does not advance the project, it should not be in the WBS. Extras are wasteful and represents a cost and schedule risk.

Element isolation - There should be no duplication of elements of the WBS; otherwise you get duplication of work and confusion over responsibility. Individual work elements can serve multiple purposes, but the WBS should be structured such that the element only appears once in the WBS.

Level of detail - Work packages should be of sufficient detail that the deliverable cannot be logically decomposed any further, and can be reliably and accurately estimated. One work package = one deliverable. In a matrix organizational structure, a work package should be executed by only one resource group.

The 8/80 rule - The work package duration should be within defined limits, typically between 8 to 80 hours of work effort. You may need to come back and decompose the work package after receiving activity duration estimates, which is a later step in the planning process.

Distributing Task Hours

Lately, I have been seeing project plans that attempt to distribute work between resources by using units allocation. But percent resource allocation is not the same as percent work performed. Allocating a resource at 50% units only means that he will work on the task half-time, not that he will do half the work!

For example, let's say that we have a 16 hour task (2 days duration, assuming an 8 hour day), and we want a resource named Able to perform the task:

To start, let's put Able on the task full-time:

Task	Work	Duration	Resource	Units
Task1	16h	2d	able	100%

Wrong way to distribute task hours

Now, because we want Able to perform only 25% of the task, we do the wrong thing and adjust his units to 25%:

Task	Work	Duration	Resource	Units
Task1	16h	8d	able	25%

As you can see, the work effort stayed the same, meaning Able is still performing 100% of the work. Only the duration changed, so by changing the units, it just takes longer to get the task done. This plan does not show that Able will perform only 25% of the work. It only shows that Able will work on the task 25% of his available time.

Right way to distribute task hours

Now suppose we want resource Able to perform 25% of the task, while resource Baker performs 75%. Remember this means percent of the actual work, not percent resource allocation.

This is what we're after:

Task	Work	Duration	Resource	Units
Task1	16h	1.5d	able	100%
			baker	100%

The duration will be 1.5 days because Able works 4 hours (25% of 16) to complete his part, while Baker works 12 hours (75% of 16). Both resources are allocated to the task 100%, so Baker's 12 hours equates to 1.5 8-hour days.

How to do it in MS Project

Go to the task usage view (either entry view or usage view).

You can distribute the task hours however you want by entering a value in the work column. Make sure you do the math correctly so the duration is the same when you're done making changes.

Return back to the task sheet or Gantt chart view. The resources are still allocated at 100%, and the duration is still the same.


Advanced usage

Now try adjusting resource Baker's units to 50% on this task, so he is allocated at 50% to his 75% of the task.

You should see the task duration increase to 3 days. Why? Baker still has 12 hours work to do, but can only spend 50% of his available time on it. So the task duration increased to 3 days, but the work stayed the same at 12 hours. Since 12 hours of work take 1.5 8-hour days, Baker should take 3 days to complete 12 hours of work at 50% allocation.

You might also want to consider changing the task type to fixed units.

Don't use task dependencies to model resource constraints

Lately, I've been noticing a tendency for planners in my organization to model resource constraints by entering values in the predecessors column of an MS Project plan.

For example, if resource R1 is assigned to tasks T1 and T2, the planner will model a dependency between the tasks to "make the dates come out right". They understand that a resource can't be asked to work on two tasks simultaneously, so they want to spread out the work and schedule the tasks one after the other.

But just because a resource is assigned to two separate tasks does not mean that there are dependencies between the two tasks. In fact, it is not necessary to introduce task dependencies in order to level resources.

Here is the basic workflow I use when planning a project:

1. Define the activities - What needs to be accomplished in order for this project to be successful?
2. Sequence the activities - In what order - if any - do these things need to happen?
3. Identify activity dependencies (AKA "predecessors" ) - Is it necessary for one activity to complete before another can begin?
4. Estimate activity effort - Given known resource capabilities and constraints, how long will it take to complete this activity?
5. Assign resources to specific activities.

You'll notice that sequencing project activities and identifying dependencies are completely independent from assigning resources.

For those who don't know, the idea of not over-scheduling is called resource leveling. You can use the MS Project resource leveling function, and your start and end dates will automatically be calculated for you. Here's how it works:

1. Create a new project in MS project. Go to Gantt chart view and make sure you can see the Work column (Insert --> Column, then enter "work").

2. Enter 3 tasks called Task 1, Task 2, and Task 3. Assign work efforts of 8 hours to each. Do not enter any predecessor information.

3. Assign resource R1 to each of the 3 tasks.

In the Gantt chart view you will see that R1 is assigned to complete all three tasks on the same day. This is the point where planners go wrong. In order to help out ol' R1, they enter dependencies between the three tasks. While this does have the effect of spreading out the work, it also introduces an incorrect model of the task network.

Rather than enter predecessor information, go to Tools --> Level Resources and click the Level Now button. You'll see the tasks spread out to a more managable schedule. The stalwart R1 will thank you, and as someone who reviews and approved project plans, I'll thank you as well.

Tracking Physical Percent Complete with MS Project

We have been addressing the question of how to tell how much work is getting done on a project, concluding that "percent complete" really only measures how much schedule and budget we have burned through, and does not give a true indication of actual progress. The remedy is to measure progress against physical evidence. We agree up front with stakeholders what physical evidence will define task complete, and the percent complete is not achieved until actual receipt of the physical evidence. I used the production of a requirements document and test cases to illustrate this approach.

Sadly, the default behavior of MS Project is to calculate a task's percent complete based on the difference between planned work and actual work. Although it gives the illusion that it's measuring technical performance (task percent complete), it really only measures hours worked. This discussion demonstrates how to use MS Project 2003 to track physical percent complete.

DISCLAIMER: I am not an MS Project expert so there may be better ways to do this.

SETUP

You can set this up at the project level, or at the task level. If you have already entered tasks you must set it up in each individual task.

At the Project level:

1. Select Tools --> Options --> Calculation Tab --> Earned Value button
2. Set Default Task Earned Value Method to Physical % Complete

At the Task level:

1. Select Project --> Task Information --> Advanced tab
2. Set Earned Value Method to Physical % Complete

EXECUTION

1. In the Gantt Chart view, insert the following columns: Work, Percent Complete, Actual Work, and Physical % Complete. NOTE: we will not use Percent Complete, but I included it for demonstration purposes.

2. Enter a resource in the Resource Sheet view. Use $100/hour for both the standard and overtime rates.

3. Add the "Write draft requirements document" task, assign it to the same resource you just created, along with "40h" in the *Work* column (not duration). Duration automatically goes to 5 days.

3. Enter "40h" in the Actual Work column. Percent Complete automatically goes to 100%, while the Physical % Complete column stays at 0%.

To experiment, put "80h" in the Work column, and watch Duration go to 10 days. Actual Work stays at 40h, causing Percent Complete go to 50%. The Physical % Complete column still stays at 0%.

WHAT DOES 'BEHIND' MEAN?

Ideally, we could measure budget and schedule in the same units. And, ideally, it would be in dollars since in the end we are interested in costs. It turns out that if we can determine a value for the task, we can frame everything in terms of dollars.

"Value" is a tricky word that can mean different things, but for now let's just think of value as equivalent to "planned cost," meaning the amount we are willing to pay for it (which represents its value to us). So, since we have already agreed on a method for determining percent complete, and since we just said the task has value, our progress can easily be framed in dollars by multiplying the value of the task by its percent complete.

The *planned value* of the "Write test cases" task is therefore 8 hours X $100/hour = $800. So, the written test cases are worth $800 to us. This is called Budgeted Cost of Work Scheduled, so BCWS = $800 for this task. Planned value, or BCWS, is also called earned value.

The *actual value* of the test cases is so far zero, since we are not yet in possession of the test cases. Our task is 0% complete so the value delivered for the work performed is $800 X 0% = $0. This is known as Budgeted Cost of Work Performed, so BCWP = $0.

However, we have incurred a cost, even though we didn't receive any value for our money. The Actual Cost of Work Performed is therefore: ACWP = 8 hours X $100/hour = $800.

By identifying planned value, earned value, and actual cost of the task, we are now able to put a dollar value on both schedule and cost variance.

To obtain the schedule variance, we can compare planned value against planned cost. A negative value means that the project is behind schedule. In our example, Schedule Variance = Actual Value - Planned Value = BCWP - BCWS = $0 - $800 = $-800.

We can also compare planned value with the actual cost to obtain the cost variance. A negative variance means the project is over budget. Cost Variance = Planned Value - Actual Cost = BCWS - ACWS = $800 - $800 = $0.

So the project appears on budget, but behind schedule. The cost variance will appear as soon as we start doing more work, as we must since we haven't delivered the test cases yet.

Let's say that the analyst takes another two hours before delivering the approved written test cases as agreed. That's an additional cost of 2 hours X $100/hour = $200. Now the task is 100% complete, so we can recalculate our budget and schedule standing.

SV = BCWP - BCWS = $800 - $800 = $0
CV = BCWS - ACWS = $800 - $1,000 = $-200

Notice that the schedule variance is now zero. This is an important point. SV will go to zero when the task is complete, even though it may have been late. You will see the negative impact on successor tasks, but it could be deceptive on a project status report.

Meanwhile, the more straightforward cost variance shows the project is over budet.

Next time: Tracking Physical Percent Complete with MS Project

Roles and responsibilities in a weak matrix organization

I recently ran into a problem on a large (100+ people) multi-team project, in which one team was structured as strong matrix, while the remaining teams were structured as weak matrix.

Although the project was a success by many measures, incorrect expectations about roles and responsibilities led to significant misunderstandings and resulted in a large number of management escalations. While the strong matrix structure provided local optimization for the one team, it introduced complexity and extra cost for the project and the IT organization as a whole.

The misunderstanding was around the issue of who, specifically, should drive resources to complete their tasks. The feeling of this one team was that it should be the PM. But in a weak matrix organization Resource Managers (RM's) must be the ones to drive their people to complete the project, not PM's. Here's why:

1. A weak matrix organization is structured around functional teams, not projects.
2. Resources are assigned by RM's; the PM does not interview candidates or select resources during project initiation.
3. Resources are allocated to projects part-time, and the PM has no view into their other responsibilities, and does not set their priorities.
4. RM's, not PM's deliver the project WBS and estimates for their areas.
5. The PM does not influence performance reviews. Resources are loyal to their direct line manager, who is the RM, not the PM.
6. Functional teams may have their own internal processes over which the PM has no influence.
7. RM's, not PM's, usually approve timesheets, meaning RM's ultimately control the project budget.
8. It is not physically possible for a PM to manage all tasks for all resources on all teams, especially in large and complex projects. Having over 100 people, this project qualified as "large and complex".
9. PM's would be forced to communicate with multiple contacts about the same piece of work (both resources and RM's). It would be cleaner for everyone if there was a single point of contact for resources (the RM).
10. The PM is essentially powerless to handle resource issues:
• When a resource is ill or leaves the company, it is RM's who accept responsibility and handle the replacement.
• In the case of poor performance, the only recourse available to the PM is escalation to the RM. Use of escalation should not be a standard business procedure, and in the end, the RM still accepts responsibility for handling the resource.

Having made the case that RM's should be the primary project drivers in a weak matrix, can we say what the different management roles and responsibilities are in a weak matrix? We can, although this is high level, and you should complete a RACI or RAM or whatever your organization uses to define and communicate the details to your teams.

PM Lead:

• Manage release plan cycles
• Leads a weekly meeting between business process owners + applications teams + PM's
  
• This meeting is for inter-customer load balancing and resource leveling (this is like a program committee to prioritize across projects)
• Tabulates and publishes results

PM:

• Note that the seniority depends on project complexity including number of resource groups
• Watch timelines and deliverables, budget
• Chair project meetings
• Facilitate, coordinate, monitor and report

RM:

• Deliver work to estimates (commitment to deliverables)
• Contingency and mitigation belong to app resource managers.
• Resource managers "own" projects!

Resource Leads:

• Make technical decisions
• Guide resources in their day-to-day work

Quantifying Project Risk

Prevailing wisdom regarding project risks states that your risk management plan must:

• Identify project risks
• Quantify the risks
• Based on potential impact, develop plans to avoid, mitigate, transfer, or accept each risk.
• Monitor and control risks

During the quantification phase, a team will typically assess the probability of a risk actually occurring. This usually results in a percentage score assigned to the risk probability. For example, Risk R1 has a 0.2 or 20% probability of occurring.

So far so good.

Then the team assesses the impact. This almost always results in either a "T-Shirt" estimation (large/medium/small), or a relative one to ten score where a larger number implies a greater impact.

This impact measurement is then multiplied by the probability factor, giving a total risk score.

But a T-shirt or relative type number does not result in a meaningful impact measurement. What does .2 X high mean? Or even .2 X 7? The risk has not actually been quantified because a relative estimate does not provide enough information to make meaningful decisions. At best, we are only able to rank the risks by score to determine an order of priority.

Now we have a problem because as project managers, we need to answer certain questions:

• How much will it cost me in time and money if this risk actually occurs?
• How do I know whether to avoid, mitigate, transfer, or accept the risk?
• How much should I spend to mitigate the risk?

We can only answer these questions if the quantification process returns an impact measured in absolute hours or dollars. Then the risk score can be calculated in the same units. So: Risk score (dollars or hours) = Probability X Impact (dollars or hours).

We are now in a position to truly understand the potential cost of a risk and we can make an informed decision whether to avoid, mitigate, transfer, or accept the risk. If we choose to mitigate, we can answer the questions about how much time or money to apply to the mitigation effort. Since we know the cost of the risk, there is no reason to spend more to mitigate the risk than the risk itself would cost if it occurs.

Work or Duration?

When entering task estimations into MS Project, do you use work or duration?

As a reminder, work is the length of time a task will take (e.g., 8 hrs), while duration is the actual time that passes before the task is complete (e.g., 2d).

I prefer to receive work estimates rather than duration estimates from my teams, so I understand the cost of the project. If the teams provide duration, they are already considering factors outside the actual task at hand, most of which is not billable, and leaving me with no idea what the real work effort will be.

Instead, I'd rather have the teams provide me only with the work hours required to complete each task, then I as the PM can factor in overhead, productivity factors, holiday plans, etc., to arrive at a final delivery date. This simplifies the estimation process, keeps the team focused on the task at hand, lets me know the real work effort, and helps ensure that estimations are determined consistently across tasks and teams.

I usually ask for estimations in hours (the default unit of measure for work in MS Project). Then, when I enter the work effort into Project, it automatically calculates the task duration in days (the default unit). Then I can see from the plan's critical path when the project is likely to end and make any necessary adjustments.

Project Management Formula Review

• Budgeted Cost of Work Scheduled = BCWS = Planned Value = PV
• Budgeted Cost of Work Performed = BCWP = Earned Value = EV

• Actual Cost of Work Performed = ACWP = Actual Cost = AC
• Budget at Completion = BAC

• Estimate at Completion = EAC
• Estimate to Complete = ETC

• Variance at Completion = VAC
• Variance = Plan - Actual

• Cost Variance CV = BCWP - ACWP = EV - AC
• Schedule Variance SV = BCWP - BCWS = EV - PV

• Cost Performance Index CPI = BCWP / ACWP = EV / AC
• Schedule Performance Index SPI = BCWP / BCWS = EV / PV

• Estimate at Completion EAC = BAC / CPI
• Estimate to Completion ETC = EAC - ACWP

• Variance at Completion VAC = BAC - EAC

8 Ways to Get a Resource-Constrained Project Done

In just about this order:

1. Remove responsibility for unrelated work
2. Improve team effectiveness (work efficiency)
   
3. Perform work in parallel
4. Prioritize use of bottlenecked resources so high-profit and time-sensitive work comes first
5. Add capacity (people, overtime)
6. Reduce scope
7. Reduce quality
8. Slip due date