Sunday, 20 December 2009 00:00

Project Managers Don't Run Projects

Rate this item
(0 votes)

If you must choose between managing a project or building a team, start with the latter.

Teams run projects, not project managers. Projects fail without teams, plain and simple. Project managers need to start by building a team. Red, or failing, projects have an even bigger problem, the teams are beat up, demoralized, depressed and frustrated. The recovery manager must focus on rebuilding the team. Balancing this with finding the project's issues may seem daunting. Fortunately, many aspects of these tasks overlap and good leadership qualities make it even easier.

Lessons Learned

Over the years, I have developed four rules I live by on any project—red or green. These were developed in the early years when authority was a dream and the only way to achieve action was through having respect. These rules are a failsafe, I live by them to this day.

1 - The Team Knows Everything You Need To Know

The answers are in the team. The team is fully aware of where the problems are in the project. They also have most of the solutions for those problems. Although disbursed among various team members, interviews with the team will uncover all the information needed. The project manager compiles it and develops comprehensive solutions to present to the stakeholders.

Lessons Learned
  1. The answers are in the team
  2. A strong team is invaluable
  3. Remain a peer with the team
  4. Objective data is your friend

Care must be taken to give credit where credit is due. However, do not make this an indictment of the executive management. When presenting the recommendations ensure the message does not get relayed as, "Well, I got all this from the project team. Weren't you listening to them?" So, it might be best to give the team credit in a more subtle manner, explaining the sensitivity and not giving anyone credit.

2 - A Strong Team Can Do Anything

A strong team can surmount almost anything. Poor management (in and above the project) is a common root cause for project failure. A strong project team, on the other hand, working closely together provides the drive and direction regardless of the level of management incompetence. What happens in this team is that one or two strong individuals rise to the top and become the leaders.

As stated in the introduction, projects fail without teams. Have you ever seen successful project where the people on the project were not a team? I have never seen it. It is paramount to build, or rebuild, the team to get the project moving again.

3 - Stay Involved

Recovery and project managers must stay involved with the team. This means the project manager should stay a peer with the team. Project managers who remain in an office or cubicle, or act imperious, failing to associate with the team on a daily basis, will lose touch with the project. Hearing trials and tribulations and feeling the team's pain is critical in being a good leader. Being removed from the project, the manager will lose track of the project.

This is a very common issue on projects. One form I call "checklist mentality." Checklist mentality is when a manager (project or PMO) sits in his or her office checking off the list of project documents and processes that must be put into place, never venturing out to the team to see if the processes or documents is being used or even applicable. In fact, this trait is so prevalent in upper management it is the primary reason that projects go off track and management only figures it out after the project is nearly unrecoverable. They may think it happened over night, but, as Frederick Brooks said, it happens "one day at a time." Management is simply not involved.

4 - Know The Data And Share It

Objective data is your friend. By staying involved with the team, Project managers will know what is going right and what is going wrong. They will be familiar with the difficulties in the project and what is needed for success. When asked about a problem on the project, the data-armed Project Manager will be able to deliver quick answers with a foundation based in objective data.

Once asked, in jest (I hope) if I could give a simple Yes or No answer, I replied, "No... Oops, I can! Damn, I guess I can't." Answering a question, with the data to back it up, brings creditability.

Trust The Team

As was the case in the Blame the Customer case study, the team pointed to the problem and were the voice contrary to management's. The team is involved in the day-to-day work and can see and hear the customer's frustration. They, as a collective, know more than executive management.

In red projects, the recovery process starts naturally on day one by interviewing the team (a process that should remain in the project as you go forward). The Project Manager's job is to collect the data, remove opinion, find the problems and collate it into a complete package to build the plan and run—or recover—the project.

Read 6503 times

Related items

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

  • Disband Your PMO

    After nearly 30 years of project work, I struggle to understand the role of a project management office (PMO). Even though, I have written of the pros and cons, and read a plethora of articles, opinions, and how-to guides little has been done to convince me that the PMO is reducing project failure. It seems to be nothing more than a tool to fill a void in leadership? Even the acronym, which is so widely thrown around, has little meaning as the "P" has no less than four meanings. It is an executive's crutch for their lack of understanding in how projects work. These, like other, unattended holes in the corporate accountability create opportunities for new and greater bureaucracies and empires that further obfuscate accountability.

  • The Catch-22 of Organizational Change Management

    "Kotter, ADKAR, or CAP which methodology should we be using to build our approach to improving project adoption?" I hear this question repeatedly from people trying to implement an organizational change management (OCM) program. The problem is that is the wrong question. Take a perfunctory peek at any of the models and you will see that in the quest for an answer people have mistakenly jumped over the first few steps and they head down the road of failure. It is a Catch-22; unless you already have an OCM process in place, you will most likely fail at implementing it. Putting one in place, however, is a change—one of the most difficult cultural transformations your company will undertake. As a result, people jump to the solution stage, which is well down the change management process path (which, they did not know, ironically, since there was no procedure in place).

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References