Help Your Teams Feel Safe Sharing Setbacks

Projects regularly have setbacks, problems, or need some other type of update or regroup. When that happens, how often do people come to you with this information, or how often do you need to find the disconnect on your own by digging through project software, records, etc.?

As project managers, we will always need to do some of each: field updates that come to us as well as go find discrepancies nobody has flagged yet. But it’s better for us if others are in the habit of coming to us with project snags: we save time hunting down issues, and we find out about the issues earlier, when they have caused less damage.

I’ve written in the past about what you can do if team members don’t give you honest or sufficient information about project status when you ask them, and how a people-first attitude and people-first processes can help counteract this.

But can we go even further and get people to let us know about new factors impacting our projects even when we’re not asking? At least some of the time?

I think we can, and I’ve found it makes a big difference if I’m intentional in the way I talk about project setbacks.

Take a simple schedule delay. I have a project owner I’ve worked with in the last few months (like a sponsor, but more hands-on with a project’s day-to-day progress) who is really onboard with using our standard project management processes but tends to be overly optimistic on how early her projects can hit certain milestones. Many of the actual tasks are hers, so she’s underestimating how long she needs to get her work done.

I think for many people, there’s naturally a shame in admitting they missed a deadline that they proposed themselves. And with shame, there can be an avoidance of communicating about the missed deadline.

But with the project owner I mentioned above, I’ve repeatedly said things like the following:

“I have no problem when project schedules need to be updated. Because you’re the one who owns the goals of the project and how important the deadlines are, I have no concerns when you decide to shift them. My main goal is simply that the target dates on project tasks and milestones are kept as up-to-date and realistic as possible, so that everyone has a clear sense of what we’re currently aiming for. Then everyone can prioritize their tasks based on the most accurate information.”

In short, I use positive messaging about change in and around projects. Project changes, even “setbacks,” need not be seen as “bad.” They are, in a sense, simply a response to the realities in the project environment. If we embrace the actual project status and communicate it to all relevant people, everyone can do their most efficient and impactful work (without, say, wasting time doing work that was only relevant to old information).

Yes, there is a sense in which delays, budget cuts, etc. may have a negative impact on a project. But for the project team, if the negative event has already happened, its “badness” irrelevant. What is key now is that the team responds to the delay to create deliverables that meet the most current project requirements under the most current project conditions.

Don’t use language that judges or blames your team for issues. Treat them as people who are always doing their best to meet project goals given current realities. Tell them how much it means for everyone’s efficiency and prioritization that you know what’s happening right now on the project.

The project owner I mentioned above now lets me know when her project schedules need an update—sometimes as soon as I ask, sometimes even before I ask. You can make this more common on your projects too if you emphasize that speaking up about setbacks has major benefits for the project and the team.