You signed the contract with the vendor in July. The kickoff meeting was in August. The project was slated to be running through development phases through the fall, with a final launch in early November. T’s were crossed, i’s were dotted, and the calendar was shiny and organized.
So why is it now nearly March with no sign of the project end in sight?
I’ve been building web sites for businesses and non-profits since the late 1990’s, and at least once every year, I look across the table at a client and know right away that the project for which they’re hiring me is going to take at least a third longer than a normal project of the same size. There are warning signs I’ve learned to identify, and if time-to-launch is important to you, you’d do well to learn how to recognize them in yourself.
You’re Not Really Sure What You Want
It’s the job of your developer to put together a well-researched proposal that details what she’s going to deliver to you by the end of the project. A good developer will take the time to walk you through the decision-making process, but in the end, you do have to make a plan that gives that developer the ability to work through the project efficiently.
Think of it as functioning much like your order at a restaurant; an order of an appetizer, two cocktails, two entrees, and one dessert gives both you and the kitchen clear direction on what to make and expect and in what order. If, midway through your entree, you decide you liked that appetizer so much that you’d rather have another one than your dinner; or if you change your cocktail order after the bartender has already mixed it, it would be fully within the restaurant’s right to charge you for everything they assembled, not just for what you decided at the end. You can argue, but that’s uncomfortable for everyone involved — and the food and drink are already made. Even if you’re willing to pay, it’s going to take longer to get that changed order.
Diagnosis: This project is going to finish late.
You Only Want to Use Free Tools
I am highly supportive of open-source software. A very smart colleague of mine once referred to open source software as “free kittens, not free beer.” The analogy is great; free beer is a momentary treat and comes with it only the responsibility for holding your mug, while free kittens may not have cost you anything at the outset but require constant care and feeding at a price certainly higher than “free.” Open-source software is a gently mewing kitten, often requiring additional expense. I still support it, but try to caution my clients that the extensions, themes/templates, and widgets that make the open-source software ecosystem so rich always cost something, even if installing them is free.
The running joke about apps is always that if you aren’t paying for a product, YOU are the product, and that is often true for free add-ons for systems like WordPress or Joomla. There are some very helpful and kind extension and theme developers who will offer product support for their free products, but many do not. That free software we chose, augmented by a free design theme and a free contact form widget and a free social media sharing tool? It’s could very well take me hours more to troubleshoot problems that come up along the way because there is no one supporting any of these products on the software developer end.
Diagnosis: this project is going to finish late.
This Is the Least Important Thing You’re Doing This Year
Picture this: a new client comes to me and says, “I’m opening a new community center this year. We break ground next week. I’m hiring about forty staff members between now and next month, and I have a graphic designer working on logos & signage. The attorney is dealing with our contracts. Just get me a basic site before we open.”
There is no way that site is getting done before he opens. In between everything else he’s doing, he will occasionally glance down at his phone and read an email from me with a question. He’ll seldom have the time required to dedicate to answering it, and by the time the importance of making decisions about his site has risen to the top of his list, he’ll have developed preferences he didn’t have time to articulate when I first asked. There will be a “follow up” meeting wherein we’ll decide to backtrack and start several things over, and the launch date for the site will need to pushed out several more weeks.
Diagnosis: this project is going to finish late.
Aside from all these issues being delay-factors on their own, many web developers set aside time for each client project such that their next project begins when the first one is scheduled to end. A delayed end on one project simply cannot supercede the contracted start date for the next project, so there can sometimes be delays that spawn more delays, leading the client to believe that the never-ending project is all the fault of the developer, who “ran out of time for us” or “gave up on our site.” That does happen — appalling but true — but more often, the project has simply dragged on longer than the developer can keep his next client waiting.
The moral of the story is that businesses and non-profits need to either nip these problems in the bud or accept that their nice-to-have deadlines are pipe dreams, and adjust expectations accordingly. Otherwise, the never-ending project will frustrate you and your developer.