How To Turn Around a Failing Software Project

Introduction

In this article, I will discuss some scenarios and situations that involve turning around a project and saving it from the jaws of failure. I will also discuss those cases where chances are slim or non-existent. And finally, I will discuss some of the possible solutions and pitfalls. A word of warning, this won’t be about heart warming stories and people probably won’t be singing kumbaya afterwards.

Failure and success can be framed in many ways for a project, depending on whether you are in a product company, a services company or a non-tech company developing internal projects. In the first case, success might be defined in terms of goals achieved (business and/or technical) and meeting deadlines, in a service company successful delivery on time and spec for a particular customer or customers. And, in the later case, it will be successful delivery on time, satisfying the requirements of the internal stakeholders. I know… This is all very fuzzy in terms of defining success.

While success is not guaranteed, failure, on the other side, can rear its ugly head early on. When deadlines are missed, budgets burn like a match and technical flaws show themselves with high bug counts. As problems start to accumulate, people start to get anxious, reputations are at stake, sometimes the company’s future is at stake. As the project spirals close to failure, changes are needed to turn the boat around with a new captain on board.

Naval metaphors aside, being a project manager under duress is very much like a soccer team manager that was hired to avoid relegation to a minor league (yay, sports metaphor). Some managers are specialized in turnarounds, it is not a pleasant job. Usually, it comes with consequences for the team members, with some players getting health issues for the rest of their lives in the process.

But project management isn’t operating in a competitive sports tournament landscape, projects aren’t a sequence of games that need to be won against other teams and intermediate victories can be invisible to stakeholders, and defining success is not as easy as checking against a score.

Best Case Scenarios

Failure presents itself in many forms, sometimes for external reasons like a death of a key person, an unexpected downturn in the economy, a middleware product that was discontinued that can severely impact the chances of success. Many are internal, bad choices when selecting managers and team members, company culture and other human related issues. From my experience, technical issues are most of the time more tractable than human issues. Especially if what is required is more time to get around the learning curve. Human issues, on the other side, can spiral into a lot of drama and soap opera re-enactments with no extra dramatic music though.

For when you are presented into the drama of a failing project the best situation that you can have is:

• Upper management is committed to the success of the project (a bit desperate will be nice, but not too much).
• The previous project manager has left the company (more on that later).
• The team members aren’t all duds and have enough skills to get the work done.
• The budget isn’t running on fumes.
• The company’s culture isn’t the cloak and dagger type.

The first thing that you will need to do is to understand what the project is, its goals and scope, timetables, technical architecture and technology dependencies. Afterwards, meet the team, understand what roles each one has, read their interactions and their demeanour, don’t make any judgements based on first impressions. Discuss what was done by the team so far, if possible do one-on-one meetings, check if the information from the team in the meetings, and on the individual interactions are consistent with each other. And, if the information that the team is giving is consistent with the feedback from upper management.

If possible, before interacting with the customer or third-party stakeholders, get an understanding if the previous project manager has lied, mischaracterized, deceived or in any way told tall tales that have framed their minds about the state of the project. If the answer is yes, then tread carefully... people often get very emotional when the facts are told, so start getting some information about these third parties and don’t do any reveals on your first meetings with them.

On the first meetings with your peers and direct superiors, discuss small on-boarding issues and check their responses, also evaluate their actions to small requests for information that is connected to the project and the company. In those meetings, check how everyone behaves, determine if there are managers that are prone to snap or bully. Check how other managers react when they feel under pressure. This will be important to evaluate to what degree the systems of rewards and sanctions are applied within the company and what type of personality is usually hired for managerial roles.

After the initial stages of getting to know the team, peers and third parties, make an initial evaluation and determine what are the ones that can help you, those that are neutral and those that can hinder you. This evaluation is not a static evaluation but a continuous loop until the project is finished. So, when you implement an initiative, you will monitor the feedback and responses, and re-evaluate your position, and make corrective changes for the next iteration.

One of the items that requires quick evaluation is the overall composition of the team, identifying poor performers and team members that generate entropy. Team members that don’t contribute with much code and have a high rate of defects for the amount of code they contribute, or break the builds frequently and don’t listen to other team members feedback, should be removed from the team as quickly and painlessly as possible. Check for internal replacements if possible, prioritize for developers with a good track record and that know what they are doing. If you need to hire or contract, prioritize people who you already know and have worked with before and meet the previous conditions – keep a habit of keeping in touch with developers that performed well in the past and that can still help you or can reference people who you can work with.

