Advice for Junior PMs #13: Let your team do work…

Meetings, bloody meetings. How many times have you looked at your calendar, as a PM, to only be exasperated that you have 16 meetings in one day, and your main milestones are close to being late? How about 8 and you are dealing with major issues? And how many of these meetings have your primary team members as mandatory attendees?

Running the delivery/build phase of a project like this is a trap and a self perpetuating cycle. It’s a sure sign that your project is either moving too fast, has not given enough consideration for planning (either requirements elicitation, technical design, or user story grooming), or is generally understaffed.

“But I have milestones to achieve and deliverables to complete!” I hear you say.  I understand; we all have top down pressure to complete projects faster with less resources.


Scheduling multiple meetings every day is not a good way to help you move faster… It’s a very good way to slow work down, though.  I see Junior PMs do this all the time, and then get frustrated that no work is getting done.

So how do you break this vicious cycle?

  1. Understand your team’s capacity – a lot of system delivery projects have one team doing most of the work.  Really understand how much work they can take on at any given time before committing to getting work complete.
  2. Finish one thing at a time – scheduling multiple deliverables to complete at the same time is a sure fire way to lose focus on everything and slow work down. Get one thing done before moving on to the next.
  3. Break your project down into smaller chunks – by doing so, you can reinforce items 1 and 2 above.
  4. Set expectations accordingly – the number 1 job of a project manager is expectations management.  Your customers, sponsor, and team should all be on the same page far as priorities and delivery pace are concerned. If you can’t meet the pace, get more people and delegate task management accordingly.
  5. Stop scheduling so many meetings – you should have less meetings.  Figure out how to give your team their working time back, and they will get more work done.

When in doubt, stop work, circle the wagons, and figure out your design/plan/goal for the next package of work.  It will save your sanity and help your delivery pace in the long run.

Having a Project done to you (aka Empathy for your sponsor)

What happens when a Project Manager gets to sponsor a project?  Should they try to wrest control, micromanage, and get involved in the planning sessions?  Or should they try to sit back and trust the person leading their project?

Oddly enough, many project Sponsors that I have worked with have previously managed projects themselves before moving up in the organization, and this is a conundrum that they have to deal with each time they start working with a new Project Manager.

It’s pretty rare that, as Project Managers, we are the clients or sponsors of project.  Sometimes there are interdependencies – especially if working on part of a larger Program – but rarely are we the principal client.  To truly become a Senior Project Manager, I would propose that you sponsor a project using your own money with a big impact on your life.

Recently, my wife and I hired a General Contractor to complete some renovations to our house.  Because we had been talking about these renovations for a while, she and I had sat down and listed out exactly what we wanted done – from the layout of our kitchen to paint colors to where we wanted a wall moved.  We had what we thought were a comprehensive list of requirements.

We interviewed 3 General Contractors, and hired the one that brought his team of trades out to site to review and provide input to the estimate.  One line item on his quote was “Project Management – 20% overhead”, which made me feel comfortable that he would be involved in managing schedule, scope, and budget.

Except he wasn’t.  As the project commenced, we learned ours was one of the first residential jobs that he had completed after years of managing commercial jobs.

There were problems with his project management, and there were problems with his assumptions about some requirements that we did not state in our scope.  He worked hard trying to keep things moving, and even chipped in to help the trades, but clearly had not worked on a project like this before

Every schedule that was presented was wrong one day after it was presented; eventually he gave up giving us a schedule and the trades would show up when convenient for them.  When we asked him about the assumptions he was making, he said he wasn’t making any assumptions.  When we asked him about the risks, he said the only risk was weather.  After a few weeks on the job, he came back asking for more money as his original estimate was too low.  We also had his trades asking us directly to get paid, as he hadn’t paid them.

A bathroom in our basement that we hadn’t really given much thought to caused further problems.  We came home one afternoon to find that he had instructed his trades to install a t-bar ceiling (think office ceiling tiles) in our main bathroom because it would be faster to install and be easier for accessing plumbing in case of maintenance required.  We weren’t consulted on this decision and had to stop him as he was buying materials.  He was visibly frustrated that we didn’t agree with his tactic or guidance from his years of working on commercial properties.  He didn’t get that we wanted a bathroom to match the other ones in our house, not a functional public washroom.

