“You always know more tomorrow than you do today.”

As we continue the topics in the “10 Things I’ve Learned as a Project Manager”, this learning ties in a lot of ways back to the first article in the series, “You can’t steer a parked car”. However, I’d like to draw the distinction between the two in that the first topic describes how to progress the team’s work, in this topic I’d like to focus more on the impact that uncertainty has on our planning.

It’s difficult to approach this subject without a bit of theory-craft to get started. We often use the terms “knowledge” and “information” interchangeably. However, there are some nuanced differences between the two. Information tends to be more of something that is provided as a reference, whereas knowledge infers that we have applied our experiences and skills to the information. Two other terms that apply are “Implicit” and “Explicit”. Implicit means the types of information or knowledge that is anecdotal or based on experiences, whereas Explicit is something that we can visualize through words, pictures, data, etc.

Learning as it’s gained in both knowledge and information is highly impacted by the individual in many ways. The way we learn and what we learn is influenced by our culture, our norms, our background, our level of education, our experiences and so on. So, what we “know” is truly subjective and can be highly variable as well. The team members may be stating things as “facts” when in truth these can be very much colored by all those factors.

Why is this important to a Project Manager? For a project manager to ensure the team is making the best decisions we need to learn how to sift through all the blurry and fuzzy inputs coming our way to get to the knowledge that is truly useful to the team. The trick is to determine what is being presented explicitly which may not be applicable to the work at hand – in other words, implicit being presented as explicit. Getting back to the subject of this article, this often means we need to act on partial information and knowledge until we can fill in the blanks, so to speak.

The tendency also may be for people to be hesitant to speak up because they are uncertain their experiences or skills apply to the problem at hand. So, the team may either overstate their confidence in what they know, or they may understate what they DO know about the subject. Regardless, I often find this is best resolved by making sure we capture what we think we know – assumptions – as well as those things we don’t know – risks. Let’s explore a couple of factors that typically influence team members with regard to overstating or understating.

Fear: Really?? This term may conjure images of a haunted house, or a movie you once saw. You might already be thinking of about something you saw to cause you to jump out of your shoes, or seat so to speak. However, fear as we would apply it to the project team can have a much more subtle effect.

I was once in a situation where there was a significant effort by the project team to deliver an enormous amount of work in a short duration of time. When I was brought in to help it was clear the team was struggling with navigating through all the work. This was exacerbated by an under-performing seller that was contracted to do the development work. Too many things happening at once and too many things going wrong.

Through several steps that we took as a team we were able to successfully deliver with a reasonable level of quality in the deliverables. The techniques used to recover will be discussed in more depth in future articles, but that was just the first phase, and the subsequent phase included a larger number of deliverables with essentially the same team and once again a tight timeline. The project management team needed to come up with the estimates for the work with those considerations.

The team members that were to provide the estimates were naturally very hesitant to give a realistic estimate of the work. When we initially asked for the estimates it became clear they were concerned not enough time was going to be allowed them based on the experience they just went through. There was a significant human toll in that previous phase, people’s lives were horribly disrupted with overtime work, stress, confusion and the re-work that resulted. The emotional toll in these situations is quite significant, and disgraceful when it occurs. This results in a sense of fear that they may go through the same thing all over again in the subsequent phase.

In these situations, we owe it to our teams to do whatever we can to repair their confidence and help them work through the fear they are dealing with. They typically play out those fears by “padding” their estimates. In this situation we used a tool in gathering the estimates that was chosen specifically to help the team in expressing their schedule concerns given the previous difficulties. This was the “Three-point Estimating” technique where we gather the Pessimistic, Optimistic and Most Likely estimates for the work and then combine those in a formula to come up with the level of estimate that was included in the plan. Because the pessimistic estimate was included, in fact we started each discussion with the pessimistic view, it allowed the team members to share those concerns.

Not only did we capture all the things they experienced in the previous phase (more on that later) but we did so to ensure they knew their concerns were being incorporated into the final product. This had the effect of dispelling their fear that they were going to be held to a tight deadline that would drag them right through the same terrible experience they had last time.

As we worked through these estimates, we also dispelled their fear of committing to an unrealistic timeline in that every time we came across a question with no answer we “parked” it. In reality what we were doing is gathering the unknowns, in project management terms – the risks. We let them know it was ok not to know every detail as we would naturally come across the answers to their questions as we progressed through the work. That is the essence, and the fear dispelling effect, of the saying it’s ok! Because “we always know more tomorrow than we do today”.

