When IT goes bad ...

Project costs not adding up correctly?

2008-10-22T19:22:00.009-04:00

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

2008-09-10T20:18:00.006-04:00

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

2008-09-01T09:03:00.000-04:00

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

Assumptions are Risks

2008-08-11T13:00:00.000-04:00

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?

2008-08-10T21:29:00.002-04:00

The "alphabet soup" - EV vocabulary is not intuitive.
Overcoming the tendency to measure received value as effort instead of results.
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

2008-07-09T18:46:00.002-04:00

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:

Copy the XSL code from the Freemind SourceForge page and save it to a file such as mm2project.xsl.
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.
In Freemind, select File --> Export --> Using XSLT ...
Browse for the XSL file (mm2project.xsl) in the "choose XSL file" field.
Browse to your target folder and name the exported file, such as project.xml. Note: The filename must have a .xml extension.
Press the Export button to create the export file.
Open the file with MS Project (using File --> Open ...).
Follow the MS Project dialog to open the file.
"Save as" to the standard .mpp format.

What Goes into the WBS - Part II

2008-06-12T20:13:00.005-04:00

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?

2008-06-05T19:43:00.005-04:00

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

2008-06-04T21:29:00.000-04:00

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

2008-06-03T21:24:00.002-04:00

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

2008-01-14T19:30:00.000-05:00

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?

2007-11-13T20:33:00.000-05:00

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

2007-10-28T12:45:00.000-04:00

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

2007-10-27T19:36:00.001-04:00

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

2007-10-27T19:32:00.000-04:00

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

2007-10-19T20:08:00.000-04:00

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.

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

How many questions can you think of?

Don't use task dependencies to model resource constraints

2007-10-17T21:06:00.000-04:00

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:

Define the activities - What needs to be accomplished in order for this project to be successful?
Sequence the activities - In what order - if any - do these things need to happen?
Identify activity dependencies (AKA "predecessors" ) - Is it necessary for one activity to complete before another can begin?
Estimate activity effort - Given known resource capabilities and constraints, how long will it take to complete this activity?
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

2007-10-13T20:38:00.000-04:00

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

2007-10-13T09:23:00.000-04:00

"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

2007-10-12T21:00:00.000-04:00

Multiple versions of requirements documents distributed via email.
Key project resources not having documents or not having the latest document revisions.
Documents not updated to reflect correct requirements status (e.g., descoped).
Requirements buried in hundreds of pages of dense paragraphs of text and hard to identify.
No common understanding of the requirements across teams.
No agreement and signoff with the customer.
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.
Changes to the requirements distributed as text in email messages.
Design components and solutions provided as business requirements.
The requirements are "just changes from what we have today," but there is no baseline against which to compare the changes.

Planning for Politics

2007-10-11T19:22:00.002-04:00

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:

We had no credible plan, but we were held to it as we executed the project.
The swap caused the project with extra resources to go over budget.
During project reviews, it was difficult to answer questions about actual resource allocation, since it did not match up with the plan.
It was dishonest. I needed to ask other people to modify the plan to show a project need that differed from reality.
It lowered the morale of people who were asked to build and execute a plan they knew was not real.
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

2007-10-02T23:16:00.000-04:00

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?

2007-09-26T19:54:00.000-04:00

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.

2007-09-25T22:28:00.000-04:00

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

2007-09-21T19:41:00.001-04:00

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?

2007-09-20T18:42:00.000-04:00

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

2007-09-19T19:36:00.000-04:00

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

2007-09-18T20:20:00.000-04:00

"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

2007-04-03T19:46:00.000-04:00

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

2007-03-28T20:03:00.000-04:00

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

2007-03-24T09:06:00.001-04:00

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:

EV calculations are time-boxed, in these examples, weekly.
Calculate EV only for completed tasks, not work in progress.
EV can never be greater than PV, no matter what the AC.
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

2007-03-17T07:41:00.000-04:00

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:

