Now you can create nice spreadsheets with indices, draw tree structures that resemble your tasks, and what does this bring you? First of all, it brings you acceptance as a Project Manager. Project Managers are supposed to create such things. Many customers are not happy when their Project Manager doesn't show up with an Incredible Gantt Chart (preferably printed on A3, double sided).

Financial people want to see the numbers. What does it cost me in the end? They want to know as soon as possible. You can hit them now with the EAC. And, of course, the techniques are ok, they help you structure your mind, your information overload, your life.

Project progress reporting is only a nice job if you take care the expectations of the stakeholders are in line with the current situation. There is no such thing as good news or bad news. If you run over budget, that's bad news. If you stay under budget, that's for most companies also bad news; if you are a supplier and your consultants will do the job in less time then expected, you make less profit then expected, hence pissed stakeholders.

Extra pot of gold

Again, like the entire message of this book, take care of the stakes. It's not just the numbers, it's the consequence of what they represent that causes negative reactions of stakeholders.

With budgets the guy or gal responsible always has to defend changes to a higher level. Consider a system that will be build for a certain business unit A. Parts of the system build for them, will be used later by five other business units. At the start of the project, business unit A has a budget for the complete system. Of course, they run out of budget. Supplier and customer are rolling over the floor: "your fault", "no, it your fault", etc. No one wants to defend the overrun to the higher level in the company.

Suddenly, some one suggests to take the costs for the parts of the system that will be used by other business units also, out of the original budget, and create an additional "pot of gold" for it. After all, it's not fair that this one BU pays all the costs on it's own. Applause. This is something they can defend to higher level. Their budget remains unchanged (with no overrun) and a new budget is created. The numbers remain the same, the fact that more money will be spend than originally thought remains unchanged, but this is fair and no one looses face. Yep, I was there. Was not my suggestion, sadly.

Extra tasks

Imagine, in your project schedule you have planned "testing". Some stakeholders are highly committed to the deadlines for your schedule (they promised probably some one else). Your system will not be ready on this time for testing, at least not the entire system. You can propose to keep the deadline for "testing", and add an additional task after it called "integral testing" or "test it again, Sam". The stakeholders can remain their word (they just said "testing would be finished") and you have your extra time.

I am not claiming this works all the time. I'm just showing that you should be creative in the negotiation on budget and schedule.

You will need to talk with financial guys, so I spend a section on higher mathematics… Remember Dick? He was part of the budget to program some application: he was supposed to spend 5 days, with a total cost of $5000.

Suppose we schedule Dick to start on Monday and is planned to finish after five days on Friday. If you want to monitor the cost for Dicks' endeavor you just need to monitor the value of the budget: $5000, which is what is originally estimated. By the way, a complete budget, which is agreed upon by the customer is called a baseline. The budget might change due to discussions and new insight, however, the baseline can only chance after a signature of the customer. On Wednesday, Dick spend 3 days working on the stupid thing, so at that time the cost in reality are $1000 * 3 = $3000. This is the actual project cost.

Dicks' manager could yell now: "the job is 60% completed!" However, the correct phrase should be "we have used now 60% of what we originally thought (budget)". Looking at the bits Dick produced, reveals that he has only done 25% of the application. So, actually the cost should be 25% of $5000 (total budget of Dick) = $1250. This value is called in "advanced project management lingo" the earned value.

What is the progress? Well, 25% of the total work to be done. Used 60% of the budget and estimated time. The question that has to be answered is "how much will it cost in the end?", "when is it actually finished?" Dick will say, he will work harder, he will make up in time. He probably will. But, not so much that the difference between budget and actual project cost will vanish.

Enter the "Estimate at Completion" (EAC). This is a forecast of total project costs based upon how the project is currently doing, the project performance. It's something you have to calculate. Preferably with a computer. EAC is calculated by taking the total budget and divided by a performance factor (the cost performance index, which is Earned value / Actual cost ). This assumes that the percentage the project has overrun today is going to be the same percentage that it overruns at completion.

So, for Dick on this Wednesday, the following overview holds: actual project cost $3000; total budget $5000; earned value $1250; cost performance index 0.417.

