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:
-
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.
-
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.
-
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.
-
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):
-
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.
-
Holding interviews with the identified stakeholders and collecting relevant information.
-
Composing an interaction scheme for the roles/stakeholders identified.
-
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.
-
Coming up with several possible reasons for the project's failure and corresponding solution options.
-
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:
-
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.
-
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.
-
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.
