Fire the Project Manager

The last decades have seen a key trend in organisations: more and more work is carried through “Projects“. The actual content of what a Project is varies from company to company, but as a rule of thumb the common element of it all is that somebody assumes the role of “Project Manager“. Other elements instead (the availability of a resource plan or of a specific budget) vary instead.
Very often this is a part time role, assumed by somebody in the Organisation who is supposed to continue carrying on its own job at the same time. But in many cases this role is delegated to a “specialist” in Project Management. This can be an internal resource, or more often a contractor, who professionally does project management by applying one of the many methodologies available. The goal of this role is to ensure that the project itself is maintained within budget, planning is respected, results achieved.

I guess you all recognize this. Yet a sentence I heard a couple of days ago from an executive made me really think.

“I have yet to see a project were the project manager is really focusing on the business objectives which underlie the project itself. Issue is that instead the PM works in micromanaging the tasks of the project, focusing on the intermediate deliverables, and trying to spend the available budget at its best. At the end of the day this only produces suboptimal results.

I was really surprised, also because being in the middle of a project of which this person was one f the main person, this consideration made me really think of what is the aim of project management itself.

A new bureaucracy

Truth is that in many cases this whole way of working adds a layer of useless work (made of endless PM meetings, status reports that nobody reads, endless coordination efforts) and stress to the team, with the only apparent advantage of having somebody to blame if something goes wrong.

The issue can be expressed in a very simple example. Most of the PM methodologies are heavily inspired from the building and construction world. At a very high level the process to “build” a house (but this can apply also to a monument, a bridge etc. the only difference being the scale and the resources involved) is articulated into four phases:

1. design: this is when an architect starts to “draw” the way the house should look like. It is a moment of high interactions with the future owners or sponsor and ends up with a detailed building plan.
2. plan: this phase (where usually an engineer supports the architect) concentrates on the detailed planning of the project in terms of resources over time, but also in terms of assessing all the technical aspects related to the actual build.
3. build: this is the phase where the “real” work begins. The construction takes slowly shape. Ad is a phase in which a lot of work is needed to manage resources and face challenges and unforeseen events.
4. delivery: here the construction is ready, and is given to its owner or sponsor. It is also the moment where the “project” ends and the “normal” use of the house starts.

Now, the interesting thing is that experience shows that also in the building industry, this approach very seldom works. And in 80% of construction projects budgets is exceeded by at least 15% and time is not respected in 86% of cases.

So why would you use this approach? Ok I can already see your eyes rotating puzzled, thinking that there is no other way. Many people would state the obvious: if a project fails to deliver in time or budget it is because of bad project management.

Curiously enough, however, in the 20% of construction projects that fell into budget, the majority of cases had no formal “project management” processes separated from the real work. Very often the person who was leading the project was either the architect (responsible of the design phase) or one of the contractors actually “building” it. The moment that PM does not become as a separate role but persists as an integral part of the project delivery, the project itself seems to gain a lot in terms of effectiveness.

The wrong focus

Which goes in line with what of my mentors taught me at the beginning of my working experience.

A good project manager does not focus on processes or mere execution, but on the satisfaction of the goals underlying the project itself.

If you are involved directly in the project delivery, and maybe are a key actor in the design phase, you will for sure be able to interpret the process necessities a lot more proactively. A project manager that instead is just there to supervise the PM process, will focus on the process itself. Which by the way is very often organized on the assumption that everything is always going well.

Interim reports, status updates, project logs, risk assessments, are all useful tool if used by somebody that knows the project aims inside out. The same tools can simply become an unbearable bureaucracy layer instead if handled by somebody that only “manages” the project.

Yet some people think that project management as a discipline makes sense exactly because you can apply a method to whatever type of project you are implementing. But the problem is that no methodology will ever tell you how to react to an unforeseen circumstance.

If we go back to the building example above, what happens if you find out, let’s say, that the terrain you are building on is less consistent than expected? If you are the designer who planned the construction, you could immediately find out what elements are needed to modify the project, verify its impact etc.. As an external PM you may well intercept the same issue in time, but then you can only coordinate that somebody else figures out what to do. Which eventually brings up the issue of delays.

Plus, there is an intimate flaw in most of the project methodologies around. They are all based on the assumption that a project needs to be split up analytically into the small tasks needed to be built. Now this is necessarily a very relevant part of the planning of the execution. But cannot equate to Project Management as a whole. Which often simply misses the big picture.

Limited Responsibility

If all of this is true, why are so many organisations continuously relying on legions of external project managers? In my opinion in many cases it has a lot to do with a de-responsabilisation mechanism. As a manager you have certain responsibilities to achieve. Adding something that may have unforeseen circumstances is often rejected, as it could impact too much your performance evaluation. Thus often any “innovation” activity is packaged into a project that is delegated to somebody external. If the results are positive, usually this means positive impact on the evaluation. If it is negative, it usually blamed to the circumstances, trying to avoid too much of a negative impact.

However, why should the “opening of a new market” be a project that needs a different management structure than that of a sales division? And why should project management skills be different than “plain” management skills?

I once taught a Project Management course. To my really big discontent at the end of the course one of the participants had written up a mixed feedback on the feedback form.

The content was well presented, but after 12 years of being a manager you are already supposed to do all of this. You just don’t draw a GANTT chart around all the time.

If drawing a GANTT chart is the only added value, is it really worth it?