Rescuing a Hopelessly Derailed Project

Perspectives on the maladies that befall an overdue project.

A sobering reality of the software development industry is that projects sometimes run late; most of the time it’s not the end of the world, although this view is not held by all (the word ‘late’ seems to be a very dirty word in the business world).

In the grand scheme of things, a project arriving one week late generally has no significant impact. Of course there are exceptions, for instance; a project may need to be delivered to coincide with a client’s attendance at a tradeshow. The kind of late project I want to deconstruct in this article is the hopelessly derailed type, generally running months behind schedule, with an irate customer banging down at door.

The causes of a hopelessly derailed project are many and varied, but the particular focus of this article is the inherited late project; this is where a newly appointed manager must pick up the pieces of a disastrously run project. Thrust into the midst of customers screaming for blood and management demanding results.

If you are a project manager finding yourself in such a situation, first and foremost you must be resolved that you may fail despite your best efforts. As the saying goes; “fortune favors the bold”, so if you can’t accept the risk, then you should not accept the challenge. This also extends to the possibility of being made a scapegoat. I don’t believe there is a level of intrigue functioning in an office where upper management ‘sets people up’ for a fall, it’s just businesses don’t like losing money. In a corporate environment, taking on greater responsibility often comes with increased salary, but if things don’t work out, your head is for the block.

In order to steer a lost project back to safe waters, a view for the long haul needs to be adopted. This seems logical since no one would be worried if only a small amount of work was required to fix a troubled project. On one occasion I worked at a client’s office for 8 months straight in order to launch their ERP application. I also have heard of instances where developers toiled for almost a year to save a late project.

Assuming you're OK with the risk of things still going pear-shaped in spite of whatever efforts are brought to bare on a late project, the following course of action is what I would prescribe (note: not all these strategies are appropriate to all projects);

Use a bug tracking system - installing and using a bug tracking system is going to be an excellent start. It will allow you to regain a semblance of control and take stock of the situation. It’s unrealistic to think a complex system can be understood immediately as a whole, so 'chunking' it often helps. A bug tracking system allows you to compartmentalize problems. Once an inventory is taken of all existing issues, distribution of tasks amongst technical team members becomes a breeze.

Realize the political obstacles are greater then the technical - on a late project there are both technical and political challenges to be overcome. The technical issues generally aren’t as bad as they may first appear, especially if a senior programmer is on hand or the project manager has a technical background. The political difficulties are trickier because they are less obvious then an error on a particular screen. It’s like being at the helm of a ship that’s gone off-course, lost in the middle of the Bermuda triangle. The biggest challenge is often re-establishing client confidence in the project (e.g. client: "these cow-boys don’t know what they are doing!", "they promised me this and didn’t deliver", "I have no confidence in these guys any more.").

Stem the tide of negative sentiment - apologizing to the customer for the poorly managed project is a good start, a bitter pill to swallow but necessary for re-establishing trust. Stating to the customer in concrete terms what is being done to correct the problems on the project is also helpful. For example, something along these lines: "I’m sorry about the delay on your project, I’m working to get it back on track now. I’ve looked at the project history, and personally, I would be angry too if I was paying good money for this system. The first thing I’m going to fix is...". Making such a statement means there’s no turning back as responsibility has been taken for the project; its all or nothing now.

Feature freeze - a common and sensible strategy is to stop adding new features. In reality, this may be easier said then done. It’s possible that agreeing to some new features requested by a client can help re-establish report, a demonstration of your willingness to listen. From a technical stand-point, adding features to an already late project doesn’t make sense, but from a political perspective, it may be a step in the right direction.

Understand the business domain - reading through any requirements documents on hand is going to be vital. Arriving late on a project is a massive disadvantage because it’s hard to know what was originally discussed. As the saying goes; ‘the devil is in the detail’. This is exactly what sunk me on a late project I was meant to salvage. Everyone was on edge, and I missed a minor requirement. At the time, it wasn’t a big deal and could of been corrected easily, but politically speaking, it was the straw that broke the camels back. One strategy which may help is to work from the client’s office for a few weeks, at least until some semblance of stability returns to the project.

Consider adding some new features - a late project isn’t exempt from this old business maxim ‘time is money’. The client has paid for something which isn’t right or has not been delivered on time. Your company has expended resources working on the project, possibly having used up all the available budget. Continuing work on the project could mean your company is losing money. This is where allowing the late addition of new features can make sense. People will say not to add features to an overdue application, that stabilizing the project is the number one priority, but adding new features can be a politically prudent maneuver. Senior management will likely be pleased that new money is coming in for billable off-spec work, but programmers probably wont share this enthusiasm.



