One of these skills you can learn over time, the other you cannot. I love to read project management methodology books, blogs and process flow charts. People are extremely creative in making project management the most complicated process on the planet. CMM for PM, Agile Project Management, PRINCE II, and you can even buy software that will allow you to create your very own methodology for PM. Maybe PMs feel under appreciated and unloved. They want people to recognize their special skills, bag of tricks, templates, flowcharts, power points, MS Project plans, etc.

Don’t get me wrong, a good PM is a valuable asset for any project. We also need to be organized and understand some basic processes that must occur in any project for it to be successful. We are, however, sometimes a strange bunch and tend to try and make things overly complicated.

I remember a project manager being hired from a large firm to handle a rollout of about 2000 desktop PCs to replace existing PCs. He came with his very nice suit (suits make the PM obviously. If you don’t have a good suit you can’t possibly be a good PM right?). He came with volumes of methodology, plans, rollout schedule templates and a huge deck of power point slides and a fancy software Excel to MS Project tool. He made it known that he had done this many times and had always been successful. Two weeks in to the project I ran in to Mr. PM in the hallway and he was practically in tears. His project management methodology required, mandated even, that you MUST have certain data elements for each and every PC deployed or the entire process broke down. The spreadsheets didn’t work, the schedules didn’t magically generate and all hell broke loose. He discovered in the real world of the company in which he had landed there were many unknowns. These unknowns drove him and his process crazy.

1. He HAD to know physically where each and every PC was located. This particular company didn’t have a good inventory. In fact, they were not exactly how many total PCs they had and were definitely not sure where they were all located. In addition, there were to be some PCs deployed in locations that heretofore didn’t have one. Well, maybe…you might get there and find out there is one there and in that case you’d need to swap it out.
2. He had to have an assigned user for each and every PC. This particular company had PCs on the manufacturer floor shared by multiple users and there was some question as to exactly how they would handle profiles.
3. There had to be one, and only one, cost center associated with each PC to be placed. You can imagine how well that went.

He had a great process. No doubt about it. It was tailored and honed to a fine tool in an environment where the PC world was a well known and well regulated environment. It just buckled under the weight of real world situations that most PMs deal with gracefully (in public at least) and deftly (don’t let them see you sweat). You’ve seen similar examples of methodologies that are touted to handle particular environments and criteria. They are the answer to your prayers. Well, if you knew exactly for what you were praying that is. I’ll let you in on a little secret. There are two skills you need to successfully manage a project. Two skills. Two skills required to be a successful project manager and maximize efficiency. You can manage a project without these skills but you will not be as effective.

1. You must be able to create, grow, nurture and maintain real people-to-people relationships. You have to be a people person. You must possess skills of empathy, compassion and understanding. You must be able to see people, not resources; people, not work units; people, not 8 hour blocks of time. People in all their foibles and complexities.
2. You must be able to communicate effectively.

That’s it. That’s all you need. Skill #2 you can learn. Skill #1 you cannot. That’s my opinion. Think back on any time in your PM career when you’ve walked in to an office of any team member, sponsor, stakeholder, etc. and said “There is a problem with the project.” If you have absolutely no relationship with the individual, you will spend hours or days wading through all the emotional baggage and overhead that is associated with that simple statement. The person you are addressing will potentially thinking many thoughts:

• Is the PM trying to blame me?
• Who IS to blame for this problem? You have to assign blame right?
• Am I going to be expected to pick up slack for someone else who has dropped the ball?
• How do I keep management from knowing that there is a problem? How do I keep this a secret?
• Am I going to be accountable for this “problem”?
• What has this got to do with me?
• Is this PM going to screw me to make sure they look good?
• Is there someone else on the project trying to screw me to make them look good?
• What do I know about this PM? Can I trust him/her?

The list goes on and on. While all the political jockeying and positioning and second guessing are going on, the project slips further and further from its original planned completion. This is where I think Steven Covey nailed it when he said “seek first to understand and then be understood”. If you have a relationship with the people with whom you are working on a project then you have the ability to start working at the problem level and can skip all that emotional overhead. The questions then become something like:

• How can we work together to solve this problem?
• Who are the best people to include in the discussion of this problem?

In a large project that required circuits to be delivered to certain locations at a certain time those circuits would not be delivered as we anticipated. Because I had a relationship with all the key team members and they trusted me to focus on the project being successful and not covering my own ass, they never asked me “Why?” when I said the circuits won’t be where we want them when we want them.

There are reasons these things happen which are beyond the control of any team member or PM. We’ve all been there. Because we had a personal working relationship built on trust it was just delivered as a fact – the circuits won’t be there when we want them. So, how do we compensate? Does this mean we ignore problems? Do we “gloss over them”; that we don’t eventually do some sort of root cause analysis? No, that’s not what I’m saying and I can assure you that circuit delivery was a major topic of discussion during the project post-mortem. But rather then spend days figuring out who was to blame, how team members could ensure it wasn’t “their” fault, how they could deflect the blame we all worked together to decide what to do about it. It’s a fact. Deal with it and move on.

This is where the communications skill comes in. When you have a group of people discussing “issues” you must facilitate this discussion in such a way that people don’t feel threatened or blamed or under scrutiny. Even if someone is actually to “blame”, as in, they dropped the ball, does it change the reality? Does it change the situation? NO! Think for a moment in your own life when you have “failed” to deliver in one way or another. Did you intend to fail? Did you get up in the morning and say, “I’m going to fail and screw up this very important project today.”? Were there circumstances beyond your control? It doesn’t change the reality of the slipped deadline but it does help us to move beyond the “blame game” and get the job done. Your methodology speaks of requirements and design and design matrices. How do you gather requirements? You talk to people. And I can assure you if you don’t get to know the people, their motivations, their reasons for even participating in, or sponsoring a project, you’ll fail. Most often the best requirements for a project are the ones that are not mentioned in public. It’s your job to get those out in the open and see them in the light of day.

The one question that is not asked enough today in IT projects is “Do we really need to do this project?” If you’ve done your job building relationships you have a team that wants to succeed, you have team members that will actually go out of their way to help other team members. You will have people who realize that people make mistakes. Sometimes circumstances are outside our control or as we all know in PM the #1 rule is “shit happens, be flexible”. When you can facilitate communication between team members in an honest, open and non-judgmental way you will succeed. My biggest job as a project manager is to get team members to talk to each other.

How often have you been in an organization structured with professional or technical silos where the two groups NEVER talk to each other? How many times have you heard one technical team member say of another “Well, I didn’t know they were going to implement THAT way! If I had known that, I would have done my part different.” Your methodology will do you no good if you cannot build relationships and team dynamics that transcend individuals. Your methodology will fail if you cannot communicate in a very real, non-judgmental way the “real” status of the project. If you try to hide information because it’s inconvenient then you will fail. If you try to hide information because it might appear to management as bad news then you will fail. Rule #1 with management when you start a project: I won’t lie to you and I won’t lie for you. Oh, I’m sure we can “highlight” the positive in our project status reports but I’ll not bury the truth completely.

If you have not established a relationship with management that ensure they understand your desire, and the desire of the team, is to make them successful then you will fail. We’ll deal with “why” something happened later, right now let’s get it fixed, get the project on track and move forward. If you insist on talking “down” to team members, you will fail. If you refuse to acknowledge your fellow team members as real human beings who actually have a life beyond your very important project you will fail. If you don’t spend your time ensuring that people are treated as people and that they are communicating at all times during the project then you will fail.