That’s a great word for a surprise birthday party or an unexpected gift, but not a great word for a Project Manager. We don’t like surprises, it typically means we either missed something in our plans or we thought something was , but in fact it wasn’t . One of the worst things that can happen is to assume we have something ready for delivery when we realize when reviewing with our customer or other stakeholder and find that it’s missing a key attribute, characteristic or component.

Maybe you’ve heard this phrase before – it’s rather common, actually. In fact, this may cause a negative reaction in you if you’ve experienced it before. It’s quite possible you’ve heard this phrase used by an over-bearing manager who looked at everything you worked on under a microscope. That would be bad, and certainly not the intent of the saying. I’m hoping this blog will help in understanding how that behavior is not the true intent of this saying as I’ve learned to use it with my project teams. Let’s take a closer look at some of the concepts we can apply as PMs.

You are the PM, but you also have a team. In previous articles in this series I’ve discussed the nature of authority as it relates to the Project Manager role. Regardless of the level of authority, however, we are placed in a position of trust by our sponsor and key stakeholders.In other words, trust is a constant, whereas authority is not. To fulfill that trust we will need to make sure the deliverables are correct and complete while at the same time not making it so over-bearing on the team to lose their respect. Let’s look at three negative behaviors to avoid and three positive behaviors to practice as PMs:

Negative behaviors:

  • Deflecting and Deferring – Recently I was working with a Project Manager that for every question on a late deliverable or clarification, he would come up with a deflection on the question. I heard a steady stream of “I don’t have control over that”, “You’ll have to ask ”, “That belongs to a different project”, and so on. Every time I heard that I just cringed inside. A vendor PM at that, AND proud to put the PMP designation after their name in the signature block. I’m thinking to myself; this person not only does a disservice to themselves, but also to their organization and more broadly to all PMs. You – the PM – are entrusted by the organization to integrate your team’s work! Go do that already!
  • Nagging – What is the definition of nagging? One of the definitions I found is to be “persistently painful or worrying”. Are you nervous about the timeline? Are you fretful the work won’t get done or whether the team member is putting enough attention on the matter? Then keep it to yourself! If we harass our team members by “hovering” or “15 minute six times a day stand-up” or similar behaviors it is often because we are putting our own needs ahead of theirs. This will tend to portray a lack of trust in the team members and certainly add to their stress. Speaking of which…
  • Being a conduit for stress–Projects are naturally stressful environments. Agile practices are intended to reduce the stress of imposed deadlines and work overload. Despite these practices, the stress can be real, and the PM has a key role in helping reduce the stress load. If we pass through, or worse, amplify the stress of delivery being put on us by sponsors and other key stakeholders to the team we will certainly disrupt the team fabric. We can do the same to sponsors, pass on or even amplify the stresses of the team members. This will likely misrepresent the true condition of the deliverables and cause the PM to lose credibility in their abilities to deliver.

Positive behaviors:

  • Own it!–Own the trust being put on you by the organization, in other words. Take to heart that trust and in so doing you will find you will be recognized as being more trustworthy. We’re likely not the best subject matter expert on anything on our projects other than how things get done. Focus on the how and you will build that trust from the team members and demonstrate your trustworthiness.
  • Put the team first – I know the sponsor is who we work for, so that naturally puts them first in priority. However, by saying put the team first, what I mean is make sure their needs are recognized and supplied before our own. Yes, we want to make sure we get what we need, but what we need is deliverables. That normally comes from the team, not from the PM, so as long as their needs are met yours will be also.
  • Be clear on expectations –Several times in my project management experiences I received a deliverable and was somewhat disappointed on the timeline, quality or even felt like the objective was missed. When discussing the outcome with the team I came to realize I didn’t get what I expected, but what I communicated. I could have done a much better job of translating the expectations of stakeholders to the team. This goes for both team and stakeholder expectations – be sure we’re communicating the substance and context in order to help the team deliver on those expectations. No surprises!


Ever have the team member to which there’s always “more to the story”! I can remember one individual I had on a few projects where the typical response was always a very short answer. In each step of the conversation I would learn the “more” to their story. The conversation would go like:

Question: “Have you finished the task we gave you today?”

Answer: “No”

Question: “Will you be able to finish it?”

Answer: “No”

Question: “What is preventing you?”

Answer: “Don’t have my computer”

Question: “Where is your computer”

Answer: “Getting fixed”

Question: “When will you get it back”

Answer: “Not sure”

Question: “Can I find a replacement computer for you?”

Answer: “I have one”

Question: “So, can you get the update done today?”

Answer: “No”

You get the picture. After very painful interactions you learn that the replacement doesn’t have the applications needed and the license key is nowhere to be found and they did something to their computer that has the support team perplexed, and so on. This type of team engagement can be quite difficult to understand how you can even help your team member!