Keep an eye for armchair trainers that keep second guessing your actions, these can be especially problematic before you can show results and can frame the attitudes of others and of the upper management.

On the project side, you will need to tightly manage scope, it is of the utmost importance to identify and focus on the core deliverables and avoid being distracted by side-features. Renegotiate the scope with the stakeholders and have them agree to a primary set of deliverables. This is the time when it important to know in advance if the previous manager over-promised or lied about the status of the project. Scope needs to be negotiated at every iteration, and it needs to fit the capacity and the skills of the team, over-promising or over committing will not get your project on-time and on-spec.

To evaluate the status of the project, you will need to meet regularly with the team members, either on stand-ups, sprint meetings or meetings to discuss project issues. Meet individually, if possible, to check on critical developments and evaluate what work is still required and if there are any blockers. Insist on a continuous release system with at least a set of sanity tests to verify early problems. Verify the feedback from the QA team and check how the defect count is evolving and verify if individual team members require help in resolving any defect. Prioritize stability over features, team members need to fix defects before starting new work.

On the QA side of things, prefer a data driven approach, have a process for comparing the results of the software project the team is developing against an older version of the product, client or company data, or business scenarios developed by the QA team or Business Analysts. Use also methods to generate noisy data to verify how the software handles boundary conditions and errors. This will provide a benchmark of progress that will help in gaining the stakeholders thrust.

Be alert for software dependencies that start breaking your builds, track their versions and make judgement calls with the team about when to revert to an older version and when to fix the code that no longer works with the new version of the library. Schedule this work around deliveries and avoid doing this when pressed on a deadline. Also, avoid the temptation of switching from software libraries for capricious reasons, only if there are clear advantages and the schedule allows for rework.

Automate as much as you can, don’t fall for the trap that says there is no time for automation. Start automating at the very beginning by identifying a suitable candidate to do this work, and identify the work that has the most repeatable patterns. By doing this, you can create enough slack that can be used to mitigate any need for extra rework due to unforeseen events, a missed requirement or to clear defects.

Make clear and frequent reports with the milestones that were reached, but beware of sounding too optimistic. That might create the incentive for upper management to start cutting resources, budget or reduce the time on the deadlines before critical work is finished. Also, it might create exaggerated expectations that might be dashed by unknown unknowns. All of these items represent extra unnecessary stress and have the potential of becoming a reputation risk for yourself.

Find ways to reward the team when a difficult milestone is reached, it is an important signal that their effort is appreciated. When communicating with them, be straightforward and clear. If there is a risk of the project being cancelled due to a change of mind of a stakeholder, let them know. Address these risks with the team and also the actions that are being taken that can mitigate the risk.

On this scenario, a successful turn around is still a lot of work, but you are still dependent on managing the relationship with third-party stakeholders. These need to be reassured by the quality of the deliverables, and they need to feel that the scope of the project is bringing them value. If they feel otherwise, they might be tempted to cancel their participation or cancel the project.

From this best case scenario, I have given a template that will be expanded in the next cases that are much less optimistic.

Project Gone Wrong II

In this situation, you will have your work cut out for you. Here, there is an increased risk of things going wrong, mostly due to human issues. In this case, the project is already showing signs of stress, and there are extra factors that can increase risk like:

• Upper management requires quick results but isn’t committing much into new resources or support.
• The team is unbalanced, with not enough highly skilled developers.
• The budget is conditional on reaching goals, so cancellation is a constant spectre.
• The previous manager is still working in the organization.

In this situation, you will need to quickly determine which developers are good enough to continue the work, and identify those you need to try to replace as quickly as you can. You will also need to verify if the team lead is part of the problem and if you will need to find a new one. In this, being an insider actually pays off, you probably already know the people in the team and who in the company can be allocated. So that you are able to re-structure the team for the project needs. An outsider will have a tough time to quickly understand those that can get results from those that sit idle browsing Facebook as they fake being busy.

The other question is understanding why the previous manager left the project but still kept her/his job in the company, the reasons why will indicate if that will become a problem to you or not:

