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

Assumptions are Risks

I reviewed a project schedule from another team that contained a list of 17 assumptions, any one of which would invalidate their plan if not held true. Naturally, they all referenced responsibilities or activities from other teams.

In other words, "we assume team X will do this, and team Y will do that. If they don't, we're not responsible when our plan fails."

How should a project manager respond to such a list?

Assumptions are risks. Replace assumptions with specific deliverables or activities to reduce risk. There should be no assumptions in a project schedule, only deliverables and their associated activities.

If there is any concern about whether team X or Y will deliver, add it to the risk list and manage it according to your risk management plan.

Why is EV so hard to learn?

1. The "alphabet soup" - EV vocabulary is not intuitive.
2. Overcoming the tendency to measure received value as effort instead of results.
3. Cost and schedule variance are not intuitive (cost variance is not planned cost - actual cost; schedule variance is measured in terms of dollars instead of time).

Others?

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.

What Goes into the WBS - Part II

There are two schools of thought on what should go into the WBS. One school, possibly the majority, holds that the WBS can contain activities as well as deliverables. Googling for the definition of "WBS" turns up definitions that use words like processes, activities, tasks, subtasks, etc.

The other school holds that the WBS should describe deliverables, not activities. I am firmly in this camp. At the work package level I'm looking for nouns, not verbs. The WBS defines the deliverables (nouns). Activities (the verbs) are defined in the project schedule (or a task list that is used to build the schedule).

Work packages must be nouns in order to manage scope.

Otherwise, scope management becomes about activities, not deliverables. As a PM, I want to know whether a deliverable in or out of scope, not whether an activity is in or out of scope. Activities will automatically be in or out of scope depending on whether the deliverable is in or out of scope. But identifying an activity as in or out of scope tells me nothing about the deliverable. Or, if you have activities that are not associated with a specific deliverable, they represent waste and should be removed.

To summarize: Verbs in the schedule are the activities needed to produce nouns in the WBS. Otherwise the WBS is just a lightweight task list that does not add significant value over the project schedule.

What goes into the WBS?

Project Managers are sometimes confused on what deliverables to put into their WBS.

Is a test environment a deliverable? It seems obvious that yes, the test environment is a deliverable since we need to test, and for that we need a test environment.

What about status reports? Suddenly, we're not sure. Do project planning and management artifacts go into the WBS?

See here for definitions of a deliverable:
http://www.google.com/search?hl=en&q=define%3A+deliverable&btnG=Google+Search.

You'll notice these definitions repeat certain phrases: tangible, outcome, measurable, output, etc.

By this measure, a status report is a deliverable. But does it go into the WBS?

I wrote here about the WBS: "The WBS should contain 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 represent a cost and schedule risk."

From project initiation all the way through to close, any deliverable necessary to successfully plan and execute the project should be captured in the WBS. This includes anything needed to meet your organizational requirements for project approval and execution.

In short: if you need it do get the project done then it's a deliverable. All deliverables must be included in the WBS.

EDIT: See here for some examples of things that should not go into the WBS.

So yes, project planning and management artifacts -- including status reports -- are deliverables that should be captured in the WBS.

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.

Process problem? Or people problem?

A successful project has people executing a process using technology. Occasionally, things break down, and something doesn't get done.

When that happens, it is tempting to make a process or technology change in hopes of avoiding the same problem in the future. But sometimes, it's a people problem, not a process or technology problem. When it is, no amount of process or technology will solve it.

Case in point: One team requested a standard service from another team. But someone didn't do their job and the request was not handled for almost 12 hours. Immediately, the management team began devising process adjustments to prevent a recurrence. The new process included having other teams follow up with the offending team to make sure their request was serviced.

All unnecessary. Just tell the person to do their job next time.

The business requirements long tail

A list of requirements is presented to the IT department. A competent team will ensure that the requirements are prioritized. When IT estimates the time cost to develop the solution, it is not unusual to deliver a plan to develop only the requirements identified as "must have", due to budget, schedule, or resource constraints.

Once the main part of the solution is delivered, the business must again justify development of the remaining requirements, as measured against competing projects. Since the remaining requirements were not must-have's, the business case can become problematic. There may be a large number of requirements that were not must-have, and that do not, taken individually, deliver significant value, and consequently may never be completed.

I call this the business requirements long tail.

The sum of these requirements may represent significant cost to the business, but unless they are evaluated as a whole, the cost of building a solution for each cannot be justified.

The business, if a solution is to be developed for these requirements, must find a way to bundle up the requirements into a coherent whole in order to make an argument for going ahead with development.

Late projects test the design but not the requirements

Projects coming in late and below target will sometimes lower the QA bar and test against the design rather than the requirements.

Yes, the system works as designed, but does it meet the requirements?

We're not sure, but if we come in on time and on budget we can declare success!

Rushing a Project

Project failure lesson #27:

IT is often under pressure to deliver a project plan because "the customer wants it by tomorrow". This leads to a rushed plan, which inevitably becomes a customer commitment.

The result, of course, will be a poorly planned project leading to missed dates and reduced scope.

It can be politically difficult, but try to spend the necessary planning time up front; it really will save your bacon later on.

Architecture diagrams

Here is a system integration architecture diagram I reviewed recently. The details have been removed for obvious reasons, but the jist of the diagram remains.

This is an excellent example of how not to do an architecture diagram, although convincing some people of that fact is nearly impossible.

The most that I can say about this diagram is that it identifies the systems, and the messages that need to pass between them. Aside from that, it conveys no meaningful information. On the contrary, instead of clearing up questions, it adds more.

1. Where is the starting point of the process? My eye wanders all over the diagram, not knowing where to begin.
2. In what order are the messages sent and received?
3. That long horizontal box in the middle looks like some sort of messaging layer. It is?
4. What are those boxes below? A persistence layer? "Oh no, those are systems to be integrated as well."
5. From the system perspective, which messages are in response to which?
6. Are messages always required? Or are some optional?

How many questions can you think of?

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.

Death and Dying

I wrote last time about mediocre organizations.

As "A" players devolve into "B" players, they follow a trajectory similar to the Elizabeth Kubler-Ross stages of death and dying:

