Great question — I hope others jump in on the conversations. Mistakes are such a rich source of learning and insight.
My big mistake
Early in my PM career our team was working on a bold new feature for our product. It was a big undertaking and the dev team needed a few solid weeks to execute. I stepped out on a limb for my team and got senior leadership to defer a high-profile project so that we could get this feature shipped. It took guts to stand up to leadership, but it was the right call.
Then I got burned.
Turns out the team misestimated the project by a factor of 2 or 3x. Not only did we not get the high-profile project completed, but we also missed the deadline for the new feature. Our credibility took a big hit.
We eventually shipped the feature and it was quite successful. Its remains a core feature to this day. However, the credibility cost was high.
What I learned
- Interpret the estimate, don’t take it at face value — Different dev teams have different estimation tendencies. Some teams hedge. Other teams are over-confident and miss every time. Its your job to acknowledge this and factor it into the timeline you give the business.
- If you’re nervous, say so — If you are nervous that a project is slipping, then tell the dev team. Saying “I’m a bit concerned that…” or “I’m starting to get nervous — it seems like we’re not on track” is almost always well received and very productive. The dev team often won’t bring this up on their own. Its your job as the PM to state the obvious and ask uncomfortable questions.
- Engage in intelligent de-scoping – If something is behind, then ask what would need to be eliminated for the project to be completed in the same time frame. Where can the project be intelligently de-scoped?
- Communicate often with the business – Infrequent communication with the business puts a lot of emphasis on each conversation. They should be hearing from you on a frequent basis. Its much easier to highlight delays, adjust expectations, and address concerns when there is open and frequent communication.
- Keep instilling proper expectations – In my case, we missed in two big ways. First, the dev team under-estimated the project, but the business also had unrealistic expectations of what was possible in the first place. It was my job to constantly be reminding the business how much projects cost in time and effort. The realities of software development are not intuitive to most people. Its our job to ensure people have proper expectations to begin with.