Five Easy Ways to Fail
A huge number of technology projects go wrong. This is news to no one. Whether you run a software company with a number of ongoing development efforts or you have a nontech company that hires consultants here and there to provide systems integration, chances are you've bumped up against this problem. Delays, blown budgets, and outright failures are so common in the software world, in fact, that it's hardly newsworthy when a project is years late and millions over budget.
In 2003, for example, I flew out to Los Angeles for one of those conferences that Microsoft (NASDAQ:MSFT) occasionally puts on for software developers. At the event, Microsoft made a lot of exciting announcements about some of the revolutionary new features coming out soon in the next version of Windows. Looking back at my notes, I see that one of the important new features was something called WinFS. I'll spare you the boring details, but basically WinFS proposed to combine the file system features of your operating system (storing files and folders on a hard drive) with database features (where you store individual data records for easy search and retrieval) into one big unholy file-and-database mishmash.
This was quite an ambitious undertaking. WinFS was in technical terms approximately the equivalent of rearranging the nation's transportation system to accommodate flying cars. Yes, it would put airlines out of business, and yes, every garage would need to be widened a bit to accommodate cars with wings, but hey, we oughta be able to deliver this in a year or so. Two years, tops.
Three years passed. A manager at Microsoft named Quentin Clark announced on his blog that WinFS simply could not be delivered on time, and that it was holding up the launch of Microsoft's latest operating system. So it was going to be delayed and shipped, maybe, as a feature in a future database--meaning that it was not going to combine the database and the file system, which was the only thing that made it interesting. So how can you tell when one of your technology projects is destined to be another WinFS? Here's my five-step guide to ensure software failure:
Mistake No. 1: Start with a mediocre team of developers.
Designing software is hard, and unfortunately, a lot of the people who call themselves programmers can't really do it. But even though a bad team of developers tends to be the No. 1 cause of software project failures, you'd never know it from reading official postmortems. In all fields, from software to logistics to customer service, people are too nice to talk about their co-workers' lack of competence. You'll never hear anyone say "the team was just not smart enough or talented enough to pull this off." Why hurt their feelings? The simple fact is that if the people on a given project team aren't very good at what they do, they're going to come into work every day and yet--behold!--the software won't get created. And don't worry too much about HR standing in your way of hiring a bunch of duds. In most cases, I assure you they will do nothing to prevent you from hiring untalented people.
Mistake No. 2: Set weekly milestones.
Say you're remodeling your kitchen. That guy you hired to do the work has done a lot of kitchens before, and can estimate the cost of the job without having detailed blueprints. But software developers are building things that they've never built before. If they had, they'd just sell you another copy of the CD-ROM. So rough estimates are impossible. They need to draw up detailed plans before they start writing code. Whether you're the customer or the developers' manager, your job is to make sure they come up with that blueprint. When you ask developers for one, however, many of them will respond by creating a schedule that breaks pieces of the process into weeks. This may seem perfectly reasonable, but it's not. If you let a software team submit a schedule with big chunky estimates of time (by big I mean more than two days of work), you can be almost certain that they're not considering every detail that needs to be implemented, and those details will add up to a huge delay.
Mistake No. 3: Negotiate the deadline.
What's worse than accepting a schedule that breaks down a software project by the week? Demanding that a team commit to completing its work much sooner than forecast. In my experience, most developers are optimists and will take your cue and engage in split-the-difference bargaining. You'll have a nice, agreed-upon schedule that you'll never stick to.
Think of it in these terms: Mama walruses deliver their calves at the end of a 15- to 16-month pregnancy. You might ask the mother to commit to 15 months and she might say, "No problem!" Or you might say, "Fifteen months? Are you crazy? We need this in eight months!" Of course, haggling like this can't possibly make things happen any faster, and even if you get the walrus to agree to an eight-month timetable, I'll let you in on a little secret: It'll never happen. You can have a schedule that says 11 months, but you'll still ship in 15 months, because that is how long it takes to make a baby walrus. Sixteen, sometimes.
Mistake No. 4: Divide tasks equitably.
Here's a great way to torpedo any project. Make a list of all the work people have to do, and then reassign things to different people to balance the project. If Mary has too much work, give some of her tasks to John. This sounds completely sensible, so you won't be challenged.
But I promise you, in the long run it's sure to cause problems. That's because when one developer steps in to replace another, it's reasonable to assume that the new one will work at about one-tenth the speed. John's going to have to spend untold hours figuring out all the things that Mary already knows about her area of code. And John can't fix Mary's bugs as fast as Mary can because Mary knows where all the hidden traps are.
Mistake No. 5: Work till midnight.
Let's say a project should take six months at 40 hours a week to complete. If you told everybody to work 60 hours a week, you could finish the development in four months flat. The software team might even embrace this challenge because it will make them look like heroes ("How great is that Walrus team? They're here every weekend!"). This should work, right? Guess again. There's a whole body of literature establishing that working more hours doesn't produce software any faster. Edward Yourdon, the software entrepreneur and author, dubbed this kind of project the "death march."
Software development takes immense intellectual effort. Even the best programmers can rarely sustain that level of effort for more than a few hours a day. Beyond that, they need to rest their brains a bit, which is why they always seem to be surfing the Internet or playing games when you barge in on them.
Compelling them to spend even more hours sitting in front of a computer won't really translate into more output--or if it does, it will be the wrong kind of output. When their brains are completely fried, software developers are almost certainly going to do more damage than good, writing unusable code and introducing bugs galore. And if you do ban the Internet and multiplayer games to force them to keep writing code past their natural bedtimes, well, they'll probably start quitting on you. Running a death march is not the only way to make a project late and a budget buster. But it is a surefire way to do so.
If these are all the ways you can go wrong, how can you ensure that a project actually goes right? First, you have to hire superstars. At Fog Creek, we tend to review about 400 candidates for every full-time hire, because the best developers can be 10 times as productive as the merely excellent developers.
Second, demand fine-grained time estimates from the developers. Yes, it's difficult for developers to predict how long it will take to build a new application. That's why they need to create a reliable blueprint before every project.
Once you have that schedule in hand, don't try to push up the deadline. If the project can't be completed in what you consider to be a reasonable amount of time, the answer is not to negotiate a better-sounding schedule. The answer is to get more resources, move back your ship date, or remove features.
As a project gets going, you'll at times be tempted to reassign work. But reassign it with care. It takes a long time for new developers to get up to speed on someone else's code. I think it's good to rotate developers through different jobs so that you don't have any irreplaceable individuals, but I do this cautiously and build an extra three weeks into the schedule for the incoming developer who's learning the new code, and an extra week for the outgoing developer who is teaching the code to the new person.
Finally, encourage your staff to work a sane 40 hours per week. Seriously. Except for occasional, very short bursts of activity to meet a deadline, we at Fog Creek work eight-hour days. In the technology world, it's better to view a big project as a marathon, and not a sprint.
Joel Spolsky is the co-founder and CEO of Fog Creek Software in New York City and the host of the popular Joel on Software blog.