A weak matrix organization is structured around functional teams, not projects.
Resources are assigned by RM's; the PM does not interview candidates or select resources during project initiation.
Resources are allocated to projects part-time, and the PM has no view into their other responsibilities, and does not set their priorities.
RM's, not PM's deliver the project WBS and estimates for their areas.
The PM does not influence performance reviews. Resources are loyal to their direct line manager, who is the RM, not the PM.
Functional teams may have their own internal processes over which the PM has no influence.
RM's, not PM's, usually approve timesheets, meaning RM's ultimately control the project budget.
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".
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).
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

2007-03-09T04:22:00.000-05:00

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

2007-02-27T20:02:00.000-05:00

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

2007-02-25T09:30:00.000-05:00

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

2007-02-20T14:30:00.000-05:00

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?

2007-02-20T05:21:00.000-05:00

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:

Unclear goals and objectives
Scope creep
Unrealistic timelines
Lack of executive support
Lack of user involvement
Poor requirements
Poor testing

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

Biweekly vs. semi-weekly

2007-02-20T05:06:00.000-05:00

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

Export Outlook Tasks as XML

2007-02-11T03:56:00.000-05:00

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

Big Important Egos

2007-02-03T02:14:00.001-05:00

I sometimes suggest communication or escalation to the executive level to handle problems with uncooperative teams. Certainly, you want to be in frequent communication with senior management on the status of your project, and this is especially true in a project recovery situation since such projects are often politically charged and very visible.

However, it is often true that senior managers have very large egos. This can manifest itself in a couple of different ways, most often by executives wanting to guide you on managing your project by giving advice on next steps, or by finding something you don't know and "teaching" you about it.

Some rules for handling Big Important Egos:

Let them talk. Sometimes these guys are just a faucet of words, but it's better for your career longevity not to interrupt. Plus, they might actually be right and you could learn something. Worst case, you'll learn what mosts interests them, and you'll gain insight into their concerns.
However, since a lot of them came up through the ranks in the 70's, or 80's, much of what they will "teach" you is outdated or just plain wrong. Where you know they are wrong about something, do not overtly correct them, especially in a meeting with others present. It's better to ask carefully worded questions, and guide the conversation in the direction you need.
It's not just what you say, it's how you say it. Avoid open-ended questions that can make them think you do not know what to do next. This opens the door to "lecture mode".

Weak Matrix Organizations (Part 2)

2007-01-27T03:10:00.001-05:00

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

2007-01-19T14:46:00.000-05:00

If you are taking MBA classes in which

The professor asks you to work in teams and working in teams, and
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:

Meeting minutes and status reports - make sure to name those present, those who have conveyed apologies, and those with unexcused absences.
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

2007-01-13T08:25:00.000-05:00

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

2007-01-07T10:29:00.000-05:00

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

2006-11-11T08:00:00.001-05:00

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?

2006-11-11T07:52:00.001-05:00

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

2006-11-04T02:10:00.000-05:00

Prepare for every interaction.
Succeed with a nasty project. Example: SARBOX.
Don’t have control? Use influence! Make a case. Go back to common language: dollars, business logic (choices).
Participate on collaborative projects to become known outside your group.
Prove your abilities before asking for the job.
Take the lead if there is no one there.
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

2006-10-28T15:10:00.000-04:00

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

2006-10-23T21:11:00.000-04:00

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.

Handling Name Droppers

2006-10-14T09:31:00.000-04:00

People will sometimes mention the name of highly-placed managers or executives in order to apply pressure on you as a project manager. You'll hear "Mr. Big is watching this closely," or -- my personal favorite -- "this will be escalated to Mr. Big."

My response: "So what?" The worst thing that can happen is that Mr. Big fires me, which I'm not worried about because I am confident that I am handling the project correctly, and I'm happy to discuss the situation with him. I also realize my direct manager can also fire me, so there is really no difference between the two, which further reduces the threat of Mr. Big.

Then I realize something more: Name droppers drop names because the technique works on them, and they figure it must work on everyone else. So now I have some interesting information about that person that might be useful in the future.

Tactical vs. Strategic Solutions

2006-10-07T08:52:00.000-04:00

