4 ms·

Nothing about what you've said wasn't known and employed by people at companies who've made budgets and estimates that went over. This is why estimates and budg

Nothing about what you've said wasn't known and employed by people at companies who've made budgets and estimates that went over. This is why estimates and budgets go over. Everyone thinks they have it figured out. The Taylorist principles of management don't apply to knowledge work in my experience. Refine your requirements gathering and estimation processes all you want. Your estimates will still be wrong most of the time. They're educated guesses and we don't have the foundation to make accurate ones. One thing I think you nail though is that communication is key. A lot of good comes from being honest, transparent, forthcoming, and supportive. I never recommend software teams and companies make estimates. I say break down tasks, make mile stones, set learning goals, and get to work. Communicate progress frequently and keep feedback coming back to the team. Working software talks. When you can see the goal in sight that's the time to start talking about release dates. Once you have that first couple of releases you then you can start developing a cadence. It's all based on evidence and what you know and making promises you can keep.

grey-area 5y ago
The Taylorist principles of management don't apply to knowledge work in my experience. The simple principles above do apply in my experience, presumably there is some difference in practice. Maybe everyone thinks they have it figured out but some people demonstrably do, because they deliver software on time which meets requirements. I agree with delivering software early and often, and that is a solid basis for delivering reliable estimates and promises you can keep. Where estimates fail IME it's down to lack of accountability and communication among stakeholders, which leads to constantly shifting and unclear priorities and requirements.

grey-area 5y ago

The Taylorist principles of management don't apply to knowledge work in my experience. The simple principles above do apply in my experience, presumably there is some difference in practice. Maybe everyone thinks they have it figured out but some people demonstrably do, because they deliver software on time which meets requirements. I agree with delivering software early and often, and that is a solid basis for delivering reliable estimates and promises you can keep. Where estimates fail IME it's down to lack of accountability and communication among stakeholders, which leads to constantly shifting and unclear priorities and requirements.