Over-emphasis on “what happened last time”: In keeping with the illustration on fear, the team members also tend to reference those things that are most fresh in their memory. The last project experience they had will override their better judgement whether for the positive or for the negative.

I’ve noticed this can be especially true when navigating risk on a project. We as project managers can get a very wide degree of answers and emphasis when we start discussing risks on our projects. We know from our training that risks are recommended to be discussed in meetings set aside specifically for risk. Although this is best practice, I often find that teams not accustomed to thinking through uncertainties will struggle in these sessions. Their perspective is skewed by what impacted them the most in their most recent experiences even if it isn’t relevant to the current topic. This can dominate the discussion and challenge us to keep the team focused on what is relevant to the project.

Another observation on these sessions is that it’s often difficult to even get the team to attend! They are most consumed with the things they are working on and don’t want to discuss “imaginary” things. There is some truth to that, in fact. The project benefits most when the team is focusing on deliverables, I know, the pure PM inside me says that the Risk Register IS a project deliverable. But I’ve found that there is a more practical way of capturing the unknowns on a project while making progress and without getting sidetracked with discussions that result in poor attendance and irrelevant outcomes.

What I’ve found more helpful to infuse the concept of risk into every discussion that occurs. We can do this because in the truest sense, risk is simply anything we are uncertain about. This does a couple of key things that I believe significantly help the team progress. In many cases people just want to know that their questions are being captured and handled. And since I also make the risk register a constant review item they are confident we are engaging in finding those answers regularly and frequently.

This approach gives a certain amount of freedom in the team to learn as you go. Risks will then become one of the more dynamic components of your regular team discussions and we can have confidence to proceed knowing that we may not have all the answers, but we have a way of getting to those. Which brings me to what may be the most important idea behind “we always know more tomorrow than we do today”.

We learn by delivering: Time to strap into your project manager geek gear. In the Manage Project Knowledge process found in Integration Management for PMI’s standard on project management, one of the most important inputs, in my opinion, is “Deliverables”. That implies even the worldwide standard supports this saying, that we learn by delivering!

This is also one of the main advantages, or leverage even, we have as project managers. By definition, projects are unique endeavors. That means to me that we can use that as way of motivating people to participate fully on a project. There is something in it for them! There is something then can learn as they deliver, gaining both skills and experiences that will help enhance their own capabilities, their contributions to the project in addition to their ongoing contribution to the organization.

The primary output of Manage Project Knowledge is “Lessons Learned Register”. The idea that lessons learned are saved for either the end of the project or when something catastrophic occurs is something that should be foreign to us as project managers. We would be better served by ensuring we are constantly learning organizations so that we can regularly learn as we go and infuse those learnings into the team’s DNA as we progress towards our project objectives.

Those that participate in the Agile project delivery methodology have formalized lessons learned at the end of every sprint in what is called the “Sprint Retrospective”. These sessions can be very effective means of learning as we go, focusing on how well the team is performing, what they could be doing better and recognizing those things that are going well. My recommendation is to start each of these sessions with an icebreaker or team exercise of some sort so that the team can shed the stresses of the project to some degree and create a more collegial environment where everyone is comfortable sharing.

Another way to think about learning is the concept of “impediments” as it’s defined within the Agile Scrum. Impediments are anything that is blocking people’s progress on their tasks for that day. One of the things I’ve found in Scrums is a significant number of impediments I hear each day are related to something the team member needs to know in order to proceed. In that regard, lessons learned are actually done every day of the Sprint!

One of the traps we can fall into is only focusing on those things that need to be fixed, so to speak. Sure, the things that limit our performance, create defects or create confusion in some way are going to be our highest priority. However, we also should be looking for the things we’ve learned that contribute to success so that we can reinforce these concepts as we endeavor to enhance the collaborative attributes of the team.

These are just some of the thoughts on this saying. For me personally, learning is one of the most satisfying and enjoying characteristic of project management. In every project, and often in every situation I find things that I didn’t already know and learn about people, systems, organizations and functions. That’s why all things at Projects by Design start with becoming Learners in our Learn|Transform|Deliver model. Having people and teams that are excited and engaged about learning in all they do you can then engage transformational practices that will lead to more effective and efficient delivery.

Thanks for reading, keep looking for future articles in the “10 Things I’ve Learned as a Project Manager” series.

Dan Barringer