Try shifting your thinking from a tactical to a strategic level to help solve problems.

Let's say that you are having relationship problems with the business, and at the same time you are charged with reducing IT costs. Rather than solving both of these separately as tactical problems, consider that there may be a strategic solution that solves both problems simultaneously. For example, outsourcing your IT function solves the relationship problem (or at least shifts it elsewhere) and could also reduce costs.

Viral marketing

2006-09-26T20:41:00.000-04:00

Too bad common sense isn't viral!

Not everything is front office

2006-09-25T10:12:00.000-04:00

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

2006-05-03T14:27:00.000-04:00

Reading list for today's MBA:

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

Others?

Oops!

2006-04-29T03:15:00.000-04:00

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

2006-04-21T01:00:00.000-04:00

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.

2006-04-19T15:29:00.000-04:00

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

2006-04-15T13:30:00.000-04:00

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.

Reporting Bad News? Or Not ...

2006-04-13T14:26:00.000-04:00

You just got some bad news.

It doesn't affect the critical path.

Should you fix it?

Yes.

Should you report it?

Maybe not.

It just makes things look worse by adding to the problem list, and fixing it will not affect the outcome of the project.

You don't want to hide things.

But a little prudence is sometimes a good idea.

Break Even Point

2006-04-11T13:00:00.000-04:00

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

2006-04-10T16:27:00.000-04:00

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

2006-04-09T04:24:00.000-04:00

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

2006-04-07T13:59:00.000-04:00

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

2006-04-06T13:19:00.000-04:00

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:

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

2006-04-05T13:33:00.000-04:00

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:

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

2006-04-04T11:50:00.000-04:00

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

2006-04-04T11:45:00.000-04:00

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:

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

2006-04-03T14:29:00.000-04:00

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

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

Tips on Handling Equations

2006-04-03T14:14:00.000-04:00

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

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.

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).

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

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

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!

2006-04-02T03:51:00.000-04:00

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

2006-03-11T07:11:00.000-05:00

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

Some much needed time off

2006-03-06T16:12:00.000-05:00

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?

2006-02-24T13:35:00.000-05:00

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

2006-02-24T13:02:00.000-05:00

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

2006-02-21T15:05:00.000-05:00

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

2006-02-19T12:38:00.000-05:00

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!

2006-02-15T16:30:00.000-05:00

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.

Getting cooperation

2006-02-04T07:11:00.000-05:00

Can't get team members to respond to your requests for estimates?

I usually follow a three-step process:

Ask informally
Ask formally with a date by which they must respond, or I'll decide for them
Decide for them

Getting to step 3 has the effect of committing them to the project plan without their input.

They complain.

But they gave up the right to complain when they did not respond to my requests.

Next time they'll get me the information I need.

Hammock tasks

2006-01-29T08:51:00.000-05:00

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

2006-01-20T15:31:00.000-05:00

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!

Project assessment report

2006-01-14T12:49:00.000-05:00

Years back, I took over a project when the PM left the company abruptly. Following is part of an assessment report I did at the time. A report like this is a structured way to evaluate the state of the project and issue reports to the execs.

Names have been changed to protect the innocent.

Goals of the assessment:

Determine the status of the project, and implement corrective actions if needed.
Keep development and testing moving forward during the assessment effort.
Develop a go-forward plan for completing the project.
Determine the state of existing systems, evaluate whether current support levels are adequate, and implement corrective actions if needed.

Initial tasks:

Keep the project and team moving forward.
Ensure that everyone involved agrees on and is committed to the same objectives.
Ensure that there is a development process in place, and that the process makes sense for this project.
Evaluate the preceding technical work for appropriateness and quality.
Assess existing estimates for completeness and accuracy.
Compare the state of progress with the project plan to determine whether there are cost or schedule overruns.
Uncover hidden issues, such as low team morale.

Factors to evaluate:

