What is it about software development projects that is different from many other types of projects? There are many things, but Scott Adams nailed on the head one of them with his March 16th Dilbert cartoon which gave me the idea for this column’s title. In the strip, Pointy Haired Boss says “My management philosophy is ‘measure twice, cut once.'” To which Dilbert quickly points out why the reverse is true in software development: the cost of experimenting (trying something out to see if it works) is a lot cheaper than analyzing it until we are comfortable that it will work.
However, all of us in software development at some time have seen the graph that shows how much more expensive it is to fix bugs as a project progresses in its development (for an example, see here). So, how can it be cheaper to try and see than see and try? What gives?
Well, the analysis follows the lifecycle of a bug not the lifecycle of a system being developed. It also assumes a waterfall methodology, in which all requirement, analysis, design, coding, and testing is done sequentially. In software development though the trend is towards Agile and Agile-like methodologies, which conduct many small iterations that go through the analysis/design/code/test cycle very quickly. So, instead of spending a lot of time analyzing and design, the developers go ahead and build it and learn from the experience.
This presents a challenge to traditional project management: the PM is supposed to know what is going to happen, when, and how long it will take before the work is to be done, preferably very early in the project’s life. In Agile and Agile-like approaches the details of what will actually be done are not known until the iteration planning takes place (iterations are short, fast cycles within a release, usually one to two weeks in duration. Each iteration aims to have code that could be ready for use by the customer. Typically they are grouped into releases, which are actually provided to the customer). So, how can a PM plan when the details are not even known?
Mike Cohn, in his book Agile Estimating and Planning addresses how to plan for a release and how to plan for each iteration. This is an excellent resource for planning at this level of detail. It gets a bit harder when planning for a project that will have multiple releases. For these situations, I have been successful using map days to get the group to build such a high level plan together.
Jose Solera, MBA, PMP
