Sins of the Project Manager (Thoughts on Enterprise Architecture and Project Management)

The current economic and employment environments notwithstanding, things still look pretty good for project managers. They are being kept on, and are still getting hired, because organizations are still ultra-cautious about spending money and getting critical projects completed as near to planned time and budget as possible. Salaries for PMs are continuing to be solid as well.

Which leads to the following dilemma, which shouldn't be surprising given the ongoing economic circumstances: everybody is now a project manager! Including a lot I have recently run into or heard about from colleagues that have absolutely no business being one, but they can talk a good game, at least initially.

In no particular order, here are some events and behaviors I have witnessed or heard about within the past few years that are clear signals the project manager involved was not skilled, have completely unrealistic expectations that medodology will always save the day, or had personal/character issues that precluded good-to-excellent performance on the job:

1. Narcissism. I have written about self-absorbed project managers in the past, and a recent experience with one (who ended up failing and getting terminated) leads me to firmly believe that this type of person has no business as a project manager. As examples, this individual: routinely made time and scope decisions on her own with no other inputs from sponsors, stakeholders, or project team members; always showed up 10-15 minutes late for meetings that she scheduled; sent e-mails to team members admonishing them to send responses directly to her, not to anyone else (and she then took credit for the team responses that she received with sponsors); when challenged about anything concerning the project, claimed that her way was 'Agile' when it wasn't even close; dismissed everything (no matter how reasonable) that conflicted with her point-of-view; and believed she was unaccountable to the team and sponsors for anything.

And those are just the highlights. This individual thought she was above all else not only within the project, but the organization. Luckily, it only took a few months for her to anger the appropriate people (she lost the project team within the first 2 weeks of her tenure) and she was summarily dismissed from the project and organization.

2. Inexperience or insufficient experience. Granted, we all have to start somewhere, and project management is no different than other professional occupations and disciplines. However, PM is a skill-set acquired over time with experience and study - just calling oneself a PM when the position held was really "technical/team lead" or somesuch isn't usually enough to do the job properly. Lots of organizations screen resumes for PMP certification. That's OK to a point, but the resume had better list some significant real-world project management experience to be taken seriously, because I know people who hold a PMP certification that cannot explain what a Work Breakdown Structure is (for starters). Which tells me that while they are good at passing project management examinations, real-world experience is another matter entirely.

The downside is that the only way to spot a smooth-talker with insufficient or exaggerated experience is when the project executes. If it happens, cut your losses early and replace the individual with one who has actually performed in the position successfully in the past. You can evaluate this successfully in job interviews if you know what to ask candidates - ask about projects and how situations were handled, and not about certifications.

3. Control Freaks. These types come in various assorted flavors and I'll break-out variants of them below. The worst offenders second-guess (rather than constructively criticize) the work of the team and effectively stifle lots of hard work and innovation based on worldview, fear, and whims, as opposed to facts and experience. If you have a PM who forbids team members to utter or write any sentence or e-mail without pre-approval or editing, your project is in big trouble.

4. Second-guessers. Related to (3) above, but while PMs should have the basic non-PM technical foundation to manage projects (i.e. an IT PM with other relevant IT experience, a manufacturing PM with a manufacturing background, etc.), it is not necessary for a PM to be an expert on every technical topic, issue, or matter involved in a project. This is particularly true on large-scope projects, and that is why we have subject matter experts (SMEs) and highly-skilled members on the project team - to provide the necessary detailed expertise and work products.

However, there exists PMs who believe that they "know it all." This unhealthy behavior trait usually manifests itself in the instant negative feedback SMEs and team members receive when advising the PM of tasks and how long they will take (in effort and duration) to do. Most SMEs and project team members do a good-to-great job and give reasonable estimates, and their judgment should always be trusted by PMs unless facts over time dictate otherwise. If this principle is not followed, the PM will lose the respect and trust of the team, and the project will be compromised.

I usually allow one episode of second-guessing from a PM to occur before I react to it. If it happens again, I have a face-to-face with the PM and ask directly what problems he is having with the estimates. It will be even more directly put if the PM alters the estimates significantly or strenuously objects. Second guessers usually have trust issues, or the estimates that they were given were not what they anticipated or wanted to hear. Too bad....that's why we have project teams. And try as they might, second-guessers almost never change reality. What they should change, if they can, are their facilitation and leadership skills.

5. Command-and-Control Junkies. Another variant of control freak worth breaking out is the PM-as-Commandant. Sets up lots of rules and regulations for the project team, as well as 'enforcement' for the non-compliant. Also wants status reports in such detail that most of the project team's work week is spent preparing them. Fortunately, this type is easy to spot, and given the need-for-speed by business in the 21st century, easy to eliminate in most cases. They still crop up from time-to-time - particularly in government projects - so they are worthy of mention.

