Early in my career, I focused so hard on hitting deadlines that I forgot to keep stakeholders in the loop, and the project nearly derailed when they pushed back at the last minute. Now I over-communicate instead of over-deliver. What's one PM lesson you learned the hard way?
Ignore silent stakeholders at your own peril. It is easy to get caught up with the loud, high maintenance ones but sometimes those are not the biggest source of risk to your projects.
Kiron Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Syed, one lesson I learned is never to confuse silence with alignment.
A stakeholder who is not raising objections is not necessarily aligned. They may not yet understand the implications, may be operating with different assumptions, or may simply not have been engaged when their perspective or authority could still influence the project.
That is why I would distinguish effective communication from over-communication. More information does not necessarily create greater understanding. What matters is whether the right people receive the right information, assumptions and trade-offs become visible, and disagreements or decision needs surface while meaningful options still exist.
For me, the objective is not to prevent stakeholders from pushing back. Sometimes their challenge is exactly what the project needs. The objective is to make consequential disagreement visible early enough to learn from it before it becomes late resistance, rework or an irreversible commitment. Saving Changes...
Bob PatrinoConsultant/Project Leader| TamazariUnion, KY, United States
Making assumptions. Don't assume that resource commitments for one phase of a project will carry over to the next phase. Confirm resources for each phase. Saving Changes...
Program Manager| HARPER SRLSanto Domingo / Distrito Nacional, Dominican Republic
One I learned is that silence doesn’t mean agreement. You can leave a meeting thinking everyone is aligned because nobody raised concerns, and find out later that people had very different expectations.
Now I confirm decisions, ownership, and expectations instead of assuming we all understood the same thing. Saving Changes...
Hi Syed, I have plenty of battle scars from lessons learned over the years—from my time with boots on the ground to playing the corporate game. However, there are three key lessons that have always stuck with me, and I try to share them with my project teams as much as possible:
1. Keep people updated on both the wins and the setbacks.
For you as the PM: It is never easy being the bearer of bad news, but that is what you signed up for. You might not be liked in that moment, but you will absolutely be respected afterward.
For your project team: It is much easier to bring an issue to light and address it while it is small, rather than hoping it resolves itself or trying to figure it out alone. I always ask my team to keep me informed. If a client calls to ask about an incident on-site, it is much better for me to say, "Yes, my engineer informed me, and we are already implementing a solution," rather than admitting I was unaware. Being out of the loop makes us look disconnected.
As a side note: Never escalate an issue and simply expect higher-ups to make a decision for you. Always bring a few potential solutions to the table for them to choose from. This leads directly to my second lesson.
2. Remember that you are not the subject matter expert on everything. A good manager doesn't need to be the foremost expert in every area; they just need to know where to find reliable information. Put your pride aside and ask subject matter experts for their input when you are looking for solutions. People enjoy sharing their expertise and feeling like a valued part of the project. Your job as the PM is to take those options and prioritize them based on the project's requirements.
3. We need to do a better job of selling our skills and our field. I often see people skip the "lessons learned" phase of a project, treating it as just the same old routine before moving on to the next assignment. In reality, this is the perfect opportunity for a PM to market themselves. We do so much behind-the-scenes work that stakeholders rarely see—they usually only see the final outcome. Use the lessons learned phase as a platform to advocate for yourself. Showcase how you improved the PM process, and highlight the tacit knowledge that was gained and needs to be transferred. Market yourself! Saving Changes...
One unwritten rule I learned the hard way is never assume that silence means agreement or commitment. Silence from the team may mean they are busy with other priorities, lack bandwidth, or need more time or changes to the deliverables. It is important to speak with them individually and as a team to understand their capacity and concerns.
Similarly, silence from stakeholders, management or leaders does not necessarily mean they have seen, understood or agreed with a status or decision. I have learned to explicitly follow up, ask for written input or confirm their position or opinion during a meeting. Clarity and explicit confirmation are much safer than assumptions. Clear and timely communication plays a key role in avoiding these assumptions. Saving Changes...
Communicating an update to stakeholders doesn’t mean they received or understood it, and a lack of emotional intelligence can negatively impact the project. Saving Changes...
One “unwritten rule” I’ve learned in project management is that there is no single rulebook for every situation. As you progress through your project management journey and gain more experience, you learn that effective project management is not only about following processes, methodologies, or frameworks—it’s also about developing judgment. You learn when you need to communicate, who needs to be involved, what needs to be escalated, and, equally importantly, what you need to let go or ignore. Early in my career, I sometimes felt that every issue needed an immediate response and every stakeholder needed to know everything. With experience, I learned that communication is about being intentional, not just being frequent. The more projects you manage, the better you become at reading the situation, understanding people, choosing the right moment to communicate, and knowing when silence is actually the better decision. For me, that’s one of the most valuable lessons in project management: experience teaches you not only what to do, but also what not to do. Saving Changes...
Danielle SmithenDirector of Operations Systems| C.R. EnglandWest Valley City, Ut, United States
One rule I learned early on (and DEFINITELY the hard way) was that not all projects are worth doing. Back then, I didn't know how to push back and ask the right questions to make sure that what we were building was actually going to make a difference. So we ended up inadvertently building some "throw away" projects. That's a good way to learn really quick.
Now, when one of my Divisions or Departments comes with this "grandiose idea" for a project, I like to take time to strip all of that away and go back to asking one basic question of them: What problem are we trying to solve for here? Understanding the problem first, and then hearing the solution, I can ask questions to poke holes in the logic or challenge certain ideas and then one of two things happen. Either we come out with a better product that WILL actually move the needle, or they find out that even if you spent development money, this won't fix the problem because (for example) it's just a data issue or requires users to change their behavior. (I'm a firm believer now that coding shouldn't be done solely to force end users to do something that really you should be holding them accountable to do in the first place, because behavior doesn't change by adding a popup or more clicks, it changes when people understand the WHY behind it and change their process.) Saving Changes...