Every IT project includes many levels, many elements, set of activities that common should create a process – starting at discovery and creating, and ending at delivery. And every process and every project can fail because of not well-working elements. Here are some examples of challenges in IT projects which seem to be most common.

 

 

Incorrectly defined business requirements

No wonder that about 39% of unsuccessful projects fail because business requirements have not been defined properly. You can’t build something that does what it should, meet its goals, and makes sponsors happy when you don’t have reasonable job requirements – you can’t even get it all done on time and within budget. Very often, the reason is that the conditions are created in isolation from the development team which has to take responsibility for their implementation.

A business team often works on collecting requirements for a year and creates a document that is 300 pages long. The development team then discovers architectural problems that affect most of the requirements, which means that they have to be changed a lot. Manager – what is natural – wants to achieve business goals and satisfy customers. To avoid the problem, you should involve all subject matter experts – business partners, IT representatives, and even end users – in the IT project requirements phase. Business representatives work with end-users to document the “what” goals of the IT project. IT representatives consider “how” – the best way to build what is required. When these two things happen simultaneously, the risk of the IT project failure from inadequate or incorrect requirements is significantly reduced.

Case Study: Qantas In 2008, the national Australian airline Qantas canceled its $40 million Jetsmart projects

Jetsmart was a project of building a parts management system for the company’s aircraft mechanics. Unfortunately, the solution was so poorly designed and complicated that the aircraft mechanics refused to use it as it was unnecessarily increasing their workload. Qantas officials later stated that they built what they thought was right rather than asking the mechanics what they needed. Without involving the relevant subject matter experts – end users – Qantas had to give up the costly PR.

IT Project sponsors not involved

Another big problem is that IT project sponsors communicate high-level requirements and wait for the finished product to be delivered. This is called development in a vacuum. This way, the team cannot contact any representative when questions arise. Instead of it, they are forced to make the best of guesswork and develop further. If they guess wrong, it won’t be known until development is complete. It leads to dissatisfaction with IT project sponsors, unreleasable products, and complex changes that make the project delayed and over budget. According to a 2017 PMI survey, inadequate sponsorship accounts for 27 percent of unsuccessful IT projects.

To avoid this setback, make sure the project sponsor or other designated business representative is involved in the development phase. The business sponsor answers the development team’s questions about the requirements and reviews the work in progress to ensure that what was developed meets the original requirements.

Case Study: HealthCare.gov

Probably the most publicized setback of the IT project of the last decade was HealthCare.gov: a government project to build a website that allows uninsured people to buy health insurance at a discounted price through private exchanges. HealthCare.gov was launched in October 2013, and problems arose immediately. The website was unable to serve the more than eight million users who visited it on the first days after its launch, so only 1% of people could register successfully.

Following an investigation, it turned out that poor communication and a significant lack of stakeholder participation were the two biggest reasons for the project’s setback. In his article, Steven Brill wrote: “No one in the White House at the pre-launch meetings had a clue that the technology was working.” The White House’s director of technology was deliberately excluded from project planning meetings.

Changes in IT project goals

Each IT project has three main areas: time, scope, and budget.

With the waterfall approach, time and scope are fixed, but the budget is flexible. The development team provides all the required functionalities within the specified deadline. If this is not possible, teams add a budget to increase the amount of work they can complete in the allotted time.

With an Agile approach, time and budget are fixed, but the scope is flexible. Realizing that little – if any IT project ever goes exactly as planned – Agile founders opted for a system that allows teams to re-prioritize what is needed to ensure that finished products meet their most pressing business needs and support business processes.

Most Agile teams operate within Scrum. Scrum teams work in short iterations that typically last from one week to one month. At the beginning of each iteration, the team plans its work. The plan cannot be changed during iteration, but each new iteration provides an opportunity to change the plan. There is a scrum master and project manager to keep an eye on it. The job needs to be done.

It may be impossible to control a change in IT project goals, but it is possible to minimize the impact of changing goals by working in a model that supports changes as needed. Changing design goals owes to 36 percent of unsuccessful IT projects, but plan changes don’t necessarily lead to setbacks.

Minimize this risk by shortening the time frame of your plans. Plan your work in two-week iterations: determine which set of work is the most important and focus on the tasks you can complete during those two weeks. This keeps the development team always focused on the highest priority work and consistently delivers releasable code. Remember to hire a great IT project manager for your project.

Case study: Virtual case file