Lifecycle management - Appropriate and correct use of version management tools
Requirements - End-user agreement to a controlled, stable, and traceable list of requirements, and developer adherence to them.
Design - A competent, flexible design that utilizes industry standards and best practices in order to provide reliability, scalability, performance, and maintainability; and user acceptance of the design.
Development - Coding standards, code reviews, and user reviews of completed modules.
Test - A comprehensive test plan, unit, system, and integration test cases, reviews of test cases.

Assessment schedule:

Week 1: Evaluate design and development methodology - COMPLETE
Week 2: Evaluate scope of work, the current schedule, and percent complete - COMPLETE
Week 3: Evaluate the condition and status of the existing system and its ongoing maintenance needs - COMPLETE
Week 4: Establish a new project plan, including schedule, budget, and a risk management plan - COMPLETE
Submit assessment for management review -IN PROGRESS

Findings:

The project is basically healthy.
There is broad agreement by all stakeholders on the need for the project and its objectives.
The development team, although comprised entirely of contractors, is enthusiastic and committed to the success of the project.
The lifecycle methodologies, technologies, and designs used are appropriate and necessary to the success of the project.
The Quality Assurance tools and techniques employed by the team are excellent, and are ahead of the techniques used by most other teams.

Project status by SDLC:

Requirements - GREEN
Design - GREEN
Build - GREEN
Test - YELLOW
Legacy system support - YELLOW

Risks:

Etc.

Risk mitigation strategies:

Etc.

Revised project plan:

Etc.

You are not productive

2006-01-06T17:46:00.000-05:00

Do I have your attention?

The cultish GTD.
Lifehacker.
Dave Seah's The Printable CEO.
Steve Pavlina's post on prioritizing.
Covey's 7 habits.
Aaron Swartz's post on productivity.
Etc.

These guys are all talking about behavior modification.
Your behavior.
"If you just change this and this, everything will be okay."

But there is something wrong.
They assume that everyone else in your organization is also changing their behavior.

They aren't.

Your colleagues will continue to interrupt you.
Your boss will continue to interrupt you.

And there's nothing you can do about it.

Therefore ...

Time management is a myth.
You can only manage what you can control.

And you can't control much of your time.

Modify your behavior all you want.
It won't matter.
Because you can't control your colleagues.
And you can't control your boss.

So what can you control?

Read this brilliant 1974 Oncken and Wass article in HBR.

You have three types of time:

Boss-imposed time - taken up by tasks your boss wants you to do with immediate penalties for non-compliance.
System-imposed time - taken up by support for colleagues with eventual penalties for non-compliance.
Self-imposed time - taken up by your own projects with no penalties from others.

You can't control boss-imposed time.
You can't control system-imposed time.
But you can control self-imposed time.

Self-imposed time is made up of two things:

Subordinate time -- time taken up by subordinates who make their problem into your problem.
Discretionary time -- everything left over.

You want to maximize discretionary time.
That's time available to you to do what you want.

So you have to minimize your subordinate time.
By managing your subordinates.

Your boss will take your time.
Your colleagues will take your time.
Deal with it.

Your subordinates will take your time.
Don't let them.

They will try steal your time by making their problem your problem.

Do something about it.

Think about their ratio of input to output.
What is your volume of input compared to their volume of output?

Oncken and Wass say there are five levels of initiative:

Wait until told what to do (lowest initiative);
Ask what to do;
Recommend, then take resulting action;
Act, but advise at once;
Act on own, then routinely report (highest initiative).

If your subordinates wait until told what to do, you can't use them.
Your input is too high.

If your subordinates ask what to do, you can't use them.
Your input is still too high.

These are people who come to you with problems expecting you to solve them.
If they don't come to you with a solution, they are just complaining.

Complainers take up time.
Your time.
You can't use them.

You want people who are at initiative level 3 or above.
That's lower input from you.

So, increase the ratio.
Get them there or get them out.

Communicate your goals.
Then let them run.

Then enjoy your free time.

And be productive.

Career Strategies -- Succession Planning

2006-01-05T14:05:00.000-05:00

Make yourself dispensable through succession planning.

Appoint and mentor team leads, or if necessary bring in an outside manager.

Then convince your manager that the team can run itself without your presence.