1. Denial: Initial paralysis at hearing the bad news: trying to avoid the inevitable.
2. Anger: Frustrated outpouring of bottled-up emotion.
3. Bargaining: Seeking in vain for a way out.
4. Depression: Final realization of the inevitable.
5. Acceptance: Seeking realistic solutions; finally finding a way forward.

I would add to this a sixth stage:

6. Roll eyes patronizingly as people who are still in denial and anger attempt organizational improvement.

Why Your Organization is Mediocre

• "A" players hire other A players.
• B players think they are A players.
• B players hire C players.
• If an A player sneaks through the hiring process, they will either quit in short order, or become a B player.
• B players will not promote A players to their own level, usually out of fear.

The organization thus descends into a steady state of mediocrity.

Evidence of a B player can be found in the statement: "If you think things are bad now, you should have seen us a year ago!"

The reality? The organization has progressed from an F to a D minus. Still a failing grade, but advertised as a success by B players.

Ten ways to screw up your requirements

1. Multiple versions of requirements documents distributed via email.
2. Key project resources not having documents or not having the latest document revisions.
3. Documents not updated to reflect correct requirements status (e.g., descoped).
4. Requirements buried in hundreds of pages of dense paragraphs of text and hard to identify.
5. No common understanding of the requirements across teams.
6. No agreement and signoff with the customer.
7. Requirements status tracked in a spreadsheet kept separate from the requirements documents, so we have to refer to the spreadsheet to understand whether a document section is still in scope.
8. Changes to the requirements distributed as text in email messages.
9. Design components and solutions provided as business requirements.
10. The requirements are "just changes from what we have today," but there is no baseline against which to compare the changes.

Planning for Politics

I was once asked to modify a project plan to swap resources between projects.

The idea was to show resources on projects that they will not actually participate in.

Why?

Because the IT management team was locked in a dispute with the business regarding whether or not to engage on a particular project. The business wanted it to happen, but IT was pointing out good reasons not to do it: the project was large and cost prohibitive, the customer was not particularly profitable to begin with, and the project did not advance either the business or IT strategy.

The thought behind modifying the plan in this way was that showing certain resources on the plan would have a dampening effect on the request for project A.

It doesn't matter whether the IT department was correct or not. To make a political point, the IT management asked their team to submit an unsuitable and ultimately false plan.

The result was predictable:

1. We had no credible plan, but we were held to it as we executed the project.
2. The swap caused the project with extra resources to go over budget.
3. During project reviews, it was difficult to answer questions about actual resource allocation, since it did not match up with the plan.
4. It was dishonest. I needed to ask other people to modify the plan to show a project need that differed from reality.
5. It lowered the morale of people who were asked to build and execute a plan they knew was not real.
6. It reduced trust between management and employees.

Using plans for political purposes occurs often in IT organizations. I call this "Planning for Politics". Most often, it takes the form of reducing estimates to something that will be perceived as "acceptable" by upper management. Either way, the result is that middle level IT project managers are caught in the no-man's land of pressure to execute projects within schedule, scope and budget, combined with inappropriate planning directives from the top.

Sometimes people are hostile to cover incompetence

During the course of a recent project, I had several encounters with an individual whose behavior was quite hostile. If I asked a specific question about how something worked, for example, she became very defensive and even aggressive.

Over time, I came to understand that she was using her hostility to cover a lack of subject matter expertise. My best guess is that her hostility was intended to drive people away and limit interactions with those who could identify her weakness.

Something to watch out for on your own projects.

Courage? Or patience?

A colleague sent me a copy of an article the other day, in which the author maintained that effecting organizational change requires having the courage to recognize the risk presented by maintaining the status quo.

Maybe, but I find that that it takes more patience than courage. It's tough having the same arguments over and over, and the main challenge is to keep from getting discouraged.

Seth Godin writes about prototypes, concluding that "your prototype has to be better ... than the finished product is going to be. That's what people expect anyway--they see your prototype and take off 20% for reality."

Depends on the context.

If you are showing something to a VC, Seth is probably right.

If you are working for a big company, and trying to sell an idea internally, one of two things will happen:

• For a prototype thats just basically the UI with nothing really behind it, people expect that it's mostly done.


• For a prototype with no UI at all, people don't get the concept and reject the idea.
  

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

How Not to Measure Variance

Last time we talked about how to determine task status, and our project now has credible data about technical performance. Assuming that the project also has cost and schedule estimates, we should have everything needed to get an accurate picture of a project's status.

Let's say that we have a project to write and execute test cases for the same inventory report we used in the previous example. We have already received estimates that say it will take 8 hours of effort to write and approve the test cases, and 32 hours to execute them. The project has been given a single Test Analyst, allocated at 100% and billed at $100/hour, ready to start next Monday.

We have also negotiated with the project stakeholders and agreed that when the test cases are approved, the "Write test cases" task will be 100% complete, and the project as a whole will be 25% complete. When all test cases have been executed at least once, regardless of whether or not they have passed, the "Execute test cases" task will be 50% complete, and the project will be 75% complete. The project will be 100% complete once all test cases have been executed and passed.

Now Monday comes and goes but we haven't received the test cases yet. We are dismayed to find that our project, which should be 25% complete at the end of 8 hours, is still 0% complete. Meanwhile, we see that the analyst's timesheet says 8 hours were worked on this project, so we conclude that the project is behind schedule and over budget.

By how much?

At this point, it is tempting to argue that the analyst may only need an hour or so to complete the draft. All we need to do is ask the analyst how much time is needed to complete the task. This estimate to complete then becomes the budget variance. Say for example, the analyst says 2 hours are needed to complete the task. Two hours X $100/hour = $200. So we are behind budget by $200. Right?

No.

The agreement up front was to measure this task as either 0% or 100% complete, but we are suddenly measuring an incremental cost. Not only that, but the incremental cost is again based on a vague, inaccurate, inconsistent, and indefensible estimate to complete, so we have returned to the original problem.

What to do? This is an important question, because we may want to make a decision about whether or not to pull the plug on a project that is over budget and behind schedule. The answer is to stick to the original agreement, which is to determine percent complete on the basis of physical evidence.

