Aborting a project is still rather unusual for many enterprises. Most would say it made sense not to flog a dead horse. But in practice this is exactly what happens. A project that is beyond remedy is often seen through to the bitter end against all odds. The reasons for this behavior are manifold. Thomas Brustbauer is a seasoned project manager in IT. In this interview, he speaks out on the reason why many enterprises refrain from aborting projects. He also indicates how to change this.
Thomas Brustbauer is managing director at InsData, a subsidiary of the Austrian insurance group Uniqa. In his long career as a project manager, he has never once seen a project aborted right in the middle. On the contrary, at that point the parties involved like to argue as follows. After investing all that money into the project one wants to get something in return.
“I think this is where a distinctly human component comes in,” the experienced project manager reflects. “I think half way through the project people are still too emotionally involved. The project team has the ambition to keep their promise. Likewise, on the customer’s side there is still hope that their money was good for something. And that the project will somehow be carried through.”
From experience, Thomas Brustbauer is more familiar with projects abandoned at the outset or shortly before closure. At the very end, the project team has no other choice. They have to present the results – however fragmentary they may be. It may be that a production date is coming up, but there is no product yet. Or what one has developed is now available from the competition.
When Is the Time to Abort a Project?
There is no rule of thumb when one should abort a project. Those responsible have to be able to recognize the infeasibility and pull the plug.
However, the company needs to have a culture that permits an abort. In some companies, a project abort means that team members will lose respect. This entails that many project managers will not even consider an abort.
“However, the company needs to have a culture permitting an abort. In some companies, a project abort means that team members will lose respect. This entails that many project managers will not even consider an abort.”
In many cases, the people who could pull the plug are not actually let in on the troubled project situation. If the company does not foster a communication culture, the knowledge of the dying project has to “leak out” first. If one is aware that projects can also fail, the actual abort is not such a big deal.
Mistakes and Experiences as Part of Company Culture
For Thomas Brustbauer, Europe lacks the company culture of allowing for occasional calculated mistakes. “I hear there is a different attitude in the US. There, an entrepreneur who has not gone bankrupt three times is not a good entrepreneur. This position would be inconceivable in Europe. A project manager is after all a small entrepreneur. But if he or she makes a mistake no one will forgive him in this part of the world.
Whereas actually one could benefit from these people’s experiences – for instance when training project managers. In training sessions for project managers, these people could tell what actually went wrong. This could help the others to overcome the fear of making mistakes. Facilitating this exchange of experiences would be a task for the project management office (PMO) of the company.
“In training sessions for project managers, these people could tell what actually went wrong. This could help the others to overcome the fear of making mistakes. Facilitating this exchange of experiences would be a task for the PMO of the company.”
How Do You Abort a Project without Losing Face?
There are several ways to avoid losing face entirely. On the one hand, it is important to highlight the consequences of going through with the project. They tend to involve a high monetary loss and the waste of valuable resources. This will persuade those responsible to lend you an ear. On the other hand, one has to be prepared to
- admit one made some bad decisions,
- acknowledge poor performance, and
- realize that some fellow workers are simply not well trained.
It is important that the leadership ranks are prepared to do the same. They must act as role models in the way they work.
Whoever claims not to have made mistakes cannot have worked.
After a failed project, one should openly analyze the mistakes made by oneself and the team. Launching a quick but successful project in its direct aftermath can help. This will show to the outside world that you are generally successful. And that a failed project will not change that.
“After a failed project, one should openly analyze the mistakes made by oneself and the team. Launching a quick but successful project in its direct aftermath can help. This will show to the outside world that you are generally successful. And that a failed project will not change that.”
More Power to the Project Managers
The matrix organization is firmly rooted in many European enterprises, according to Thomas Brustbauer. In most cases, the project managers carry the entire risk. They put their neck on the line if a project is not going well. However, it would actually be important to give the project managers more power.
“If I only carry the risk without backing from management or power to act I will try to avoid risk. I will only take on projects that are easy to manage. And if I cannot get out of a complex project I will try to be very quiet and make it work somehow. Project managers tend to be guided by hope rather than realism under these circumstances.”
How Should Companies Handle the Notion of ‘Failure’?
Failure is normal; failure is part of life. Everyone has failed at some point and will do so again. That is, making mistakes and learning from them is all right. To keep on making the same mistake over and over again is not all right.
This is why project managers should take preemptive measures. Certain events should be classed as risky before project start. After all, project managers will have to report if a project is foundering. This requires a company culture openly acknowledging mistakes.
“This is why project managers should take preemptive measures. Certain events should be classed as risky before project start. After all, they will have to report if a project is foundering. This requires a company culture openly acknowledging mistakes.”
What Should Be the Criteria for Aborting a Project?
This is quite simple for Thomas Brustbauer. The project order lists the goals. If they cannot be achieved the unachieved goals become the abort criteria.
In the course of the project, it might transpire that these criteria cannot be met. In this case, someone should really shout ‘Stop!’. A possible scenario could be that you have used most of the budget for a specific milestone. Yet in practice, those responsible often do not know what is happening at project level. This or that person might try to cover up the progress of a project until things improve.
No matter if you call it goal or abort criteria: It should be clear from the start what benefit you have to achieve with which milestone. If this benefit fails to materialize and you have already spent a certain amount of money, you should consider a project abort.
“No matter if you call it goal or abort criteria: It should be clear from the start what benefit you have to achieve with which milestone. If this benefit fails to materialize and you have already spent a certain amount of money, you should consider a project abort.”
Are some Projects ‘Too Big to Fail’?
In theory, no project should be too big for an abort. In practice, you have to weigh the damages. After all, some projects are big enough to ruin a company financially. This can happen especially in medium-sized companies.
It may be that you offered a customer a solution at a fixed price. Later it turns out that you can only realize it at a huge extra effort and expense. This discovery may come late on in the project after you have already billed the major part. In such a case, you may have to struggle through the consequences in spite of everything. Rescinding the contract would drive the company into financial ruin. So, yes, projects can be too big to abort.
“This was exactly the reason why we reduced the project size at our company. That is, a project should not take longer than one year. In the past, very long projects did not always succeed. We just did not have the capacity for such large-scale projects.” Now, Brustbauer continues, the company has defined its scale of feasibility and the projects go well.
Test Project and Possible Back Out Points
The management of a company should be able to make a realistic estimate regarding the feasibility of a project. On occasion, the feasibility is not so easy to determine. In such a case, they should have the courage to take a justified risk. In the end, you may save an awful lot of money and time if you do a trial run first.
You start the project with a certain budget. At a preassigned milestone, you check whether the project can succeed. If it transpires that it will not you abort it.
“You start the project with a certain budget. At a preassigned milestone, you check whether the project can succeed. If it transpires that it will not you abort it.”
This gives the responsible project managers room to operate freely without living in constant fear of failure. At the same time, customers can be sure that their money is not bogged down in a project painstakingly kept alive.
Thomas Brustbauer gives an example:
“One project abort was a bad experience for me. A large-scale project with a seven-figure sum to be invested and thousands of man-days came to a premature end. The customer did not like the results we delivered. On first seeing the product, they said plainly that they had not pictured it that way. And my team and myself were unable to rectify the situation. In the end, the customer said they did not care about the money but wanted to back out of the project.
I learned from this experience to involve the customer at an early stage. I show them prototypes. This is helpful for both sides. They can find out what the other side expects or can deliver.”
Conclusion – How You Abort a Project
Aborting a project should be a feasible alternative when a project is not going well. It is best to start a project with a certain budget. At a preassigned milestone you check whether the project can succeed. If not, you abort it. Project managers should get a greater stake in making such a decision. Customers also benefit from such an approach. They avoid losing money in a doomed project.
When aborting a project you should assess the mistakes you made and admit them. But this requires a company culture openly acknowledging mistakes. It is vital that top management embrace this culture.
What are your experiences? Have you ever aborted a project? Please share your thoughts or let us know your questions in the comment area below.
Final tip: Subscribe to the TPG Blog Newsletter now and never miss another blog post.
If any one say STOP they will sack him out of the project , did you face such scenario!!!
Sameer Mihyawi, thank you so much for your comment. Such scenarios do happen. Also, many companies have a culture where project managers are in fear of such scenarios. This prompts them to either avoid projects that are difficult to manage. Or, if stuck in a failing project, they will try to keep quiet and see it through regardless of the cost.
What we are saying is that a project abort should not mean project managers lose respect. It should be a feasible alternative to avoid wasting money and valuable resources. But we are aware that this will not be the case with a company culture dominated by fear.
That is why Thomas Brustbauer advocates a change in company culture. And such a culture openly acknowledging mistakes needs to be embraced by top management. If we do not work on changing company culture, your scenario will remain the rule rather than an exception to the rule.
Perhaps we should ask a related question regarding successful projects, before asking about aborting projects? My question is: How many projects are completed successfully? In other words, how many don’t finish by default, but actually finish, do a formal project closure and are acknowledged as successful in that they met their goals?
I think you’ll find that most projects are in the middle. They don’t finish well and they don’t stop well. With the latter, it means that the project may be stopped for various reasons and no one had to formally request to stop it.
The article above addresses the case, in my opinion, where some had to formally “pull the plug”, which is different to what I claim is what usually happens. Is that correct?