Playing the Blame Game: Who should be held accountable for the failure of an IT project?

Do you know the percentage of IT projects that get declared as a failure and are scrapped? If you don’t, the answer will surprise you. Recently, I was going through article published on CIO, where the author mentioned stats about a survey conducted by a cloud portfolio management provider named Innotas. The survey polled 126 IT executives from January-March 2015 and revealed that 55% of the respondents claimed that they had experienced project failure, up from 32% in 2014. That’s close to an increase of 70% in a relatively short span of time.

“The better prepared you are to fail, the greater are your chances of preventing it from happening”

Someone once told me that the better prepared you are to fail, the better you’re suited to prevent it from happening. And I believe it to be true in today’s world. With millions of dollars wasted each year because of scrapped projects, one must be ready to face all possible contingencies in order to come out with improvised solutions to the problems faced during the development of the project.

What does “Project Failure” mean?

Simply speaking, a project is termed as a failure when it doesn’t deliver what was promised. Moreover, failure also means the loss of revenue for a company, owing to one of the following reasons –

· Extension of the project timeline midway, which the customer doesn’t agree on, leading to the IT professionals putting in extra unpaid work.  

· The client abandons the project due to constant changes in the timeline and the budget.

· The IT professionals have to spend lots of time finalising the project requirements with the client, without anyone paying for those wasted hours.

The situation problem at hand

IT projects are often complex, time consuming and resource intensive. Though each project is different, the reasons for failure are similar. With the proportion of failed projects on the rise, it is no surprise that it bears a huge cost on the economy. In fact, IT failures cost the US economy around $50-150 billion annually. Moreover, only 2.5% of companies successfully complete 100% of their projects.

The most common reaction of a customer after the failure of a project is to cease all business transactions with the IT firm as he/she strongly believes that it’s the company’s fault. They also publicise their experience and subconsciously advise people in their connection against conducting business with the aforementioned firm.

Addressing the common misconception

A communal misunderstanding among people is that it’s always the fault of the IT firm, which is blamed for every small setback in the development life-cycle. They give the firm a poor rating and some common statements posted by angry customers on different sites include phrases like “Their performance was not up to the mark” or “They lacked the necessary communication skills” and such like. An involuntary reaction associated with bad experiences of angry customers is to share their experience with the maximum number of people so that they too stop doing business with that firm.

But if you’re still with me, let us look and analyse the causes of failure from a neutral third party’s point of view, having no stake in the matter. More often than not, the customer/client is equally to blame in case of an unfortunate event where a project is scrapped or abandoned. We will talk about the particular cases later on in this article, but first, let’s talk about the scenarios when the workflow and management of the IT firm is one of the primary reasons of failure.

The common causes of failure – When the IT firm is at fault

1.      Misaligned expectations

The expectations of the professionals and the customers are not really in sync when talking about the future of the project. The developers plan to launch versions of the project and work on the issues received through feed-backs to boost the performance and ensure smooth working of the project whereas the client wishes to get the final product in the first release.

2.      Poor planning

Most company officials are so thrilled to be assigned a new project that they get on it right away and think they have it all planned in their head. Without a proper team meeting where members give their respective inputs and the plan is finalised in black and white, the entire process is prone to managerial setbacks where issues such as redundant efforts and wasted energy are major contributors to the doom of the project.

3.      Faulty resource shuffling and no reporting/updates

When there is no proper work plan, it is not known when and which resource will work on the project during the development process. A natural consequence is that the management does not know the progress of the project and is unable to communicate the same to the customer thus making the customer lose faith in the company and making him/her question his decision of working with them in the first place.

4.      Starting work without proper allocation of resources or budget

Companies nowadays are so pressed on delivering projects within the specified time period that the sales teams informally convey the requirements to the software developers and the work begins even before the client has agreed on the budget mentioned by members of the sales team. The end result of such a faulty approach is that when it is time for the customer to pay for the services offered by the company, there is a discrepancy between the proposed budget and the actual budget, due to which the customer ends up paying more than what he/she was supposed to. If this gets blown out of proportions, the customer might scrap the project and look for other vendors.

