IT Project Recovery: Some Proprietary Insights from SYTOSS


While IT success stories are all around, IT project failures surface only in mag articles about big-time startups going bust. You may, sometimes, hear something on the grapevine, but it's neither often, nor much.

Their project just crumbling is not the scenario someone with a bundle of investor money is likely to consider all too seriously at the start of an IT endeavor. Especially, if the website of their prospective software provider sports an impressive collection of various client logos.

However, one look at the Google query stats is enough to understand that IT project recovery is not a terribly unpopular topic at all. A closer look will tell you the situation is widespread, to say the least. This may, probably, come as a surprise, but according to CIO magazine, in 2016 a whopping half of all IT projects failed. We are sure this statistic has been stagnant ever since, just like it had been for years before 2016.

What are the reasons for this happening? And what should you do if this has happened to you, or you simply sense that the current state of your project spells big-league trouble and something just has to be done about that now?

It just happened so, that we here, at SYTOSS, have quite a bit of hands-on experience in IT project recovery in the Telco sector. We'd like to offer you our take on the matter in the hope our insights will help you either avoid trouble, or extricate yourself from it early enough and in a more optimal way.

IT Project Failure: Nip It In the Bud, If You Can

Things don't go sour just all of a sudden. Whatever makes IT project recovery necessary can always be preempted if you are careful enough and have the right expert support.

From our experience, the vast majority of implementation-related problems originate from several areas, both technical and business ones. These areas have long been known. One of such areas, problems in which are responsible for a hefty number of IT project failures, is solution architecture.

Another frequent reason for IT projects hitting the skids is the wrong choice of the underlying platform: the platform you choose may either be at variance with your hardware, or just technically prevent your app from reaching the desired performance. In both cases, prior to proceeding with your choice, double-check from well-seasoned experts in these areas.

IT projects are, often, caused to fail by immature software development processes, wrongly selected methodologies, and the absence of proper business processes, well-tuned delivery-related interactions, or clearly defined tasks. For instance, one of the more typical failure scenarios is an attempt to deliver a project that includes strict deadlines, imposed by company-wide factors, using Agile.

Sometimes, when the implementation of a project is hampered by a lack of qualified resources, the company implementing it has to bring in staff from some other, overseas locations. The new employees' often lower qualifications, lack of business domain knowledge, cultural differences and unfit onsite retention practices all result in them taking their leave as soon as they have a smattering of the required industry expertise and get offered more profitable employment elsewhere.

It is not a rarity that the business stakeholders of major tech companies, who are in charge of implementing large-scale projects, have a pretty iffy idea about the final product and the business needs is it supposed to fulfill. Usually, this idea becomes more clear at a later stage in the project implementation cycle. This can trigger an avalanche of changes that affect the bulk of the already implemented functionality.

Often, big IT and other technology companies have many conflicting business processes. At the same time, their change management practices are far from the ideal. Untested contributions, made on the fly to a large enterprise system in an uncontrolled and undocumented manner by temporarily assigned employees, are a frequent happening.

There is only one possible remedy for all the above situations: an in-depth, overall analysis of the different aspects of your project. This should not be mistaken for Business Analysis alone, but should also include analyzing your methodologies, architecture, and technical processes. Moreover, you should also take a close look at all the key project-related appointments:- are you sure all those folks make good fits for their corresponding positions considering the project is failing now?

It is necessary to make sure your BA, employment and retention practices are up to par. In the case of outsourced projects, especially, if the project to be implemented is a major and complex one, you should pick a software provider with a strong Business Analysis team. This team must be capable of establishing a good communication flow. In addition, you should help this provider make the BA process as interactive, as possible.

Unfortunately, a software development project can deteriorate or become overly cumbersome financially at any stage in the implementation cycle. This can, even, happen already after your app has gone live. For example, if you fluff the BA/ requirements gathering stage, the maintenance of your software can become too costly. Frequently, this can be attributable to the use of legacy systems and/or antiquated technologies: in this case, you have to source difficult-to-find experts (a good example would be COBOL) who are at a premium, or, sometimes, even to re-engineer the system from scratch to ensure the desired performance, or achieve a required integration.

Conclusion: examine the technology stack you are dealing with from this perspective before the start of your development effort.

Sticking to the above tips from prior to when your project kicks off may spare you both a fortune and a lot of time-consuming dealings with companies that offer IT disaster recovery services.

What If It Has Actually Happened

If things have already gone wrong and you feel that the project implementation process has gotten out of hand, don't push the panic button. Start acting on the situation as soon as possible. Remember this: one can, basically, initiate an IT project recovery effort at any point in the project implementation life-cycle. Please, also, note, that, sometimes, it is necessary, expedient, and possible to perform project stage recovery, rather than project recovery. In other words, if, for instance, things have deteriorated in the QA department, there may be no need for you to mount an enterprise-wide IT project recovery effort.

You should start by looking for a reliable and qualified partner that can come to your rescue.

While project management companies and IT providers that claim having appropriate expertise are fairly numerous, you, obviously, don't have too many chances to muff.

So, how should you choose?

