Save a Doomed Web Project in Six Easy Steps

1. Take the time to give an in-person detailed project brief. I’m talking face-to-face meetings here, not just over the phone or via Skype. Extended meetings, too, not just a hit and run. Over the course of 2-3 days, at least. You have to give the new team plenty of time to ask questions, draw conclusions, and challenge you with their new perspectives. You never know when the person receiving the brief will surprise you with an insight from a similar project from not-too-long-ago.

2. Call a time out. Turn off the game clock, if you will. I know that someone somewhere told you six months ago that December 1st was the go-live date, but it’s now November 10 and the project has been wandering in the woods for three months.

What this means, realistically, is that there’s no way that a new team of people can help you reach that December 1st deadline. It doesn’t matter how good they are. You could hire a team of mind-reading cyborg Jedi who don’t need food, sleep, or bathroom breaks, and are willing to work for free 24/7, they’re still not going to make your deadline.

You have to accept that fact if you want this thing done right. You have to pull over to the side of the road, take a stretch, and give the new guys some time to think about where the project stands.

If you’re not willing to turn off the clock, then what you’ll end up with is a frantic series of all-nighters that will just burn out the new team, burn through more money, frustrate the executives–and, oh yeah, I forgot to mention, still result in a missed deadline.

Trust me, I’ve seen this kind of thing happen over and over again. It never works.

3. Put an immediate focus on the end users and their requirements. Why? Because the real requirements live with them. You may have already talked to them at some point, but it’s highly likely (and I say this only because I’ve seen it happen approximately 100% of the time) that what the user really wants has been transmogrified by your own agendas and dynamics. Along the way, they’ve been further codified on special tablets in the temple of worship, objects that have become inviolate and unalterable, yet completely out of whack with reality nonetheless.

It’s nothing to be ashamed of, we all do it, just cop to it and let the team speak to the end users of the application being built. You’ll be happy that someone did.

What will emerge is a way to prioritize all the things that are in the brief. You may want 30 features in the web app, but only 5 are mission critical for the end user, with all the rest being “nice to have” items. Once you understand that, it’s easy to make them happy: focus on the mission critical stuff.

4. Allow the development team to proceed with bottom-up planning. Once the team has been briefed and talks to end users, priorities and development paths emerge. Team members can more easily see how they can respond to the priorities and what pieces should be tackled first, and by whom.

If part of your app integrates with a CRM vendor, for example, then the best CRM guy should draw up the work plan for it. He or she will be the most qualified to say, “This will take 100 hours of effort” or “There’s a plugin for this, should take about 30 minutes to install.”

Your input and feedback on the plan is critical, of course, but the best way to handle this part of the project is to have the developers provide a lot of input up front.

You’ll quickly see that the nexus of brief + end user priorities + team capabilities will bring a lot of obscured items into focus, and focus leads to success.

5. Everyone needs to be up front about technology and platform requirements. For example, I personally only work with open source technologies, so would never take on a Microsoft project. This has nothing to do with my feelings vis-a-vis Microsoft, it’s just an acknowledgment that the Microsoft world is different from mine. Developers can spend an entire career figuring out all the in’s and out’s of Microsoft. Instead, I’ve spent my time and energy figuring out Perl, PHP, and other open source tools, so it’s only fair to say that up front.

Know your platform. Be careful who you bring on board — the last thing you need on a .NET project is a Python team rewriting your project from scratch. Or a bunch of PHP guys trying to rewrite your ASP app. Who needs that kind of pain and hassle?

6. Have a realistic idea of how much this will cost you. Take a look at what you’ve already spent. Now add another 10 to 20 percent to get you started, but be prepared to spend up to 30 percent in case of trouble.

If you’ve spent half a million, be prepared to spend $100K to $150K to complete the project. If you’ve only spent $25,000, then be aware that $2,500 might only get you a two-day visit and some overview advice on getting unstuck.

This last bit of information should get you thinking–if you’re going to follow these patterns and spend this extra money to save the project, then the project better be worth saving, right? I’m not in a position to tell you whether it is worth it. Only your market research can validate your decision here.

Working with Triple Dog Dare Media

So if your project is on the rocks, why would you call us? This is where I ask for the sale. If you’re not interested in the pitch, then stop reading. Otherwise, let’s keep going.

First, my bona fides.

In the last ten years, I’ve worked on about a hundred web apps, give or take. Some of them were teeny-tiny (finished in 2-3 weeks) and some were 9- or 12-month efforts. Most of them could easily be categorized as “3-coders, 3-month efforts”. Some were projects I’ve worked on for my own enjoyment, most were work-for-hires for a client, others were jobs that I’ve taken over when someone else didn’t deliver.

In some cases, I’ve had the distinct displeasure of failing to meet objectives and seeing my project go to some other group.

Whenever failure happens, it’s because I’ve violated one or more of the six patterns. I’ve either acquiesced when a client refused to brief me, “went along to get along” if the end users were not available to talk to, or what have you.

I’ve taken my lumps, see, and now I’m sharing some of that wisdom with you.

So why am I talking about this service offering now?

Because we have a fantastic team of developers who can help you get out of a rut. The core of our A-Team consists of a handful of CodeIgniter developers from the US and UK — we’ve got solid experience creating web apps in a fraction of the time it takes other developers to do things — part of this is the marvelous CodeIgniter framework, and part of it is their raw talent and good communication skills. I’ve worked with them before and they’re solid gold.

Supporting this group of application developers is a larger network of UI experts, accessibility experts, web content developers and strategists, designers, and others who can provide very specific expertise. This is an important point that bears extra emphasis: having a core team of web application developers is good, but having access to adjunct team members who provide additional depth, even if only for a dozen billable hours, can mean the difference between success or failure on some ventures.

My network has a presence in North America and the United Kingdom, with other members on the European continent and Australia. With this wide coverage, we can easily travel to just about any point on the globe to meet with you and get the brief. We work virtually, using collaborative technologies, which means that your project can get started quickly and proceed with a high level of efficiency. We use agile methodologies (daily meetings, prioritized work lists, two-week sprints, and so on) to create shippable code as quickly as we can.

If you’re interested in having a discussion about a project that’s taken a wrong turn and what we can do to help you get back on track, then reach out to say hello: