The vast majority of projects fail. According to Standish Group, 75% of all types of projects globally on an annual basis fail. Regardless of the project management method. Regardless of the staffing on the project team. Regardless of the tools used, traditional or agile. Although more and more people involved in the projects are highly educated in the field. They have completed numerous courses at top universities or training companies. They have outstanding project management certifications. None of these attributes guarantees a successful project. What is the reason for this? Are there any lifewheels? If so, it may be worth your while.
My business experience spans several decades. During this time in a leadership role, I have completed 50 major projects. Large-scale projects. In addition, I have been involved in a second number of different roles: project team member, project sponsor, coach on the project. In the SixSigma area alone, as a Master Black Belt, I have supported dozens of Green Belts and more than a dozen Black Belts. I don’t complain about the lack of courses on project management or the lack of certifications. I have had the pleasure of leading a team of project managers in a large corporation for over 6 years. About 5 years ago, I began to study the phenomenon of failed projects, to look for a common denominator for failures. But also experiment with tools and practices that could reverse the trend.
Whether the project uses traditional methods, such as. PRINCE2, PMBOK, or agile methods such as. Agile/Scrum, every project is in danger of getting bogged down in three minefields:
In an ideal world, in books, in academic lectures on project management, stakeholders work brilliantly together, communicate properly, and follow common goals. But not in real life. In practice, they often tug the line, in official discussions
and unofficial are trying to stake their claim, to get as much as possible for themselves. Consequently, they initiate non-stop changes in the project: in goals, scope, specifications, schedule, project team composition, budget, etc. I myself have distinguished in my mentioned 5 years of observation
and experiments two typical situations in which stakeholders love to pump up the scope of a project.
These situations are:
– Bringing your own mess into the scope of the project. Often in their own area, they ignored problems and swept them under the rug. Now the Green Belt project has emerged. An opportunity to pour your own garbage into the scope of such a project.
– Ego explosion. The stakeholder sees that it promises to be an interesting project. Or he sees that the project is going well. You have to flash in front of others, in front of your supervisors. So either during the approval of the project charter or during the steering committee meeting, you have to throw in your three cents. It is necessary to exist. It is necessary to shine. Something needs to be added to the scope. Something has to be criticized.
The problem with projects is that they don’t go according to plan. Because nothing in life goes according to plan. Military commanders are well aware of this. Sports champions know very well. General Eisenhower used to say: plans are nothing, planning is everything. The problem is that the people involved in the projects, do very well in them when things go reasonably well. When things go wrong, not necessarily anymore. Here, too, in the course of the study, I distinguished two reactions of project leaders when there are deviations, disorders, risks, and crisis in the project:
– Waiting for it to happen on its own. The illusion that problems will solve themselves. Problems never solve themselves. At most, they go underground, build up and eventually explode. What then do the people involved in the project say? They spread their hands and ask: “Then what am I supposed to do now? ” Nothing anymore”. – I often answer. Now it’s nothing.
– Premature and often unprofessional escalation. Deviations in the course of the project simply have to be managed. Methodologically. And not panic firing due to deflections with self-guided escalation missiles.
All the projects I have observed in my business history have had status meetings, progress boards, Gannt charts, critical paths, numerous steering committee meetings. Did it save these projects from failures? By no means. I know plenty of projects in which the number of tables, charts, summaries (so-called minutes) led to nystagmus, and the projects bogged down for years, dragged on mercilessly and delivered nothing or little in the end.
Is it possible to avoid these three pitfalls, to avoid these three minefields in the project? From my years of observation and first-hand experience, it seems not. It is impossible to bypass these traps with some sort of bypass. They must be confronted. There are methods for this. Three methods. I called them lifewheels. They can be used in both cascading and agile projects. The three lifewheels are:
I have been using these three lifewheels for years and have never been disappointed with them. I have taught many of my subordinates to use these wheels in their projects.
are overwhelmingly successful, although they fell into each of these three traps.
If this issue interests you, and it should if you are or will be a project leader this year and don’t want to join the 75% of failed projects, take an interest in the three lifewheels. You can learn about them on your own, or you can take my course on the Udemy platform (www.udemy.com). The course presents step-by-step each of these lifewheels with references to my twenty personal project management experiences. The course is available in Polish and English. Links to these courses can be found under the TRAINING menu.
Applying these three wheels, you are not guaranteed to trumpet success and open champagne for each of your projects. You will have failed projects. It’s inevitable. Even needed, because we learn from failures. The difference will be that your success rate in projects will not be like the world average. You don’t want to have 75% failed projects, do you?