From 2000 to 2005, programmers from the FBI worked on the Virtual Case File system – a system that was intended to modernize office IT systems and replace the old case management platform. After five years and nearly $170 million, the project was abandoned.

The case’s virtual documentation was deemed “incomplete, inadequate and so poorly designed that under real conditions, it would be essentially useless.” The team signing the software development contract emphasized that the problems arose from the extensive scope and frequent changes to the IT project specifications.

Inaccurate estimations

The uncertainty cone presented above is a graph intended to explain the problem with project estimations. When the team knows very little about design requirements and dependencies, cost and time estimations can be four times or four times less than actual costs and time frame for implementation.

As requirements are better known and development begins, this variability diminishes, but the only time it is zero is when the project is complete.

Variable, however, estimates are a necessary evil in IT projects, as few business sponsors are willing to return a blank check. Before approving an IT project, sponsors need to have some idea of whether they can afford it and whether the price is worth investing in or not.

However, inaccurate estimations are not the direct cause of project failure – even when reported as the cause of failure in 28% of IT projects. Approximate estimates are the result of two main factors:

1. Poor estimating practices – inexperienced development teams will often provide estimates assuming everything will go smoothly without underestimating time and cost.

2. Planning – IT project managers request an estimate too soon and never go back to the project team to determine if the estimate is still feasible. The solution to this problem depends on its cause:

• Inappropriate estimation practices: Provide estimates over time. For example, if developers estimate it will take them a month to complete a project, look at the cone of uncertainty for the range that corresponds to the project’s current phase. If you are in the initiation phase, give your estimate as .25x-4x, or “one week to four months.”

• Initial estimates: if they cause problems with the estimates, they should be planned and re-estimated more frequently. Get an estimate in the initiation phase, then ask the development team to come back to it once the requirements are met. During development, ask the team to continuously review the plan to determine if the project is still on track.

With proper planning and estimation, teams can typically deliver something on time and within budget – even if it’s not 100% of the requested scope. Keep in mind that for a project sponsor, getting less than expected is always better than getting nothing.

Case Study: Denver International Airport Baggage Handling System

In the 1990s, the city of Denver decided to build a new airport to accommodate more people using the existing airport. Part of the design of the new facility was an automated baggage handling system that would cut flight times by 30 minutes.

Unfortunately, the complexity of building a new baggage handling system has been grossly underestimated. The baggage handling system alone delayed the airport’s opening by 16 months and cost the city of Denver $1.1 million a day during the delay.

Although a version of the baggage handling system was finally released, it never worked as planned – even after long delays and additional costs of $560 million – and was eventually altogether scrapped in 2005.

Unexpected threats

There are three types of risk for any project:

• Known risks that you know about and can plan to mitigate. For example, you are dependent on another team completing coding before work begins, but this other team has yet to commit to achieving it. Because you know about this risk, you can be prepared for a worst-case scenario.

• Problems you know can become risks. For example, the team you depend on has committed to delivering its code by a specific date but is notoriously late. Even if it does not risk yet, you know it can become one, so you can plan accordingly.

• Unknown risk – a risk that catches you suddenly. For example, halfway through the code, you discover a dependency on a team that you haven’t spoken to at all. This is a considerable risk as there is no guarantee that the other team will be able to do the work that you now need from them.

These risks account for 27% of project failures. The solution to unexpected troubles is the same as the solution to inaccurate estimates. To avoid project failure due to unpredictable risk factors, estimates need to reflect both known and unknown risk factors.

The cone of uncertainty is intended for just this purpose. In the project initiation phase, your team estimates it will take a month to complete the coding. As there is still such a high potential for unknowns, an estimate of four times as much should be provided to the project sponsor.

These additional three months will provide time to deal with any unexpected threats that may arise. At best, you will finish three months early. It is always better to tell the IT project sponsor that you will complete it earlier and under budget than to say to them that the project will be late and cost more than planned.

Case study: A project to automate data collection in US Census Fields

In 2001, the US Census Bureau decided to initiate a project that would modernize how data is collected for the 2010 census. Instead of using paper forms, interviewers would build hand-held computers to collect survey data.

Unfortunately, this technology was more complicated to build than anticipated. After in-house development teams failed to develop the technology, the Census Bureau had to engage a supplier to complete its construction. However, the original failure left the supplier only one year to complete the project before the required test period.

Ultimately, the project was not completed on time, and the Census Bureau had to ask for an additional $ 3 billion to finance the 2010 paper-based census completion.

Dependency-related delays