You are now free to look for other opportunities.

Traffic test on bridge

2006-01-03T19:21:00.000-05:00

A summary of two types of testing and their difference:

1. Performance test -- Bridge should be able to handle N vehicles per hour

2. Volume testing -- Put more and more traffic on the bridge until a traffic jam develops, then look at why: not enough lanes, lanes too narrow, too many turns, etc.

Classic "misteaks"

2006-01-02T18:24:00.000-05:00

Steven C. McConnell ~~posts~~ provides a list of the classic mistakes. Haven't read the book yet, but boy, I've seen these!

Scope cuts may not save time

2005-12-31T13:38:00.000-05:00

Brian Kennemer over at Projectified points out that scope cuts may not save time.

The thing that I have noticed people forgetting is that sometimes it takes time to NOT finish a feature. How is the feature or code you are pulling from the product linked or related to other features in the product? Do other features or parts of the application depend on code you plan on pulling or not finishing? Will it require you to rewrite other code to deal with the cut you want to make? Was the application designed in a way that will make this hard or easy? If you decide that you do need to make changes to other code to compensate for this cut has that code already been tested? Will you need to retest code because of this cut?

I would add a couple of comments:

The code management tool you are using (e.g., cvs, ClearCase) can make a big difference in the effort required to cut scope by cutting code. So long-term, you can save time by installing and using a good toolset.

However, if the code was built as class files with big giant methods this job can be very hard. A good architecture will help immensely with this task. Unfortunately, my experience has been that with projects in trouble, the architecture is usually very poor indeed.

Independence Day?

2005-12-17T02:51:00.000-05:00

Summary: Don't air your dirty laundry in public.

Watching the Independence Day movie the other day I was struck by the portrayal of military communications. When the spaceships are beginning to enter the Earth's atmosphere, and the submarine captain encounters one, he immediately "phones home" to his command to report what is happening and await orders.

What would have happened if he had not reported the situation, and taken some action of his own choosing?

This was interesting to me because I'm currently watching a colleague struggle to rescue a project and one of the key problems is that people at all levels feel free to communicate anything they want to the client. Sometimes, this is not a Bad Thing. But in this case, the project is in serious trouble, morale is bad, and the political situation is deteriorating, so the communications are of the sort "It's not my fault," "Nobody told me to do that," etc. Email makes this problem much worse, because it's so easy to CC reply all to a lot of people, including the customer (and executives!). Obviously, this is not the sort of communication you want your customer to hear.

In the beginning of the rescue, you need to control the message to the customer. To do this, have the project participants to communicate to the customer only through a single point of contact. Make a clear statement about communications rules, and articulate clear consequences for uncontrolled communication.

Later, you can have a PM and communications structure in place to handle these situations, so issues are reported to "command" in a proper way, and action can be decided and taken at the appropriate levels.

2005-12-03T03:13:00.000-05:00

Sometimes there are so many problems with a project that you can't seem to get anything accomplished. What should you focus on first?

This can be viewed as a multitasking problem. An analogy from the financial industry may be helpful here. Suppose that you have 5 credit cards that are all maxed out and every month you are paying the minimum balance owed. Obviously by splitting your attention across all five cards and simply paying the minimum balance, these things will never get paid off.

Usually there will be varying balances, so you can order the credit cards from least owed to most owed. If you can pay off the least owed amounts first, you can then apply the amount you are paying to that credit card to the next lowest balance, and so on, so the thing builds on itself.

The same strategy can apply to multitasking in a project environment. By trying to focus on too many things, nothing gets done. Try knocking off the small things first to get a little elbow room.

Project Turnaround Initial Steps

2005-11-26T06:07:00.000-05:00

