Mani Masoodof project management activities and business enterprise projects go badly wrong. In fact, if you believe the stats, about 50% of major corporate projects end up as a fiasco.
Some people argue that the project management failure figure is much higher in reality. However, a lot of big-name organizations don’t like washing their dirty linen in public. They never own up when they have just spent millions of dollars on a debacle.
Those failures generally fall under one of two major categories:
- projects that deliver precisely zip after organizations have spent huge sums on them;
- those that do deliver something, but whatever it is subsequently proves to be a huge disappointment. It never pays back the sums spent developing it in the first place.
Why things happen
If you took all the reports and books about why projects go wrong and stacked them up, you would probably have a tower reaching from here to Mars.
Those postmortems make interesting reading. However, one thing appears prominently, again and again: the problem of poor leadership structures.
Poor project management leadership structures remain one of the biggest causes of project failure.
Up until round about 20 years ago, things on projects were relatively straightforward. An essentially hierarchical structure clearly defined roles and responsibilities. It also defined the associated authority for taking certain types of decision.
Inevitably, this was something of a pyramidal structure, with the project manager sitting at the top. The PM reported to the sponsor or executive board. He or she had responsibility for delivering whatever the activity happened to be. If anything went wrong, the organization held that person accountable.
It was old-fashioned and, by today’s standards, politically incorrect. It gave people a degree of authority to do their job and also provided clarity as to who was in charge of what. So, that was self-evidently argument enough for tearing it down. Organizations replaced it with something proven in many different environments to be a total waste of time – i.e. matrix management.
Managing technical debt is critical; otherwise, you risk running into IT project failure and chaos. This severely impacts organizational profitability.
The origins
Whatever the books tell you about the intellectual and philosophical origins of matrix management, the reality is simpler. It and its related philosophies really took off in the mid-1970s. At that time, a lot of people who probably were previously hippies decided to migrate into people development roles within commerce and industry.
Suddenly, instead of getting on with the job, people found themselves sitting on cushions in a circle on the floor. Someone told them they had to share their life experiences and deepest worries with their colleagues.
Someone thought that this might help the company, for example, find better ways to build its electrical motors for small domestic appliances.
Of course, everybody was now sitting on the floor and publicly declaring how much they loved all their colleagues in the team. From there, it was but a short logical step to start despising authority and single-point decision-making. After all, why should anyone have more authority to make decisions than anyone else? Isn’t that undemocratic?
So, out of these mutual admiration societies sprang the idea that everyone should have a say on every decision. Everyone would also share in making it.
Eastern verses western philosophies
Far Eastern businesses, notably in Japan, had practiced this idea for some time.
However, businesses in the U.S. and other western countries badly confused two different ideas. The first involved encouraging people to contribute opinions, irrespective of their hierarchical position. The second assumed that the originator had the same level of authority as more senior personnel.
So, the concept of the work-group and its associated workshop was born.
This meant gathering large groups of people together to map out a way forward. The group then voted upon the outcomes. The crazed thinking behind this still continues to some extent today. It assumes that consensus should decide direction rather than an individual’s vision and decision-making capabilities.
The logic is that everybody will support a decision if it comes from a democratic consensus process. They will then buy into it more readily, and the organization will more likely deliver successful outcomes.
Of course, it’s absolute nonsense in most cases. Astonishing success or turnaround stories like Ford and Apple provide strong testimony.
Project Management Today
Things have softened down a bit since the heyday of everyone trying to love each other to death in a work team. Nevertheless, project structures are now frequently extremely difficult to define on paper. Organizations officially discourage hierarchies.
That means that project management decision-making is sluggish. Many project managers have also lost confidence in the organization’s support. They fear making fast, tough calls that subsequently don’t work out.
In passing, it also means that issues constantly fall between the gaps. Nobody deals with them. Organizations frown upon exact responsibility definitions and demarcations. They deliberately leave them vague to avoid offending people by visibly showing authority on an organization chart.
What’s now more likely is that people will duck decisions and convene a ‘working group’. The group will generate a lot of hot air and associated delays before reaching a consensus.
The lack of clear, unambiguous roles, structures, and authorities within project management teams leads, at best, to confusion. At worst, it leads to chaos and decision-avoidance. Still, if nothing happens because people missed or seriously delayed decisions, at least we can say the problem was collective. It was not the fault of any one person.
So, things are a lot better clearly.
Learning from Project management history
One of the most enduring and successful human organizational structures is that of the world’s military.
Nobody’s suggesting that project teams need uniforms or should go around saluting each other. However, they can learn one important lesson from the armed services throughout history. That lesson is: “ambiguity of command is the first step on the road to disaster”.
That’s as true today as it was for the ancient Romans 2000 years ago. So, why do projects today work hard to blur who’s in charge? Why do they blur who can make what decisions and who is responsible for what?
Could it be that our ancestors knew a few things about successfully achieving objectives that we’re in danger of forgetting?
Note: This article was written in 2014 and may be outdated.
Thank you for visiting! I write about cybersecurity, AI, and risk management. Explore more insights in the Cybersecurity, Artificial Intelligence, or Risk Management sections.
To learn more about project management, visit the Project Management Institute (PMI). You can also explore the CompTIA Project+ certification to strengthen your project management knowledge and skills.
Mani
