The Art of Getting the Things Done

As a Project Manager, most of your energy is focused on how to get things done. For some of us there is where the inherent beauty of Project Management resides. It avoids the comfort zone and parsimony that ongoing operations inevitably bring with them. You are given a goal, a time frame, a set of (scarce) resources, a (big) bunch of constraints, and you are expected to scramble them as best as possible to make it all happen (or to elaborate a strong case on why it can’t happen). You are done and you are gone. If you like action movies you can’t help but to think about cops and SWAT teams when you think of Project Management on those terms. There is something exciting about it.

There is another thing about Project Management that is not that poetic. As a Project Manager you will usually play in matrix environments where your team is not really your team. Most likely they will be reporting to other team leads and functional managers that may or may not be aligned with the priorities of your cherished Project. You have some authority but that authority comes with certain restrictions. You need to use it with decision and wisdom. Sometimes you need to push and sometimes you need to let go. 

This is probably why one of the things that set great Project Managers apart is the core belief that they have the right level of authority required to make things happen, as Andy Crowe describes in his book Alpha Project Managers. As I spoke with him during a conference last year, the most interesting thing would be to know if these Project Managers had that authority or not in reality. From my perspective it doesn't really matter. The point is that this belief and their skills allow them to manage Projects in a successful way. 

In the same way, managing yourself in a matrix environment where your authority has inherent restrictions is a mix of art and principle that relies heavily on something named an Escalation. Escalations deal with the subtle question of who has authority over whom and when a higher authority level should be invoked to get things done. 

Who is who? – People get things done. Nothing else does. So, one of your first priorities to get things done is to understand who does what and which their chain of command is. Who is the team lead? Who is the functional manager? Who is the team member with the right skill set? Who is available when? Do all of them belong to the same team or are there different teams involved? You must gather this information and put it in an easy to action format like a Contact List or Project Directory. 

This list will be a key asset when you deal with the most favorable scenarios where the team is sharp and ready to collaborate with you and the Project. So you just only need to concern on who is doing what, when and which issues do they have. If you come into least favorable conditions, where for some reason that synergy is broken, this information will serve as the starting point for the escalation process. You want to make sure to bring the right thing to the attention of the right manager above your assigned team members. 

You must deal with something – being a Project Manager is much more than asking all the time for fully digested and crafted information to use as an input for reports. Should this be the case, you would be nothing more than an escalation gateway. You would be providing a very poor value to your team and organization. As a Project Manager you need to understand and execute the Project Management process for the life time of the project. There are things that are not to be escalated because those things are your job. 

You are responsible for sitting yourself with the team and work out activities, durations and schedules. You are responsible for triggering scope discovery meetings with the business if there is no full clarity on what is the scope of an endeavor. You should challenge the team’s estimates if you have factual basis to question them. You should action on any blockers they may face to get their things done. You should catch the scheduling conflicts ahead of the curve. 

If you come each and every time with the statement that you were expecting more information to do your job, or if you are escalating everything under the sun, you can start by questioning if you are really managing your Project. 

Use your judgment – Deal with the right things will put you in a better position to decide on the escalations you need. Escalations bring some visibility and noise with them. That’s the whole point of triggering them. You escalate with the expectation that the added visibility and noise will allow you to align things for the greater good of the Project. You need to use your judgment to decide the right things to take to the upper levels for action and which things should you keep within your own range of action. Escalating trivial things or escalating too many things at the same time will create a harmful level of noise. You will transmit a sense of blurry management and instability to the stakeholders. You want to get things done but nut at such a cost. You should balance your priorities carefully according to the needs of the project. 

Don’t jump too high too soon – once you decide that something is important enough as to justify the effort required for an escalation, you should reach the next upper level. Try to avoid escalating two or more levels at a time since it can be counterproductive. You don’t want to jump too high too soon. You risk falling down unnecessarily. Also keep in mind that your colleagues at that level need some time to align them and to align the team around the needs that you have conveyed. If you were clear about the criticality of the time frames required and they said they will action on it, give them some room to proceed accordingly; even if you become anxious as the deadline approaches. 

Escalating Attitude – An escalation is asking for upper management collaboration, it is not a complaint or a trial against the team. Even if you are disappointed by the lack of results, make sure to act in good faith and judge the team in a good light. You may have failed to clarify how critical a task is, you may lack context on what the team is doing or why are they taking a given course of action. Even when you escalate do not take for granted that you must be right or they are wrong. What you want to do is to align everyone involved to get the things done as required. 

Making a Good Case – As I mentioned above, escalating trivial things or escalating too many things at the same time will create a harmful level of noise. You will transmit a sense of blurry management and instability to the stakeholders. Equally as important as your decisions on what will get escalated is the case that you build to justify an escalation. You want to provide concise and clear data to the stakeholders. So they can understand what do you need to happen, why it is critical, what will be the impact if they don’t action it, and when do you need it. If there is a complex technical issue blocking the team, you don’t want to tell the managers the entire novel on why the pieces are not working together. You need to emphasize what the result the issue is blocking, what is the impact and what the team needs to remove it. You will only waste time, energy and focus narrating the novel to the stakeholders. 

Ask for upper Feedback – Some time ago I required a technical answer before moving on with a deliverable. I exhausted my due diligence to get the answer from the team and I escalated. The escalation reached a high level quickly, something I was looking for since that prevented us from tackling a task on the critical path. My escalation was about to reach the highest person on the command chain, when my upper manager dismissed it and returned it back to me. Man, I was disappointed. Nevertheless I considered that my manager had a better line of sight than me. So I asked privately what I was not seeing. He candidly told me: we play the role of experts here. We don’t want to knock on the door of the highest rank around asking if he can get an answer for us. That means we don’t know. So get back and perform another round with the team to get that answer. That’s the kind of advantage that upper feedback can do for you. 

Cheers! 

- Sergio Calvo.