What is the Most Important Skill for a Project Manager to Have?

Srini was a veteran project manager, but had never coached a junior project manager before.  Sarah was a newly hired junior PM who had the right credentials and some experience.  They were at lunch and Srini was describing the organization, the key people Sarah needed to get to know, and the background for their project processes.  He was winding down when Sarah asked him, “What is the most important skill I should develop to be a successful project manager?”  With the cynicism that years of political maneuvering had created, he thought, “How can someone be so innocent?”

The introductory paragraph is fictional, but I encounter this question regularly on LinkedIn group forums.  I almost always want to throw my hands in the air and scream at the person who asked this question how they could be so naïve.  Or maybe they are intentionally trying to cause trouble and controversy.  Either way, the question is just So Wrong.

But then I sit back, let my breath return to normal, and pop a few Metaprolol (no, I don’t really do that).  When I’ve calmed down, I realize there is an appropriate answer to this question.  (Before reading further, do you agree that there is an answer?  If so, what would you say is the most important skill for a PM?)

Let’s break this question down.  A PM has to have a variety of skills across several domains:  political skills (for navigating successfully within an organization), social skills (for dealing with stakeholders and motivating team members), emotional skills and technical skills in both the project and product domains.  How can anyone say, conclusively, that any one specific skill in any one of those areas is most important over all of the others?

Further, PMs operate across many organizations, industries, cultures, etc.  And whatever conditions may be appropriate with a specific team, they change and evolve over time.  So how can anyone say, conclusively, that any one specific skill is most important over all these different environments and at all times?

Realistically, they can’t.  Except…

Let’s take a momentary interlude here.  In one LinkedIn discussion I followed on this topic, the comments eventually reached the consensus that soft skills were the most important skill set for contemporary PMs.  I don’t disagree that soft skills are important for success, but, well, doesn’t the question assume that you have the hard PM skills?  And that if you don’t have those, you’re not a PM and, thus, the value of soft skills don’t apply?  Or, from another approach, can you say that, universally, soft skills are always more valuable than other skills in all environments at all times?  I think anyone stating that is naïve.  I mean that this way:  there are environments and times that demand other skills that are more important (even if you don’t encounter those conditions very often) and, if you haven’t, then you naively assume that what you’ve encountered is sufficient.

Getting back to the discussion then, what is the answer?  Is it flexibility?  I think that’s a good answer.  The PM often has to be flexible about how they mix and match the skills on a particular project or assignment, but, as good as this answer is, I don’t think flexibility is the best answer.

My vote for the best answer to the question “What is the most important skill for a PM?” is Balance.  Balance so accurately describes what we do:  we have to balance the inflexible demands of the iron triangle of scope, time and money.  We also have to balance our approach to each project to deliver precisely the right mix of soft and hard skills appropriate to that situation.  We even have to change at different times during the project which skills we present. 

If I answer otherwise – if I name any one skill – that indicates that I believe that one skill is universally more valuable than any other skill, which just is not the case.  It is the complete mix of skills, appropriately stirred, combined and presented in the right way at the right time that makes for a successful project manager over many projects over a long and successful career.

© 2014 Chuck Morton.  All Rights Reserved.

The Tailoring Rule

"Professionalism is knowing how to do it, when to do it, and doing it.”

                                                                                                - Frank Tyger

When people choose to complain about project management, one frequent refrain is the burden and overhead of all that process.  (I believe this is often a red herring, used by detractors who are concerned that project management best practices will expose their delivery weaknesses, but today’s discussion is to address the valid concerns for appropriate levels of process.)

A typical organization does many different types of projects of different sizes, styles and complexity.  For example, an IT department might have projects for:

• Infrastructure
• New software development
• Enhancement and maintenance
• Product selection, acquisition and installation

Since all projects, regardless of size, style or complexity have many common elements necessary for success, does that mean that the organization only needs one methodology?  Well, yes.  And no.

If the organization has one bloated methodology dictating that all projects must produce all deliverables from identical templates, then those people who complain about too much process have a (partially) legitimate complaint.  It’s legitimate because for most projects there will be too much process, but they are complaining about the wrong thing.

However, there are so many common and essential elements for project success that no organization wants to manage multiple (many?  dozens?) of different, but similar processes.  How to resolve this contradiction?

Both SEI’s CMMI and PMI’s PMBOK® Guide provide for Tailoring.  Tailoring is an important but rarely formally practiced principle.  In fact, in all of my years of consulting across a broad range of companies, I’ve encountered numerous cases where formal practices are ignored or circumvented because they are too onerous or just irrelevant, but in only one case have I worked at an organization that formalized process tailoring.

Even the description in PMBoK does little to suggest that the organization should establish tailoring in the formal processes:  Initiation and Planning includes “guidelines and criteria for tailoring the organization’s set of standard processes and procedures to satisfy the specific needs of the project” (27).  This description makes it sound like tailoring should be done inside the project to customize the organization’s standards rather than that the organization’s standards should specify the tailoring appropriate to different projects.

For example, an IT software development project, an IT software implementation project, an IT infrastructure project and a business process redesign project all have many similarities on how they should be run (they should all have charters, business cases, status meetings, risk logs, change management, etc.), but also significant differences (a new software development project won’t need the RFP activities in the implementation project and the BPR project will need a host of training and documentation activities that will not be needed for a back-office infrastructure project that has no end-user visibility).

Further, for a sufficiently small project, the charter could be fully contained within an email and the change approval process will need to be sufficiently streamlined, since long decision timeframes would jeopardize the delivery of the project.  In contrast, a long, complex, risky project wouldn’t want to make change decisions too informally or too quickly.

The process burden needs to be appropriate to benefit the project – designating those best practices that best assure project success – while addressing project risk without over burdening the project.  A requirements document for a small project might be a few pages, whereas the requirements document for a large, complex project could be a tome, with sections and subsections for business requirements, functional requirements, technical requirements, non-functional requirements, etc.

One size does fit all in project management, as long as that one size addresses the principles of successful project management.  (Is that a tautology?)  Organizations with best practices are clear about what processes are required and how those processes are customized based on type of project, complexity, size, risk.

The mistake often implied by those that complain about excessive process is that the situation would be better if there were no process.  But processes evolved because lack of process (chaos) could not be relied on to consistently deliver successful projects, whereas the use of the processes improved the project success rate.  The solution to excessive process burden (or bad process, for that matter) is not eliminating process.  Rather, the solution is to fix the process through lessons learned and continuous process improvement.

Of course, organizations are even worse at lessons learned and process improvement than they are at projects.  Look for my eventual series on lessons learned to address just this subject.

© 2014 Chuck Morton.  All Rights Reserved.