Mr. Yuk Says Project Roadmaps Are Poisonous
Filed 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.
Quantifies Unknowns
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.
Instantly Degrades
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.
Promotes Urgency
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….
7 Responses to “Mr. Yuk Says Project Roadmaps Are Poisonous”
[…] Mr. Yuk Says Project Roadmaps Are Poisonous (Max Pool) […]
Nice post. Estimating is one of the hardest parts of my job and I hate it because you do get sucked into the problem of management and clients thinking that the estimate is a final price as well as timeline. I’m working on a project now that’s FUBAR and I’m really kicking myself in the ass for not estimating better. The only advice I can offer is to get as detailed as you can in the estimate as to what you are providing and charge for anything outside of that. In estimating, generality is your enemy. Looking forward to your follow up post.
James
These charts and the people who create them is a symptom that your company treats software like a physical construction project and is not approaching software realistically. You can either run or tell them they need to stop and rethink the whole project management thing and stop treating it like a waterfall A->B->C project.
Background. Part of teams using Agile and using PMBOK and a bit of PRINCE2. Teach people to pass the PMP and teach corporations how to manage software projects.
1. Iterations can be timeboxed, therefore they can be represented on a bar chart
2. If we can’t produce software in an agreed timeframe with agreed features, how do we set expectations on the ‘cost’ of the project?*
*Without a cost, they don’t know where to invest their money because they don’t know how much of it they will need. TurboTaxOnline.com costs me about $150 a year. I find that to be a great value. However if they told me who knows the cost we’ll just charge you I’d opt out of using the website.
@Eric –
Yes, Iterations are timeboxed, but what can fit in those iterations is the bigger question…
Not to bleed into Friday’s post, but one of the many questions we have to change is not how much something will cost, but having this budget and timeline what do you think can be done and what is the probability?
I will expand more later this week… 😉
In my experience Gantt charts provide no value once a project goes off course.
How many times have you heard “we missed this target, but hopefully we’ll make that up later on.” — likely in the QA phase.
The other issue I have with these charts is that they try to immediately break things down into the task level, which isn’t ideal.
I’d rather coordinate dependencies and priorities with FEATURES — something that the client will care about — and in that regard we can deliver software in many small (yet complete) chunks.
Good write up!
[…] are some really insightful points over at CodeSqueeze. Though, the starting point is agreed on by managers in the […]