How does your team communicate/justify project delays to the upper management?
I recently took some of the project management responsibilities as the manager of my team left the company.
I obsess over making good estimates. I want to help the team members make better estimates and want any changes, usually delays, to be communicated clearly and understood by the upper management on a regular basis.
Sometimes I feel like I'm the only person obsessing over it, but there are signs at my company that we need clear communication of these. For example, there's a tendency to underestimate, especially for projects that do not seem as difficult as they actually are.
How much does the upper management of your organization care about good estimates, and how well do they work with unexpected changes?
If you have a template for reporting these estimate changes, from individual team members to the team lead/PM, and then the team lead/PM to upper management, can you share it? If not, what do your reports usually look like? Disclaimer: Sorry I will not br giving you templates because I don't have any. > I obsess over making good estimates. Be careful with this mindset. Estimates are not available at all times, especially when involving complex product. If the engineer is not comfortable giving estimates for a certain complex deliverable, give them "task" time-boxed to research for estimates. If the engineer is TOO comfortable making estimates, make sure you have a senior around to help you assess the situation. > Sometimes I feel like I'm the only person obsessing over it I must assert that it's actually more important to care about customer satisfaction than estimates. If your customer trust you, they trust your estimation. With their trust, you can add reasonable buffer to partially nullify the importance of accurate estimates. And by customer, I mean all those the actual product customer, the upper-management, and THE TEAM. I know PM's tasks are not easy tasks. Now if you feel you are the only person obsessing about CUSTOMER SATISFACTION. I think you will need to inquire if those people don't care, or don't have a bandwidth to care. If it's the former, then it's bad. If it's the latter, you will need to ask how you can make bandwidth for it. > tendency to underestimate If you haven't, read the mythical man month. It's not just about the mythical man-month really. It has other useful stuffs. References:
I'm a lead engineer, my GF is a producer, we exchange ideas alot. (fortunately we are not in the same team) "Responding to change over following a plan" We don't give estimates for large, difficult projects. We do have a roadmap that is documented. We do decide what is next, and maybe lay out a month or two of a swag at what we'll get done, but mostly we just keep moving forward, delivering at a reasonable and sustainable speed. Sure, leadership gets their own idea of what schedule we'll hit. And we often do meet their expectations. When it isn't correct, we tell them what stopped us from hitting it. But we do not approach such things as a "delay" - it is just how software dev works. Just explain the issue. If it's reasonable and they still give you crap, then maybe you don't want to work for them. I try to avoid estimates; they're inaccurate anyway. This is a great video to watch: https://www.youtube.com/watch?v=QVBlnCTu9Ms