We would recommend the following criteria:

  1. In-depth business domain expertise. This one is an absolute must. Certainly, making this criterion your top-priority limits your choice severely, but there is no escaping this. Favor this one over any other of your selection criteria.

  2. Proven IT project recovery experience. No newcomers in the trade please. Make sure they've done it as an organization. Make sure that, at least, some of the same people are still on board. Make sure they currently have the capacity to come to your aid.

  3. A strong overall Business Analysis culture. It takes quite a bit of skill to unravel what is, often, a tangle of somebody else's business processes and workflows, vet them for viability and expediency, and, finally, create new ones, if required. Besides, while for smaller projects Agile may be the thing, for larger-scale ones well-tuned Requirement Management must still be in place in what should be, at least, 80% of instances.

  4. The ability to allocate senior software development experts to evaluate the code quality and determine whether your technology stack is a good fit.

Now that we've identified the kind of an IT project recovery agency you want to hire, let's proceed to the next stage.

The Problem Identification Stage: Getting to the Bottom of It All

As mentioned above, the reasons for an IT project going haywire can be many and diverse. For example, if the quality of the code seems to be the problem, it must be established how, for what purpose, and by whom this code is written, as well as how it is delivered and tested. If the problem seems to be related to the way your business processes are organized, these business processes must be analyzed and overhauled, and so on.

How do you best go about initiating your IT project recovery effort?

Although the authors of this article have taken part in, or spearheaded different IT project recovery efforts, we concur in the opinion that the following approach should, normally, be taken by an IT project recovery agency (and fully supported by you as a client):

  1. Identifying the key roles/positions within the business organization and persons who hold them.

    Client Actions: Make the required introductions and familiarize your project management consultants with the responsibilities of each of the roles in question.

  2. Holding interviews with the identified stakeholders and collecting relevant information.

  3. Composing an interaction scheme for the roles/stakeholders identified.

  4. Identifying the more frequent causes of disruption for the interaction flows, depicted in the interaction scheme.

    Client Actions: Be ready to provide relevant information and statistics for an extended period of time.

  5. Coming up with several possible reasons for the project's failure and corresponding solution options.

  6. Discussing the solution options with the client's stakeholders and decision-makers.

Implementing the Change: What You Must Bear in Mind

As mentioned above, the means of implementing the required changes can vary and depend on the identified problematic areas. However, there are several generic rules and recommendations that are of great importance and must necessarily be upheld both during the problem Identification stage and during the Implementation one. They are as follows:

  1. Your IT recovery consultants must talk you through all the existing solution options and guide your decision-makers to the right choice. No decision can just be forced upon any of your decision-makers.

  2. It may, oftentimes, be necessary to allow your IT project recovery agency's experts take up the leading positions in the project and you must be prepared to do so. We have taken part in IT project recovery efforts on site and can confidently say that this is, often, not only highly effective, but also totally indispensable: the vicious cycle of personal or factional interests, baneful tradition, mismanagement and negligence can, sometimes, be broken only through direct intervention by external experts.

  3. The external experts, involved in your IT project's rescue, must be given real leverage and be able to actually influence the situation.

If you are not comfortable with any of the above, or you do not have enough trust for those you've chosen for the performance of your IT project recovery effort, you may be facing much lesser odds of success, if any.

As a rule, IT project recovery is a multifaceted process that involves good knowledge of the business domain, strong IT knowledge, quite a bit of experience, and more.

If you have found yourself in a situation when IT project recovery looks like a possibility, we can relate and we'd really be eager to help. Just drop us a line if you want our take on what and how should be done in your specific case.

Related Articles

Optimizing Requirement Management in Business Analysis
Business analysis

Optimizing Requirement Management in Business Analysis

Do you have a promising project, but one, implementing which takes more than just programming skills? Do you have an awesome development team, but can just sense the business domain knowledge they have is not enough for the project at hand?  Do you think the Business Analysis process you currently have in place could be further improved?

We have recently re-engineered and optimized the whole of our Business Analysis process, taking into account the more than 15 years of Business Analysis experience our experts have. 

We would like to help you by sharing these insights here.

Read More
IT Staff Augmentation. The Advantages of This Business Services Model
IT Outsourcing

IT Staff Augmentation. The Advantages of This Business Services Model

Are you fed up with your operational and development costs continually skyrocketing just now, when you have so many exciting business plans?  Do you wish some of your developers and QA engineers had better qualifications, but you haven’t just been able to find anyone better for the great demand in your location? Or, is your business experiencing rapid growth, but you’ve just been unable to source several hard-to-come-by experts you desperately need to support it?

Eastern Europe may hold a great solution to all your problems. Let’s talk about IT Staff Augmentation.

Read More
7 Reasons to Hire an Independent Software Testing Provider
QA and Testing

7 Reasons to Hire an Independent Software Testing Provider

Poor product quality is known to have derailed more than one technology startup. Just like many smaller IT companies, startups, often, lack the required resources and experience, or their founders have too many things to tend to. 

How can such full-fledged and fledging technology companies benefit from Quality Assurance and ensure a good quality of their products?

Read More