Introduction
Recently, I’ve become quite interested in the topic of “schedule planning” due to issues with project timelines, and I want to see different engineers’ perspectives on this problem, mainly referencing the article: The work is never just “the work” - Dave Stewart.
I often just see problems and try to solve them. But if a project is on fire and the manager sets an unrealistic timeline, how do you explain it? This is why I want to research this topic: the people closest to the implementation are often the ones who can provide the most accurate estimates.
Everyone hopes that projects can be completed quickly and on time, and when things go wrong, I hope to analyze the causes and directions for improvement.
Why is Project Time Estimation So Difficult?
You have never truly experienced the same situation; you think you have, but you haven’t. Everything changes: colleagues, companies, clients, tools… you yourself, either have changed or are in the process of changing…
This Hacker News source caught my interest, mentioning some intriguing discussions:
I once had a boss who always chose those overly confident, unreliable, low-bidding people. He never estimated time in days or weeks. For him, everything could be done in “an hour” to “an afternoon.”
So when I said, “It takes two weeks to complete the entire process,”
that person would say, “I can finish it this afternoon.” But the code he delivered didn’t work at all, and then it took me, QA, and him three weeks to fix it before it could run properly.
The result was that what originally required two person-weeks of work ended up being about 5 to 6 person-weeks of work.
The problem lies in the inability to predict what needs to be done and how long it will take to complete. Perhaps having a bit more similar experiences helps? Maybe suggestions like “reserve 30% for project management” or “add n times the estimated time” are helpful? But these methods rely on rough experience, and the only accurate estimates exist at the moment of completion.
Estimation Failed, What Next?
Estimation fails, but we can learn from the experience of failure. Most failed estimates boil down to two key points:
- Many tasks are “work done to complete work,” rather than “actual work.”
- Most work is underestimated or not estimated because it is not “actual work.”
We like to estimate how smoothly things will go under professional execution, rather than worrying about unpredictable variables. This also involves issues of self-esteem and pressure, so instead of blindly trusting that things will go smoothly, perhaps we can establish a framework to include both the work and its associated additional tasks in the assessment.
Evaluation Framework
All projects have an unchanging characteristic: the work can be categorized into three types: before, during, and after the project. It can be further subdivided according to a more detailed framework:
- ⚫ Work surrounding the project (administrative): meetings, reviews, project management
- 🔴 Work done to obtain the project (acquisition): research, experimentation, defining boundaries, quoting, persuasion
- 🟠 Work before the project (preparation): setup, infrastructure
- 🟡 The project itself (execution): actual product design, development, testing
- 🟢 Work between projects (iteration): iterative debugging, refactoring
- 🔵 Work extending the project (change): omissions, new changes, additional items
- 🟣 Work outside the project (issues): unexpected events, extended tasks
- 🟤 Work after the project (support): deployment, security issues, updates
Breaking down the various aspects of the project in advance helps to assess timelines from a more objective perspective. Sadly, the nature of each project is different, and there is no one-size-fits-all framework that can be applied to any problem, but such a framework can help us better notice the potential complexities of the project.
Conclusion
- Evaluate completed projects to bring expectations back to reality.
- Be aware that the vast majority of projects have hidden work.
- When things go wrong, instead of continuing to work hard, think about improving estimation biases and weaknesses.
- Pay attention to fixed-cost projects.
Since the factors affecting execution are constantly changing, my thoughts on this topic are that there is no need to be overly obsessed with the accuracy of estimates, but rather to learn how to quickly adjust when estimates fail and have a comprehensive understanding of the work.