5.      Internal conflicts

Project managers resolve inter and intra departmental conflicts on a daily basis. There are a number of reasons for these conflicts, such as differences in the proposed approach towards the completion of a project, availability of resources, miscommunication, team members not getting along etc. A primary drawback of such events is that instead of sticking to the timeline and getting the work done, a lot of time is spent trying to resolve the issue at hand and following an approach which is suitable for everyone.

6.      Assigning inexperienced resources on critical projects

After the budget allocation, when it’s finally time to start working on the project, inexperienced resources should not be assigned on projects which are of huge value to the organisation. Such projects demand the best of what an organisation has to offer and instead of providing a learning opportunity to the rookies (who might make numerous mistakes and delay the completion), the primary focus should be on completing the project with the minimum possible delays.

7.      Inadequate documentation

Lack of proper documentation and (or) not updating the progress charts of a project is among the most severe reasons for failure. This is because when the client asks for updates and the Project Coordinator is inadequately informed about the latest details regarding the project, it puts off a bad image of the company in front of the customer, making the customer feel that his/her project isn’t taken seriously by the professionals.

8.      Inability to identify KRA and KPI

Wrongly identifying the KPI and the KRA can have grave effects on the project and thereby the company as the developers might have understood the KPI to be something and prioritised it over other factors whereas the customer might be expecting and judging the company based on another. This mismatch between the expectations and the actual end product delivered leads to conflicts and tension between the client and the service provider.

9.      Not addressing scope volatility

Due to improper and informal protocols during the planning phase, there is no dedicated workflow, which leads to unprecedented growth in the scale of the entire project during its life-cycle; further adding to the budget of the project, owing to which, either of the two might happen –

· The customer ends up paying more than what was agreed on.

· The company has to put in extra unpaid man hours to compensate the customer.

Both of which are considered as the failure of the project.

10.  Failure to think ahead and predict bottlenecks and other problems

A Project Manager/Coordinator (PM) usually knows his team well enough to predict where a particular resource might face troubles or might need help. When the PM lacks the ability to foresee such troubles, it creates unnecessary chaos and such mismanagement leads to added overhead costs, which in turn lead to an extension in the project timeline ultimately leading to project failure.

11.  Key decisions made by people who lack relevant experience

Although it is necessary for companies to provide proper training to their employees, it should not be done at the cost of the project at hand. Success is all about making the right decisions at the right time and following through on those choices. But while handling a project, the key decisions should be made by seasoned professionals who know the working of the company inside-out. The experience of such senior employees often plays an important role in guiding the different team members and ensuring the successful completion of the project.

12.  Lack of proper testing and not paying attention to feedback

With the deadline closing in and angry customers regularly asking for updates, companies usually push forward the launch of the project without fixing all the bugs and issues with it. Moreover, when the pressure of the launch is too much to handle, the companies are unable to take care of all the issues the customer had mentioned in his feedback, further enraging him. The customer might refuse to pay the firm for its services or even ask for extra unpaid man hours as compensation for not delivering what was promised.

13.  Solving the wrong problem

A typical example of “Solving the wrong problem” is when a customer requests a small change in a page of his website but the developers misunderstand the request and end up changing the layout of the entire page. Similarly, consider the customer support services provided by various companies. What the support staff does is simply reaffirm the customer that his/her problem will be solved instead of actually taking out the time to feel the customers’ pain and help resolve the issue so that it doesn’t happen again.

14.  Lack of understanding of the client’s expectation

Generally speaking, there are four stages in the life cycle of a project viz.

· Stage 1 – The Sales & Marketing team gathers the requirements from the client.

· Stage 2 – The Business Analysts draw up an estimated project timeline and calculate the budget, which is sent for approval by the customer.

· Stage 3 – The requirements gathered in Step 1 are shared with the software developers and other involved teams so that work can be started.

· Stage 4 – Testing is done and finally, the project is handed over to the customer.