In the case of large and complex IT projects, numerous development teams are often involved. Sometimes they are internal teams from other departments that own and manage specific platforms or services. Sometimes, they are sales teams customizing a product or service to meet the customer’s needs.

When other teams you depend on fail to deliver their commitments on time, it can ultimately push your project off the track. Dependency-related delays are the cause of failure in 23% of unsuccessful projects. There’s not much you can do to rush the other teams and finish their part on time. However, you can reduce the risk through proper planning and estimation.

The dependency delays fall into the category of known unknowns. Though you can’t be sure, the wait will occur – before it happens. You are aware that such a risk exists – always remember about proper planning. Use the uncertainty cone for other teams’ estimates. If they say it will take two weeks to deliver the needed changes, let’s assume it can take up to two months and schedule it accordingly. Have your team work on a functionality that is not dependent on changes in another team, and if that is not possible, plan to wait for another team to finish the project before starting work on the IT project.

Case Study: Boeing’s Dreamliner in 2004

Boeing launched its Dreamliner project to create an innovative, quieter, and more fuel-efficient aircraft. Project leaders decided to outsource most of their design, engineering, and manufacturing work, leaving Boeing the ultimate integration and assembly task.

Unfortunately, this decision led to many problems: delays in the delivery of parts by the supplier, the lack of documentation on how the systems were installed, and the receipt of fewer fasteners than necessary. Due to these problems, the Dreamliner shipped four years after its originally scheduled maiden flight, and the design cost twice as much as originally estimated.

Insufficient resources

IT project managers often use the word “resources” to refer to people, so “insufficient resources” refers to not having enough people to do the project. This is the reason for 22% of unsuccessful projects. Issues with members of the team and the quality of the team are the most common IT management problems.

As mentioned earlier, different project management methodologies have various persistent limitations. In waterfall it’s a budget, meaning you have to add as many people as it takes to complete the job. In Agile it’s a scope, meaning you only engage as much work as an existing project team member can do.

Projects that fail because there weren’t enough people are usually the result of running projects with a fixed scope, budget, and timeframe. It does not work. One of the three constraints must be flexible to accommodate unforeseen risks. A lack of adequate resources should never cause failure – it can only be the cause of not starting a project. With proper planning, it should be evident that there are not enough people to complete the required amount of work within the required timeframe. The solution to this problem is to make one of the project’s three-time budget or scope constraints more flexible.

If you need to deliver something within a specific timeframe and budget, commit to a smaller scope. If you need to provide the full scope within a particular time frame, wait for more resources before starting your project.

IT project management problem

The last IT project management challenge is all about process and the people responsible for this process – IT project managers. When an IT project is mismanaged, the signs are unmistakable. The budget is eaten up too fast, teams don’t have the right goals.

Creating a plan is not enough. Someone has to monitor this plan. This could be a project manager, IT manager, or scrum master – it doesn’t matter. You need the project manager to monitor your progress. Inadequate supervision over IT project management accounts for 20% of unsuccessful projects. To prevent this cause of failure, you must have a person responsible for monitoring progress against your project issues and goals. If you assign supervision to someone with little IT project management experience, make sure you invest in proper training before starting the project. The type of training required is flexible. Outsource this person’s long-term study for PMI certification or ask them to spend a few days learning about the types of planning exercises used in Agile.

Case study: Shared Services Transformation Program

The Shared Services Transformation Program was an IT project to be used by the UK Department of Transport. Once approved, the project’s estimated cost was £55.4 million, but it would save £12.4 million over ten years.

Unfortunately, the numerous changes and unexpected complexities – coupled with little oversight of IT project management – caused delays and increased costs. Before the problem became visible, the project’s cost had risen to £121.2 million, while projected savings for the department had decreased to £40.1 million. Due to the project’s poor management, a project manager wasn’t the right person for the problem of this IT project. Which aimed to save 57 million pounds, actually cost 80 million pounds.

Team members procrastination

Accounting for 11% of unsuccessful projects, delay caused by team members goes hand in hand with poor IT project management and bad IT project managers. If developers are procrastinating or if other team members the developers depend on are not delivering answers, high-quality code, or services on time – it should be evident that the IT project plan has gone off track.

In addition to monitoring the plan, the person responsible for overseeing the project and business processes must keep a register of cases and requests and pressure those responsible for providing answers. Look for someone detail-oriented, organized, and aggressive – not negatively, but productively. The project manager must be willing to escalate problems to the appropriate channels when necessary to resolve the issues and obstacles that, if not resolved, could lead to project failure. That’s project management!