Thursday, June 14, 2018

leftovers: mythical man month - some thoughts on scheduling

No matter what precautions, safeguards, or techniques a manager uses to put together a project schedule, slips and errors are inevitable. A good rule of thumb to use for building the appropriate slack into the overall schedule is to devote the least amount of time to the most easily estimated parts of the project. (In software projects, coding time is easier to estimate than debugging time, for example.)

Schedules that slip a few minutes at a time tempt managers to drop everything and make up the schedule slip right away. A good manager will leave these little ‘catch-up’ exercises to the team, however, because the overall impact on the schedule is negligible if a schedule disaster strikes in the meantime that affects the timeline by hours or even days. The manager's job isn't to make up for lost time, the manager's job is to use foresight to prevent time from being lost in the first place.

One method to prevent against surprise schedule setbacks is to implement a strict quality control system. Without proper quality measures, projects may move forward with defective components. If these turn out to disrupt the efforts of subsequent project steps, it may require the redoing of several portions of the project. Poor quality could also cause especially large projects to bog down during the debugging step because larger projects tend to involve more test users and the number of bugs tends to correlate to the number of users.

It is vital to ensure enough time is scheduled for testing. Any delays at this stage are particularly costly because the project is likely fully staffed at this point yet there is little defined work for each member to complete. The temptation in such situations to skip quality control steps (like rerunning test cases) must be avoided, however, because failures at the testing step are handed directly to the consumer and this will turn out to be far more costly than a delayed release.