Now, when what the customer wanted to convey and what the Sales & Marketing team understood is different, there are going to be clashes ideologies during the entire life-cycle of the project and a lot time will be spent in redundant tasks where the objective will be to try and align the entire project with the customer’s expectations; thereby leading to extension of the timeline and extra costs.

15.  More than one Project Manager/Coordinator

When there are more than one Project Manager(s)/Coordinator(s), it’s obvious that they’ll have different approaches towards the how the project should be handled. Moreover, since both have equal authority to talk to the client, if Mr. A is not at the office for some reason, Mr. B will communicate with the client. A consequence – Mr. B might give instructions to the resources different from what Mr. A had initially given and as a result, there is confusion within the team leading to complications with the successful delivery of the project within the predefined timeline.

16.  Poor requirement gathering and aligning entire team on that plan

If the right requirements are not gathered from the customer, the development takes place in a direction different from what the customer had hoped for. When there’s a difference between what the customer is expecting and what the developers are working towards, it leads to the wastage of precious resources in order to be on the same page as the customer. 

17.  No good discussion between Business Developers and the Operations Team

After gathering the requirements from the client, the Business Developers forward that information to the Operations Team. There are two main problems arising from improper communication with the client and with other teams within the organisation –

· Since the client cannot be bothered to ask for the requirements time and again, the Business Development team has only one chance to understand the full scope of the requirements from the client. Any fault here will cause troubles during the development in the later stages and on the final end product.

· The Business Development team was unable to properly explain the client’s requirements to the Operations Team (and thus the development teams) leading to the company failing to meet the customer’s expectations.

Both of which will ultimately lead to the failure of the project.

18.  Lack of red flags alarms on the project

The thing that surprises most PMs is that even when the developers are fully aware that they’re standing at the “Oh! This project’s deadline is tomorrow” mark and the project is barely 50% complete, the PM isn’t given any information about the progress of the project as the development team never raised any flags on this matter and the PM wasn’t kept in the loop. 

19.  No change request alarms

It’s natural for a client to provide feed-backs and give his suggestions during the development phase of a project. If the client suggests a particular feature and the developers start working on it (perhaps even exceeding the budget agreed upon by the client) without any written confirmation from him/her, he/she may refuse to pay the firm owing to the overall cost exceeding the budget which was given to him. The primary reason for failure in such scenario was to not inform the client about the extension of the timeline and the added costs to the budget and implement the changes without the client’s confirmation.

When the customer is to blame for the failure of a project

1.      Lack of clarity

A major complaint of IT professionals is that on numerous occasions, when the customer approaches an organisation for help on a project, the customer himself is not clear as to what his requirements are. The customer expects the representatives from the organisation to guide him on the subject. Therefore, a lot of time is unnecessarily spent in coming up with ideas which the customer might like.

2.      Inability to differentiate between long term and short term goals

A majority of the clients expect their business revenue to skyrocket after the release of their project. While this may not always be the case, the inability to differentiate between the short term and long term organisational goals is often the reason for the customer bearing a feeling of animosity against the IT firm. The customer expects miracles straight after the release and blames the IT firm when no such thing happens as he/she often fails to grasp the Time Vs Goals concept.

3.      Impatience

We’re all in a hurry. In today’s fast paced world, there is no time to slack off. So are the clients, often in such a hurry that they want their final project (free from any and every bug, obviously) as soon as possible after the requirements have been successfully understood by the Business Developers.

What the clients don’t understand is that there is a protocol which needs to be followed before officially releasing the project to the public. First, there is a PoC (Proof of Concept) demonstration to verify the real world applications of the project. Then there’s a MVP (Minimum Viable Product) to show to the client to receive feed-backs for future development purposes. And lastly, there are different releases of the final project with bugs fixed and updates being made with each subsequent release.

4.      Selection of wrong vendor

Hiring a big company to help you with a new IT project might seem like an easy option. These suppliers are almost always competent in their field with credible experience and a solid portfolio of projects, perfect for your needs but aren’t always your best option. The cheap vendor may be appealing but you need to know why they’re working for a cheaper price.

