I am a software developer, and I work in a small web development company. It seems to be a recurring theme that a middle-manager will ask me how long something will take, and when I give them my estimate, they think it is too high. If it's a more technical manager, or another developer, they will usually already have in mind an estimate of their own, and start trying to implement it in their own way because they think they can do it faster.
There is a trend, though, where the other developer(s) have ended up using significantly more time than they quoted. They will get half way through their budget, then realize that there is some business need that their implementation plan cannot properly address. More times than not, my plan would have addressed this need, but it was shrugged off as a "You ain't gonna need it" feature.
Worse yet, when they hit this wall, they will usually come to me to help them get out of the corner they have painted themselves into, but there are only so many hours in my day.
Best case: These interruptions cut into the time that I have allocated for my own development work, resulting in other projects being delayed, or me having to work overtime because I am "the only one that can do X".
Worst case: I end up having to take over the task/project as my own, and by that point there's no time left in the budget for me to do it "my" way. I have to try to finish what they started in the way they started it, so "the company doesn't lose any more money". This always comes back to bite me because then it becomes "my" hacky code, and when it breaks people ask me why it was created the way it was (after all, they have no idea who actually created it.)
So my question is: How can I help these colleagues to understand when things aren't as simple as they are envisioning, and they need to re-evaluate their understanding of the client's needs?
Unlike this similar question about Convincing management to deal with [existing] technical debt, my question seeks strategies for helping the team to realize [proactively] before they are about to incur technical debt, in an attempt to prevent it from happening to begin with. These two things do go hand in hand, but they are distinctly different in my mind. The other question's answers suggest adding refactoring time into estimates for future features. This can never work if other developers (and therefore managers) always think that said future feature will take less time than it actually will, and I cannot convince them that my estimate is more realistic.