Development Schedules

I’ve been pontificating about the problems with planning project schedules lately.  Unfortunately, I’ve been involved with companies that have, for whatever reason, had schedules that were grossly unrealistic.  In more than one instance, management was claiming the project was only a couple months from completion when all of the engineers were openly stating that completion was a year out (note: these were both large IC developments so the year+ schedule isn’t out of the norm).  One might argue that schedule pressure forces people to work harder.  However, unrealistic schedules force inefficient choices to be made.

Consider writing some tool to make your development process more efficient.  It’s going to take time to write that tool.  If the amount of time your going to save having the tool is less than the time it takes to write the tool, it’s a net loss of time and not worth it from the perspective of time savings.

Let’s consider an example.  If it’s going to take a developer 3 days to write a tool and according to the schedule the task that the developer will be using the tool on is to be done in 10 days, that tool must save at least 3 days of work over the 7 days remaining to be a net time saver.  That means that in order for the tool to be worth the time investment that the developer must get done in less than 7 days what would have originally taken 10 days.  This would mean that the tool would have to increase productivity by >= 10/7 or ~43%.  That’s a fairly high bar so it’s probably better simply working less efficiently and forgo writing the tool.  Instead, the time entire 10 days should probably be spent on the actual development instead of a development tool.

However, what if the 10 days wasn’t realistic.  What if it’s really 20 days of work, but the ‘overly optimistic’ schedule pushes the developer to try to hit the 10 days.  What if the schedule had been more realistic and allocated 20 days ?  The 3 days spent developing the tool would only require that the tool increase productivity by 20/17 or 17% to break even.  It’s certainly more likely the the productive gain from the tool is > 17% than it is > 43%.

Scheduling is more of an art than a science.  If you’re doing truly new development, the time that a task is going to take is largely an unknown and any estimate is little more than a guess.  It’s important to have milestones and to have dates for those milestones.  However, if the dates are overly aggressive, it very possibly may result in the development taking longer than if the developers had been working toward more realistic dates and able to make proper time trade-offs.