Reasons for IT Project Failure Exposed

Introduction

Every IT company’s core power grows from a strong IT team (that deploys configurable projects on time). But why sometimes does this wonderful vision of an ideal team delivering a seamless project get ruined? Instead of productivity, innovation, and success, CTOs and CIOs face challenges connected with implementation, shrinking budget and a ticking clock.

According to The Standish Group Chaos Report, just nearly 30% of IT project implementations are done right and with success, whereas 20% of projects are total failures.

Before we get to the point of failures, let’s look at the requirements of a successful project:

All these things must happen to produce a project with pride. Well, as the expectations are high, the reality proves that it’s hardly achievable (nearly ¼ projects fail because of bad requirements). What are the reasons behind it?

Wrong requirements

The team is not present while someone is writing the specification for a project. If a team first sees a draft of something to work on, it can impact the whole process. It’s highly probable that the entire project will be impossible to complete and there’ll be a need to rethink it totally and.. start from scratch.

REMEDY:

Bring all experts together in the planning phase – partners, reps from IT teams, users(!) – they will tell you what to change and come up with some solutions. Business reps can cooperate with end users to know the main goals of any project. It’s a good way to design a successful project.

Uninvolved… sponsors

Sponsors are supposed to be involved in the development phase. They can’t just dictate the vision and wait for all the work to be done and released.

What if some problems, issues, question come up? There’s no rep to turn to. If a team of devs decides on the way a project should go with no consultation and make the wrong decision, the business will be ruined.

PMI’s research uncovered that over 27% of projects fail due to lack of sponsor support.

REMEDY:

Always check if there’s a project sponsor or another appointed person to consult, answer questions, and review work during a project’s development phase.

Shifting project objectives

Many IT teams work in the SCRUM framework – in short iterations (from one week to a month). At the beginning of every iteration there’s time to plan the work. The plan cannot be modified easily, but every new iteration opens up the possibility to implement changes.

Sometimes it may be hard to follow changing objectives but their impact can be minimized by embracing a model supporting the change if needed.

Remember: Changes don’t mean failure! You can reduce the risk by minimizing the time frame of plans.

REMEDY:

It’s good to plan work in 2-week iterations: say which set of tasks is the most important and and focus on them in those 14 days. Let the team be focused on the key work of highest priority to deliver valuable code.

Clumsy estimation

In the early phase of a project, estimating is like guessing. Your IT team knows really little about a project and its cost, estimated release time and requirements to know the costs of implementation and timeframes.

When development begins and requirements are less blurry, then it’s time to start slow estimation.

Changeable estimates seem to be required in IT projects as nearly no sponsor will invest in anything without assurance. They need something, a draft or an idea to know the cost and risk of investing.

In fact, inaccurate calculations and guesses are caused by:

• bad estimation practices – dev teams lack experience in providing estimations and assume more will go smoothly.
• planning too early – project managers and CTOs want to know the estimates as soon as possible and that often means immediately.

REMEDY:

If estimating isn’t working for you, try estimating in ranges. If your devs say that a project will be completed in 2 months, take it with the cone of uncertainty (in Agile) and consider the range applying to the current phase of the project. Eg. if it’s the initiation phase, relay the estimate as “from 2 weeks to 4 months”.

Sudden, unexpected risks

The cone of uncertainty mentioned above was in fact designed for such risks. In the initiation phase, developers estimate the time to complete coding. Right…just remember that there still is a high risk of unpredictable failures. Rely on estimating 4 times the supposed time of estimating time of release.

This extra time will allow for handling any unexpected issues that emerge. Think that thanks to the cone of uncertainty and no failures, you can finish earlier, cheaper… and think about announcing that to your client!

REMEDY:

Sudden risks in nearly 30% are the reasons for project failures. But there’s a solution for that! It’s the same as for clumsy estimates. Estimations needs to mirror the known and unknown risks to truly avoid unexpected missteps.

Resourcelessness

PMs, CTOs and CTOs tent to refer to people (meaning employees) as resources and having “not enough resources” refers to having not enough people to work upon a project. This situation occurs in over 20% of failed projects.

Various methodologies have different constraints. In the WATERFALL methodology – budget – here you have money to finish your work. In AGILE – scope – you do the work that your team is able to complete successfully.

In projects where the resources are low, it often happens that the scope, budget and timeframes are inflexible, which isn’t good. At least one of those constraints has to be flexible due to unexpected risks.

In fact lack of resources ought never to be the reason behind failure! It should be the reason why the project didn’t start. When you plan your project in a proper way, you should know from the start if you have enough people in your team(s) to complete that much work in a given timeframe.

REMEDY:

Solve the problem of resourcelessness simply: make 1 of the 3 constraints: TIME, BUDGET, SCOPE flexible.

We will end this article by giving a list of 3 things to do to SUCCEED:

• give all experts involved in a project a chance to speak up during the whole lifecycle to avoid wrong requirements and inadequate products.
• choose 1 flexible constraint – time, budget or scope – and make re-planning frequently to check whether plans are on track (or adjust them to be back on track).
• befriend the term “cone of uncertainty” to estimations from everybody involved to lessen the risk of unexpected failures and delays.