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.
Summer gave way to fall as the client selected and then began working with a UX consultant. The new design he came up with would require the development team to learn a new Javascript library, but otherwise appeared to be within the parameters of the original ballpark estimate. The client greenlighted development and we scaled up the team to a size reasonable for the budget and calendar time until the trade show. At first, everything seemed fine. However, Feature Creep is called Feature Creep because it creeps! It can be hard to notice that the sum of a number of small, seemingly innocuous, changes can represent a significant amount of development effort. Such was the case with the implementation of the new UX design.
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.
As it happened, the developer assigned the task of learning the new Javascript library took longer to come up to speed than anticipated. Art & Logic relies on our developers to learn new technologies as they work. It’s one of the key objectives of our recruiting process — to find developers who are capable of learning quickly, and excited to do so. This particular developer was newish to Art & Logic. He had worked on a previous large project for the better part of a year and there had been no concerns with his productivity or ability to learn new tools. But for whatever reason, whether it was circumstances in his personal life or he just found the particular Javascript library difficult to learn, it took him longer than anticipated to come up to speed.
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.
