Scheduling in the 21st century

Surprise! In the 21st century the art of scheduling - and the joys of creating elaborate Gantt Charts  - is becoming less and less relevant.


Why is this so?


Because  - at least in the software world - projects are being delivered continuously!


As soon as there is something to ship, it can be uploaded to the web, and as improvements are made, they can be tested and shipped as updates.

However, there still are some large projects that need industrial-strength schedules.


The easiest way to schedule a large project, is to find out when the boss wants it delivered. This way at least one person will be happy with the initial schedule. :-)


How long does it take to write new software? The real answer is: "we don't know", since this piece of software has never being written. If it had been, then we wouldn't be writing it again.


Experienced programmers do have an idea how long it will take them; experienced Project Managers will know how to gauge that estimate and how much padding to add to it.


Padding:

• When in doubt, simply double the number and add a week. "Many a true word is spoken in jest" aptly applies in this case.
• As a rule of thumb, (based on years of creating schedules,) I believe that 40% of anybody's time is unavailable. Be it vacation, holidays, parties, meetings, sick leave, miluim (as reserve duty is  called in Israel) and other reasons that prevent people from working on their project.
• The estimate you got always assumes they will be working 100% of the time. Always look at a calendar with all local holidays, check the company vacation calendar and speak to the resource in question.
• Even if there's 100% certainty that none of the above will interfere, you still need to add in 20% for the predictably unpredictable.
• An estimate will never include the following, which need to be added:
• Integration - unless your project is a standalone application implemented by a single person. Every milestone will require at least 1 day of integration, unless somebody can prove otherwise.
• Always get these proofs in writing... this will usually prevent the same person from contradicting you next time.
• Testing
• The testing schedule also needs to be padded, as above.
• The testers will usually need time to learn the system, or the changes to the exciting system.
• Debugging
• Testing almost always uncovers bugs that need to be fixed.
• This will affect the engineer's schedule for the next phase of the project.
• This will require another day of testing, at a minimum.
• Documentation
• If needed, then assume it cannot be completed before the debugging stage.
• Maintenance
• Unless the engineer is new (and you allocate for the learning curve) you will have to add padding for them to maintain all the projects they have ever worked on. We have seen cases when senior engineers get no work done because they have a full-time job maintaining years' worth of legacy projects, and assisting (relative)newcomers to learn all the legacy code.

Now you can try create a schedule, which will be out-of-date before you finish preparing it.

In a future post we will discuss how often to update a schedule.

- Danny