This leaves open the question of how to develop an accurate picture of budget and schedule variance, and that is the topic for next time.

Next time: What does "behind" mean?

Task Status

"Are we There Yet?"

If you are a parent who has driven long distances with young children, you have probably heard this plaintive cry from the back seat. Project managers hear it often, and from just about every stakeholder. In the context of project management, the question is really: "When the budget is spent, and the schedule has expired, will the work be done?"

Unfortunately, many projects focus on tracking schedule and cost, but do a poor job of tracking technical performance. So we can see how much money we have left and how much time is left before we need to be at our destination, but we can't clearly see how far we have traveled, or how far we have left to go!

Some projects will try to derive technical performance numbers by obtaining estimates of task percent complete from the team, or a report of time spent along with an estimate to complete. In essence, they use proxy data as indicators of technical performance. This raises some questions. On what basis were the estimations made? Are they accurate? Consistent? Defensible? Is the estimate a measure of effort or results?

The question then becomes: What can we use as a reliable indicator of task status? A simple solution is to look at a task's deliverables. Only when the deliverable is, er, delivered, can we say that the task is 100% complete.

For example, let's say that we have a very simple project to write and approve a requirements document for a new inventory report. We have in hand an estimate that says it will take 40 hours of effort, and the project has been given a single Business Analysis resource billed at $100/hour and allocated at 100%, ready to start next Monday.

The task deliverable is clear: an approved requirements document. Since the project is relatively short, the value of a percent complete measurement is not very useful and all stakeholders should agree that the task can only be either 0% or 100% complete. The task will be 100% complete only upon receipt of the draft document, and will be 0% complete otherwise. We either have the document or we don't.

What about long-duration tasks? For these, we can define intermediate milestones, and agree on an allocation of their percents complete. For example, let's say we agree that when the first draft of the document is received, the task is 50% complete, and upon document approval the task is 100% complete. The task can now be 0%, 50% or 100% complete. Again, we will not ask for a percent complete, since we have explicitly stated that the task will be 50% complete upon receipt of the first draft, and 100% complete upon approval of the document.

Notice that we will not be asking the analysis for an estimate of percent complete. Instead, we introduce an objective, consistent and defensible way to measure technical progress. This method measures results rather than effort, and since results are the whole point of a project, we no longer need to rely on a vague estimate of percent complete to get an accurate picture of task status.

Next time: How *not* to measure variance.

Away from a Cybernetic Theory of Project Management

There is a tendency in academic PM circles to lament the fact that there is no "theory" of PM, and to attempt to remedy the situation by identifying PM with control systems theory and particularly with cybernetics (feedback loops). The essence of the solution is usually to model PM as a closed-loop control system.

More advanced papers on the topic commonly arrive at the conclusion that such linear approaches do not suffice for PM. To address this new understanding of the problem, an adaptive controller approach is suggested, in which attributes of the controller -- in essence the "rules" of project management -- can be updated in real time to respond to inputs that vary nonlinearly.

Overlooked in such approaches is that no general theoretical method of designing adaptors exists. Adaptors cannot cope with arbitrary or unknown perturbations, and so are usually developed for specific applications. Adaptive controllers therefore do not provide a model that can be used to develop a general theory of PM.

Task Complete

Last time I advised that actual cost (AC) should be used to determine EV (BCWP). The reasoning, which would have been more fully explained in a follow-up post on handling work in progress, was that a task's percent complete can be given as AC / (AC + ETC), so that EV = percent complete x PV.

In order to make this approach work, I introduced a rule that EV cannot exceed PV, no matter what the AC. I received some excellent feedback on that rule, and although the math still works, I am now convinced that it only adds complexity. More importantly, it relies on AC as a proxy for the quantity of work completed, and thereby assumes that effort equals results. As Glen Alleman pointed out, this is a dangerous assumption. The issue of completeness is therefore left unresolved. How are we to know when a task is complete?

Tasks should have success criteria, in the form of well-defined outcomes. Unfortunately, project managers seem to focus more on task activities than on outcomes, perhaps because of pressure to meet schedule and budget constraints. In reality, activities lead to outcomes, and only upon receipt of an outcome is the project matured toward its objective. Therefore, it is not so much the activities that are important, but their outcome.

Outcomes can then be measured against expectations, and a determination made about the completeness of the task. Glen suggests physical evidence as a key indicator of completeness. I would amend this to say physical evidence which everyone agrees meets the task success criteria. Incomplete or low quality results may not sufficiently advance the project's maturity. For example, a requirements gathering effort that does not provide an understanding of the problem domain has not met its success criteria. Reaching a "requirements signed off" milestone therefore means that everyone agrees that the task has met its success criteria.

Earned Value, Simplified

Here are some simple examples on how to do EV:

Example 1 - ON TIME:

A very simple project, one resource, one task, duration of 80 hours at $85/hour, that completes on time and on budget.

Setup:

1. Set up your 2 week project plan with the WBS as usual.

2. Calculate your Planned Value (PV), based on task completion dates. (IMPORTANT RULE! EV calculations are time-boxed.) For this project, the task will be complete at the end of week 2, so:

• PV for week 1 = $0
• PV for week 2 = 80 x $85 = $6,800

Execute:

1. At the end of each week, add up the Actual Cost (AC) for each completed task. (IMPORTANT RULE! Only calculate AC for completed tasks.)

• AC for week 1 = $0, because the task is not completed
• AC for week 2 = 80 x $85 = $6,800

2. Calculate Earned Value (EV) by adding each week's AC for completed tasks to the cumulative cost of the project. The cumulative cost for this simple project is $0 until the end of week 2, so:

• EV for week 1 = $0
• EV for week 2 = $6,800

Report:

1. Cost Variance (CV) = EV - AC = $6,800 - $6,800 = $0
So, this project completed right on budget.

2. Schedule Variance (SV) = EV - PV = $6,800 - $6,800 = $0
So, this project completed right on time.


Example 2 - LATE:

Same project (one resource, one task, duration of 80 hours at $85/hour), but this time it completes 20 hours late and over budget.

