In many of my articles I have tried to visualize the sources of bad projects: companies’ insufficient acknowledgement and consciousness for good project management’s value. Today I’d like to dedicate a little time to my experiences I encounter in my project recovery practice all over again.
Technics is overrated
There is a lot of research about issues and reasons why projects fail. To say it upfront: technical problems only cause a little fraction of it, not more than ca. 10%. However most of the responsible people in management and within the projects investigate first and with focus here. You can see this especially in engineering environments…
Four major root causes
The problems mostly are not of technical nature, rather than there are four main factors which repeatedly have led to project distresses according to my long project and project recovery experience:
- the individual “project manager”,
- insufficient project support from the company respectively the organization,
- not enough time, for the project as well as for project management, and
- the task itself, especially its complexity.
The respective statistics list factors like communication, resources / skills, unclear requirements etc. which overlap with my categorization, but are in my opinion the effects of the clusters I have chosen.
Weak project management is a result of weak management decisions
In one of my case studies (https://eobz.de/?p=1454) an “experienced” project engineer, an eminent authority in his profession, had been assigned project manager. He was taken up in his science, research and development, but didn’t find a good rapport to project management and team leadership. The “human” result: He invested the majority of his time and attention into the product while the project’s planning and coordination fell apart. When the project got distressed he focused on what he was best in – and again project management suffered.
If take managing your projects serious – and that should be the case at executives, similar to managing their business – then it should be clear that employees don’t automatically become good project managers just by having contributed to many projects. Best case they become as good as their examples, but they may also copy some bad practices.
You can learn good project management practices
If you want to lead a project successfully you need, similar as in other professions, a good, methodical education which includes recognizing the specific project situation’s requirements and reasonably applying the adequate tools and techniques situatively and virtuously. That’s at project management like with craftsmanship where you find trainees, advanced and masters.
Therefore a good project manager would not have undergone flaws like in our case because he would have taken care for a clear target and task definition from the start, and would have requested his superiors’ support consequently – for the sake of his project and himself. His planning would have based on realistic assumptions, and he would have identified and escalated risks and deviations and initiated counter measures early.
Project management is a leader position
To achieve he also needs another skill: leadership qualities. He is his project’s manager, responsible for the result, and he must steer his team and his superiors so that each one contributes his part to the whole. Not an easy task, in particular if the company doesn’t work project affine. And not everybody is the person for a leadership role, feels well in it. But if he takes his job serious he will apply project management including leadership consequently. Otherwise he will soon become a scape goat if the project fails. Not a very motivating perspective, or a subject for opportunistic PM nomads who sometimes call themselves project managers…
Have time for project management
Another frequent factor for troubled projects is time. I don’t mean the duration granted to the project for execution. This actually should always be sized realistic, not determined by wish thinking or arbitrarily. That means it must be based on realistic estimates done by the executing team members and taking the interdependences and frame conditions into account. Therefore “duration” falls into the category “Individual” for me, i.e. that the project manager does a competent job.
I’d rather reflect the time granted for project management. If you look at many project budgets this position often appears calculated significantly too narrow or even not at all. As if you could do this job with cheap resources or just at the side – that’s how expensive projects arise !
In fact many statistics, e.g. the one at https://eobz.de/?p=854, show that may project managers spend only a fraction of their working time actually with project management. The majority is dedicated to activities like business development, technical execution, functional line tasks etc. The reason mostly is the way the company “does” project management, but also often the project manager’s self-conception as described above in “Individual”. But if everything else is more important than project management you don’t need to complain about miserable project performance.
Have time for the project
The time for project management can obviously be scarce for the project manager because he must take care of multiple projects in parallel. That’s probably even the usual case in small and midsized company. It may be acceptable if the projects are in various phases with different needs for attention and communication. But in general – this is proven by many studies – multitasking is very inefficient because of the permanent need for getting-again-into-the subject. Thus it costs more time, money and risk than concentrated work in only one project.
The more people work together in a team, the higher is the communications and coordination effort even in a single project if it is supposed to run effectively and efficiently, and project management is a full-time job. Then it is reasonable to bolster up in staff with the advent of many projects, be it with own well educated project managers of with externals. Because the better or less the project manager can take care of his projects the better or worse it will go. Simple logic, isn’t it?
But that’s the point where we already are at the projects’ integration into the corporate organization by the management, the hot spot why projects fail which I will regard more in detail next.
Competing projects and lines
Did you know? More than half of the issues in troubled projects are not caused by sources inside the project itself ! That’s why you can only cure the symptoms there and recover, but at the next occasion problems will re-occur.
Classic example: The project manager is requesting resources for his project, but he does not get enough and not the ones he needs skill wise but those who are on the bench. These are often not the best as those are needed for line tasks obviously. And if there is a lot to do at the lines even these resources will be re-prioritized…
So the predominant part of project issues arises out of an insufficient support from the executing organization, which in turn is founded in the project culture, the management’s and established organization’s mindset.
Where departments or plants are responsible for P&L, projects always be in the second lane. What a pity if the company even makes it’s money with projects as in IT, consulting, machine and plant engineering etc. Then the business units may be quite profitable, but not the customer projects. I’ve seen top quality being delivered that way so often, but unfortunately not at the agreed upon milestone or within the calculated budget.
Insufficient organization and infrastructure
No project can perform decently if it permanently faces resource issues, if collaboration and communication within the team, between team and organization, and among the department silos doesn’t work out because it is unfamiliar, or if the project manager’s authority doesn’t fit to his responsibilities. 
In many companies in addition well attuned, fast interlocking procedures for decisions, escalations, risk and change control etc. are missing. Sometimes there is not even a sufficient infrastructure for projects in place, e.g. standards, processes, and tools. Being all alone on his own the project manager is like Don Quixote, and the “work floor” team members’ motivation for engagement in project work as well as the project’s results are unsatisfactory accordingly.
Do the home work !
Before holding the crisis project manager the scape goat at the management executives should do their very own home work and critically investigate whether the company’s projects find the frame conditions to prosper and be successful. In case the business model is even project driven further reflections (see https://eobz.de/?p=2142) might bear enormous surplus strategic potential.
Trouble cause task
Usually the endeavour is weighted heavy as being the source of problems in projects. How that applies to technical challenges I already described at the beginning of this article. But many times there are very different aspects of project work that make projects fail.
Dependence due to lacking internal know how
Let’s think about projects of which the subject is beyond the company’s core competence, e.g. an IT project in a producing company. Then in many cases there is only limited internal know how with the project’s IT solution but also with experience in handling the external supplier or consultancy. Project management is purchased together with the trade, and so you get at the mercy of the supplier all too often – if you do not have a good project manager at your side as a counterbalance.
The endeavour’s complexity
Or let’s talk about the project’s own complexity instead about technical green field challenges. There are a multitude of interfaces between the departments (cue cross-functional work), suppliers and sub-suppliers, all with an own understanding of project work, different organizational maturity and eventually reliability. But any case with high requirements towards 
communication and coordination.
May be there are also dependencies from or with other projects. In international projects this possible source of issues will potentiate with distributed and/or virtual teams, cultural differences, and work across time zones.
And then there also some more and sometimes prominent examples where complexity is driven up to absurdness by politics, interests and influencing…
Project success lies in management’s hand
As I already said: There are a lot of parameters which, badly managed, may quickly lead to failing projects because they are underestimated by managers responsible for the project, and staffed cheap but underqualified or even not at all at important positions. Last but not least – but not exclusively – it is the matter of the deciders on management level, how they anticipate and acknowledge the role projects play in their company, and how they define the rules according to which corporate projects are set up, staffed, executed, and supported. It’s a good example of how corporate success is really determined by the management.