Is this because they have a distinct advantage, giving them the ability to deliver at low costs or do they plan to set a course to improve their margin by making frequent changes to the project during the development phase?

Clients must be extremely careful in choosing their IT vendor by following up references and testing the vendors to see whether they possess the required competence and knowledge. Surveys show significant resources wasted for development write-off purposes, which could easily be avoided if the client was more vigilant during the procurement and planning phases.

 5.      The customer changes his/her mind

During the development phase of the project, if the project takes too long to deliver or strays too far from the decided budget, the customer might end up changing his/her mind and abandon the project. A successful project requires commitment not only from the developers’ end, but also from the client’s.

When and if a project is abandoned, all the man hours that were put in for the success of the project go to waste and are the project is a failure thus amounting to a severe loss for the company.

6.      Requesting drastic changes midway

Researchers have found a direct relation between the size of the project and its probability of failure. This especially holds true in the case of a customer requesting major changes to the project when the work on it has already begun.

If the customer comes up with an idea and requests huge changes to the project in the middle of the development phase, both the timeline and the budget will increase accordingly. Now, the customer may or may not agree upon the added costs to the budget and might ultimately abandon the project before its completion.

7.      Client is very choosy and not sure about what he wants

When the client takes excessive care while making choices and finalising decisions, he/she expects the IT professionals to help suggest and implement the best possible features in the project within the specified budget.

Now, when the IT professionals do suggest the required features, sometimes the cost goes up and the customer feels that he/she is being conned and the customer ultimately ends up looking for new vendors and service providers.

8.      Client’s involvement with the resource and bypassing the project coordinator

The PM should be the only bridge of communication between the client and the developers. If this isn’t so, there can be communication gaps between the client and the PM as the developer can sometimes lack the necessary communication skills to convey the client’s words to the PM effectively. Else, requirement gathering will become a redundant task and will lead to wastage of precious time.

Repercussions of the failure of a project

Failed projects, apart from adding to the losses to the company, damage the company’s relationships with the client. At times, there are disputes filed by the customers and huge compensations have to be paid by the company officials.

Clients lose faith in the vendor and take to social media to share their experiences with others, amounting to bad publicity for the vendor and huge potential losses. Bad publicity further adds to the vendors’ woes as there is no revenue generated by customer referrals and there is no brand growth.

Furthermore, there will be no repeat projects from a client (the biggest source of revenue for 74% of IT vendors) if he/she loses faith in the competency of the vendor. The client too, will suffer a loss if the project fails and he/she has to get it redone through another vendor.

A sustainable approach

In order to successfully complete the project within the dedicated timeline and budget, it is imperative that the client and the IT vendor work together and be completely transparent while communicating with one another. The vendors have various channels to prove their competency in the domain. So, after short listing the right vendor, the client needs to be clear regarding what he/she expects at the end of the project.

The firms should also work on their resource shuffling capabilities and plan their approach meticulously in order to avoid any setbacks and delays in the project. They should streamline their approach when starting work on a project and always keep the client in the loop while making critical decisions such as those which further add to the cost of the project.

Both – the client and the firm – need to understand that the client is helping the firm generate revenue and the firm is helping the client achieve his/her business goals. They’re both part of a symbiotic relationship – each benefiting from the other's efforts – and are equally important for the growth of the other.

A final note

If and when a project fails, the involved parties should not play the blame game and instead try and work towards making sure that such a thing never happens in the future.

And instead of having stereotype opinions, it is always advised to have an open mind about matters so that one can effectively come up with solutions to the problems instead of spending resources in getting tasks done and repeating the same mistakes over and over again.

I hope this post helps you look at things differently and understand both points of view (the client’s and the IT vendor’s). If you keep a cool head and work your problems with your vendors/clients through effectively, you will successfully ensure that the project is completed efficiently and both parties will benefit from it on the monetary front (imagine Tom Cruise from Jerry Maguire yelling “Show me the money”).