Overtime wont fix everything - I’d recommend against project managers or coders working ridiculously long hours, but an additional couple of hours each day can make a positive impact on a late project. If people normally leave the office at 5pm, departing at 6.30pm-7pm instead is reasonable. People can consistently maintain an hour or two of extra work per day for many weeks without sacrificing the quality of their work or their sanity. Working until 9pm or 10pm every night and on weekends will result in burn-out within a few weeks. After that point, extra time on a project is doing more harm then good. In the unlikely event that senior management takes issue with this point, a decision needs to be made; do as they ask (i.e. work more hours), or say something along these lines; "I’ve already committed a few extra hours each day to work on this project. I’m here for the long haul and I’m going to get this project done. But I’ve reached the limit of how much extra time I’m willing to put in. There are other commitments outside of work I need to keep too." Unfortunately, taking such a stand in some organisations can have negative consequences. By no means am I against working hard for a worthy goal, I am merely saying the effort needs to be weighed up against what you are going to be sacrificing (e.g. health, family, etc).

Get movement on the project - I have come across suggestions that when first arriving on a late project, the best thing to do is “stop and write a spec” or “stop and do this or that...”, I believe this is unrealistic. The project is already stagnating, the last thing senior management or the client want to see is a complete halt, they want to see progress! I have been in a situation where I’ve told a client “we need to stop coding for a week or two so I can write a proper test plan. Otherwise the bugs will just keep coming.” It’s not that the client didn’t understand the importance of this, it was more an issue of cost; who was going to pay for this time? The client wasn’t willing to pay for the lull in development, nor was the company developing the software. Needless to say, the bugs did ‘keep coming’. It’s important to get some small wins happening so things can get moving in the right direction again. This could come in many forms; for instance, clearing all currently logged bugs, stabilizing one particular module within the system, etc.

Map-out tasks ahead of time - a project manager needs to work-out what programmers are doing ahead of time, having programmers waiting on a project manager to give them work is tremendously inefficient. For a technically-oriented project manager or senior programmer, this will generally mean they get to do less coding or technical work. The best way to map-out tasks is by maintaining an up-to-date schedule which lists pending tasks and who’s responsible for them. Programmers should always know what they’re working on after they finish their current task. There should rarely be a time when they ask "what do I work on next?", they should already know.

Build-in recovery tools - sometimes to achieve a goal or solve a problem, an indirect route is required. For example; it may take 12 hours to track down and fix a particularly troublesome bug. Instead of doing this, it may take only 2 hours to code in a corrective utility which solves the problem for the time-being (yes, this is sort of a ‘hack’). Time and momentum are of the essence on a late project, and unfortunately bandaid fixes sometimes make the most business sense, especially when software has recurring problems which are hard to pin-down.

Be observant of the client’s mood - it’s important to demonstrate you are on the client's side. For example, the client may say "this product is unacceptable", you could respond with "I agree, I wouldn’t be impressed If I were in your position either. All I can tell you is I’m focusing on it now and wont rest until you’re happy". When report is re-established with a client, they may even help shield you from pressure emanating from other stake-holders on the project.

Lead by example - programmers have no reason to become emotionally invested in helping to correct a hopelessly late project, and why should they, it’s management that got them into this mess after all. But programmers may care if it becomes about comradery or delivery of a product they can be proud of. For instance; a project manager may tell the programmers "I’m staying back a few extra hours to work on the project. I’d appreciate your help if you’re willing to give up your time." Or "I know its not our mess, but we're going to clean it up anyway. I want to get our customer the best good quality software we can". Emotive rhetoric is useless if it's not from the heart, people can spot a phony a mile away and wont appreciate being manipulated.

Many suggestions made by other project managers on how to fix an ailing project assume a fairly high degree of power to affect change (e.g. “say no to new features” or “stop the project to restart it properly”). In reality, chances are the project manager is joining the late project already hamstrung. If it’s a senior programmer that’s been tasked with correcting a failing project, they will traditionally have much less power to affect change then a true manager. This doesn’t mean “give up, don’t try”, it just means a lot more creativity and soft skills will be required (i.e. people skills).

I’ve also come across people who say its better to bail on the project and ‘run for the hills’. I have had experiences where it was possible to fix a hopelessly derailed project, and some which could not be salvaged to everyone’s satisfaction. It’s really a personal choice whether to take up the challenge or not.