No matter how much we challenged, pushed, or complained, we could not influence how this General Contractor was managing our project.  At points, I would try to give him basic tools, such as a calendar, to help illustrate when certain pieces of work would be done; but this was to no avail.  As quality fell and delivery slipped well passed the planned completion date, we were being backed into a corner to approve a change request else our project would not get done.  We were having a project done to us.

After this experience, I had so much more empathy for all of my past Project Sponsors.  How many times has a project sponsor been able to foresee danger, doom, peril, or missteps given their depth of experience that I did not?  I can think of a few projects from very early in my career where I was doing a project to my Sponsors.  I now understand their level of frustration for the times that I went back for more money and time (even if it was due to known risk events).

Your responsibility, as a Project Manager, is to understand the expectations of your Sponsor and present to them a single plan to deliver your project.  You must ensure that your assumptions are communicated (which is a two-way process), and be sure that the risks are well understood for how they can impact the project.  You are doing this project FOR your Sponsor, not TO your Sponsor.

Have you ever had an experience that has given you empathy for your Project Sponsor/Client?

The Essentialist Project Manager

When I first picked up “Essentialism: The Disciplined Pursuit of Less” by Greg McKeown, I was reading it to help me work on managing my time.  I had become over-committed to many things – full time job, sessional instructor at the Haskayne School of Business, volunteer work, mentoring, mentee-ing – all over and above family life.  I wasn’t spending much time with my wife, I hadn’t seen my friends in weeks, I wasn’t spending any time on my fitness, and I was constantly running from one meeting to the next while trying to keep 4 projects on track.  Something had to give before I was totally burned out.


Read more of this post

Advice for Junior PMs – #12 – Proper Risk Management will make you more like Sun Tzu

Have you ever seen a Project Manager lose their job because of not managing risks?  Usually, a PM will be let go because of multiple schedule delays or cost overruns, but rarely do you hear office gossip about someone being fired because they weren’t managing risks.

However, if you break down how multiple schedule delays or cost overruns happened, it’s usually due to a few small risks that went unmanaged.  Most companies that I have worked with take the view that only the highest impact/probability risks should be listed, and everything else is not worth noting.  Others have the culture of listing risks only that are timely (i.e. could impact the next reporting period), and others still have the culture of listing no risks whatsoever lest it impact the optics that the project is perfect.


It’s because of this that when talking about status reports with Project Managers that I am responsible for (either at a Program Management level or that I am coaching), my first topic of conversation is always about the Risks section. I try to re-iterate to them that incentivizing PMs to only focus on “big” or “visible” risks opens the project to the cognitive bias of risk homeostasis – that is, if the most visible risks are “managed”, we don’t need to do anything else.


In the Art of War, Master Sun’s statement regarding winning the battle by making no mistakes is one of the most important lessons for a Project Manager regarding planning and risk management. “He wins his battles by making no mistakes. Making no mistakes is what establishes the certainty of victory, for it means conquering an enemy that is already defeated.” (The Art of War, Section IV, point 13.)

Mistakes in the context of battle mean that resources are wasted unnecessarily; mistakes in the context of Project Management means that the Project Manager has missed important or key details that impact the project’s success, ultimately wasting resource.

Thus, I counsel Project Managers to assess all tasks for the risks. When developing the project schedule and work breakdown structure, look at all tasks for worst case “what can go wrong” scenarios, identify the mitigations, build that time into the schedule and cost into the budget. “If, on the other hand, in the midst of difficulties we are always ready to seize an advantage, we may extricate ourselves from misfortune” (VIII, Point 9)

It may sound simple, but it surely is not. It takes time, commitment from your team to working through the exercise, and your attention to focus on all risks in both the short and long term time horizons of your project’s schedule. Knowing – truly knowing – how to respond to risk events, and having your team know how to react implicitly will spare you and your team from the churn, will demonstrate to your sponsor and client that you have planned for eventualities, and can help you keep your job if you need to draft a change request.

“Hence in the wise leader’s plans, considerations of advantage and of disadvantage will be blended together.” (Section VIII, Point 7)

Advice for Junior PMs – #11 – Plan for Transition to Operations as early as possible

