The difference between a good and a great PM is choice of projects. The credit for this quote goes to a seasoned project manager that I was supporting fairly early in my project management career. He asked me this in the form of a question of me as I was working on developing my project management skills. My response was typical, a great scheduler, maybe it’s the soft skills, and so on. I never expected the response he provided. Although this may seem somewhat cynical on first hearing, however, I’ve found this to be a very important aspect of my project management successes.

We all want to get that sweet project opportunity, don’t we? When I say “sweet” opportunity, often we see this as an opportunity to work with a high-performing team and deliver effectively in a highly visible way. Over the more than twenty years of delivering dozens of projects of varying complexity, benefit and visibility it is evident not all projects are created equally.

So, how does that make us feel as project managers? What if we get assigned that “sweet” project with significant tangible benefits to the organization and has team members that are the best in self-organizing, self-directing and self-correcting members that essentially manage themselves? We find that our key stakeholders, sponsor and/or customers will be highly satisfied and view us as an extremely talented project manager. But the opposite can be true as well, your new project assignment is difficult to quantify in terms of benefit, you have a pesky project team member that blows up each of your working sessions and/or there are unrealistic expectations for time and budget from sponsorship. No matter how well we manage the effort there is little to no recognition of our efforts in those situations.

Regardless of the situation we owe it to ourselves, our teams and our customers to be as effective as we can in our role as project manager. There are a couple of things to consider no matter our project situation and how we can best manage the situation to deliver a quality project and product.

Understand who you can and cannot influence. You may notice that I used the word “who” as opposed to “what” we can and cannot influence. This is an important distinction, in fact, if we want to influence our circumstances, we need to influence those who control the circumstances.

Several years ago, one of the projects I was assigned was the type of project that may be described as a “rescue” project. There was a wholly owned subsidiary of the company that grew through acquisition, with their own IT department which committed to migrate the new entity onto their business system platform. At the time, project management services were offered to the organization for the delivery of the project, but the offer was refused. The comments that betray a lack of delivery maturity were made, e.g. “we don’t want that level of complexity”, “we can get this done in six months”, etc. The outcome was predictable, two and a half years later the organization finally implemented their system changes, which essentially brought that business unit to a stand-still.

My first action on getting this “wonderful” assignment was to visit one of the manufacturing sites that was on the new system. Even as I approached the facility it was clear there were major problems. The number of trucks lined up waiting for shipments was more than half of the number of shipments in a typical 24-hour period for that site. On entering the facility, the stress and fear of the staff was palpable, even to the point of tears when I spoke with them about what they were encountering. The human toll was significant as they struggled to keep the business afloat as the organization was bleeding cash.

When I returned from the visit I sat for a while trying to figure out what to do first. My manager and mentor saw that I was struggling, took me aside and asked me a question that I remember to this day – “what is your focus?”. Naturally, like any good PM, I answered, “I have to understand the scope of the problem areas, come up with some resources, schedule and costs to go solve the problems, but there’s so many I don’t know where to start”. He probed me again, though, by saying, “I didn’t ask what you are going to do, I asked what is your focus?”. That got my attention and he then explained that coming up with scope, schedule and cost is something we’re good at as PMs, but in order to deliver this particular project there were two things I was going to have to focus on, 1) the sponsor is going to have to hear the message that it’s going to take more money to get them out of the problem that had been created, and 2) the same people who created the problem are going to have to be the main source of information on how to get out of the problem. In other words, the two messages that no one wanted to hear!

As I look back on that experience, there were so many things that needed to be done but my focus turned to the impacted people and focus our efforts in a way that they could recover from the effects of the failure. By no means was I going to be able to change the circumstance, but we came up with an approach that was focused on fixing one big pain point to gain confidence and credibility with the team and sponsor, something that we could build on for future deliverables. From that point we then got the team and sponsor commitment to start tackling the other areas that eventually resulted in a stabilized platform.

If we were to use the Project Management Body of Knowledge subject area to refer to this, we will find a great reference for this in the discussion on “Sphere of Influence” (page 53). There’s a very good illustration in that discussion that I use to remind myself on all my projects where my focus lies. Primarily the influence I have as a PM lies with the project team, the resource managers, as well as other project managers and PMO staff. To a lesser degree I can influence sponsors and governance, and even to a lesser degree I have influence over customers, suppliers, end users etc.

However, that doesn’t mean that influence can’t be applied to those groups furthest from us in our sphere. Typically, we will have project team members responsible for those relationships and it is in the way that the PM influences the team that customers and end users, as an example, are then influenced. Our focus is in making sure we maintain our interaction primarily with the team rather than those for which we wouldn’t necessarily have primary influence. This is what happened as the team and resource managers gained confidence in fixing the one big pain point, as a team we were able to give the end users a sense of hope that we could deliver, which the sponsorship then bought into as well.

Know your level of authority. As we move from project to project, we find our levels of authority within the project can differ, sometimes drastically. When I was less experienced as a project manager I often thought if I only had more authority then I could be more effective as a PM. As I matured as a PM this attitude changed as I realized that I need to be able to be effective no matter the authority level on a given project.

