Let’s first get expectations right: Don’t expect wonders, there is no cure-all for all kinds of software development projects that spiraled out of control. Some projects may have gone astry in culs-de-sacs to a degree, that you should just start afresh.
Secondly, the reasons for the failure of IT projects are manifold, and the approaches to solving them are equally diverse. Consequently, this article outlines a set of practical methods that can be used to identify the root cause of issues and develop an appropriate solution.
Who’s best suited to act as troubleshooter?
In a first step you need to determine the status quo of an IT project: Which development progress has been achieved? What are the reasons for the project crisis: incomplete specifications, lack of developer expertise in the relevant technologies, wrong prioritization of features, poor communication, overstretched project managers?
In order to get answers to all of these questions, you need to someone to dig deep, talk to all involved parties and put the pieces of the puzzle together. Anyone who wants to establish the status quo and get a fair picture of the situation, will be confronted with a serious amount of the blame game. It generally requires a fair amount of diligence and smart questions to cut through the noise and emotions. In many cases some key issues are well-known already (and may have been ignored), or a few interviews will bring up sufficient insights on critical challenges and wrong decisions; such interviews can be done by management or a well-reputed senior who is not part of the project.
In a few cases you may require an external troubleshooter, especially if you have the following gridlocked situation: Communication between the different project participants has come to a standstill, the situation is (emotionally) completely lost. If an external troubleshooter enters the field (this can also be an “external” troubleshooter from another department of the company), then he or she should have the following qualities in particular: Distinctive communication skills, high resilience, good analytical abilities and expertise in the relevant technology environment as well as the domain. For sure, know-how of agile and other project management methods is required as well. With regard to acceptance by the various parties in the project, he should have a technical authority, for example, based on proven success in project management.
Analysis of the project status and the causes of the crisis
It seems a no-brainer, but especially in derailed IT projects there’s no easy answer to the key questions: Where do we stand in the project? Which requirements have already been implemented, tested, ready to be deployed? Which features are already in use? Which costs have already been incurred? Are the milestones and expenses until the achievement of the initially agreed project goals already defined, what is the level of uncertainty?
The troubleshooter must also make a root cause analysis of the reasons for the crisis. There is a multitude of possible causes for this, some of them are listed below (without claiming to be complete): The domain managers deliver wrong, inconsistent, incomplete or ambiguous functional specifications (or even an endless stream of change requests and new requirements). The project management (in a Scrum project: the product owner) is overburdened and does not make the necessary prioritization decisions in time (or not at all). The technology stack for the project is not suitable for the requirements at hand, which may result in poor performance, high development effort, insufficient security, low scalability or even functional limitations (in the worst case this may endanger the project goals). Libraries are used that cause licensing issues. The development team has a high turnover of staff. The development team does not have sufficient expertise for the technology used. End users are involved too late in the development process (untypical for projects using agile methods). The budget was set too low from the beginning.
This status and crisis analysis requires familiarization with the essential project documents and project documentation, as well as discussions with developers, domain managers, software architects, etc. Depending on the size of a project, such an initial analysis phase takes one to a maximum of three weeks.
reorientation, project stop or development of alternative development paths
If the team didn’t get the entire technology wrong and if the crisis situation comes down to one or two weak points in project management or organizational set-up of the project, an approach to achieve the turnaround may seem obvious quickly and may be achieved with comparatively little effort: The project goals are adjusted, or adjustments to the project management method are introduced, or you may have a shuffle in the development team or project management organizsation.
In some IT projects – especially in larger projects – the first analysis phase identifies the causes of the crisis, however, the development of solutions requires more time. Let’s assume, for example, that the choice of the technology stack was ill-devised; in such case it is anything but easy to decide what to do next. Start from scratch with a different technology-stack? Exchange parts of the Components? Continue with development in spite of drawbacks from the technology stack? – It will require time to evaluate the different scenarios or development paths. We’ll call this the (conceptual) solution phase.
Project restart: Renewed kick-off, clear project vision, close project controlling
Once a project has fallen into crisis, frustration, anger and/or lack of motivation often spread among those involved. Therefore, it is eminently important to make a visible break and close the “old” project or the past. In a kick-off for the project phase after the crisis, it should be presented in a way that is comprehensible to all, what has been identified as the causes of the crisis and what measures will ensure the success of the project in the (near) future. The presence of the top management at this kick-off underlines this new beginning.
Here, the clear communication of the project vision is once again imperative: Why are we implementing this project? What are the benefits of the IT project? Why is it so important to top management? The more convincing this target vision is, the better a project team can get through a difficult phase in a project, the higher the motivation to go the “extra mile”.
And last but not least: Progress monitoring or project controlling has a special relevance after a crisis. If such an IT project controlling already existed before the crisis, it should at least be extended so that in future the causes that led to the crisis are quickly visible – and can be avoided this time.