How many times have you heard the expression “tossing the football over the fence” related to something that your project is building? In the world of projects, this expression ultimately means giving accountability/responsibility for maintenance and support to a group different than the project team. Some members of the project team may transition to support roles; but ultimately the group that will have to own the product/service will be different.

Having worked with a myriad of maintenance managers – both technical (IT) and construction focused – the common complaint of Project Managers by Maintenance Managers that are so focused on delivering on time/on budget/to scope is always the same: “they have surprised me with something new to what we are doing, and I don’t have the staff to support something new. We’re simply not ready.”  Similarly, the common complaint of maintenance managers by Project Managers is that: “they are so difficult to work with.  They have these silly requirements that will add so much work to the team.”

The lesson from Clayton Christensen’s “How will you measure your life“, as well a whole group of academics and business leaders, is to not wait to build capabilities for when you need them, but to build the capabilities as soon as practically possible so that they are available for use when you need them.

What does that mean in the context of projects? How can you avoid the pain?

1. Know your scope
If you haven’t considered transition to operations as part of your scope, you don’t have the complete scope for your project.  Ensure that you work with the maintenance team to document exactly their requirements for transitioning to support, and update this document if any changes occur throughout the project.

2. Early engagement
When you first start scoping a project, figure out who the supporting organization will be, and give them an information session. Allow them to ask questions. Give them the proposed timing for your go-live. Talk to them about what they will need to support. Help them understand how you will be changing their world, and ask them what you can do to help them be successful.

3. Build Tools
As you work through the project, start thinking about the support materials that the project will need to build for the maintenance organization. Do you need quick reference guides, process documentation, screen shots of a new application, central repository of safety documentation, or something else entirely? And just like you would with the product itself, be sure you review these deliverables with the support organization.

4. At time of go-live, involve the support organization
Involve the support organization when building production servers, commissioning communication towers, performing installs on users’ computers, inspecting sites, or anything other major deliverable activity to highlight what has been delivered, what your client/customer/users are experiencing, and to start the transition away from the project team to the maintenance organization.

5. Get sign-off
There is no worse feeling than doing a good job, only to have someone come back and challenge you as to whether you did the job at all.  Get sign-off on the document that you developed in point #1 above.


As a project manager,its your job to ensure that your team’s achievement of transitioning to support is well planned an executed.  What other strategies have you used to make transitioning to support painless?

Reference Info Only – Hours Available by Month

Because I am building so many cost estimation templates, I need a quick reference table that I can easily copy and paste.

Possible Working Days Canadian Stat Holidays Available Days Hours
Jan-15 22 1 21 168
Feb-15 20 20 160
Mar-15 22 22 176
Apr-15 22 1 21 168
May-15 21 1 20 160
Jun-15 22 22 176
Jul-15 23 1 22 176
Aug-15 21 1 20 160
Sep-15 22 1 21 168
Oct-15 22 1 21 168
Nov-15 21 1 20 160
Dec-15 23 2 21 168
2015 total 261 10 251 2008
Jan-16 21 1 20 160
Feb-16 21 21 168
Mar-16 23 23 184
Apr-16 21 1 20 160
May-16 22 1 21 168
Jun-16 22 22 176
Jul-16 21 1 20 160
Aug-16 23 1 22 176
Sep-16 22 1 21 168
Oct-16 21 1 20 160
Nov-16 22 1 21 168
Dec-16 22 2 20 160
2016 total 261 10 251 2008
Jan-17 22 1 21 168
Feb-17 20 20 160
Mar-17 23 23 184
Apr-17 20 1 19 152
May-17 23 1 22 176
Jun-17 22 22 176
Jul-17 21 1 20 160
Aug-17 23 1 22 176
Sep-17 21 1 20 160
Oct-17 22 1 21 168
Nov-17 22 1 21 168
Dec-17 21 2 19 152
2017 total 260 10 250 2000

Advice for Junior PMs – #10 – Manage the project, not the sales process

This is a special professional services edition…

