The Heliocentric Software Revolution
As early as 4th Century BC the group known as the Pythagoreans thought that there was a fire in the middle of the sky and the Earth rotated around it. However, the Pythagoreans were considered crazy at the time, though Aristotle did give it some thought, and then dismissed it. In 1540 Nicolaus Copernicus again wrote down this idea. Galileo strengthened this with his observations and then Johannes Kepler came up with the math. So it took about 5000 years of observation, fact gathering, and mathematics but the MODEL that the Earth was the center of the universe did change. This was the Heliocentric Revolution.
If a model which is engrained in science and religion can change after 5000 years, then WHY can't a date on a project plan change? This is the central question for the Software Heliocentric Revolution (SHR).
A software plan starts with estimates and guesses. Not facts. These numbers and tasks are then written to a piece of paper or some computer program. The project gets started, real facts start trickling in. Bits and pieces of information gradually start forming a real model, one that is based off of facts. However, the project plan, the model, is not updated. It is as if all the facts are ignored and the Earth is still the center of the universe.
There are three basic items on the project plan; the number of resources, the tasks, and the estimate on how long a task will take. Given these three items a project manager is to create the model. The PM shapes this model, adds decorations here, color there, until it is a work of art. Perhaps this is why it is difficult to change? Coming up with this model is not an easy task. After putting that much effort into something, it is hard to admit that it isn't "right".
Maybe this is the solution? Stop making your project plans so darn pretty! Put less work into them because they are going to be thrown away and revised weekly if not daily. At the end of the project when the model is indeed correct, then add your decorations. Make it look just as good as the product. You will want it to look good when you hang it on your wall as another successful project.
So part one of the SHR is to turn your project plan agile. If the plan doesn't match the facts, then quickly and accurately revise that plan. The goal should be to keep the plan up-to-date at least weekly, if not daily. You can't have part one without part two so here it is.
As a developer I don't think I have ever been on a team that has wasted time. Indeed, most of the time we are happily working overtime on projects because we like it. Yet, it is common mantra to state "We are falling behind". What? What exactly is it that we are falling behind of? If the project plan is wrong, then how can we fall behind it? Isn't really what is happening is that the project plan is falling behind? So part two calls for a change in the mantra. No longer will we say things such as "I'm a week behind". Instead we will say "The plan is a week off" or "My estimates were a week off, please revise the plan".
Models are based upon facts. The developers need to get those facts to the PM so the model can always be right. Dates must move if the facts deem it. If the date just absolutely can't move then you have to get rid of some features. We can't continue to work in our current fashion. Viva la revolution!
Posted at 10:39PM Jun 20, 2006 by Aaron in Essays |