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?

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?

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?

Advice for Junior PMs – #8 – Status meetings are boring

I know this might be a bit of a controversial topic, but your status meetings are boring.  As someone who runs these meetings, I know it.  I can see it in my team’s eyes.  They hate it; they are coming up with responses that could be covered off in an e-mail to answer the same questions that I have each week; and find that it kills their productivity.

Advice for Junior PMs – #7 – Keep your lessons close at hand

As a junior PM, you likely haven’t managed that many projects (call it less than 10 for argument’s sake).  As you go through these first few projects, it’s fairly easy to remember what the project was about, when risks became issues, and all of the lessons that the team learned.

However, as you get into more projects, the early ones start to blur together, the lessons you have learned start to evaporate, and you cannot remember which SME was responsible for which area.  This becomes especially problematic when you are asked to work on a project like one that you had worked on previously, and the only thing that you can remember about the project is that you wore brown shoes to that one meeting…

Advice for Junior PMs – #6 – Starting your own Project Management Knowledge Book

One of the Project Management RSS feeds which I read had an interesting article in it (it looks like a recycled link, but was new to me).  The article stated that in order to continue growing in your project management career, you should start keeping a binder of your best practices.

Given that I’m not particularly into dead tree and lugging a binder about, I fired up Google Docs and started a new file.  I spent 30 minutes hammering out everything I could think of as a best practice.

My first line item, which came from a fortune cookie that I have taped to a photo frame, was Promise Only What You Can Deliver.

Advice for Junior PMs – #5 – How the PMO can help you succeed

It is day two on your first large project. The business case for the project has been presented to you, and you are driving your team to give you an estimate for everything that needs to happen for the project. Whether you are running Agile and creating a backlog, or running waterfall and defining your phases, you have tasked your team to give you a firm estimate on exactly what the project activities will be and how long the project activities will take.

Stop. Time out. You’re about to let your team know that you secretly want them to fail (even if you don’t) and let your sponsor know that your estimates can’t be trusted.

Advice for Junior PMs – #4 – Do not be afraid to communicate risks that have become issues

You saw it coming. You captured it in the risk register, reviewed the mitigation plan with your team and had them alter some of the response strategy. It’s even part of your status report. And then the risk event occurred, but you didn’t know how to have the conversation with your project sponsor.

I understand. I’ve had some awkward conversations myself. It can be intimidating to walk into your sponsor’s office for a status update and having to try to (not so subtly) clearly say that you will need more money, time, or resources to properly respond to the risk event and keep the project on track.

Advice for Junior PMs – #3 – The value of a kick off meeting for a small team

Culture eats Strategy for Breakfast – Peter Drucker

As a junior PM, you’re likely not going to be given a multi-million dollar mega project.  You probably won’t be managing more than 3 or 4 people for your first few projects.  If you have a project that lasts longer than 6 months, you’re the exception, not the rule.

So why, then, even though your small project was more likely to be successful than some of the larger ones, are you not feeling that elation and BFF-ness with your project team once things wrap up?  Quite frankly, it’s because you, as the Project Manager, did not take the lead proactively setting up the culture of your project.  Culture tends to devolve to the lowest common denominator – which isn’t a bad thing when you are surrounded by awesome people, but can really suck when you are assigned a couple of bitter cynics.