One of my favorite software-related quotes is the opening line of Anna Karenina:
“Happy families are all alike; every unhappy family is unhappy in its own way.”
It seems that every software project that goes off the rails is the result of its own unique set of circumstances. Certainly there are many common themes, but each train that’s destined to wreck follows its own path to disaster.
Often, projects are endangered by the relationships of the principal characters. If the Client and Developer are unable or unwilling to communicate honestly and collaborate to solve the problems as they arise, it may not be possible to bring a project back on track. But sometimes, bad projects happen to good people – people who like each other, communicate well, and act entirely in a well-meaning way with the best interests of the project at heart. Here’s one example:
We have a client that is an established (i.e. 10-year-old), small company. They don’t have the resources to conduct large projects, but have retained us for quite some time to maintain their software product at a slower, manageable burn-rate. It is a strong relationship, characterized by trust, good communication, and genuine affection.
Over the summer, the client began discussing a large re-design of the software product’s user experience (UX) with our project manager. The client’s goal was to launch the redesigned product in time for a January trade show. Our project manager produced a ballpark estimate for the client’s planning purposes and the client began searching for an external UX consultant to help. It seemed there was plenty of time.
The client built their entire trade show strategy around launching the new UX design and did not have a fallback plan in case the project encountered delays. Normally, you would plan conservatively and allow for the possibility of not meeting the schedule. However, the project had always gone smoothly, so the client was confident moving forward without a safety net. As a result, for their business, failure to launch was literally not an option and the trade show became a true “drop-dead” date.
At this point, you can see the DNA of a troublesome project: a fixed schedule, a limited budget with little headroom for feature creep, an underperforming developer on the project’s critical path, and the potentially devastating consequences of failure. And here’s the thing: at no point did anyone involved act in anything but good faith and with the best of intentions. In hindsight, of course, it’s clear what went wrong, but hindsight is 20-20. Reasonable, albeit suboptimal, decisions were made given the information available at the time. As a result, good people found themselves in a bad situation.
I’ve always felt that what separates the best companies from the pack is how they respond to situations like this. When the DNA of the project became clear to us, we immediately opened a dialog with the client to triage features and defer as much work as possible until after the tradeshow. The client wasn’t thrilled to hear this but, given the currency in the relationship, trusted our judgement and approached the situation collaboratively instead of confrontationally. We also made a conscious choice to do whatever was necessary to avoid failure regardless of what it would cost us. From a financial standpoint, we could have made a case for walking away from the project rather than investing our time beyond the available budget to meet the tradeshow deadline. With some long weeks and a few weekends, we were able to release a stable, redesigned site several days before the trade show. The client was pleased with the results of the trade show and is receiving positive feedback on their new-look product.
As much as the custom software development business is about technology and engineering, it is just as much about relationships. Software projects are challenging in the best of times and approach “impossible” in the worst of times. Often, it’s the willingness of the client and developer to invest in each other and to replace confrontation with collaboration that makes difficult projects successful.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.