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.

The Scourge of Unnecessary Meetings

Tactics for reducing time spent in unnecessary meetings.

As a project manager that used to be a programmer, I can recall how much I loathed sitting in meetings. My train of thought was commonly along these lines; “why am I in this meeting talking about the project when I could be out there coding it?” Because of this, I do my best not to subject programmers to meetings unless it's absolutely necessary. Obviously not all managers come from a technical background, so this empathic understanding may not be present.

Ad-hoc meetings are a growing trend, but its not always convenient for three or more people to stand around discussing the details of multiple projects in an open-plan environment. When it’s realized that an impromptu discussion is probably disrupting other people around you, the common suggestion is “lets take this to the boardroom”. Now you have an ad-hoc meeting which has become the real thing, a meeting which can potentially turn into a lengthy discussion.

This brings us to the topic of written agendas, some swear by them, but are they in keeping with the spirit of Agile? Having someone write up an agenda is added bureaucracy. For short meetings at least, I believe agendas can be substituted with presence of mind and self-discipline. You need to be able to say two things in a meeting without being viewed as negative; “we’re getting off track here” and “we need to move on to the next item”.

Ideally, a project manager should do everything they can to shield programmers from meetings. If operational management is going directly to programmers for project status updates, then the project manager isn’t being allowed to do their job properly. It is not unreasonable to expect a project manager to know exactly how a project is progressing at any given point in time.

How does a project manager keep abreast of project status? Simple, by maintaining a project schedule which programmers go into 1-2 times per week and update their particular sections (e.g. when Jane finishes the validation for the sign-up form, she marks the task as 100% complete). Most other situations can be handled as one-on-one meetings, by email, or via MSN.

The only time all programmers need to be in one room at the same time is when they all have to talk to each other. Senior programmers must bare an additional burden; they are commonly needed in meetings to provide technical expertise.

Development team meetings are an exception; by this I mean meetings with nothing but programmers in them. These meetings are rarely superfluous, programmers will be itching to get back to their computers and continue with their work so they wont waste time on unnecessary matters.

I hear you saying “but if you keep programmers out of meetings, they wont interact with other staff and wont know what’s happening in other departments”. You can’t cajole a team to ‘jell’ by putting it into a contrived environment such as a meeting, which is an inherently formal situation anyway.

You’re more likely to build a sense of internal community by organizing events which are obviously social gatherings (e.g. everyone leaves the office at 4.30pm to go for pizza and bowling). Another way is to provide a pleasantly furnished communal eating area where people can sit and chat during lunch time.

I have seen it suggested that coders answer project status queries by saying something like; “it’s in the bug log”, or “it’s on the wiki”, or “I sent you an email about that”. Even if you assume a manager understood the reasoning behind such a statement, it’s still mildly rude at best and politically insensitive. Perhaps a better version would be “I’m happy to meet with you to discuss it, but it is in the bug log. And to be honest, I would much rather be coding so we can delivered sooner”. Would such a statement work? Who knows, but at least it wouldn’t come across as being negative.

Using MSN as a communication tool is a topic of potentially heated debate. Some companies ban it outright, others embrace it and reap the benefits. I have been at one company where everyone had it on their machines and it worked-out just fine.

Admittedly, sending a message like “can I talk to you when you’re free?” to a person sitting three feet away does feel kind of weird. However, walking over and interrupting them midway through a task is likely to break their train of thought or disturb others sitting near by. There is a degree of ‘knowing what a person likes’ here, if you know a person prefers emails, send them emails, if a person prefers face-to-face discussions, so be it, accommodate them.

At the risk of being facetious, I would say programmers love MSN. This is because it offers a degree of control. An instant message can be left for a few minutes without being answered and doesn’t break concentration the same way verbal interruptions do. I’d say MSN is more suited to specific questions like “will the file upload feature be ready today?” rather then vague queries like “how’s the project going?”

MSN is also great for giving simple instructions like “a friendly reminder Tom, I need you to go into the project schedule today and update your areas” or “the client has logged a few bugs, I’ve assigned them to you, go get them when you’re ready.”

The main danger managers see with allowing programmers to have MSN installed on their computer is that they will talk to their friends; and they will, but sometimes you have to take the good with the bad. Personally, I fritter away maybe 20 minutes per day talking to friends on MSN (e.g. “did you go for a ride on the weekend?”, etc). The problem is when the amount of time spent on MSN becomes inordinate (e.g. 2 hours plus), but this is a matter of self-discipline and only occasionally affects some programmers.