Which brings us to an EAC of: $5000 / 0.417 = $11,990.41.

Dick's in trouble.

"This isn't a project plan, it's wallpaper for the Tardis you're going to need to meet these ^&*&%*& timescales."

"Why is it a programmer has these success stories on how he constructed in his free time the most incredible foo-compiler within 2 days? Without bugs? Why is it that the same programmer cannot finish a simple dialog for a payroll system within the agreed period? A period he himself indicated (which by the way he largely exaggerated)? If it isn't going to happen any way, why does a project manager bother planning programmers?"

Ok, the previous paragraph is meant in a provocative manner. But being a software project manager these questions cross your mind. And off course, there's another view on the subject, that of the programmer…

"Why do I have the following discussion over and over with the project manager: 'I told you it would take 3 weeks - why did you cut it to 2 weeks, just because it met the quarter reporting deadline'. Why do I have to tell you that your $%^&^ plan bears so little relation to the Babylonian calendar that the rest of the world uses that you must be a ^%%&* Maya."

I know why I need a planning. It is a useful tool to communicate the tasks, time scales and dependencies within a project. It's a way to indicate the agreements with several parties on when what is ready. But why should programmers be bothered with a planning? What are the effects on them handing over a Gantt chart? Is it the right way to communicate any way? What does a programmer want from a planning?

So, I posted on an internet discussion forum this simple question: "Can you tell me why you (as a programmer) need a planning?" This section reflects some of the answers and, of course, strongly my personal view on the matter.

Planning vs. schedule

I will use the term planning and schedule interchangeably in this section. Actually a planning can be a larger document with backgrounds, etceteras, and a schedule (tasks, person, time). However, large documents are never read, and everyone just goes straight for the schedule. So, in most cases just the schedule is provided. That's why we can use the terms, for the sake of this section, for the same item.

Agreement

When I order some furniture in Holland, the guys who will deliver the stuff at my home will send me a letter indicating which day they will come to my doorstep. The day for them starts at 8am and ends at 10pm. So, I take a day off and wait. Sit and wait.

