"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