“Adventure is just bad planning.” [Roald Amundsen]

Abstract

If you have to make a plan for an IT project, think BIG: What will the environment of your application look like ten years from now? Five years? One year? The scope of your timeframe as well as the scope of your application will define the range or the necessary depth of your plan.

If you develop together with five colleagues or more, consider using Microsoft Project. I used it only to devise an initial project plan, never to monitor a project during execution.

A book which gives you a very good overall feeling:

The Mythical Man-Month, Frederick P. Brooks, Jr., ISBN 0-201-00650-2

Some good advice from this book:

Rule of Thumb for Scheduling a Software Task (Frederick P. Brooks)

33% Planning
17% Coding
25% Component Test and Early System Test
25% System Test, all Components in Hand

The Second System Effect

There is a general tendency to over-design your second system. You want to use all ideas and tricks you have not been able to apply in your first system.

So, always insist on a senior architect that has done two projects already. And be aware of these special temptations.

Growth and Turnover

A large project can sustain a staff resource buildup of 30% per year. More than that will threaten the project’s essential informal structure and its communication pathways (Source: V. A. Vyssotsky, Bell Telephone Laboratories).

Long projects should expect a staff turnover rate of 20% per year. New staff must be technically trained and formally integrated into the project’s structure (Source: F. J. Corbató, MIT).