Sit and wait is not my favorite waste of time. Especially on the job (I'm a fanatic, what can I say). For the projects I run, I will have some kind of planning, so I know when I can get my stuff to bring to the next guy. This next guy is also glad that I can tell him exactly when he gets the stuff he needs to do his thing. All in all, from my planning I can tell a lot of stories.

My storyboard in this respect might be a Gantt chart. I can send this chart to a fellow project manager, and he will immediately now what I mean. I use the chart also to put in how long and when a certain programmer performs a specific task. I do this to put our mutual agreement in writing. "How long will it take and when will it be ready?" "Well, it takes 1 week and I start on Monday." The Gantt will be used to let the programmer know I agree on what we agreed and let the rest of the world in on out little secret.

So, that's why I, a software project manager, send the programmer the planning in the first place. Why do I need a written agreement, and can't I be satisfied with just a telephone call? I wasn't even aware of the question, let alone the answer… But someone posted on an internet discussion forum a fairly good answer…

You need a schedule for the programmer, otherwise he will never do the job you ask of him. Remember the first paragraph with the foo-compiler and the payroll system? This specific programmer would rather be writing a compiler then creating a non-challenging dull dialog for the payroll system. So, if you let him schedule his own stuff (or no planning at all), he will probably do the things he really likes first, internetting, chatting or taking the kids to the zoo.

If you would approach this pessimistically, issuing a schedule is the only way to provide the project manager with some power; non-delivery of a product is something that can be proven easily, and is therefor a perfect form of surveillance on the programmer. And this form of monitoring is needed, otherwise the programmer just slacks off.

I'm not completely happy with this form of reasoning, it's to darn pessimistic. But, if we are looking for a short statement on reality, this one is fairly close to it. I want to communicate to the programmer our agreement. This is still the case. I'm only wondering if providing a Gantt chart is such a smart move. I'm curious how I will respond if he answers me with something in UML or Bachus/Naur form.

What this thing called 'planning'?

The software project manager walks into the room. Very proud, handing over his new, fresh Gantt chart. It's shiny. The programmer looks at it. Holds it up, against the light… The project manager wonders what the programmer is thinking.

"How do I read this? What is this?" The more experienced programmer goes straight to the second thought: "What happened to my numbers? I told him it would take 3 months, why did he slash it to 1?" Actually, this may not be a surprise if you think of the planning as a written agreement. The programmer first looks if it might have changed, by one party. The one who writes the document, has the power to change the text. And sadly, the 'text' of a schedule is very limited; there is no explanation on why things are what they are, why the estimate was changed. Decreasing someone's estimates of his own tasks, is a bad suggestion in the first place.

The handing over of the planning is the first form of feedback from the project manager on what he actually did with the estimates the programmer provided him earlier. If they're the same, the manager gained some credibility, if not, he's lost forever.

Focus on the past, not the future

But, this large chart, does it provide some use for the programmer, besides just the line with his own tasks? Yes it does… it can provide insight in the quality of preparations for his task. The tasks after him or not of much interest, but the past, what happened before is key.

Having the right preparations is essential. Without them "… the result is that when I have to do some work, I loose a lot of time getting the preparations done (that have been 'forgotten' to take place), talking to people that I need the results NOW, doing things myself because the right person has other priorities, etc. And the result of this is that other people come to me wanting results NOW for work I didn't know I had to do…", as one programmer puts it.

So what?

I hoped that I could say "we can throw the planning out of the Tardis, we don't need this thing". Sadly, we do. It's a way to communicate an agreement. However, if this way should be plotted on A1 with only a Gantt chart? I don't think so. I hate these charts anyway.

If you take all you tasks from the WBS, and your estimates how long they will take and, when they could start and finish, you have the ammunition to create one of the icons of project management: The Gantt Chart. It is a good way to visualize to information you have before you. And, because it's considered an Icon, using it in your communication will set some stakeholders at ease.

Related link
Burn-Down Chart Instead of Gantt
The Death Of Gantt Charts?
Reality Refuses To Follow Your Plan

Basically, a Gantt chart is an overview of tasks. You put weeks, days or months at one side, and the tasks at the other. You draw fat lines to indicate the period the task will be performed.

Put next to the task the name of the person who will do the job, and you come a long way in creating your Gantt chart.

Making A Gantt Chart With Excel (video)

PERT; almost as good as Gantt charts

If Sesame street has Bert and Ernie, Project Management has PERT and Gantt charts… PERT is a notation technique, which has a lot of fun features I will not discuss. The good thing however on creating a PERT chart is that you have to think about the relations between tasks. Can task X start before task Y? Do they have to end together? Must they start at the same time? etc. If you think in this way about your tasks you can create graphs like shown below.

Before you can pour your coffee, you have to get up. Before you can get dressed, you have to be up. You don't have to be dressed to pour the coffee. However, you have to be dressed and had your coffee before you can leave for the office.

Suppose "Pouring coffee" takes you 5 minutes, and "Getting dressed" 15 minutes. Suppose your wife pours your coffee. In that case the time it will take you to get up and leave home is the total time for "Getting up" + "Getting dressed" + "Going out". Say, that is 30 minutes.

As long as your wife stays under the 15 minutes, you have no delay. Only if she decides to make you an espresso, you are late. You see why? This is very useful information. Not for the example I used, but for the project you have to take on. It shows you who has to wait for who, and stuff like that. It shows that a delay of one task, does not automatically mean a delay of the entire project. All the tasks that have this property however, are called the "Critical Path". These activities have to be done sequentially, will take the longest in that time frame, and a delay in one of the tasks within the critical path, will cause a delay in the entire project.

Related link
Burn-Down Chart Instead of Gantt

"How long would it take you to walk the marathon?" If some one asked me this question, am I able to answer it? I never walked 42 kilometers, but I think so. I once did half a marathon, so I have some indication (believe me, this was years ago). I would just multiply that time by two and add a little thing. So, although I didn't do the job previously, I can give a reasonable estimation on the duration.

"How long would it take to make your own dress?" If some one asked me this question, I am in trouble. First, I would be worried by the question itself, and second, even if I tried, I would be unable to give you a proper estimate. I would know how to make a small web site. I would know how to make a excellent spaghetti. My best guess would be something in between the site and the pasta.

Yep, we are now talking all about estimating. So, pick up the dice, and start rolling them…

Getting an estimate

You created already a nice WBS and put some millstones (just kidding, milestones) in them. That's just fine. It is a nice structure, but it tells you nothing about the most important part of a schedule; time. Some one has to yell some dates, how long will it take, when can you start?

The best people to provide you with an estimate, are the people who will have to perform the task. First of all, they probably know what they are talking about. But most of all, it will be their estimation. Otherwise, if you have to work with the people later on in the project, and you provided the estimate, they normally will not agree and will not feel committed to do the work in your estimated time. Getting a good estimate from e.g. a programmer is not just a task for the programmer himself. The project manager plays a critical role in getting quality numbers. He has to talk with the guy (or gal), to see why he thinks it will take 7 days… Because he already walked half a marathon, or because he thinks a dress and spaghetti are the same to create. I know, I repeat myself. I already stated this before. But, just do it, for … sake.

So, the project manager is a kind of shrink for the programmers. That's right. They just have to kick back and tell what comes to their minds, and that's it. Yeah, right, duh! The programmer, in this case, should take steps to ensure that his estimates are getting more and more accurate. He can do this by keeping statistics on how much time he spend on what. How accurate were his previous estimates, etc.

I dug this quote up on an internet newsgroup:

"My experience is that people work to deadlines. If an engineer estimates a task will take 4 weeks, they do *not* mean 4×40=160 Hrs. They mean its feasible that it will be done 4 weeks after the start, and the Engineer will put in as many or few hours as necessary to get it done. On one hand, the Engineer will be factoring in such things as other workload going on, planned days off, etc. On the other, most people will underestimate the time it actually takes, and the experienced manager will know how to "pad" (or in some cases shrink) the estimate based on the track record of the individual."

Related links

If You Can Not Measure It, You Can Not Manage It

"Son, what do you want to be when you grow up?"

"Well, dad, I have no idea. Because I'm just 8 years old I haven't evaluated my options yet. Hormonal changes will probably alter my preferences and with the pace of development in technology, it's hard to say what kind of new jobs will emerge in the future anyway."

If your kid creates a sentence like this, be afraid, be very afraid…

A 'normal' child would just say: "Fireman, dad." Dad will smile, open a trust fund to put his son through college in the future, and will not slap him when on the kids' 20th birthday finishes his first year in medical school. That's a familiar situation!

Now Dad talks to his boss…

"Well, Project Manager (a.k.a. Dad), when will it be ready, and what will it cost?"

"Boss, I have no idea. The 'it' you are referring to is undefined, the requirements are changing. The responsibilities are unclear, new people are assigned to the project from the user groups every day. It's best I take it one day at a time, we go incremental. I can tell you what the first increment will cost and when it will be ready… but don't ask me how many increments it will take. If we ever finish at all."

Should be familiar also. Dad is a professional Software Project Manager, he knows Planning (capital intended) and has learned by experience that if he can't keep the promise, he will not provide one. Funny though, that the two 'familiar' scenario's involve the same man. Why it is funny? Even though he knows that the changes his son becoming an actual fireman will be slim, Dad is satisfied with the answer and saves money based upon whatever assumptions he has. He has no idea if his son will go to college, if so, when, and he has no clue what it will actually cost at that time. But still, he reserves money for the future of his son.

What might be Dads problem with 'it', which happens to be an information system? The answer provided to his boss is honest and probably the truth. However, his boss is not waiting for such an answer, he must have some statements to be able to run his business. So, even though his statements are true (let's assume), is it fair to claim that you have no idea?

Fair to whom? To himself… well, he made his point; he told the exact view he has in his mind. But is it fair to just consider his own well being? Should he provide some statements to his Boss although he is highly unsure? Actually, the overall well being of the company is also in Dad his interest; if it goes bankrupt, he has no job (and his son will have no college fund). To keep the business healthy, the Boss has to have some vision on the future… How long will my people be involved in this project (so, out of their day-to-day operations). How much money do I have to reserve for this endeavor (you know, income and expenses should be inline with each other to run a business)? So, in his own interest he should provide some statements, just like his Son.

Consider why his Boss needs the claims for the future. First of all to anticipate expenses and extra resources, but also, to determine the overall course. All related activities within the company should be in tune with the strategy of this project. It's like crossing the ocean, you don't have to know the exact path you will sail, but just knowing that you aim to hit the coast at the opposite side, will help you plan a welcome committee at the other end. Some kind of vision will help the Boss steer the complete business in a direction, which will benefit Dad, his project, and the stability of his job, so in the end will help raising his son

The Europeans discovered America by accident. When they sailed over the ocean, they sudden stumbled upon some land. The first times they encountered the native inhabitants they used rum to keep from being scalped. On their next journey they came prepared; they brought beans and mirrors to trade with the Indians.

So, the Europeans gave generously the mirrors and other colorful shiny stuff in exchange for the land. However, there was so much land and so much tribes to encounter, they had no idea how much to take with them. After some experience, the Spanish, Portuguese and the Dutch could give a good estimate how much to bring with them to take all the land. They evolved even some kind of metric: five beans for 5 square miles of land. The confiscation of land took a pace never seen before. Later on, they discovered that they could not take all the beans and mirrors they needed, so they took guns instead.

The less important lesson history is trying to teach us here, is that if you come prepared you are more efficient.

Show me the money… the project budget

To be able to give some statement on the financial state of a project, you first have to got a clue about the expected total amount you will spend, and to know where your costs are: which parts of your project require money?

To create such an overview, or to check an already existing project budget, you should take the WBS you constructed for the project. For every task (or group of tasks) you determine who will do it, and what is needed (in material) to do the job. E.g. "Programming the interface" will be done by Dick and he will need a PC, programming environment and a room to work in. For each person and material you need the units (man day, square feet, etc.) and the cost per unit. For the previous example you can get the following table:

For your project budget you have to cluster the costs that are similar in type. So hardware, software, infrastructure, personnel project costs (you know, the cost of Dick and the like) and training for example. This is to avoid having 20 pages of costs to get an overview of the budget, it's a kind of summary.

For more issues related to a software project budget, please read my total cost of ownership guide.

If you check your bank account, it's not because you want to see just the numbers; I assume that you are not a kind of number fetishist that gets his or her kicks from watching numbers on a piece of paper (if you are…. then these are especially for you: 633677290…. oooh, aaaah). With the state of your finance you can determine how much you still can buy, how much you can give away to charity, etc. It provides you info over how much you can satisfy your own stakes.

The project progress provides information for the stakeholders that issued requirements to the process, to the way the project is conducted. Although I encountered some financial people that come very close to fetishism, keep in mind during this entire section that it's not the numbers that are important, but the impact of the numbers on the stakes.

Road to nowhere

To determine the progress, in time and in money, you got to have some roadmap. For time this is a project schedule and for money this is a budget.

The project schedule itself is not that difficult; it's a list of tasks, start and end date, who will perform the task, what will be the effort. Getting the schedule is something else, but, as everything in this course, no rocket science. A good starting point for creating the schedule is the project strategy you created during the intake. You have some phases and you need now to fill in these phases with some details. And that's where the WBS comes in.

WBS does not stand for "What a BS", well … sometimes it does, but normally it's a "work breakdown structure". You take a piece of paper and you set on top of it the tasks you must perform. Under it you write the tasks that make up this higher task, it's actually a more detailed description of the first task. And you can do this for every other task, resulting in a nice tree shape structure of tasks.

How far in detail should you go? There is no definitive answer to this question. Enough detailed to provide you with insight in the tasks that have to be performed, but not to the level of tasks that will take 2 hours to perform. That kind of detail is too much, it can even get the flexibility out of your approach, if during the project you find out you forgot something, or things are not going as you anticipated. This is a mistake encouraged by some stakeholders who are happy to see a WBS of 15 pages, thinking that the project manager has anticipated everything.

I read somewhere this comment about a schedule of a project manager:

My personal rule of thumb is this: If I can't fit the key tasks and milestones on a regular size sheet of paper and still read it, it's time to delegate part of the planning.

Milestones or Millstones?

With the phases and the WBS you can construct a list of tasks to be performed. Picking the dates for the tasks is an estimation problem, which we will handle later on. But how do you handle a list of tasks? How do you control the schedule? The answer is to have milestones.

Milestones are events with a specific date in the schedule, that function like a kind of beacon. They represent a state of the project that is unambiguous. You are there, or you are not there. You know those computer games where you have to race and pass all these checkpoints within a certain time frame? In a project we call them milestones.

Actually, all there is to say about milestones is in the following quote from Brooks:

For picking the milestones there is only one relevant rule. Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness. Coding, for a counterexample, is "90 percent finished" for half of the total coding time. Debugging is "99 percent complete" most of the time. "Planning complete" is an event one can proclaim almost at will.
Concrete milestones on the other hand, are 100-percent events. "Specifications signed by architects and implementers," "source coding 100 percent complete, keypunched, entered into disk library", "debugged version passes all test cases". These concrete milestones demark the vague phases of planning, coding, debugging. (The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition)

In October 2000 I went for the first time to the US. Together with my then girlfriend, I flew to Las Vegas for a month's trip into Nevada and California. We married in Las Vegas and afterwards hit the road towards Reno, NV.

I had spoken to a lot of people before we took the trip. They told me "you can drive there for hours and don't see anyone". Being from Western Europe I thought "yeah, sure, right". In my area the best you can do is not seeing anyone for 10 minutes in the neighborhood of nuclear waste disposals. So, I hit the road Jack. Rental car, newly wed wife next to me, climate control to the max, Rick James funkin' from the CD-player, driving through Nevada. You know these postcards where you just see a road going straight to the horizon and then disappear, with nothing but nature next to it? That's what I got for two days.

When they mean nothing, they really mean nothing. I had most of the time no idea how far I was, how much time I needed for getting gas, coming to a town bigger then two houses. Just this one road, and once in a very long while you hit upon a landmark (e.g. old mine), and I was able to determine "ok honey, we can go to a bathroom within 2 or 4 hours." The advantage of one road is, you cannot go wrong. No exits, no decisions, no errors.

Driving from Las Vegas to Reno is easy compared to driving from my hometown to a customer I once worked for. It's only 50km distance, but full of turns and twists, detours and uncharted roads on newly built industrial areas. Every 500 meters you have to make a decision.

Driving Miss Project

Project progress is all about driving the project on the road towards its final destination. Where are we and how long do we still have to go? Attached to the answers of these questions are the requirements of the stakeholders towards the process of the project: Are we still within budget? Do we make it on time?

The project progress is an indicator relative to the path from the start to the estimated end, is an indicator where you are on this path, it's always a comparison between two situations, e.g. the start and the end. Project status on the other hand, is a description of a certain moment in time, it's a snapshot of a particular situation. Status is "we spend $300,-", progress is "we spend now 40% of our total budget, and we are on 30% of the total duration".

Feedback all over again

I hope you first read the previous chapter on requirements validation. There the issue was giving feedback on the product requirements. In this section the mantra is "giving feedback on process requirements". And frankly, the experience is that this particular feedback loop is the more appreciated one, it's high profile, if you really succeed in this one, your career is set. So, it's a good way of helping your own stakes.

In this chapter I will talk about schedules and budgets, just simply because it's the way to communicate the feedback on the project progress. I will even go this far in yapping on Gantt, not because "Gantt is project management", but just for the fact that it's an accepted way of communicating; most of the time it's even because some stakeholders do believe "Gantt is project management", and it's always easier to communicate within the expectation of the other party.

But remember, it's feedback time all over again.

Links of Interest

Executing The Plan
The 1:10:100 Rule
Project Management And Feedback