Creating a Project Plan (part 2 of 3)

Estimating Time is probably one of the hardest aspects of Project Planning. Typically, it is felt that most people are generally not naturally good at estimating time. However, with a suitable approach, most people can get over this challenge.

It helps to have accurate time estimates, but they don’t need to be perfect.

You’re trying to predict the future here, there is a great deal of uncertainty in predictions of future events. The worst thing you can do is spend time estimating time rather than doing anything else on the project.

If you, or your team have never delivered this type of project before, estimating time can be just plane difficult, but there are things you can do to help.

Clarify what you’re estimating

You’re trying to estimate effort rather than duration, this is subtle, but critical point!

For some, this may seem like semantics, but in Project Management terminology, the effort is how much time you need to work on something in order to complete it, whereas the duration is how long it’s going to take you to get around to doing it. This can be important when working with cross functional teams, many of whom may be working on other projects or normal daily business activities. It may take 8 hours of effort to complete the task, but the team are having to fit it around their other activities and they may only have 2x 4 hour slots spread over three days, the duration would be 3 days.

In order to understand the effort, the team needs to know how long this type of work normally takes and if this is the first time they’ve done this type of work, then they can base the estimates on some piece of work that is similar. If your research or the feedback from your team shows differing estimates of effort, take the average (median).

Unfortunately you may often find that people simply give you the maximum time they estimate the work to take. If you take every task at it’s maximum estimated time to complete, your project will slip far beyond the initial deliverable date.

When we consider time to complete a task, we need to consider the measure and in most cases estimating to person-days is sufficiently accurate. In fact, if you estimate to person-hours then you’ve gone into too much detail. For very large projects, you may sometimes see tasks broken down by person-weeks and occasionally person-months.

If you are still struggling, start looking elsewhere for an answer:

• Ask someone else that might know
• Model it against similar tasks
• Use available ‘rules of thumb‘
• Decomposition – break the task down into smaller tasks
• Assumptions – make them, but document where and why you made those assumptions.

Contingency

This is like that emergency cash you might keep tucked in the back of your wallet. You hope, and indeed plan, not to need it, but it’s there as a little safety net if you need it.

Contingency in Project Management is about tolerances, it’s where you make those ‘give or take xxx’ kind of statements.

How much contingency you set aside depends on the size of the project and the level of risk involved. Furthermore, contingency is not just about time, but also cost and sometimes quality. Some tips as follows:

• 5-10% variance for low risk projects
• 20-25% variance for higher risk projects
• 50% for very high risk projects, although you might struggle to sell that to your project board…

Ordering Tasks

Let’s say you’ve broken down your project into 150 distinct tasks, you could, if you wished, start them all on the same day. The project would merely take as long as your longest task. However, as it is unlikely you will have enough resources to work on all of tasks at the same time, you’re going to find that some tasks will need to wait until resources are free, and some are actually dependent on an earlier task. Understanding these limitations helps with task order.

Your task order should also make some consideration for external predecessors such as supplier provided items, or items that need to be manufactured. These external predecessors are beyond your control, you have no way of managing the internal processes of a third party. For these situations, you should identify these risks at an earlier stage of the project, long before building a Project Plan. Reaching out to vendors, suppliers, manufacturers or other third parties that you have a business relationship with earlier can help you plan for their long lead items when building the Project Plan. For example, if we know it takes 8 weeks to order a new Network Switch for the Core, then we need that to be ordered at least 8 weeks before the network team are due onsite to build out the core network.

When you start looking at the tasks and forming the task order, you will identify many tasks that can run in parallel, both the Server Team and the Network Team can work independent of one another, there remains a need for some order, but the server folks can physically mount servers whilst the network folks are building the core network, the server folks can continue with server build, configuration and testing whilst the network team move on to the access layer and start building out the switches in the communication closets, etc etc etc.

In part 3 I’m going to talk about People & Costs.