The.Steward.of.Time

One of the most challenging area in project management is managing timelines. Setting it too tight, you may end-up with an unrealistic timeline. Setting it too loose, you may cause the organization to lose its business opportunities. On most cases, timeline is nothing but a negotiation number between the management and project manager (PM).

PM says, "I think we need six months to complete this project.", Management says, "You only have three months." PM applies some gut-feel, factor-in some weekends and says, "At most, I think we can do it in 4.5 months." Depending on the Management, he may accept the timeline or may go further to press on his three months ultimatum.

This method of schedule estimation is flawed. Eventhough the PM won the 4.5 months despite sucessfully negotiated for more time, the estimation can still be unrealistic because none of the people doing the work were consulted. In this case, it is still a number plucked from the sky.

There are some PMs who came from software development background and can provide better estimates. "This module is very easy. I can build it in a week, so can you". Now this may sound sensible since the PM has software engineering experience but it is flawed as well. The reason is because it is the resource who is doing the work and not the PM. Considerations for different level of skill-sets eventhough similar must be taken into account.

So how can good estimates be derived? In reality, we can't. Estimates are just what they are - Estimates. However, a PM can still apply some good strategies to obtain near-realistic estimates. To do that, the first thing a PM should do is to consult the people doing the work, namely, the developers. However, in some cases, the developers may over-buffer or under-buffer.

When a PM asks a developer, "How long will you need to develop this feature?", the PM will most likely get what was asked for - the time to 'develop' the feature. Usually, I will remind my developers that they will need to factor-in the time to study and understand the requirements and also the time to test and fix any bugs. Therefore, the estimate should include the time for studying the requirements, developing, unit testing and debugging.

However, that still doesn't tell if a resource is over-buffering. Although we should always trust our developers but there is no harm to perform some verification. The PM can request a few developers to come up with estimates for the same tasks and evaluate them for cross-check-and-balance. In fact, using this method, the PM can even tell who can work on the task more efficiently.

With the estimates in hand, the PM can then present it to the management for review (or negotiation). Very often, the timeline will not be that attractive if there is a critical business problem to solve or an opportunity to capture. When under pressure, the PM should slash features and reduce the scope instead of squeezing the resources. It is always better to promise something that the team can deliver eventhough it may not be on the desired timeline rather than over-promising on an unrealistic timeline and then failed to deliver.

The PM should always keep weekend time and over-time away from estimates. It is never healthy to tell the resources that they have work over the weekends because of a promised timeline. This will damage the morale of the team and impact on productivity. However, if the timeline or estimate was promised by the resource, then it is the resource's responsibility to fulfill it.

The PM should be aware of the differences between effort and duration (timeline). While duration can be shortened, the effort to complete a task seldom can. Twelve hours to do a task can be spanned across three days, one week or be completed in a day but twelve hours is twelve hours.

To summarize, the PM should be a steward of time rather than a deadline chaser. A PM should present to the management in the form of "At the rate that we are going, we should be delivering on ..." and make proper adjustments to number of features or number of resources as needed.