“Jenkins, we need you to manage this bridge building project.”
“Got it.  I’ll get the team together to meet with the client and spec out some requirements, and then get back to you with time, cost, and scope estimates.”
“No need.  You have $100 and 2 months.  But definitely collect their requirements and make sure you deliver to those. I think I heard something about them wanting it to support tanks and allow boats to go under and maybe have some color changing lights on the side.” 

Sound like a familiar set of circumstances?

As a Project Manager, it is not your responsibility to try to meet ridiculous scope, cost, or schedule requests.  It is your responsibility to represent the truth, to do what is right and honorable, and to act in the best interest of your project.

The first, and most obvious thing to do, is to challenge Business Development on what they are trying to sell.  In a formal setting, using documented facts (not conjecture), and always in a respectful manner, communicate your concerns with the unrealistic expectations.    However, this often fails given that almost every single project manager in professional services has been put in this position once or twice before.  Someone in business development has made a commitment to a client, who has made a commitment to their superiors, that something realistic can be delivered in an unrealistic amount of time to an unrealistic budget.  And you wonder why consultants get a bad name

So what do you do as a Junior PM stuck in this position?  Manage the project, not the sales process.  Once Business Development has sold the project to the client:

  1. Communicate information early and often.  
    It will do you no good at the end of the project to say “see, I told you so!”  Someone will try to punish you for making Business Development look bad (because they are the golden ones who wine and dine clients), so you need to ensure that you have covered your ass from the outset.  Formally document your thoughts around delivery, and communicate them to your senior manager (be it a PMO lead, line of business lead, or practice lead).
  2. Work to build your client’s trust through your expert project management skills.
    This means not just being a glorified project controller, but rather working as a leader of both your team and your client.  Involve your client in planning activities so that they can see what is required for successful delivery.  Invite them to status meetings to hear what the team are working on.  Be honest in your status reporting.
  3. Lead by example.
    Ensure that your team are focused on delivery and not complaining about how the budget sucks or the timing is ridiculous.  If you demonstrate the “we can get it done” mentality, your team will start to as well (within reason.  They are not dumb, after all…)  However, ensure that your team are recording the actual hours they are working, and what they are working on.

Indeed, this is a tough spot to be in.   Do not worry too much about the project economics.  Either your firm will be ok with eating some hours to ensure successful delivery (likely through you ghosting some hours in activities like “learning and growth” or “general management activities”), or your client will be ok with a Project Change Request to increase your budget once you start to deliver like the rockstar you are.

It may be stressful (and not the good kind) to go through this type of experience.  But a lot of us have been there before, and have lived to tell the tale.

Have you been in this uncomfortable position before?  What other advice would you give to Junior PMs?

What type of Project Manager do you want to be?

Have you ever worried that you are haphazardly grasping at a path?  Becoming the type of Project Manager that is sought after as a trusted adviser doesn’t just happen.  You have to be deliberate in defining the type of Project Manager that you want to be.

Read more of this post

Advice from a Project Manager on delivering “Business Value”

Ever so often, I poke my head up from my projects to review what’s going on in magazines like HBR, CIO, and Forbes.  In this recent round, I came across a “trend” that directly impacts the projects that I have been working on – Justifying the Business Value of IT.  These articles, though, are focusing on all of the same topics that we have been kicking around since Y2K – delivering to expectations, managing customer demand, and providing professional service.

As someone who has worked with IT (either in, for, and managing) for the majority of my career, I really don’t want to get into the argument of whether IT matters or not, because it does (like any other service organization).  However, I have only ever worked with one company where IT was not the “problem child”.

Successfully managing IT should not be a hard task, but is often made complex due to an unmanaged gap between expectations and reality.  More often than not, IT does it to themselves by not understanding their clients, the constraints of service delivery, and remaining aloof with a black-box mentality.

I would like to offer some advice from a Project Managers perspective on how to run Corporate IT.

Read more of this post

Advice for Junior PMs – # 9 – Choosing the right project

Early on in my career, I was given the very sound advice of “Part of being a successful Project Manager is choosing the right project.”  Up to that point, I had either been very lucky (approximately 70% of IT projects are failures per a 2008 statistic) or just really really good at what I do (but I’m leaning towards luck with just a hint of skill).

This advice has proven more and more true (and I can see it more and more as projects go on) for me as my career has gone along.  But what makes the right project? Read more of this post