Mr. Yuk Says Project Roadmaps Are PoisonousFiled Under Estimation, Software Process
For some time now, I have thought that high-level project roadmaps (Gantt charts in particular) are one of the most worthless documents that a software project team can produce. I shouldn’t be so hard on them, but there are an uncountable number of reasons why I despise these charts.
As the old saying goes:
You don’t know what you don’t know.
Most roadmap documents are created with very little research or prototyping done before hand. As a result roadmaps are left with very large holes in them. To add injury to insult, some roadmaps are even then “buffered” to account for these unknowns.
Regardless, these timelines are then declared “complete” as every action (that they knew about) was covered, and some arbitrary number is placed on the things that they didn’t know (which is always the lion’s share of the project).
Promotes Optimistic Estimations
The main reasoning behind estimation methods such as point estimation is that we have a hard time distinguishing the difference of long running tasks. Sure we can accurately estimate the difference between a 1 hour task and a 2 hour task, but can we really estimate the difference between a 23 hour and a 24 hour task? No, not in the least.
Roadmaps promote these optimistic estimations at an epic scale, attempting to reason the difference between a 3 month task and a 4 month task. Most commonly this is also done without ever breaking each of these course task blocks up into actionable tasks that can be completed in less than a day, thus getting back to quantifying the unknowns.
If the development team is very unlucky, the development team will be forced to estimate each of these tasks in an impromptu meeting lead by the manager creating this document. This is very unfortunate because it now allows the developers to become the estimation scapegoat.
Progress is not linear, unfortunately, all roadmaps are designed to show that software is built in a linear factory-like manner. Some might say that it is the medium of which the message is delivered; however, I believe it doesn’t matter if the document is written on toilet paper – the core philosophy is flawed.
The instant the Step 1 – Step 2 – Step 3 plan deviates into Step 3 – Step 1.2 – Step XYZ, the document instantly degrades and needs updating. This is simply not how software is built, or how its’ progress should be kept.
Although I do agree with the fact that we all need some level of healthy stress; however, because of inaccurate timelines and optimistic estimations we create slipping deadlines and broken promises.
As a result, we create poisonous environments of urgency. I believe it was Steve McConnell in Software Estimation who said that a developer under strict deadlines will actually produce less due to high levels of stress, which in turn, will put more bugs into the system – quicksand effect if you will.
So what can we do to combat Product Roadmaps? I am just getting going…be sure to look for Part 2 on Friday….