3.5 Facing total failure

Sometimes, you get brought in to advise a project that is in full crisis mode. The critical stakeholders have lost faith in the project, and most likely, the relationship with the vendors is also in ruins. There are a lot of emotions in the room, mainly the fear of losing face or losing the already-made investments. They may ask for the architect’s advice on how to proceed.

As an architect, your role is crucial in defusing emotions and providing a thoughtful, analytical solution. Your company should mandate an IT project manager for every major IT initiative, even agile projects. While the project managers are supposed to manage the crisis, the architects will voice their opinions. Usually, the project manager is already under the lens and doesn’t represent an impartial opinion. Crises are where your expertise comes in, producing a thoughtful and analytical solution.

Many companies victimize themselves, somehow reorganizing the work left, bringing in new talent, and forgetting to address the root cause of all the trouble. After implementing the initial superficial changes, there often exists a belief that additional effort invested in the project will lead to its recovery despite the lack of a solid foundation to support that assumption.

After implementing the initial superficial changes, there often exists a belief that additional effort invested in the project will lead to its recovery despite the lack of a solid foundation to support that assumption. The project will usually finish, but it will still fail. Finishing and succeeding are not the same. You should aim for success, not finishing.

You should wisely avoid giving your solution instantly. Instead, you should decline to answer immediately and have a private chat with every stakeholder group, the development team members, and the vendors. After that, you can start parsing together your recommendation. First, you should state the provable facts of the situation.

The team is falling behind schedule, and they have exceeded the budget. They are unlikely to meet the original targets. If we walk away now, this is what we can salvage and not. The stakeholder group X thinks we should do Y, and one other group agrees, but another group disagrees and thinks we should do Z. The developers’ morale is bad, and we are arguing a lot with the vendor.

Simply stating facts for yourself and others will help defuse and approach the situation more objectively and analytically. No one can argue the facts, which will serve as the common ground. Then becomes the time to identify the factors behind the problems the various parties have noticed, and present them in a balanced, non-confrontational manner.

I underestimated how much work feature X will require. It also forced the developer team to attempt something they hadn’t done before. They did not have the skills to develop this. Now, the whole team is demoralized. They will continue if we ask, but they burn out.*

Your options are to cancel the project completely, continue with minor changes, or complete a reset before continuing. Continuing with minor changes allows for the most face-saving but is the least effective in ensuring good results. You have to quantify the risks to remove emotion from the situation.

If we terminate the project, we lose 7,5 million euros worth of work done by us and the vendors. If we continue without major changes, the project will spend 16,2 million euros to finish the software. If we remove the feature causing much trouble with the software and switch the development team, we should be able to finish the project, having spent 11,5 million euros.

In crises, project teams often find completing the project more appealing if they can make trade-offs between the scope, costs, or timeline. As costs and timelines typically overrun, stakeholders frequently seek to change the scope. That has always had business implications. Then, it starts the discussion about the sunken cost fallacy.

Terminating a project is the hardest decision any IT department, project, or architect can recommend. Typically, you want to pivot and salvage something. However, if you can’t, have learned the facts of the situation, and see how the project can realistically succeed, you should state so. For example,

I know there’s a lot of investment in this. I have been going through the situation with everyone, and it doesn’t seem like the project can finish the implementation at this point. We lost what we started with, but we have learned valuable lessons here, and from now on, we can improve. We know now what is hard and use this to improve our maturity to develop these things. I know it’s a hard call, but I advise you to terminate this project now.

Preparing such a statement requires drafting it and going through it privately with the most critical stakeholder groups. This will allow them to process your opinion beforehand and soften the blow. It also shows you respect their positions and own your opinion, taking responsibility for recommending the course of action. As the architect, you have to be able to give a recommendation no one wants to hear; that’s called integrity.

Typically, a steering group holds a meeting to decide. There’s a round of comments and then a few advice. Sometimes, your recommendation stands, and sometimes, the group will want to overrule you. When much emotion is involved, things are hard to predict reliably. There will usually be resistance to what you say, but state your piece with all the reasoning anyway.

When the decision-making gets complex with all the variables, differing recommendations, and opinions, analogs are the most powerful tool available for you. They’ll live much longer than the rest of what you say and convey an emotional component. A lame example: “We are like a cowboy that thought he could lasso a hippo. Yeah, you can try, but what happens after that isn’t going to be pretty.”. It’s best left for one-to-one discussions, but it’s a potent tool should you need one.

You, as an architect, should, when necessary, be able to give out facts-based analytical advice. You should not, however, forget that crisis projects involve many emotions. Talk privately with all the stakeholders before forming your final advice to soften the blow and gather new points to consider. Start with the facts to get common ground, then the factors involved, and then proceed with the recommendation part. Remember, it is your recommendation; you are not there to and can not appease everyone.