Before we can understand how this impacts us, let’s take a closer look at a couple different aspects of authority:

  • Authority must be given; it can’t be taken. This is true regardless of what we do for a living and in all aspects of organizations – and life for that matter. Just as the government receives its authority to govern based on the articles in the Constitution, so does the project get its authority from the project charter. Spelling out the delineation of accountabilities
  • Authority always rests somewhere. You don’t have authority within your team as a project manager? Someone does! So, the question isn’t whether I need more authority to deliver the project, but rather understand where authority exists so I can influence appropriately for the best needs of the project. As we mature as project managers, we will learn how to identify the appropriate level of authority for our decisions, actions, issues and the like and influence or leverage that authority for the best outcomes for our projects.

Authority, however, should be proportional with the level of priority of the project within the larger scheme of the program, portfolio or organization. The higher the priority, the higher the level of authority the project manager should be provided. In fact, when I’m teaching project management at various venues, I like to say that if your project is of the highest priority you should act like it, but if it’s not, then don’t.

To illustrate this, I once had a project that the senior executive for that organization had stated was the highest priority project to deliver during that period. In fact, it was even prioritized above operations support, that is to say, the project team members were fully released from their support obligations and there were backfill resources for those support responsibilities. A couple of weeks into the project one of the resources managers came to a project team member and started getting them involved in a production support ticket. Naturally, I intervened and reminded the support manager of the priorities and the agreement that the team member was released. In reality, this was a challenge to authority that required resolution through escalation. Not a pleasant experience but something that I would be remiss if I had allowed the situation to continue.

Most situations are not like this, however. As project managers we most often find ourselves negotiating with resource managers for everything from, more time, system resources, team members or even conference rooms. Understanding priorities and the corresponding authority is key to effective negotiating in this regard. Negotiation is going to be necessary when authority is shared so that we can come to a collaborative solution that best meets the needs of the organization. Ineffective project managers will act as if their projects are always the highest priority.

Do the right thing…always. There’s no question in my mind that project managers are by their nature some of the most ethical, forthright and unbiased actors in a typical organization.The “skin in the game”, so to speak, for us is to deliver our projects rather than be invested in the long term solution. But there’s also a trap we can fall into where we get our validation as PMs from the results of the project. If we have a project that returns huge benefits to the organization we will probably be viewed by management as a truly great PM regardless of how we managed the project. On the flip side, we may not be viewed as a great project manager as the result of a project that didn’t return the expected benefits or was just a necessary scope of work where benefits weren’t expected.

Regardless of the benefits of the project, and in order to stay on course with our value as a project manager, it is best to seek that validation through other means. Personally, I’ve been through both situations. On some of my projects the business benefits were difficult to explain, for example, upgrading a network with new switches in order to replace end of service life equipment, and the business leadership was not enthusiastic about spending the money. There was one project with a low-cost barrier for adoption of a new technology that literally paid off the project costs within four days of full implementation. Believe me, the business leaders were ecstatic! All they could talk about was what a great project manager I was for that delivery.

If I can’t get validation on the strengths of my project management abilities from the benefits of the project, then where should it come from? Surely, we all want to know that we’re valued for our contribution. In that regard we are no different than any of our project team members. Here’s a couple areas to consider where you may receive some validation for your efforts.

  • Doing the right process, at the right time, in the right way. Project Managers at their core are problem solvers. We are problem solvers on how to manage the team to deliver effectively in any situation, with any team and in many types of environments. This means being flexible and adaptable to know what, when and how to leverage our process subject matter expertise in the project in a way that solves the problem. In doing this we gain credibility and respect of the team and our stakeholders.
  • Having a team that wants to be on YOUR project. This is one area where I’ve gained the most satisfaction as a project manager. If we want to know our value, then share the value you see in others! Everyone wants to know the value of their contribution. In teaching and consulting often I hear complaints about not having enough funding for recognition and rewards. To me, this is no excuse for not having a recognition and rewards plan. In fact, we should always seek opportunities to share the value we see in our team members no matter whether we have funding or not, often the things that people value the most are not necessarily quantifiable. In fact, I know we have arrived as a team when I see the team members recognize each other and share the value they receive from the mutual contributions. More on this in a later article called “It’s never not about the team”.

Projects are full of stresses that work against us. Often this may seem like we need to take shortcuts or move faster to meet the unrealistic demands of key stakeholders. This may be the most destructive things a project manager can have to deal with. We likely have had sponsors who follow the behavior where they always state milestones that they know are next to impossible to achieve as justification for “keeping the team focused”, or “if we let up people will get lazy” as two examples from my experiences. This is bad management to start with, and, at worst, destructive to people’s lives.

When things get tight on the schedule, though, one of the axioms I like to use is – “if we’re out of time then now we HAVE to do it right”. Or “shortcuts are never short”. We may have to be more expeditious in our delivery but do so by using techniques like co-location or teaming tools to facilitate communication rather than trying to transfer the stress that causes people to take those shortcuts. Communication yields collaboration and ultimately the PM connects the dots by integrating the work so that we can achieve those short-fused delivery dates.

In all these things we can take satisfaction in doing a great job as a project manager in delivering our project no matter the circumstance or how “sweet” the project assignment might be. It is primarily the team from which we can understand our value rather than the project or, for that matter, our sponsor. Accolades may come from the sponsor, which are nice and certainly affirming, but we truly understand the value of our contributions from how the project is delivered rather than directly tied to the benefits the project achieved.

Stay tuned to more in the series “10 Things I’ve Learned as a Project Manager” next week!

Dan Barringer