The post 8 Reasons Estmates are too Low, is one of those pieces of material that on the surface seems plausible but has series flaws. First is the restating bad management practices and then arguing against them. This seems all too common in the Agile domain for some reason.
A poster campaign at Rocky Flats in the late 90's for safety and safeguards, but usable everywhere is...
Don't Do Stupid Things on Purpose
If we ignore the red herring approach of doing stupid things on purpose and then tilting at the resulting windmill, let's look further for each idea in the post. The picture to the right is used when engaging in a conversation about making improvement, but starting with a credible baseline. This is called Dead Horse on a Stick. Thanks to the Master Systems Engineer on our program for this concept. He uses this when he starts a review and the ideas are dead before he got there. It's also appropriate for concepts that are dead on arrival, like suggesting that those paying for products don't have a need to know how much it's going to cost, before they start spending money.
- Super Hero Estimates - the use of a super hero is a well known flaw on all projects. Don't do this. Just say no to the super hero. Use Reference Class Forecasting. Use past performance. Use reference designs. Find like products. Have a Red Team to assess all estimates. Have the super hero contribute an estimate - the possible anchor. This number can be the most optimal. Then adjust that estimate accordingly. This anchoring and adjustment process is well defined in Tversky and Kahneman's work.
- Wrong Team - simple - get the right team. Much harder than this of course. But without the right team, the project is headed to the ditch. Knowing its headed to the ditch might provide incentives to get the right people. This is called triage.
- Guessing in the Dark - stop guessing in the dark. Do your job as an informed engineer. Start with Reference Classes. Install a Red Team. This is one issue with estimating. But can be fixed with good estimating processes. There are lots of sources for advice.
- Forgetting Stuff - this is the role of the WBS. It's the all in product and services for the project. If you forget things, you don't do a good job of the WBS. The WBS is usually derived from the Statement of Work (SOW), Concept of Opeerations (ConOps), Statement of Operations (SOO), or some description of what the customer wants. If you don't have one, go get something that describes enough detail to start the project, then develop that understanding as you go. In the end if you don't know what capabilities the customer wants, your project is not likely to be a success before you even start.
- Ball of Mud Project - this is bad architecture. It's more common that desired. But it's a bad basis to start a projet. Spend time and money to untangle the project, otherwise you're laying the seeds of disappointment before you start.
- Multitasking - there should be ZERO doubt that multi-tasking is bad. Don't do it.
- Mythical Man Month - this is bad management. Don't do it.
- Lazy Developer - really? Time to replace that person.
Quick Summary
- Get a reference class. Don't have one. Get a reference class
- Get the right people
- Build a model of the cost and schedule drivers
- List the deliverables for the project against the needed capabilities.
- Unscramble the mess before starting. Can't do that? Don't start
- Stay focused
- Plan needed staff
- Get people who will contribute
So what's the point?
When we look at making improvements to anything from projects and sepnding other people's money, to better peddling of my road bike on century rides - start with
stop doing stupid things on purpose.
Only then can you make real and lasting improvements. If you don't do that, you are beating a dead horse.