Get a list of the outstanding issues. Talk to everybody. Chances are good that there is no single list of issues that can be prioritized and managed. This will take some time; be prepared to spend at least a few weeks getting this list together.
Create a plan from the prioritized list. Execute it.
Reset customer expectations. Do not try to deliver everything immediately -- this might be the reason that the project is in trouble in the first place. This step will lead to some very difficult and uncomfortable conversations with the customer. They are already unhappy, and will not be thrilled with your news that the project will be delayed even further. Take full advantage of being the "new kid on the block" if that's your situation (you can plead ignorance and be sympathetic -- for the moment, this mess is not your fault). Take some blame. Admit mistakes. Be transparent with your recovery plan. DO NOT SUCCUMB TO PRESSURE! AVOID RASH PROMISES!! If you give achievable dates and deliver, their attitude will slowly change, and it gets easier as things go along. Under-promise and over-deliver is the mantra here. If you fail to deliver, your customer relationship will get worse in a hurry.
Reset executive expectations. In particular, check the financials right away. If the project is already over budget, highlight the fact right away. If you delay this news by even a few weeks, it will become your fault. Same thing if the project is about to become over budget. Be aware that this step will almost certainly lead into discussions about how you should deliver with fewer resources, less time, etc. That prioritized list from step one and the plan from step two will save you here because you can defend your needs assessments.

How effective is your team?

2005-11-26T06:01:00.000-05:00

Summary: Use an effectiveness factor in your estimations

Poor estimations are a common reason for project failure and result from a variety of factors. A blindingly obvious but commonly overlooked fact is the fact that people are not 100% effective. If you put someone down for 8 hours of work per day, it is very unlikely that they are actually working productively for the entire 8 hours. 100 hours of effort do not translate into 100/8 = 12.5 workdays! Meetings, sick days, unplanned activities, staring out the window on Friday afternoon: these are all effectiveness killers. So many managers fail to account for simple things like this, setting themselves up for failure.

Consider putting an effectiveness factor into your calculations when planning. This example shows an the result of an 80% effectiveness factor:


Start date                    1-Dec  1-Dec
End date                     31-Mar 31-Mar
Workdays                         87     87
Work hours per day              8.0    8.0
Effectiveness factor            1.0    0.8
Effective work hours per day    8.0    6.4
Effective hours available     696.0  556.8

Estimated project hours       1,376  1,376
Estimated FTE's                 2.0    2.5

Without accounting for effectiveness, you are in danger of understaffing by 0.5 FTE.

Think about all the diversionary activities your team must contend with, and either get them explicitly into the plan, or roll them up into a effectiveness factor. Bear in mind that if the business sees a number like this, you will have some explaining to do, so in many cases, it's better to explicitly state them in the plan.

Change control: What is the ROI?

2005-11-23T21:00:00.000-05:00

A project I worked on recently had a horrifying characteristic: The business was asking for changes to the system (via a weak change request process) without providing any financial justification. The net effect of the weak process was that the IT department provided any change requested without anyone performing a cost-benefit analysis. As a result, the IT group was working very long hours to put out changes that, in the end, provided very little benefit to the organization. Among other things, this caused them to look extremely expensive, and ironically generated a number of comments from managers on the business side about IT costs.

Be certain that the projects your team works on make good business sense. You can use this to help pare down or at least prioritize your requirements list if your project is under time or financial pressure.

Is this thing on? Tap, tap! Hello?

2005-11-20T21:41:00.000-05:00

After a long absence, we're back on the air!

To ease back into things, let's take a look at a Conversations with Dale entry from a while back: Estimations are not Commitments.

The key statement from the post:

If you want commitments, don't ask for estimates. Ask for commitment.

Developers will tend to view estimates as commitments and pad their estimates anyway, but it's good to make it explicit.

Another thing to be explicit about when asking for estimates is effort vs. duration. Effort is the amount of work to be done over a duration of a certain time. A task or project may take say, 40 hours, but the duration will only equal the effort if two things happen:

The resource is 100% productive
The resource is not interrupted and can focus on this one task for its entire duration

Otherwise, the duration is always longer than the effort. Make sure you specify effort or duration when asking for estimates!

I'm still here!

2005-09-14T04:25:00.000-04:00

I got an email the other from my reader (hi mom!) wondering what's happening with this blog. I've been remiss, but I have a good excuse. I haven't blogged for a while because I'm in the process of relocating my family to another continent. For anyone contemplating a similar move, I can't recommend the process. But if you can bear with me, we'll return to our regularly scheduled program shortly.

