Why cloud IT projects fail

Insights from recent cloud projects and how we overcame the issues faced.

The majority of projects will see some unexpected complication, so it’s fair to say that cloud IT projects, which are complex by nature, are prone to their fair share of unforeseen circumstances.

First of all, before we look at why cloud IT projects fail, we need to understand what failure means. Failure can take many forms, from a project being scrapped entirely, to being delivered on-time and within budget but the solution isn’t fully fit for purpose. This can be caused by a range of factors including…

• Unrealistic timelines
• Underestimated costs
• Inadequate resource
• Overlooked requirements
• Unforseen/unanticipated technical or logistical complications.

While some of the above can be planned for, it’s often a combination that makes technical projects difficult to manage and deliver. Over the course of this article, we’ve focused on recent scenarios faced during projects at Cloudhelix, the risks they present and how they can be avoided.

There’s an overreliance on speed

Time and days are a tangible thing we all understand in business. The idea that you need something within an amount of time, therefore paying people for their time to deliver it makes sense, but is often too two dimensional for cloud and infrastructure projects.

Think of it like this; if your business is undertaking a huge infrastructure project, do you want its success to be determined by a pre-configured amount of days? If a project is of critical importance, it deserves the time and attention to succeed. Adequate time should be allowed for each step of the project, from data capture through to reporting.

It’s important we know when something will be delivered, but it’s imperative that when setbacks occur, the deliverable itself doesn’t suffer. It’s not uncommon for features to be stripped away as a deadline approaches, with the project becoming more about delivering something than meeting the project aims. In this scenario, it’s important that the project vision (the project goal and what problem is being solved) remains in sight.

When it comes to a technical project running late, avoid piling in additional resource to speed the project up. Brooks’ Law, from The Mythical Man Month [1], shows that increased manpower equals a later project. Here’s why…

n(n-1)/2

n in this scenario is the number of developers working on a project. So let’s say you add an additional 10 developers into your live project in order to deliver it on time…

10(10-1)/2 = 45 extra lines of communication

Throwing an increased number of developers increases your communication channels. Due to the complexities of software projects and the importance of communication within them, it quickly becomes very difficult to keep developers in sync. This then begins to delay the project further.

Let’s say you were building a house. Chances are you can estimate the amount of hours it takes to get a specific job done, and if need be, when a project begins to run behind, extra workers and night shifts can be brought in to allow for a faster build. More work being done = a house can be built faster.

The same can’t be said for software, cloud or infrastructure projects, where the complexity of the work means everybody has to know their impact on the rest of the development, which takes us onto our next point; what to do during a project where speed of delivery is imperative.

Delivering fast shouldn’t mean you’re delivering everything

Technology is implemented to solve a problem or answer a need. Most simply, it allows people to do work. A customer or internal stakeholder could come to you with a defined kit list and configuration requests, or they simply come to you with an issue and an end goal in mind. There are many ways to reach this end goal, and it’s important to remember that phase one delivery doesn’t have to be the all singing, all dancing end goal.

In cases when time is the defining characteristic of a technology project, i.e. “we need x by y date”, then speak to the stakeholder to understand what work this project will allow them to do, or what they can’t do without it. With this information, you can work out what your Minimal Viable Product (MVP) could be. You can propose a solution which can be deployed quickly and allows the stakeholder to get up and running within their timeline. The understanding being that the MVP, while meeting the project vision in a minimally viable sense, can be iterated upon until the maximum potential of the end vision has been reached.

Let’s say it’s Wednesday and your stakeholder requires cloud connectivity up and running in a new office by the end of next week. To meet the full client requirements, you might need about four weeks to complete the job. By understanding what a stakeholder or client is doing in that office, who will be there on day one and what they need, you will be able to offer a phase one alternative MVP that’s much more realistic and achievable than trying to deliver the entire project in less than a week.

This approach allows your stakeholder to stick to their deliverables and, with the MVP in place, your project team can continue working on the long-term cloud solution.

How the adoption of agile, automation, DevOps, PaaS and more should improve how cloud projects run

Some of the terms mentioned in the heading above are merely buzzwords for many enterprise IT teams, where it’s common for legacy issues to slow the introduction of new ways of working. The existence and growing prevalence of automation and agile project management in modern IT departments should make delivering technology projects easier, or at least it should reduce some of the risks that could derail a project.

The premise of agile project management and DevOps is simple; writing code in smaller chunks, testing it and deploying it once its bug-free allows far less margin for error. This approach means higher quality code is committed, which will help mitigate some of the many risks that can cause a project to change course.

Automation eases the pressure on your project team, especially when time is short and deadlines are tight. This would reduce some of the hands-on tasks techies have to carry out, including network configuration and load balancing. With some tasks automated, there’s less chance of human errors causing outages or bugs, especially given the complexity of the work, which can hamper productivity and affect timescales.

The idea of agile project management and failing fast allow for less of a fixed project goal to be set. While on one hand it might sound risky to kickoff a project without a fixed goal, it’s better to deliver a solution that’s fully fit for purpose than isn’t the victim of a rigid goal. The idea of failing and iteratively improving, as a general idea across the IT department, can help your business become more competitive by rolling projects out faster.

Any of the scenarios discussed in this post sound familiar? Are you working on a cloud project you’re worried might be starting to lose focus? The Cloudhelix team are happy to help. We don’t just get involved with new projects, we provide an outside eye and extra hands during large-scale, in-flight infrastructure projects in order to keep them on track. Talk to us today, tell what you’re up to and we’ll happily provide you with advice.

[1] – The Mythical Man-Month: Essays on Software Engineering is a book by Fred Brooks from 1975. The central theme to this book is that “adding manpower manpower to a late software project makes it later”. Read more about it on Wikipedia.

If you’d like to recieve our very best content click here and sign up to recieve fortnightly email updates from Cloudhelix.