• Sickness, or burnout which could indicate that he or she might have been under a lot of pressure.
• Calling in sick, which can be used to avoid career destroying events and get the blame on someone else.
• The previous manager has a powerful protector, and to avoid being tarnished by failure, a new placement was found. In this case, be very careful.
• Just gave up on the project and negotiated another placement.

The previous manager can also act as a spoiler in the case your performance is better than his/her, to avoid looking bad, he or she might feel the need to frame other managers' opinion of you. So it is good to get an idea of his/her personality to estimate this risk, discretely get some references from other people who worked with him/her.

Find if there were other managers meddling or trying to change the direction of the project to fit their needs. Check what is their influence and their standing in the pecking order. Check if they can be co-opted, or if they can be persuaded to stop and be on the sidelines. Otherwise, you might have to use guile to put them out of action. A warning, using such means will get you enemies that will not hesitate to punish you when the time comes.

Check with stakeholders and try to find what is their current level of commitment and what is their general mood about the project. Check also if there seems to be an indication that they are contacting or already in a working relationship with other companies or teams to do similar work.

Address any issues of inter-departmental conflict of interests. Like in the case that QA is a separate team. Check to what extent the head of QA has an interest in getting a bigger share of the available budget. And, if the QA team apply tactics that maximize the amount testing time or resources. This could be for example, finding critical defects a day before the release on every release. Always check for the incentives that can reward this kind of behaviour and how it can damage the thrust between the development and QA teams.

After identifying the sources of internal and external political risk, devise a strategy to counter these risks, and to mitigate them so that the development team is insulated from theses issues and have the conditions to continue their work in relative peace.

Work to keep an effective control loop on the project status with the development team, track issues early on and don’t fall for the trap of magical thinking. Devise clever methods to get information from the tracking tools available so that you can automate part of your process.

Be on the lookout for motivational issues, if team members are becoming unresponsive or an undeclared conflict is going on between two team members. Or worse, the team has split into factions. Work to resolve these issues as quickly as possible and don’t let them fester. Cause your success will depend on getting them to work as a cohesive team.

In these scenarios, the challenge will be navigating the internal political situation in the office, maintain external stakeholders committed, and resolving any issues with the project team, while having an unfavourable hand at the start. And probably a lot of bumpy roads to cross…

Hopeless Cases

Not all projects are salvageable, and there are times you should consider to forgo such “opportunities” for development. And, you will need to be able to identify when these situations are presented to you. Because some people might have an interest in passing the buck to you or someone else. To avoid being fooled, you will need to read the signs, like:

• No commitment by upper-management and/or external stakeholders in the project.
• No budget, and there are only vague promises of new budget allocations.
• The team is filled with flunkies.
• The company is a hotbed of toxic office politics.

For example, you might be told that you are replacing another project manager on a much hyped project, and that this manager will be promoted to a new position. And after some due diligence on your part (or you already know), you find that the project was nothing more than placeholder for the previous PM, and that this PM had already been fast tracked for a promotion, but needed some sort of “fluff” project to justify said promotion. Now, the project was never meant to produce results, but now it needs to be shutdown without tarnishing the reputation of the previous PM. And in this case, you are the designated fall guy, in this there is no upside for you. Even if you are capable of showing results, upper-management might actively undermine the project to protect the previous PM. Try to find a good excuse to not accept these situations or get a new job.

Avoid getting yourself involved in projects that everyone expects a hail Mary moment to save the day. If it reeks of desperation, run!

If the development team is filled with friends of the previous PM, or some other manager, and have a care free attitude about work. And you can only count with those in the team and can’t hire new ones to replace them. Don’t lose your hair, find another placement. Avoid working with people who you don’t trust their work or their commitment.

In Conclusion

Turning a project around and safely navigating it to success is an art, as you could see I didn’t talk much about technical aspects but more on the human factor. I believe that most projects that fail, usually get into that situation by human intervention. The technical side is as daunting as the time necessary for the learning curve to be mastered, and the amount of resources it requires to completion. Unless, you are trying the impossible given the technical means that exist and the concepts of the time.

Projects usually fail due to failure in scope management, failure in balancing the project team with skilled people, failure in properly managing relationships between the team and stakeholders, not having proper levels of commitment from the higher-ups, and failure to manage office politics.

To be successful, you will need to find your own style for dealing with each one of these issues. A good piece of advice is, find and retain your allies. You will need them, cause no man or woman can do all by themselves.