Reasons why projects could fail

Anti-patterns

As a senior product manager, I’ve witnessed some projects succeed and others fail. In this story i will highlight common reasons that could fail projects:

Management & individual anti-patterns

The personas that are considered in this story are: the management, the product manager, the architects/experts, the execution agile team and the client.

Analysis paralysis

In this anti-pattern, the product manager gets stuck in the specification phase, overdone brainstorming and details discussions before starting the work.

This causes a waste of time and delays in the delivery of the project.

The only way to know if you project will work or not is to build it. If it works, you’ll get the acknowledgment. If it fails, it fails fast and you return to base.

Putting the cart before the horse

It happens that, in the influence of the client or top management, the product manager and the team place too much emphasis on a part of the project that should be done later. This results in doing the wrong thing at the wrong time.

Instead, the focus should be on what needs to be done right now and not what needs to be done along the way.

Groupthink

This is a very common anti-pattern that appears in social life in general and in projects in particular. it’s a term from the social sciences that describes how people tend to follow the general opinions of a group, even if they disagree individually. In most of the cases, this leads to poor decisions as a result of groupthink.

Some methods could be useful to resolve this problem. One of them is to generate solutions to problems silently. Have the team separated in small groups imagining their own solution and then combine solutions all together.

Silos

Communication and transparency are at the core of an organization’s success. the lack of communication makes it easy for a company to lose its unified image. As a result counter-productive management strategies take hold.

It’s always recommended to reduce the amount of management in the organization and move to a horizontal management. Reduce office bureaucracy and get people talking to each-other ideally face to face. And most importantly encourage a positive atmosphere around inner-team communication within the organization.

Over engineering / gold plating

Product managers could fall into creating a product that is more complex than it needs to be, and put extra effort into a feature that does not contribute to the value of the product. In such cases, the product becomes at best confusing to use and at worst unusable. The client becomes confused and disappointed.

The best practices would suggest that user requirements should be specified by the client and discussed with the team. A helper could be conducting user studies: taking a small sample of users and get their feedback.

Fire drill

This happens when too little work is done throughout the majority of the project and all of a sudden there is a need to make a big push towards the end. This leads to sacrificing the quality in order to deliver something quickly.

A product manager should establish expectations early. With a little help from agile, implement time boxing. People are always motivated to work on a steady pace.

Heroics

In a non-balanced skillset team, everyone relies on one person to get the work done.

Delegation and making people accountable reduces this risk and empowers the team to deliver collectively.

Death march

One of the most fatal anti-pattern for projects. When management and team are at odd. Management struggles to get the team believe in what they are doing. Everyone knows that the project is destined for failure but continue to work as of obligation.

If management is stubborn and in denial of the inevitable failure, the team moral goes to its lowest and product quality suffers for it.

The people building the product should believe in it and get on-boarded on a common journey or else the product will not be the best it could be.

Micromanagement (control)

Command and control is the enemy of agile product management. When someone in a management position tends to want to be involved into every single detail of the project and feels the need to offer their opinion anywhere. Those symptoms show lack of trust and of manager’s own fears, insecurities and own stress.

You wouldn’t want your product manager and team to be demotivated. The solution in this case must come from the manager himself. He should seek further management training to be self-aware and adjust accordingly.

Seagull manager

Someone you don’t see until a problem arises, he flies in makes a lot of noise and dumps on everyone and flies out. This behavior is very destructive and causes stress to the team.

In such cases, the organization should take strong decisions. The manager’s schedule needs to be re-evaluated along with the way he interacts with his team.

Loose cannon

A loose cannon is a team member that makes significant project changes without consulting with the team. He asserts his opinion on nearly any topic. He raises small concerns and questions every little thing.

Such a behavior causes major headaches and recklessness, in addition to leading to groupthink.

This person generally wants to cause trouble or prove that he is worth something. This should be dealt with as quickly as possible to avoid its consequences on the team.

Conclusion

If you’re a product manager facing trouble in delivering your project, try to identify if any of the anti-patterns listed above are faced in order to take the proper actions towards resolving those exact impediments.

The information provided in this story is the result of product management trainings that I thought are worth sharing as an easy PM reference. Thank you for reading, please feel free to share your feedback.