Project Planning — Estimation (Part 1)

I’ve spent weeks thinking about this topic and can’t find an easy way to deal with it. So… I’m just going to dive in. As it turns out, a single article turned out too long, so I’ve split it into 2. This one will deal with context and overall approaches, while the second one, coming soon, will tackle estimation techniques for different activities within an IT project.

Estimation context

If, as a Project Manager (PM) you can’t estimate time, effort, budget… then you’re not much use to anyone, really. One of the most important tasks for a PM is to be able to give the customer (I use that term in all it’s flavours) some idea how long it will take, or how much it will cost, to undertake a piece of work, whether that’s the whole project, or just a piece of it.

At the beginning, there’ll be a period where this is ALL you’re doing. This is while you’re establishing the schedule, cost and resource elements of the plan (see here for a project planning overview). But the need for making good estimates continues right though to the end of a project. We’ll see why a bit later.

Basic estimation dynamics

So we need to understand some simple facts about estimates before we look at specific cases:

For most activities, the core number to determine first is effort. How much work will it take to get a particular task done? This is usually (but not always) measured in person-days: one person working for one day is one (you guessed it) person-day. Of course, even this simple measure hides lots of complexities. Do we mean 8 hr days or 6 hrs (to allow for other stuff)? Do we mean an “standard” team member (whatever that is)? The best? A grad? Whatever you decide, all effort estimates will need to be understood (and corrected for) based on these assumptions.
Of course, the effort required to do different types of things will need to be estimated in different ways — more on that in Part 2.
If it’s a simple task with one person working on it, then the duration (the time it takes to do the task, in work days), will numerically be the same as the effort. So… a 5 person-day task undertaken by a “standard” team member should take 5 working days to complete. Simple.
If it’s a large task, and you therefore assign more than one person to it, the duration should, in an ideal world, be equal to the effort divides by the number of applied-resources. Example: a 20 person-day task for 3 people should take just under 7 working days.
So you can see that effort, duration and resource-level are intimately linked by duration = effort / resource-level. This is a fundamental equation which lies at the heart of all project scheduling software, like Microsoft Project.

Adjusting estimates

In the real world, effort and duration calculations, even for simple tasks, need to be adjusted for different factors. For example:

Skill level of resource. This is probably the biggest factor. The best people can easily be 5 times more productive than the average team member, and maybe 10 (or more) times as productive as a newbie or a grad. So this will have a big impact on the estimates. Assuming that you work out your estimated effort on the basis of some sort of “standard” resource, you can correct for this in two ways: 1. Either you adjust the effort: AdjEffort = Effort / ProductivityFactor 2. Adjust the duration: AdjDuration = Duration / ProductivityFactor Both of these are, of course, equivalent. For a multi-person task, it might be easier to adjust the duration by some sort of average productivity of the people involved. You could get more mathematical than this but I doubt it’s worth it — there are too many other factors which impact the estimate as well.
Task size. If you’re looking at a large, monolithic task (eg. “Develop business logic”) then there’s a lot of internal complexity to be considered, and it’ll be almost impossible for anyone, even your most experienced practitioner, to give you an effort estimate with any degree of accuracy. You need to split this up into component tasks (making sure not to forget any) and estimate them separately. Then add the effort values.
Conversely, if you try to split the work into really small tasks (eg 1 person-day sized or less), then the uncertainty in the estimate of each task will overshadow the magnitude of the task itself, and you’ll have huge aggregate uncertainty values which will likely be unrealistic.
In my experience, it’s best to split the work into chunks of between 3–10 person-days effort. At this size, the overs and unders of sub-tasks will tend to even each other out a bit. Also, this tends to be a good conceptual task size which people can get their heads around (for estimating purposes) without too much trouble.
When looking at large, multi-person tasks, you’ll need to adjust for internal communication overhead. If we were looking at the earlier example of a 20 person-day task with 3 people, I’d tend to give it 8 days, rather than 7, simply because I know that 3 people will consume some time communicating with each other as the task progresses. This will also allow time for the occasional misunderstanding or disagreement on how something should be done. The more people involved, the larger this overhead will become.

Estimating effort — knowledge is power

When it actually gets down to looking at a task or an activity and trying to figure out how much effort it will require, your most valuable ally is knowledge about the job to be done. In turn, the most valuable form if this is having access to one or more people, hopefully senior, who have done this same thing, or something very similar, before.

These people are gold! Nothing beats direct experience when it comes to knowing how difficult a task will be and what sort of problems might slow you down.

At the very highest (and least valuable) level, you need to get an experienced practitioner of that task to estimate it. This means: getting a senior Business Analyst (BA) to estimate requirements tasks, a senior developer to estimate coding and unit test, an architect to estimate high level design and a test lead to estimate all post-unit phases of testing. If you’re not at least doing this, you’re just guessing.

To get the next level of accuracy, you should aim for domain and/or technology experience. For example, try to get a BA who has worked in that functional area and, preferably, for that business customer before. This person will then know where the complex business processes are and which parts of the business are difficult to deal with. When it comes to development, it’s critical to have someone who understands and has used the target technology, and where difficulties might be encountered.

In the same vein, you should try to get an architect who has worked in the target IT environment, especially if there are a number of other systems to be integrated. Understanding the nature of each of the other systems and the likely complexity of of the integration will be key.

Finally, an experienced test lead who has also worked in that target environment will be extremely valuable. Test difficulty can come from a number of directions: business process complexity, functional and performance constraints, integration complexity (not to mention orneriness of integration partners) and user co-operation and enthusiasm.

There could also be other tasks which I haven’t mentioned above, and for which you should also seek experts. These include (a) data cleansing and migration, (b) training, © security compliance, just to name a few.

It should go without saying that if you had to choose between two different experts, pick the one whose experience is closer to the specifics of the project that you’re about to undertake.

Finally, if you don’t have these skills directly available to you at this point in the project, then you should beg, borrow or steal them from somewhere. Do NOT attempt any sort of estimation (in situations where the numbers actually matter) without them!

Finally

That’s it for this article. I’ll look at how to estimate different software delivery tasks in the next one.