Issues in my current engagements have led me back to text books. There are clearly documented lessons that we software professionals fail to learn over and over again. It reminds me of the chapters from a book I read long time ago: Life is a game and you will be presented with lessons, and lessons will be repeated until learned”.
Well, all I can say is that I am relearning the lessons in scheduling and estimation and I hope I will carry them onto my next engagements.
Talking of scheduling, Tom De Marco and Timothy Lister, writing in their superb book “Waltzing with Bears” mention “schedule flaws” as one of the inherent risks common to all software development projects. A schedule flaw is an error in the schedule as opposed to error in the way the project is run.
Schedule flaw is not only a real risk; it is the largest of the five core risks in its impact on plan vs actual performance.
They write, when a seven months project ends up taking 12 months, angry upper management seldom blames the schedule; instead they blame those who were supposed to make that schedule – no matter how ridiculous it was – into reality. But the problem is flawed schedule and not flawed performance.
Barry Boehm, writing in Software Engineering Economics, states that the elapsed time from writing a software requirements to product delivery, will not be less than 2.15 times the cube root of person-months, that is
T > 2.15(MM)^(1/3)
This formula has to be # 1 on my checklist for scheduling.