The Joys of Leadership (2)

2005-05-14T14:00:00.000-04:00

Continuing with a discussion of William C. Taylor's interview with Ronald Heifetz:

That's the old definition of leadership: The leader has the answers -- the vision -- and everything else is a sales job to persuade people to sign up for it. Leaders certainly provide direction. But that often means posing well-structured questions, rather than offering definitive answers. Imagine the differences in behavior between leaders who operate with the idea that "leadership means influencing the organization to follow the leader's vision" and those who operate with the idea that "leadership means influencing the organization to face its problems and to live into its opportunities." That second idea -- mobilizing people to tackle tough challenges -- is what defines the new job of the leader.

This is something I'm learning first hand on a project in Europe. The management style required is very different from that in the USA. In Europe, it's a lot more about people relationships than it is in the States. That means the management team cannot go in with a "My way or the highway" type of approach. Instead, I find that my role is an initiator: I spot opportunities or risks, and then help the team talk through how best to take advantage or mitigate. My job is now more to help the team understand the business constraints under which we must operate and less to come up with the solutions myself.

Consider changing your leadership style but be alert to the danger that the team can talk ad nauseum while never arriving at a solution. This can and will lead to many unnecessary and excruciatingly long meetings after which nothing is actually decided.

The Joys of Leadership

2005-05-13T18:20:00.000-04:00

William C. Taylor over at Fast Company has an interview with Ronald Heifetz on the demands of leadership. An excerpt:

The role of the leader is changing, Heifetz argues. The new role is "to help people face reality and to mobilize them to make change." And making change is painful: "Many people have a 'smiley face' view of what it means to lead. They get a rude awakening when they find themselves with a leadership opportunity. Exercising leadership generates resistance -- and pain. People are afraid that they will lose something that's worthwhile. They're afraid that they're going to have to give up something that they're comfortable with.

This is so true of project recovery, where your role as a turnaround manager is to effect change in an intentional way. It's not all project plans and budgets.

A Plague of Locusts

2005-05-09T12:47:00.000-04:00

From Exodus Chapter 10 (King James Version):

"10:4 ... behold, to morrow will I bring the locusts into thy coast:

10:5 And they shall cover the face of the earth, that one cannot be able to see the earth: and they shall eat the residue of that which is escaped, which remaineth unto you from the hail, and shall eat every tree which groweth for you out of the field:

10:6 And they shall fill thy houses, and the houses of all thy servants, and the houses of all the Egyptians; which neither thy fathers, nor thy fathers' fathers have seen, since the day that they were upon the earth unto this day."

That's how much email I receive. It's a plague. It blots out the sun. Strong men quail, women scream, babies cry, dogs bark.

I'm increasingly convinced that email is the scourge of our era. Robin Allenson has a recent post about getting people to write succinct emails. ChangeThis.com has a very good article on managing email (warning: PDF). GTD practitioners recommend methods for keeping your inbox empty. Bert Webb over at Open Loops has a post on Chunking your Inbox.

And now there's this news.

Clearly, I'm not the only one with this problem.

I've noticed that the pattern of my email is that I receive many separate emails on many separate topics from many separate people. This makes it impossible to consolidate into conversation topics, so each email must be opened, read, and dealt with separately. There is no opportunity to gain any economy with this pattern. Like you, I'm busy, so I can't read emails every few minutes. Instead, I do it once in the morning and once in the afternoon. But I fall further and further behind as the week progresses.

About once per week, usually on a weekend, I try to get the inbox cleaned out by moving items to the task list or whatever, but I am rarely successful at this. Usually, I cannot summon the inspiration because I'm looking at a few hundred emails in my inbox. Figuring 3 minutes to deal with each one on average, times, say, 200 emails, that's 10 hours to clean it all out. Who wants to do that after a long week? Not me!

