Why traditional IT project management is failing

It is 9 AM and a room full of end-users, who have been ordained by their management, are looking at their PCs to begin testing the new software product that they are going to use at work. They have been over supplied with coffee, doughnuts and chocolate, to keep them happy and alert. Nervous project team members and developers are pacing about in the room and roaming the halls outside, like family members waiting outside a hospital operation room to know if their loved one is going to make it out alive. Finally, the first few minutes of testing progress without any incident, and then they hear the first sounds of protest, like the resounding church bells at a royal wedding- "This is not what we asked for!... This is not how we work!...We can't work with this screen!...This is too complicated!...The old system was better!.." . The Project Manager, Product Owner and developers step in to calm the crowd, with heavy sighs, but tensions rise, and chaos ensues.

Many of us with experience in IT projects, irrespective of the organization, might be familiar with this scene. During this time, we fall into the temptation of re-visiting the agreed scope and reproduce logs/emails of previous agreements, to understand where we went wrong or who is to blame. However, what we don’t realize in this nerve wrecking tango, is that the fundamental way IT projects are handled traditionally has failed us. Here are some reasons why-

 1)    The 'waterfall' effect

 IT projects have generally followed the waterfall methodology, which despite its flaws, have given us some structure to the way things are done. However, the rigid structure of waterfall takes the scope and requirements at the beginning of a project and turns into a product within a timeframe (say a year or two) and then expect the outcome to be appealing to the end-user, when it comes time to testing/UAT. To the end-users, what happens between the time their requirements were gathered and when they see the product for testing, is a black box. They often realize what they asked for, and what the development team thought they asked for, are two different things.

 2)    Command and control style project management

In the traditional way, project manager and/or product manager, is king/queen and the rest of the team members are humble subjects. Team members act like worker bees in a colony, focusing only on what is assigned to them and not realizing the big picture or why they are doing what they are doing. Knowledge of what is happening in the team is restricted to a few and there is a shroud of secrecy. There is no delegation of authority and all decisions are centralized, with a great deal of micro-management. Appeasing the Manager or Product Owner is key, even when the team knows the path they are headed towards is a dead end.

 3)    Zero tolerance for failure

There is no room to show weakness or vulnerability. Team members feel if they fail or show that they don’t know something, they will be penalized or kicked out of the team. Very often, mistakes are covered up or blame is passed on to someone else. Of course, this does no good for the success of the project.

4)    Silos

Working in silos can be counter-productive, especially in cases where team members don’t realize what others are doing and may even duplicate work. There is no collaboration or knowledge sharing and everyone works in their own bubbles. Politics and ego take precedence over team work

5)    Toxic people

All of us can think of that one person who always claims to ‘know-it-all’, and very often insults or talks down to their team members in private or in public. They often hoard knowledge and may even be the gossip-central of the team. Everyone is afraid to confront this person and this person’s negative behaviour is tolerated, because of how skilled they are or because they are friends with someone important in the organization. However, no matter what value this person brings to the team with their skills, their negative behaviour will be more than enough to undo any progress their good skills may bring, with the breakdown of team morale.

6)    Contracting

The way many project contracts are structured today is with fixed scope and price. This structuring is a necessary evil to keep us within budget, but fails to leave room for an evolution of our understanding, with regard to what will really benefit the end-users. The project team’s understanding of what the end-users want, from reading the predetermined scope/requirements at the beginning of the project, will definitely be different from the time they are in the middle of the project and so on.

 So enough with the doom and gloom. Let’s focus on what we can we do to make our IT projects better. Here are some suggestions-

 1)    Use the best methods

More and more we are realizing that Agile and Design Thinking are increasingly effective in building bridges with our end-users, achieving early results and increasing chances of project success. Although, many organizations may not be mature enough to fully transition to Agile or Design Thinking in the blink of an eye, it is possible to integrate some of these methods in a waterfall framework, while organizations and teams transition. Hence, we must not consider methodologies as magic wands that make all our problems disappear. Adopt methods from Agile or Design Thinking or Waterfall that helps you achieve your end result, taking into account the organization’s culture and people. Organizational culture is an underlying factor why even the best methods fail and hence we must inject the right method or combination of methods that works for the organization concerned.

2)    Get the right leaders

A successful leader is a ‘Servant leader’, who walks the talk and creates a culture of trust. Leaders with an agile mindset are rare commodity and must be treasured. They outline expected results and clear obstacles. Good leaders don’t hire smart people and tell them how to do their jobs but instead give them targets and clear the path for them. They encourage openness and allow room for failures. They are transparent, and people focused. They have empathy and are good listeners. They share credit and don’t pass the blame when things go wrong.

 3)     The right team

A team should be chosen, not just for their skills, but also for their attitude and people skills. True, not everyone can be outgoing and social but that’s not the point, a team should be able to trust and respect each other. If people don’t enjoy who they work with, their productivity can go down.

4)    Contracting

This is a tough one. We must start re-structuring our contracts to allow us to adopt more agile/ iterative methods. Every case is different and hence we have to put our minds together to see what the best solution is in each case. Our contracting or agreements, need to evolve at the same pace as our project methodology.

5)    Employee Experience

Team members are people with aspirations and hence it is important to design recognition programs and hold other events like team dinners etc. Team members also need to be supported to grow into their areas of interest and progress in their career. A team that is supported to grow, will help the project or the organization to thrive.

6)    Offer solutions and not just an IT system

Most IT projects are overly focused on the software system, and all the finer things like change management, training and business process / roles transformation are marginalized. It is like building a house without a foundation- you may have produced the best software product, but it won’t succeed if you have failed to provide the full solution. Projects which pro-actively focus on business process transformation, change management and re-skilling the end-users, will find better reception and less resistance for their software product. This is what I love about IBM- IBM offers holistic solutions instead of just a product.

Being an Agile Coach/ Employee Experience Leader/ OCM Lead/ ERP Consultant, with 9 years of consulting experience across 6 countries and different organizations, I have a lot more to say on this topic, and I have a lot more to learn. My journey continues, and I will share what I have learned along the way as I move forward. All the best for your projects or programs!

 Author Rejo Mathews Agile Coach/ PeX Leader/ Senior Consultant / OCM Lead, IBM Canada, [email protected] or [email protected]