Now we come to one of the most disturbing causes of unnecessary meetings, ones which have been called for the sole purpose of stroking a manager’s ego (nb. this may be on a subconscious level). Tom DeMarco in Peopleware calls these 'status meetings'; not because they are about getting the latest status on a project, but because they are about affirming the bosses 'bossness' status within the organisation. There may be little that can be done about this situation, after all, they are the boss right?

I have seen one company where the managing director would have weekly meetings which went for an hour. During each meeting, he mostly talked at people. Programmers said maybe four or five words in total during the meeting, this was a good indicator they didn’t need to be there.



The bottom line is meetings are here to stay, including the unnecessary ones. This is simply a product of a corporate environment, managers are social beasts who like to talk, programmers are technical beings who like to code.

I have seen programmers suggest other approaches for alleviating the blight of unnecessary meetings. For example; require that an agenda exist before accepting the meeting request, insist off-topic items be discussed at another time, keep a log of time spent in meetings to use as ‘evidence against your boss’ when projects slip, etc. All idealistic and pragmatic, but unfortunately whilst the balance of power remains with the managers, the tilt will remain towards verbal communication.

One Minute Goal Settings

Getting quality work from your team members

Most arguments people have with each other are a result of misalignment of expectations (e.g. Bob: “you said you were going to do this...”, Tony: “I never said that!”. Jane: “You promised this...”, Greg: “I never promised that!”).

- Concept from Brian Tracey's book The Psychology of Achievement

A common problem encountered in the workplace is when a team member thinks their responsibility or task is one thing, but their manager has a completely different idea about what they should be doing.

This is where One Minute Goal Settings come to the rescue (or Goal Settings for short). Simply put, its just a one page document which is split into two parts; the first part describes the task to be undertaken, and the second part details the level of quality that is required.

This strategy was developed by Kenneth Blanchard and Spencer Johnson and is contained in their classic book The One Minute Manager. At its core, the idea is that people working together should know what is expected from beginning to end, there should be no surprises.



What’s that I hear you saying? “just fire off an email or put a Post-it note on their desk telling them what you want them to do.” Well, a goal setting document is different in two very important ways; for starters, its a mutual agreement, and secondly, it specifically sets out the level of quality you have in mind.

These are two very powerful things which should not be underestimated. It’s well known that people are more inclined to do something if you ask them rather then tell them. Giving people a say on how they work is very empowering. Getting a person to happily agree to the parameters of a task has so many benefits its simply beyond the scope of this article to discuss them all, lets just say the chances of success go up dramatically.

The second major aspect of a goal setting document is the level of quality expected. Why is this important? Because people can have vastly different ideas about what constitutes quality. A programmer may not even notice a button is misaligned by a few pixels, but to a usability expert, this could send them right over the edge. There’s an added bonus to openly discussing how well things should be done, over time it can actually lift peoples’ quality of work as they are exposed to a higher ideal.



This is a typical scenario of how a goal setting session with me would go:

Louis: “John, when you’re ready, I’d like to go over your goal setting for system testing”

John: “No problem, I’ll just finish writing this email. Say 10 minutes?”

Louis: “Sounds good”

[we go off to the boardroom - goal settings shouldn’t be done around other team members]

Louis: “OK John, I’ve written up your goal setting for conducting system testing on the Widgets Project. I’ll read through it and you can tell me if it all sounds reasonable, if you’re not happy with anything in it, I’ll go change it”

[read through the document – this takes only a minute or two]

Louis: “How’s that sound, does it all make sense?”

John: “You said you need it done by this Thursday, but I’ve got a dentist’s appointment in the morning. Can we make it Friday instead?”

Louis: “Done, I’ll update it and re-print it”

[I adjust the document, re-print it, and come back – this rarely happens by the way]

Louis: “OK, updated, Friday it is now. So you are happy with everything I’m getting you to do, ‘cause you are making a commitment to me on this task”

John: “Yep, all sounds fine to me”

Louis: “Cool, we’re all done. Oh, keep in mind John, before you come to me to say you’ve finished, just be sure to re-read the document at least once to make sure you really are finished, OK?”

John: “Yeah, make’s sense”

[Friday passes and John reports the work has been completed. I review it, its great]

Louis: “Hey John, can I give you some feedback? When you do testing with such detail, it really impresses the hell out of me. You logged 32 bugs, that's 32 bugs the client won't see. Thank you, great work.”

And that’s it, it really is that simple. Assuming you are working with competent and passionate individuals, things will rarely go wrong. If you want to know what the course of action is should things go wrong, I recommend getting the book as it covers the topic in the required detail. When things go right, just be sure to let the person know you are happy with their work.