Same setup:

1. Set up your 2 week project plan with the WBS as usual.

2. Calculate your Planned Value (PV), based on task completion dates. For this project, the task will be complete at the end of week 2, so:

• PV for week 1 = $0
• PV for week 2 = 80 x $85 = $6,800

Execute:

1. At the end of each week, add up the Actual Cost (AC) for each completed task.

• AC for week 1 = $0, because the task is not completed
• AC for week 2 = $0, because the task is still not completed, and now our project is late
• AC for week 3 = 100 x $85 = $8,500

2. Calculate Earned Value (EV) by adding each week's AC to the cumulative cost of the project.

• EV for week 1 = $0
• EV for week 2 = $0 (because the task is not complete)
• EV for week 3 = $6,800 (IMPORTANT RULE! EV can never exceed PV no matter what the AC!)

Report:

1. Cost Variance (CV) = EV - AC = $6,800 - $8,500 = $-1,700 (IMPORTANT RULE! A negative number means that the project is over spent.)

2. Schedule Variance (SV) = EV - PV = $6,800 - $6,800 = $0 (IMPORTANT GOOFINESS! The task was completed late, but the schedule variance goes to zero once the task completes. This is clearly misleading, but there is a technique called earned schedule to address it.)

SUMMARY:

There are only a few simple rules to keep in mind:

1. EV calculations are time-boxed, in these examples, weekly.
2. Calculate EV only for completed tasks, not work in progress.
3. EV can never be greater than PV, no matter what the AC.
4. Negative SV or CV mean the project is late and over budget

You may have noticed that with this technique SV will never be negative. That's because we have ignored work in progress by focusing only on completed tasks, and it is the subject of the next post.

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

Dementia pugilistica

Dementia pugilistica, a.k.a. boxer's dementia results from multiple blows to the head, occurring over a sustained period of time. A number of boxers, notably Muhammad Ali - whose condition has deteriorated in recent years - have suffered from this condition.

It is rarely a single knockout blow that causes long-term damage. Instead, it is the accumulation of
blows, endured over a period of years that results in the disorder.

The application to project management is clear. Those small uncontrolled scope changes, the failure to manage risk properly, etc., in themselves may not kill your project, but the accumulation of a large number of small failures occurring over a period of time probably will.

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.

Blunderbuss

From this Wikipedia article:

"By its nature, the blunderbuss is not a very precise weapon. Although it was sometimes used in a military setting, it was more effective when the goal was not to hit a specific target, but rather any one of multiple targets, such as for crowd control. During combat, the blunderbuss was a very unpredictable weapon; it could hit an entire group of enemy soldiers or miss all of them. The blunderbuss thus became a byword for inaccurate marksmanship in any field."

As a project manager involved in high-profile, high risk projects, or even a project recovery, you will be subject to people sending scattershot emails complaining about some aspect of the project, or criticizing your work. The email may or may not be correct, but the problem is that you have now been openly criticized in public.

In a case like this, you must reply all with some kind of response, but you risk getting involved in a public dispute that makes everyone look bad.

The solution is to go ahead and reply all, but just say something like: "I don't agree, lets have a meeting". That gets you on record as disagreeing with the original charge, but also gets the debate out of the public eye.

You can then set up a meeting one-on-one with the original complaintant to handle the issue in a more professional manner.

Dropping SCUD Missiles

Project managers must frequently communicate bad news. When the bad news refers to poor performance, you want to give the manager of the offending person or team a heads up before reporting it, so that they have a chance to rectify the situation, or are at least prepared for the fallout. Otherwise, you will make an enemy, and the first chance they get, they will respond with the same.

George Costanza, Project Manager?

The reference is to a Seinfeld episode in which George determines to do the opposite of whatever he thinks is right. In doing so, he lands a date with a hot chick, and a job with the New York Yankees baseball club.

Is there application to project management? I think the answer is a resounding no.

Most IT projects still end in at least partial failure, meaning that they are not completed on time, on or under budget, or do not deliver all agreed content. Why? Because the most fundamental rules of successful project management are broken:

1. Unclear goals and objectives
2. Scope creep
3. Unrealistic timelines
4. Lack of executive support
5. Lack of user involvement
6. Poor requirements
7. Poor testing

Looks like in most cases we are already doing the opposite of what should be done!

Biweekly vs. semi-weekly

• Biweekly means once every two weeks.
  
• Semi-weekly means twice per week.

Export Outlook Tasks as XML

File this under GTD.

For a variety of reasons, I use a PDA to take notes in meetings, and when I sync, these become Notes in Outlook. This itself is not the problem, but it becomes one if I want to access these notes in any other application.

Following is a quick and dirty VBA I wrote to export Outlook Notes in XML format. It saves the categories (like "tags"), and converts special characters to their html equivalents in order to avoid XML formatting errors.

Option Explicit

Sub SaveNotesAsXML()
Dim App As Outlook.Application
Dim NotesFolder As Outlook.MAPIFolder
Dim NoteItem As NoteItem
Dim filename As String
Dim f As Integer

Set App = Outlook.CreateObject("Outlook.Application")
Set NotesFolder = App.GetNamespace("MAPI").GetDefaultFolder(olFolderNotes)

f = FreeFile
filename = "Outlook notes.xml"
Open filename For Output As #f

Print #f, ""

Print #f, ""
For Each NoteItem In NotesFolder.Items
With NoteItem
 Print #f, ""
 Print #f, "" & .Categories & ""
 Print #f, ""
 Print #f, encode(.Body)
 Print #f, ""
 Print #f, ""
End With
Next NoteItem
Print #f, ""

Close #f
End Sub

Private Function encode(ByVal str As String) As String
Dim ch As String
Dim i, n As Long

n = Len(str)
For i = 1 To n
ch = Mid(str, i, 1)
Select Case ch
 Case "&": ch = "&"
 Case "'": ch = "'"
 Case Chr(34): ch = """
 Case "<": ch = "<"     Case ">": ch = ">"
 'Case vbCr: ch = "\n"
End Select
encode = encode & ch
Next i
End Function

Weak Matrix Organizations (Part 2)

Weak matrix organizations are characterized by the fact that power and control lie less with a project manager, and more with functional or resource managers. This can lead to problems for project managers who are held accountable for the success of their projects, even though they do not have control over resources.

Besides the control issue -- which can be significant if resource managers do not keep their promises -- a key problem is visibility. Are the estimations correct? Are we tracking to budget and schedule? I hope so, but since I do not have a direct view into team activities, I must rely on reports from resource managers.

Without a detailed view into team activities. I can perform linear projections based on current trends, but this has limited value since progress is rarely linear. I am forced to rely on hope. For project managers in weak matrix organizations, hope is often a prominent aspect of their risk management plan!

A better approach is to shift responsibility back to the resource managers, since they have the control. Embrace the weak matrix organization. Become more of an administrator and coordinator than a manager. Ask for statements on budget and progress status. Publish those statements far and wide. Make sure the senior management sees them. Then if the teams come back later saying they will be over budget or over time, they bear the responsibility, not you.

Weak Matrix Organizations

If you are taking MBA classes in which

1. The professor asks you to work in teams and working in teams, and
2. You have teammates who are not pulling their weight ...
   

... get used to it.

It's the same in a weak matrix organization.

I have exactly this problem with a project team right now. There are a couple of ways to handle it:

1. Meeting minutes and status reports - make sure to name those present, those who have conveyed apologies, and those with unexcused absences.
   
2. Set up a standing meeting with execs "to provide visibility" and use the opportunity to point out what is going on.

This helps protect you by making everyone aware of the situation while it is happening, and not at the end of the project when it is too late.

Communicate your strategy to the team

As you pull your project from the depths of dispair, you will want your teams to start taking more decision-making responsibility. This is important so they can gain experience, and so you will eventually be free to take on another project.

Help your people take initiative, but make sure they understand the strategy (goals and execution plan). Without a good framework within which to evaluate options, the teams will not be equipped to make good decisions. And all your hard work might be for nothing.

Micromanagement = Bad

In a project recovery, a key goal is to develop the team so that they see how to run a project successfully. To that end, you want to define task outcomes. Don’t micromanage by defining the steps.

Entering Estimates into MS Project

I wrote last time about estimating task as effort as work rather than duration.

Now I have my estimates and I am ready to start building my MS Project plan. But wait! The default Gantt view in MS Project 2000 allows me to enter task durations but not work effort. Why?

I find it confusing, since tasks in Project are by default effort (work) driven, and not fixed duration.

I find it slightly annoying as well, since I always need to insert the work column when building a plan.

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.

Career Strategies

1. Prepare for every interaction.
2. Succeed with a nasty project. Example: SARBOX.
3. Don’t have control? Use influence! Make a case. Go back to common language: dollars, business logic (choices).
4. Participate on collaborative projects to become known outside your group.
5. Prove your abilities before asking for the job.
6. Take the lead if there is no one there.
7. Focus on general management. If you become known as an expert in an arcane technical area, you could be seen as indespensible and end up get stuck there.
   

Your Project Status Elevator Speech

Always have a project status "elevator speech" ready. You never know when you are going to run into a project stakeholder!

• Milestones
  
• Budget
• Risks and issues

You might also take the opportunity to "sell" aspects of the project, such as strategic benefits, team performance, or whatever.

Looking ahead during project status meetings

One thing I look for in project status meetings is two week lookahead. The team leads who provide the report should know their milestones dates, and should have a detailed knowledge of what is due or coming up in the next two weeks.

There are two thoughts behind this. For one, I make sure that the leads know what is expected of their teams; and two, the milestone review helps ensure we identify roadblocks or risks which might cause us to miss the date.

Not everything is front office

Hiring new resources, administrative management, directing workflow, review processes, change control, career development, and change management are all "back-office" activities. That is, although necessary, they are not directly related to developing IT solutions for business problems.

If you bill these activities to the business, they raise exactly that objection.

News for them: Not everything is front office. The business don't get to cherry pick their resources. Without these activities, they wouldn't have a development team for very long! Your job is to make sure these activities are also billed appropriately.

Reading for Today's MBA

Reading list for today's MBA:

1. The Long Tail - Chris Anderson - Focus on the large number of small niche markets
2. The Cluetrain Manifesto - Levine, Locke, Searls and Weinberger - Markets are conversations.
3. How to be Creative - Hugh McLeod (NOTE: Key buzzwords out there today are "innovation" and "creativity")
4. The World Is Flat: A Brief History of the Twenty-first Century - Thomas L. Friedman
5. Seth Godin's blog
6. Web 2.0 - Tim O'Rielly
7. Blink : The Power of Thinking Without Thinking - Malcolm Gladwell
8. Tipping Point - Malcolm Gladwell
9. Zazzle.com - personalized products
10. ksblog - marketing from a female perspective, but very straight and blunt.
11. Guy Kawasaki's blog
12. Guerilla Marketing - Jay Conrad Levinson
13. The Personal MBA - Josh Kaufman (okay, I cheated a bit here)
14. Blue Ocean Strategy - Kim and Mauborgne

Others?

Oops!

I was looking at an account that from all appearances was in deep trouble.

Unhappy customer, no controls, poor quality, you name it.

Looked at it for about a week. It looked bad. Very bad.

So I made some staffing changes. Some process changes.

And completely screwed up the project.

Why?

Because I did not understand what was really going on.

I came into the project with some pre-conceived notions. Some assumptions.
And I was wrong.

My actions broke up a team that was functioning well under the circumstances.
Slowed everything down. Lost subject matter experts.

Did the project have problems? Sure.

But I identified the wrong things as problems.

Obvious moral to the story: make sure you really understand what is going on in a project before taking action.

Handling Emasculations ... er ... Escalations

You cannot allow the customer or the business to go over your head and have an effect.

If you have made a mistake, 'fess up and fix it.

If you haven't, demand the backing you need from the execs or your boss.

If you don't get it, don't take the project.

Schmooz ... er ... Networking.

There's been a lot written lately about networking.

Keith Ferrazzi's "Never Eat Alone" book and blog.

Guy Kawasaki's The Art of Schmoozing.

There are others.

A word of caution: In a big company, you need to be careful who you align with.

There are almost always political undercurrents hiding just underneath the surface. If you pitch your tent in the wrong camp, you could get taken out along with your allies.

Be sure you understand the lay of the land before making relationship commitments.

Nine Women, Nine Months, Nine Babies

There is an old IT adage that you can't make a baby in one month by throwing nine women at the problem.

The point being, of course, that there is a diminishing return on investment to adding people to a project (reference Fred Brooks' point that adding people to a late project makes it later).

Usually overlooked is the fact that nine women can make nine babies in nine months.

Break Even Point

Our last installment on the business of business! It was a little academic, but hope you enjoyed the series.

Break-even defines the number of units we must sell to at least cover our costs. It is the number of units at which profit p will be zero; that is R = C. It can be expressed either as the number of units sold, or as revenue dollars.

Q  FC  VC  TC   R    p
 0 100   0 100   0 -100
10 100  10 110  90  -20
20 100  20 120 160   40
30 100  30 130 210   80
40 100  40 140 240  100
50 100  50 150 250  100
60 100  60 160 240   80
70 100  70 170 210   40
80 100  80 180 160  -20
90 100  90 190  90 -100
100 100 100 200   0 -200

We can see the BEP must occur when 10 <= Q <= 20. The graph visually confirms this. But what is the exact Q needed to break even? In order to know this, we must first understand a concept called contribution margin (CM).

Contribution margin is the price per unit less the variable cost per unit. CM therefore tells us how much revenue per unit is left over after variable costs are accounted for. We can use CM as follows:

CM = p - VC = 5.5 - 1 = 4.5

Having accounted for variable costs, we next want to know how many CM's it will take to cover our fixed costs, so we just divide FC by CM to get the break-even point:

BEP(Q) = FC/CM = 100/4.5 = 22.22

Since we can't make and sell partial units, we round up to 23. We said that break-even can be expressed in wither units or dollars of revenue. Knowing units, we can now calculate BEP in terms of revenue with:

BEP(R) = p * BEP(Q) = 5.5 * 23 = 126.5

There is another way to compute BEP(R) without knowing price or variable cost. For this, we need to know the contribution margin ratio (CM%):

CM% = CM/p = 4.5/5.5 =0.82

CM% thus tells us what portion of the selling price remains after accounting for variable costs, and allow us to know the BEP without knowing p or C:

BEP(R) = FC/CM% = 100/(4.5/5.5) = 122.22

This doesn't match the result of 126.5 above, since we rounded 22.22 up to 23 before multiplying.

Marginal Analysis

Last time we developed data showing that our greatest profits come when we produce between 40 and 50 units; that is, when 40 <= Q <= 50. Now we want to answer the question: How can we find the exact value of Q that gives the greatest p? One way is to just keep zooming in on the area of the data. In the next table, we zoom in on the area between 40 and 50 to see what happens:

 Q    p      R    C      p
50 5.0 250.0 150 100.0
49 5.1 249.9 149 100.9
48 5.2 249.6 148 101.6
47 5.3 249.1 147 102.1
46 5.4 248.4 146 102.4
45 5.5 247.5 145 102.5
44 5.6 246.4 144 102.4
43 5.7 245.1 143 102.1
42 5.8 243.6 142 101.6
41 5.9 241.9 141 100.9
40 6.0 240.0 140 100.0

The area of greatest profit appears to be at Q = 45. But suppose it's at Q = 45.1? Or Q = 44.9? We could zoom in again to find out. In fact we can repeatedly zoom in as far as we want, since there's no shortage of real numbers. Another way to find the Q for greatest profit is to incrementally change Q. We can do this with the concept of marginal profit.

Marginal profit (Mp) is computed as: Mp = (p2 - p1)/(Q2 - Q1). That is, for a change in Q, how much does p change? From the data, we see that the change in p varies with the change in Q. We do not have a constant rate of change. This is because the profit equation yields a curve, not a straight line, as we saw when we developed our model previously. We would need to compute Mp for every point we want to check.

Here is an example for a change in Q from 50 to 49 from the data above:
Mp = (p2 - p1)/(Q2 - Q1)
Mp = (100 - 100.9)/(50 - 49)
Mp = -.9/1
Mp = -.9

Here is another example for a change in Q from 46 to 45:
Mp = (p2 - p1)/(Q2 - Q1)
Mp = (102.4 - 102.5)/(46 - 45)
Mp = -.1/1
Mp = -.1

So, given that the profit equation does not give us a straight line, how can we identify the Q which yields the greatest p? We can see a clue by noticing that there is a definite maximum in profit curve, where it reached the top of its' arc before it begins to descend.

This is the point where an additional change in Q results in Mp = 0, and further changes cause Mp to become negative. So the Q which gives the greatest p lies at the top of the curve where Mp = 0. If we were to draw a tangent line at that point, its' slope would be zero:



So if we can find the point on the curve where the slope of a tangent line is zero, we will have found the point of greatest profit and consequently the desired Q. How do we do that? Differential calculus.

Recall that the profit equation is: p = -.1Q^2 + 9Q - 100. It turns out that by taking the derivative of this equation with respect to Q, we can find the slope of the tangent line at any point along the curve. Here's how:

Step 1: Find the derivative of the profit equation. This gives us the marginal profit:

p = -.1Q^2 + 9Q - 100
Mp = dp/dQ = -.2Q + 9

Now for any Q, we can find the marginal profit.

Step 2: Since we are looking for the point where Mp = 0, and we now know Mp = dp/dQ = -.2Q + 9, we can set -.2Q + 9 = 0 and solve for Q:

Mp = dp/dQ = -.2Q + 9 = 0
-.2Q = -9
Q = -9/-.2
Q = 45

So our profit maximizing Q is 45. What price is required to sell this quantity?
Recall that p = 10 - .1Q, so p = 10 - .1(45) = 5.5

What is the profit we can expect to earn for Q = 45 and p = 5.5?
Recalling that R = pQ, C = 100 + Q, and p = R - C, we see that:

R = pQ = 45 * 5.5 = 248

Using the revenue equation we developed previously, we can confirm:

R = -.1Q^2 + 10Q = 248

Also,

C = 100 + Q = 100 + 45 = 145

Finally,

p = R - C = 248 - 145 = 103

Confirming:

p = -.1Q^2 + 9Q - 100 = -.1(45^2) + 9(45) - 100 = 103

Now that we have R and C, we can also find our break-even point. That's the subject of the next section.

Profit

Now we know our costs, and since we can compute the quantity sold for a given price, we can also project revenues as R = pQ. We are therefore in a position to compute profit.

Profit is given by the profit equation p = R - C, where R = revenues and C = costs.

Since we already know R in terms of Q (R = -.1Q^2 + 10Q), and we can see that C = 100 + Q, then it is clear that:

p = (-.1Q^2 + 10Q) - (100 + Q)
p = -.1Q^2 + 9Q - 100

  Q  p   R   C    p
100  0   0 200 -200
90  1  90 190 -100
80  2 160 180  -20
70  3 210 170   40
60  4 240 160   80
50  5 250 150  100
40  6 240 140  100
30  7 210 130   80
20  8 160 120   40
10  9  90 110  -20
 0 10   0 100 -100

Notice that our greatest profit occurs not when revenue is highest, but when the distance between revenue and cost is greatest. Increasing revenue by producing more units also increases costs.

A look at p shows where we make the most profit: where Q is between 40 and 50. Clearly, we should target production in that range. But can we produce 45 and make more profit than at 40 or 50? That is the subject of the next section: Marginal Analysis.

Costs

Now that we can derive revenue in terms of p and Q, it's time to look at cost. Cost can be broadly divided into two types: fixed and variable. Fixed costs are those the company would have to pay whether or not they are actually producing anything in the factory. Examples of fixed costs are rent, insurance, and the like.

Variable costs are those costs incurred by the company during production. They are not incurred if the company is not running the factory. Examples of variable costs are hourly wages, raw materials, etc.

Costs, therefore, are described by the cost equation as: C = FC + VC.

Suppose, for example, our factory has monthly fixed costs of $100, and variable costs of $1 per unit. Our total costs would be computed as: C = FC + VC(Q). Using the same quantity data as before, we can chart our costs:

  Q  FC  VC   C
100 100 100 200
90 100  90 190
80 100  80 180
70 100  70 170
60 100  60 160
50 100  50 150
40 100  40 140
30 100  30 130
20 100  20 120
10 100  10 110
0 100   0 100

If we produce nothing, we still have the fixed costs of $100, so this looks right.

Revenue

We can now compute projected revenue R for each Q, since R = pQ. Note that we want to know R in terms of Q, so the revenue equation becomes:

R = pQ = (-.1Q + 10)Q = -.1Q^2 + 10Q

Plotting this data gives the following:

  Q   R
100   0
90  90
80 160
70 210
60 240
50 250
40 240
30 210
20 160
10  90
 0   0

Notice that revenue is not a straight line. Evidently, revenue rises up to a certain point, but then starts to decline as we increase Q further. In other words, it is unwise to produce beyond a certain point.

Price and Quantity

Now we are finally ready to develop an economic model of the firm. If you have stayed with me this long, this is where the payoff begins.

Based on test marketing trials, our company has developed data on how the demand (Q) for our product changes with a change in price (p). You can see that as we raise the price, we sell less:

 p   Q
0 100
1  90
2  80
3  70
4  60
5  50
6  40
7  30
8  20
9  10
10  0

Since we would like to be able to predict Q for any p, we need to develop a mathematical model (the demand equation) that describes the relationship between price and quantity sold.

The equation of any line is: y = a + bx, where x and y correspond to our p and Q respectively; b is the slope of the line, and a is its intercept.

The slope (m) of a line tells us how much Q will change for a unit change in p. In this example, m = -10, meaning that for every unit increase in p, Q decreases by 10. Slope can be calculated with:

m = (y2 - y1)/(x2 - x1) = (100 - 90) / (0 - 1) = 10/-1 = -10.

Notice we use m and b interchangeably here.

The other term we need for the equation of a straight line is the intercept. This is just the point where the line crosses (intercepts) the y axis, in this example 100.

So the demand equation for our line is: y = a + bx = 100 -10x, or Q = 100 - 10p. With a little algebra, we can rearrange the equation to derive p as well as Q:

Q = 100 - 10p
Q - 100 = -10p
(Q - 100)/-10 = p
(Q/-10) + 10 = p
-.1Q + 10 = p

This is the price equation.

Rules of Derivation

Okay, this might be a little over the top, so you could get away with just skipping this and come back to it for reference if you need to. Tomorrow we start the good stuff.

• The derivative of a constant is zero. For y = 7, dy/dx = 0
• The derivative of a constant times a variable is the constant. For y = 13x, dy/dx = 13.
• Power function (most important). For y = ax^m, dy/dx = m*ax^(m-1).
• Example: For y = 4x^3, dy/dx = (3)(4)x^2 = 12x^2

Slopes and Derivatives

Now for the really yucky stuff, but we're almost home!

Derivatives (the math concept, not the financial instrument) are interesting to us as business people because they have to do with rates of change.

The derivative of a function shows the change in the dependent variable y given a change in the independent variable x. It is written dy/dx.

Suppose we have the equation: p = 2Q - 0.1Q^2 - 3.6, where p = Profit and Q = Quantity.

In this equation, Q is the decision variable; that is, we ask the question: What Q will maximize p? Notice in this equation, that if Q = 0, p = -3.6

Here's the data and graph for the equation:

 Q    P
0 -3.6
2  0.0
4  2.8
6  4.8
8  6.0
10  6.4
12  6.0
14  4.8
16  2.8
18  0.0
20 -3.6

We see that p is maximized at 6.4 when Q = 10. This is the point at the top of the curve. If we draw a horizontal line across the curve at that point, we get a tangent line whose slope is zero. Finding the tangent slope is referred to as taking the derivative of the function.

Thus: dy/dx = derivative of function = rate of change = slope of function at a specific value of x.

Functions and Graphs

Two for the price of one tonight because I'm anxious to get the the good stuff. Again, stick with me here, but you can skip the stuff after linear functions if you want to. I'll let you know when it's okay to go.

A function expresses the dependance of a variable on one or more other variables. For example, consumption is a function of disposable income, wealth, etc.

We write: y = f(x) to indicate that the variable y is dependent upon the variable x. Note that we do not yet know in what way it is dependent until the function f is defined. Since our goal is to find the exact nature of the dependence, we will need to examine the specific form of the function.

Y may be linear, quadratic, cubic, quartic, etc.

Linear functions have the form y = a + bx, where a is the intercept and b is the slope.

Example: y = 4 + 0.5x



The term b is called the slope of the line. In this example it is 0.5, meaning that as x increases by 1, y will increase by 0.5. You can see y increasing by 0.5 for each increase in x in the chart above.

Okay, you can leave now if you have had enough. Don't worry, missing the rest won't affect the rest of the series; I just added it for completeness.

Multivariable linear functions are linear functions having more than one term, as in: y = a + b1x1 + b2x2 + b3x3 + ... + bnxn

Quadratic (2nd degree) functions have the form: y = ax^2 + bx + c.
Example: y = 2x^2 + 3x + 5

x  y
0  5
1 10
2 19
3 32
4 49
5 70

This equation makes a parabola; that is, it is not linear. All equations of this form have two solutions.

Cubic functions are similar to the quadratic, except that they contain another term, and the first term is cubed instead of squared.

Example: y = x^3 + 2x^2 + 3x + 24

 x   y
-5 -66
-4 -20
-3   6
-2  18
-1  22
0  24
1  30
2  46
3  78
4 132
5 214
6 330
7 486

Tips on Handling Equations

Continuing the math review. Math phobics, stay with me here. It's not hard, and the payoff will be worth it.

1. If a variable is on both sides of the equation, as in: 24 - 4Q = 4 + Q. Since the two sides are equal, subtracting one from the other yields zero, so we can rewrite the equation as (24 - 4Q) - (4 + Q) = 0 and solve for Q.


2. Two simultaneous equations: C = 1200 + 2Q and C = 4Q. Since both equations are equal to C, then 1200 + 2Q = 4Q, and this becomes the same problem as (1).


3. Q/2 can be rewritten as 1/2Q or .5Q


4. If the variable you want is negative, rewrite the equation by changing all the signs. Example: Solve P = 24 - 2Q for Q:
   P = 24 - 2Q
   P - 24 = -2Q
   -P + 24 = 2Q
   24 - P = 2Q


5. An equation of the form (a - b) - (c - d) can be rewritten as: a - b - c + d. Think of the second term as -1(c - d), which can be rewritten as -c + d.

Business first!

Today we start a series on pricing, revenue, and cost. Why? Because we are business people first, then IT people.

We start with a little math review

• The associative property: (A + B) + C = A + (B + C)
• The commutative property: A + B = B + A
• The distributive property: A(B + C) = AB + AC

Free Leadership Books

On-line here. the quality is mixed, but there's some good stuff.

Some much needed time off

I took some time off for a quick trip to London with the family. Pictures are posted on Flickr.

What would you do if it was your company?

IT people seem to operate in their own world of bits and bytes, isolated from the rest of the business.

Technology becomes our primary focus and we lose sight of the business need.

But our work happens within the larger context of profit and loss.

For example, delays in the monthly billing run mean delayed customer payments -- resulting in higher accounts receivable and days sales outstanding.

This impacts the quarterly financial statements, affecting investor's decisions, lines of credit, and the like.

So think like a businessman and remember that bits and bytes affect the dollars and cents.

What would you do if it was your company?

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

Making your Point --Part II

Who is your target for persuasion?

It may not be the C-level execs.

Instead, find the people who influence them.
They're who you want to persuade.
Otherwise, they could be working against you.

Get them to work for you.

Then they'll persuade the target.

Making your Point

How do you make your point?

There are two schools of thought.

One school holds that you should present your weakest arguments first, and build to your strongest so that your point becomes better as you go along.

Wrong.

In any presentation you must establish credibility immediately.
You don't want your audience to feel any risk in buying in to your point.
If you start with your weakest argument, it will be instantly attacked and you must defend.

The audience will feel risk they won't forget it no matter how strong your later arguments are.
That ruins your credibility.

Start with your strongest arguments.
This sells people on your point right away.

Then follow up with the weaker arguments.
They will be seen as correlating evidence.

That removes risk for your audience.
Your credibility is demonstrated.

Your point is made.

Read the meeting minutes!

Taking over a troubled IT project means dealing with people who are not happy.

Not happy.

They are interested in getting their problems straightened out as quickly as possible.

So are you.

But you are also interested in establishing project controls.
So no more promises to make unreasonable dates.

They will insist that you commit to dates even before you know whether it's possible.
Sometimes they publish minutes of meetings committing you to dates that you have not agreed to.

Why?

They hear what they want to hear, not what you said.

You must read the meeting minutes and immediately respond with corrections.

Otherwise you are committed by default.

Then it's you who are not happy.

Hammock tasks

Every project has them.

You have them too.

Tasks in a project whose duration depends on the duration of two or more other tasks.

They are called "Hammock Tasks".

Take for example the activity "management reporting". This is a task that starts at project initiation and will last until project closure. Once you enter this task, and you decide that one or more other tasks need a different duration, you always have to adjust the reporting task again.

Microsoft project can be made to adjust these tasks automatically in your plan by pasting the start and finish date fields of the task as links.

You copy the date from the referenced task, paste special and then select "link" to paste this value in the hammock task date value.

More information is available in the Microsoft Knowledgebase.

Stakeholder analysis

Mindtools has an article about stakeholder analysis.

I was interested in the Power/Interest grid referenced in the article.

I forwarded it to my boss at work.

His response:

"The article assumes that stakeholders are supporters or can be made supporters. This is not always the case. In critical situations, you have to undermine and remove 'blocking' stakeholders if the normal process fails. In some circumstances 'The Prince' is a more appropriate management style."

Ouch!