Google





Classic Mistake #3: One Size Fits All

Luc K. Richard
January 1, 2005

Project plans are vital to determine the cost of a project and control its execution. However, in order to accomplish these two goals, plans must be fairly precise. A project schedule that's +/- 10% accurate is extremely useful to the management team because they can correctly estimate the cost of a project and its release schedule. On the other hand, a guesstimate that's +/- 30% accurate serves no real purpose.

One of the most common problems for overly optimistic project schedules is the project manager’s failure to account for all the activities required to complete the project. While most technical project managers are fairly precise at estimating the effort required to implement a specific feature, many can’t accurately determine the overall duration of a larger software development project. Their Gantt charts highlight the core activities required to complete the project, but neglect to account for the derivative tasks that take up a good portion of the developer’s time.

Core Activities

By core activities, I mean actions or deliverables typical of 95% of the project plans, such as:

While these activities typify the major milestones of most software development projects, they're certainly not all encompassing. Let’s look at a practical scenario we can all relate to.

Mike, one of Red's senior software designers, is in charge of implementing a new feature for the next release of the product. That feature is on Red's project’s critical path, but Mike is one of his most reliable designers and more importantly, he's very precise whenever he's asked to size a feature. He tells Red he can implement and test the feature in 2 DPM's, and Red is confident in this estimate. He therefore adds 8 weeks to his project schedule, and communicate the release date to the senior management team.

One and a half week in, Mike catches a serious case of influenza, and is forced to miss 3 days of work. Knowing that Mike is a hard-worker, Red knows Mike's going to make up for the lost time. He's never let Red down before, and our project mangler is positive Mike won’t let him down this time either.

When Mike comes back on week 3, he's feeling as energetic as ever. He even spent time over the weekend thinking about his feature, and has come up with a solution that will speed up the implementation.

Come Friday, Mike reminds Red that he's taking next week off to go on vacation with his family. Red had totally forgotten about this vacation, which had been booked three months earlier. Since our PM neglected to include it in the project schedule, he's now faced with a choice; slip the release by one week, or hope that Mike, being the reliable designer that he is, will work extra hard when he comes back from his vacation so that the software meets its release date.

Monday morning, week 5. Mike comes in an hour early to check his emails before getting back to his regular routine. One of his emails is marked as urgent. A lead customer has just deployed the last release of the software and is having a problem with the feature Mike had implemented. That customer has installed the system over a network topology that had not been considered during the initial design. It’s imperative that this problem gets resolved ASAP, and Mike, being the best designer and the only one familiar with this feature, is the best candidate to fix it. He's convinced he can resolve the problem within a week, and he's right. That Friday afternoon, the patch is being installed on the customer’s site, and everyone is extremely happy. Everyone except for Red who realizes that his release is scheduled to be shipped in 3 weeks, but Mike still has 5 and a half weeks worth of work on his feature.

Mike spends the next 5 weeks working extra hard. He even voluntarily comes in on a couple of weekends, and works until midnight most of the last week to fix a defect he found during his feature testing phase. Mike is very proud of his accomplishment; he's completed the feature in 7 ½ DPM's instead of the 8 he predicted, and can claim that he made up for his 3 sick days. He's aware that the schedule has slipped by 2 weeks, but whose fault is it if the project schedule didn't account for his vacation? Additionally, he's not the one who opted to spend a week fixing a software defect in the previous release.

Sounds familiar? Of course it does.

Derivative Activities

Mike was very accurate in the effort required to implement his feature. What wasn't accurate Red's estimation of derivative activities; less obvious activities that are not always directly linked to the project itself, but that are nevertheless required, such as:

While it’s easy to assert that derivative activities should be accounted for in your project plan, reality is, it’s not that simple. You can certainly plan ahead of time some tasks such as the development of upgrade scripts, or knowledge transfer sessions, but even the best project manager can’t determine up front when a designer will call in sick, or when the daily build will break. Nonetheless, if you're an experienced project manager, you should be able to predict how much time, statistically speaking, will be spent on such activities. This aggregate time should be included in your project plan as a buffer, which should:

If you know that your designers will have to spend 5 DPM's fixing defects in your previous release, include that activity in your project plan as a separate WBS (Work Breakdown Structure) element. Do not include it in your buffer. Buffers are not meant to increase the schedule to account for project risk, and they're certainly not there to pad the plan so you look like a hero when you deliver the project ahead of schedule. They exist to account for derivative activities – activities that cannot be scheduled up front, but can nevertheless be guesstimated based on your previous experience.

Make sure you next project plan accounts for both core and derivative activities. Its accuracy will significantly improve, and so will your reputation as a project manager.