Good project managers wear many hats

When I first started to manage projects, I had envisioned the role as being similar to that of an orchestra conductor – while not being directly responsible for playing specific instruments, possessing familiarity with the strengths and weaknesses of each, and being instrumental (pun intended) in creating harmonious melodies instead of raucous cacophonies.

This illusion rapidly dissipated after a few days on the job.  I came to realize that project managers need to be like Lon Chaney – the man of a thousand faces.  Here are a few of the roles that a PM might be called on to play in a typical project.

1. Salesperson - Successful PMs need to be able to create a need for and “sell” their customers, stakeholders and team members on decisions or recommendations that may not be popular.

2. Football lineman – A PM must often be the offensive lineman preventing their “quarterbacks” (a.k.a. team members)  from getting tackled by distractions.

3. Coach - Vince Lombardi nailed the essence of effective project management with his quote “Coaches who can outline plays on a black board are a dime a dozen. The ones who win get inside their player and motivate.”

4. Diplomat - PMs are often called upon to help resolve conflicts, negotiate for win-win outcomes and to deliver bad news in a constructive fashion.

5. Historian - PMs should be able to review the past life of their projects, analyze events and derive lessons that can be applicable to future projects.

6. Diagnostician - PMs require the analytical ability and perspective to look beyond symptoms to help identify the root issues that are plaguing their projects.

My guess is that there are probably a hundred other roles that could be part of this list – how many can you add?

Forewarned is forearmed – the rationale for risk acceptance

A close variant of the saying “Forewarned is forearmed” has origins dating back to the 1500′s (and possibly even earlier).  This came to mind when evaluating the role of risk acceptance as a valid risk response strategy.

Risk acceptance is often treated as the odd cousin thrice-removed that no one wants to remember or mention in polite company.  The terms “acceptance strategy” itself appears to be an oxymoron  – acceptance conjures up thoughts of inertia while strategy inspires action.  While documenting their risk registers, project teams feel good about those risks that can be mitigated (good), transferred (better) or avoided entirely (best) – acceptance seems a weak approach and they fear that sponsors or stakeholders might view the team in a poor light for bringing them problems instead of solutions.

Such environments are clearly risk immature – it is unrealistic to expect that all “known unknowns” can be controlled on anything other than the most basic project.

So what are the benefits of the risk acceptance strategy?

1. Communicating a risk is of benefit even if we can’t do anything about it.  We are better able to deal with “known unknowns” than truly unexpected events.  The latter often causes us to instinctively use our lizard brains resulting in fight-or-flight decisions that (should) have no place in business situations.

2. Acceptance does not mean “do nothing”.  While little might be done actively in advance of a risk being realized to reduce its probability or to diminish its impacts, nothing prevents a project team from preparing contingency plans to be executed if it is realized.  In many environments, an acceptance strategy may have a better chance of success than a more active one – proactive risk response plans are often not executed due to a lack of priority or resources, but developing a contingency plan may be more palatable.

3. Avoiding deja vu.  A risk that is accepted on today’s project might be one that could be actively addressed on a future project.  Risks of any sort are a good source of lessons learned, but accepted risks need to be considered with greater gravity if we don’t want to repeat past mistakes.

Perhaps the issue is with the term “acceptance” itself – maybe the next edition of the Guide to the PMBOK and the Project Risk Management standard might consider a less fatalistic term such as “acknowledgment”?

Which should you start with – Project Portfolio Management or Project Management?

It’s often assumed that Project Portfolio Management (PPM) should only be introduced into organizations that have first achieved standardization and consistency with project management.  This is logical as “doing the right projects” is an academic practice if you cannot “do projects right”.

Here are some justifications for introducing PPM in parallel, or even in advance, of improving your organization’s project management capabilities.

1. If resource availability is a common source of risk to the successful delivery of your projects, reducing multitasking by focusing resources on higher value projects may improve the estimates of resource availability, which in turn could improve project predictability.

2. If your organization suffers from invisible sponsors (see Overcoming Project Management Super Villains), PPM might be a good way to “encourage” real commitment.  When sponsors realize that their projects will get axed if they aren’t fully engaged, they will be more likely to support their project managers.

3. Clarifying scope and expectations for a project can be a painful, effort-intensive activity for project teams.  Introducing a consistent project intake and evaluation process can front-load this effort before the project team has even been assigned.

4. Focusing and motivating their teams is a common challenge for project managers.  This challenge is aggravated when the team is asked to work on a project that appears to be of limited value or when the project is not treated like a priority by sponsors or stakeholders.  With appropriate project intake and prioritization practices, the rationale for projects should be obvious so that he project manager can effectively communicate the benefits the project will have to both the organization and to individual team members.

Like the age-old question of whether the chicken or the egg came first, with PPM and project management, either option is viable with the right context!