In these situations I do whatever I can to “leapfrog” the next short answer. I can phrase the next question to be a multiple choice, for example, “do you not have it done because you didn’t have the time, or there’s a question you need answered, or you don’t have what you need?”

Be clear about what “done” means.Those who have worked in Agile teams know that the concept of “Definition of Done” (DoD) is one of the core components to the Agile team. When I was working with one team helping to launch a project and discussing the way we were going to work, I brought up the subject of the team coming up with the DoD. They said, in effect, that’s not something they need to do since they always use the same definition.

This may be a good idea from an operational perspective, but not necessarily a good idea on projects. If we don’t go over it with the team at the start of each project/sprint/scrum we miss the opportunity to trigger a response of something recognized that’s unique to those stories or deliverables we are committed to complete. Eachtime we have an opportunity to review for the uniqueness of our project deliverables, besides, it’s a great opportunity to get to know the team even that much better.

Which brings me to the heart of what this saying truly means to me. In order to truly become an effective PM, we should have a team that holds itself accountable for delivery. We use terms such as “self-directing” and “self-correcting” teams to describe this approach. I like to think of this in two different approaches, the micro and the macro inspection

  • Micro-inspection: These are the one-on-one engagements or individual discussions we have as team members going over the project work. In doing so we make sure we are fully done, as in the updates are correct and complete. In project teams I’ve always found it’s best to have two sets of eyes on all deliverables, either teaming to create the deliverable (big fan of paired programming). The team members naturally inspect each other’s work, but all within the context of team collaboration.As for my micro-inspections it may be a simple as making sure the document is checked back in, or the updates have been published. If not, then
  • Macro-inspection: Team reviews – regular reviews of the project work can always be a very helpful thing to make sure the team stays on track. In Agile this is a key component to your scrum as you are aware of yours and your team member’s work through techniques like osmotic communications (information flows among the team members in the background).In virtual settings this needs to be much more intentionally managed. There are some great tools that are emerging to encourage collaboration in the virtual setting (I’m a huge fan of Microsoft Teams) and the best is yet to come!

In both micro-inspection and macro-inspection the goal is the same. That is, to ensure the work is both correct and complete so that we are comfortable there is a high probability it will be accepted by the customer. The more this is worked into the team norms and behaviors the less the burden falls on the project manager to do the inspections themselves.

For your current project teams, how are you implementing your inspections? Do you feel like you are having to inspect everything? Are the team members avoiding, or ducking your questions? Do they understand what “DONE” looks like? As a project manager I struggle with these questions regularly. When and how to “check up” on the team member is a delicate balance between displaying trust or lack of trust. In fact, if we are to be trustworthy it will require us to trust the team. The best approach to creating an engagement of trust is to involve the team in the process of ensuring the project is delivering quality products. Which brings us to…

Quality is job #1. Why would an organization invest in project management? If you have more than a couple years in project management you’ve probably heard the criticism of project management in that it’s too process heavy or slows the organization down. Personally, I’ve been a part of three separate PMOs in my career that were significantly downsized or even eliminated. The reason management took that action was because the PMOs were not perceived to add value. In other words, management was unwilling to continue the investment because the returns were just not there.

What did those PMOs lose sight of? There was a common denominator in all three that they attempted to implement an enterprise project management solution and tried to do so in a way they would never allow any other project to proceed. But that was the symptom of the larger problem. In every case they became so hyper-focused on forcing a standard methodology on every project regardless of complexity. I like to say, they felt the process was the value they were providing. However, that runs at odds with key component of the definition of a project – a unique endeavor.

Our value is not in the processes we follow, our value is if the customer receives a project that is of higher quality as to scope, schedule and cost than they would have if the project manager wasn’t in place. This is the trust that’s placed in us. I knew the end was coming with those PMOs when I was simply filling out a bunch of forms to keep the process beast fed but managed the teams in a way that shielded them from all the demands of the PMO. To this day I feel like one of the best compliments I received in the aftermath of a PMO being dissolved and being hired into a business unit for … project management … was “PMOs don’t add any value but I like what you do”.

What did I do to get that reaction? The customer in that case felt like they were getting value for their investment in project management. What was the value? Doing the right thing at the right time in the right way. That’s the best definition of project controls that I can find. In fact, the way we work can be any number of practices or approaches, however controls are not optional. It is in inspecting the deliverables that controls ensure the right thing was done in the right way at the right time. That means we, as project managers will be inspecting regularly, as we engage the team in a self-correcting way. Let’s practice the behaviors as PMs to ensure quality in our deliverables – the whole reason we are hired in the first place!

If you are enjoying this series we’d love to hear from you at Projects by Design! Send us an email at or leave a comment on this post. In our next article we’ll cover the learning that “Bad news doesn’t get better with time.” Looking forward to it!