So I'm forced into a triage system in which I sort my inbox by sender name, and then read in this order: Wife, exec stakeholder, immediate boss, direct reports, the business, other. I also look for meeting requests, which will probably be the subject of another ranting post, because I have far too many meetings.

I'm not going to solve this problem here. Instead, I provide a quick VBA program to count the messages in your MS Outlook inbox and find how your senders are distributed. You can take the data and import into Excel or something to sort and graph, or whatever. I might build a better solution if there is enough interest.

This works for me, but you use it at your own risk. I also do not have any time to support it, so you're on your own. I am interested in bugs or mods though, so let me know.


Option Explicit

Sub Test()
Dim myApp As Application
Dim myInboxFolder As MAPIFolder
Dim myItems As Items
Dim myItem As Object 'Must be Object not MailItem if there are appointment requests in inbox
Dim firstOne As Boolean
Dim lastSenderName As String
Dim count As Long

'Point to inbox
Set myApp = Outlook.CreateObject("Outlook.Application")
Set myInboxFolder = myApp.GetNamespace("MAPI").GetDefaultFolder(olFolderInbox)
Set myItems = myInboxFolder.Items
Debug.Print "There are " & myItems.count & " items in the inbox folder"

'Sort by name
myItems.Sort "SenderName", False

firstOne = True

'Count up each name
count = 0
For Each myItem In myItems
   With myItem
       If .SenderName <> lastSenderName Then
           If Not firstOne Then
               Debug.Print lastSenderName & "=" & count
               count = 0
           End If
           lastSenderName = .SenderName
       End If
   End With
   count = count + 1
   firstOne = False
Next myItem

'Don't forget to report the last one!
Debug.Print lastSenderName & "=" & count
End Sub

Time for Tea

2005-05-08T10:47:00.000-04:00

"Good Heavens, it's 4 o'clock, time for tea."
"But this is an emergency, man!"
"Emergency or no, nothing should interfere with tea."

This is a snippet of dialog from an old David Niven movie, Around the World in Eighty Days. The movie itself was fairly bad, but this dialog, delivered by Mr. Niven with the inimitable British Dignity for which he was justly famous, has application to project recovery: Do not let things that are urgent distract you from the things that are important. See Stephen R. Covey for more on urgent vs. important.

Decisions, decisions

2005-05-06T08:43:00.000-04:00

In a project recovery, a huge part of your responsibility will be to effect organizational change. As a change agent, you will make many decisions, most of which will be scrutinized and criticized by the affected stakeholders, sometimes long after the decision was made. Chances of you remembering the details of the decision are remote.

Keep a record of your decisions. Who, what, where, how, why, when. This will provide traceability and accountability, and when you hand over the project to another manager, an historical record of the project.

One common approach is to create a project diary. However, this can be time consuming and difficult to maintain, because it is often hard to find the inspiration needed to write a diary entry after a long stressful day.

Norman Crouse over at Managing Today has been talking about decision making. He has an interesting post on decision records, which can be a simple form containing the salient points of a decision. This would be faster than a whole diary entry, but would still give you a useful record of your thinking behind the decisions you are making.

Travel much?

2005-05-05T08:03:00.000-04:00

For the past year or so, I've been flying back and forth pretty frequently between the USA and Europe. If you are flying a lot you may find this link helpful. If you're on 737's, check this out.

Bloglines UI considered harmful

2005-05-01T18:01:00.000-04:00

I've just started using Bloglines to subscribe to a bunch of feeds. In playing around with the service, I came to understand that I could make my list of feeds public. But how? The help says that for public sharing, you should make sure that your profile allows sharing. I click on the profile link, but there is nothing there that indicates how to set up sharing.

I finally found the answer here. It's buried deep in the comments, so in case you miss it, here is the salient point:

"The trick is Account > Blog Settings. Despite what the page says, the fields do not just affect blogs and blogrolls, but also public subscriptions. Enter a username and set the thing to “yes.” Et voila."

By "set the thing to 'yes'", he means "set show my blog" to yes. Even though I'm not using bloglines to host my blog.

I can't tell you how many hours I wasted on this. Hope I've saved you some!