Do goal setting documents always work? The simple answer is no, there are rare occasions when it’s actually counter-productive to enforce a goal setting agreement. Let me relay an instance when just such a situation occurred.

I was working with a number of programmers at a small web development company where resources where quite tight. I had been using goal settings with success amongst the junior programmers, but a time came when I negotiated a goal setting with the senior programmer to have him produce a coding style guide. Even though I could of produced the guide myself, it was too far outside of my dominion. The style guide was more likely to be accepted and adhered to if it was championed by ‘one of their own’ (i.e. written by a programmer for other programmers).



At the time, the senior developer was under a lot of pressure to deliver on a number of client projects. The agreed date was missed and no style guide materialised. Even though there was a pretext to say “hey, didn’t you say you were going to produce the style guide by the 18th?” in this situation, the value of doing such a thing would have been counter-productive.

I could obviously see that he had been working exceptionally hard to keep other commitments he had made. Also the fact that he was in a senior position in some ways gave him mandate to drop tasks as he saw fit, he is after all a professional with many years of experience, he knows what he is doing.

Management Styles in Web Development

How operations management affects project management in a web development environment

“Fostering an atmosphere that doesn't allow for error simply makes people defensive. They don't try things that may turn out badly."
- Tom Demarco, Peopleware

One of the best teachers I know once let a martial arts student punch a wooden board when he knew it wasn’t going to break (due to incorrect technique). After the student’s failed attempt, he said to the group “I could tell it wasn’t going to break, but who am I to stand in the way of your dreams and goals?”

It’s happened a number of times now that I have arrived at a company and heard statements like “run projects how you think best. After all, we hired you for your expertise and experience.” These bold proclamations inevitably give way to operational management’s desire to change things for the better good (i.e. over-ride some of my decisions).

Perhaps this happens because project management looks like a logical pre-defined process, much like operational management. However, the whole point of a project is to create something novel and never before seen, thus introducing a large element of the unknown to the undertaking. This is one of the reasons why risk analysis is such a major part of formalized project management methodologies.

Passion or concern can often lead operational management to actions which actually stifle a project. Much like a mother, at some point they have to ‘cut the apron strings’ and allow their child to make some mistakes for themselves.

It’s like watching a child banging their toy against a wall, do you say “that’s going to break if you keep doing that” or do you take the toy and save it from certain annihilation, potentially robbing them of a valuable lesson on taking care of their property? On the other hand, some lessons can’t be learnt the hard way, for example; crossing the road without looking both ways.

The question then becomes, do you stand by and watch someone make a mistake? I would hazard that this would often be the motivation of upper management, that to them it looks like you are about to make a mistake which could cost the company money or damage client relations, so isn’t it logical to intervene before its too late?

I’m fairly sure no managing director wakes up in the morning and thinks to themselves “hmm, how can I make my project manager’s life difficult today?” I should say that I don’t intend for this article to be a denigration of past employers. Operations managers generally don’t acquire their position without being highly intelligent and capable. But I have seen the phenomena Joel Spolsky calls Command and Conquer Management. This is where the person least qualified to make a decision is doing just that.

From the companies I have worked at so far, I have seen three distinct approaches when it comes to operational management dabbling in project management. One type would commonly interject if they felt they had a better way to do things (with changes I could not veto), another would occasionally come to the rescue if things weren’t going as planned (again, with me having no veto power), and probably the most interesting one has been a boss who only occasionally intervened, but still allowed me to have final say.



Personally, I wouldn’t want to work in an environment where people didn’t say something if they felt you were about to make a serious error with your work. But that is obviously part of what team is about. People need to be able to ask questions and give suggestions. But they should also be given the option to reject a suggestion without ego coming into it.

project management isn’t an easy discipline, hence why not everyone does it. As mentioned earlier, the reason for this is because a significant portion of a project is unique. Getting good at tackling the unique aspect of projects only comes with experience, and experience comes in two flavors: success and failure. Unfortunately, it’s hard for some people to accept the unpredictable nature of software development because mistakes can be expensive.

Another interesting ingredient being added to this dynamic is the increasing uptake of industry standard project methodologies such as Britain’s PRINCE2. Although this is definitely a good direction for the software industry, it does pose a potential hurdle.

PRINCE2 is squarely aimed at project managers, there’s no doubt about it. The problem lies in the fact that non-project managers within the team also need to understand the methodology for it to work well. I believe it’s possible for a project manager to teach the basics of PRINCE2 to subordinates such as team managers, programmers, designers, etc. (just enough for them to get by). But would this work upwards, with corporate management?