6. Tries to Manage People, not Projects. From my experience and observations, there are very few instances where members of project teams directly report to project managers. Usually, project management is a matrix function within an organization and team members have a manager that they directly report to, and the PM is the manager principally guiding outcome of the project, not direct supervision of team members.

While effective PMs must have authority concerning project matters in addition to responsibility, people management - as in the supervisory kind - isn't usually part of the deal. PMs can certainly add or subtract people from the project team as needs and circumstances dictate, but day-to-day management of the people comprising the team is not in the job description.

Some PMs don't get this concept very well and believe that the team is at their beck-and-call for anything and everything. In such cases, the team members get confused because now they 'take 'orders' from two people - the manager that they report to, and the PM. And those orders often conflict with each other, making the problem worse.

Project team members have a number of choices in how to react to this, and the best move, in my opinion, would be to notify the 'real' boss/manager of the situation and let them handle it with the PM - that is, after all, part of what they get paid to do. The worst move? Telling the PM off, that you don't report to him, and he can kiss your posterior if he doesn't like it, ad nauseum. Use this only as a last resort if your real manager doesn't respond. Why? It can be really damaging to the team (especially if others are doing it also), and unless you really enjoy working on low-morale projects with a lot of gossip, rumors (none of them good, by definition), and backstabbing, this only puts more gasoline on the raging project fire and solves nothing - for anyone.

7. Lack of Transparency. One of the worst things a PM can do, short of outright lying about project status, is to make it very difficult for anyone to assess where the project really stands in terms of deliverables, budget, and schedule. Once that happens, credibility is usually lost with sponsors, major stakeholders, and the project team, which makes it almost impossible for the PM to continue on that project.

If and when things go wrong - and they inevitably will at some point on any given project - three things matter: 1) assess the problem and impact; 2) provide a solution; and 3) implement the solution. This is Basic Risk Management 101. However, some PMs are so afraid of any damaging or potentially-damaging facts leaking out that they go to great lengths to destroy, hide, or distort such information - perhaps in the blind and often misguided hope that 'things will get better' somehow. Or, as is common with the various forms of control freakery, hiding the truth so the PM does not look as inept as he really is.

8. Embracing Alternative Project Management Methodologies as Fads - or Worse. There is no question that alternative project management methods such as XP and Scrum have taken hold in our world. After 10 years, Agile methodologies have matured to the point where many organizations have successfully used these methods to deliver projects. The problem here is two-fold: PMs who claim they are running an Agile project when in fact they aren't; and PMs who mix Agile/incremental delivery methodologies with older sequential ones like waterfall unsuccessfully (the latter case goes by such derogatory terms such as "Scrumbut," "Cragile," and my current favorite "Water-Scrum-Fall").

The first case is easy to spot as the PM continues to rave about "being Agile" and "we're Agile" and on and on to give sponsors and management the appearance that the project will be completed much faster than it actually can be. Usually while they are waiting for requirements and many scheduled meetings (over weeks) with the business and business analysts to get project requirements completed and signed-off. Then, because they are "Agile" - some miracle will occur that will deliver a complex project in an absurd or unrealistic timeframe.

The second case is much more complex. While I have written in the past that "following the receipe" for any given methodology is usually best to gain experience and discipline while reducing dogma, there are certain elements of Agile - the daily standup meeting for the project team as an example - that can be used successfully on almost any project. The issue with mixing methodolgies wholesale is that it is usually very difficult to integrate them into a cohesive project plan because they approach major events and deliverables in completely different ways that are difficult to manage or introduce significant risks to the project. The brunt of this usually falls on the head of the project manager, and most in this situation find out that it's really difficult to be "Agile" and have incremental delivery if the organization political landscape insists that many meetings must be conducted, requirements "gathered" in minute detail, approved and signed-off at multiple levels, and revisited in full for even minor changes.

Is it possible to run "Water-Scrum-Fall" project successfully? Maybe, but so far I have not seen or heard about it from peers, in blogs and in the PM press. What I have heard about are a number of project failures - some spectacular - when PMs tried it; and other post-delivery failures when the organization finds out how many silos they just funded and built that don't and can't interoperate with each other because they were developed in Agile project silos with no coordination - organizational, technical, or project - between them.

If you're a project team member, understand what your PM is going through and how they plan and react to events. If you are a PM, what can you do - today - to improve your performance and relationships with your business sponsors and teams? What things - behaviors, approach, relationships need to change to make the project (and you) successful?