If you've ever been responsible for hiring a team of developers for a tech project then you probably know first-hand what Steve McConnell, software project estimation guru, is talking about when he describes how terrible software companies have been at estimating deadlines since, well, forever:

"The inaccuracy of software project estimates has been a problem for many years. In the 1970s, Fred Brooks pointed out that 'more software projects have gone awry for lack of calendar time than all other causes combined'. A decade later, Scott Costello observed that 'deadline pressure is the single greatest enemy of software engineering'. In the 1990s, Capers Jones reported that 'excessive or irrational schedules are probably the single most destructive influence in all of software'."
– Software Estimation: Demystifying the Black Art

One recent study on software development found that on average, most software projects are delivered late taking nearly 1/3 longer than promised, and this has been true since the 1980s!

It can seem like it's downright impossible to land a tech project during your expected timeframe.

Fortunately, there are a lot of things that YOU can do to dramatically increase the chances that your next venture in tech will buck this trend and be ready to go when you need it!

1. Don't Request "ASAP"

A significant number of clients say they want their project completed "as soon as possible," but few ever really think about what it is they actually want.

Most often, saying "as soon as possible" is just asking for the closest date when it is technically possible to have the project finished. This just means arbitrarily choosing a deadline based on everything working perfectly, which is also the statistically-speaking least likely date of completion.

This is arguably the primary cause of so much disappointment with deadlines in the tech world. Instead of an arbitrary deadline, discuss with your provider the important upcoming dates for your organization (such as a soft opening, ribbon cutting, an upcoming conference, etc.) and work backwards to create a schedule. This lets you ensure that you have what you need when you actually need it.

2. Don't Fall for the "Too-Good-To-Be-True" Deadline

The old adage, "if it sounds too good to be true," is absolutely true in estimating deadlines. When you're reviewing proposals, the one that promises delivery the fastest should send up a red flag.

By the time you find out that the crucially-important deadline is going to be missed? Well, you're nearly always in too deep to switch horses. If missing that deadline is so important that you're seeing red and want to fire the development team who promised delivery, then it's rarely possible to do so because you won't find out you're going to blow past your deadline until too late in the game.

While the team may be behind schedule, trying to find a whole new team, get them up to speed, and then make a deal is going to take much longer than letting the original team finish, no matter how angry or frustrated you are. And no matter what the contract says, it's rarely the developers who will be over the barrel when this happens.

3. Developers can't estimate your time for you

Just like it says, no development team can estimate the time on your end to respond to requests, answer calls, or attend mission-critical meetings. The time it takes for you to give your developers what they need is as important to setting an accurate deadline as how quickly the developers can actually write the code. Clients can be nearly as bad as developers when it comes to being overly optimistic about their time.

The solution? Be humble and pragmatic when working out a realistic deadline.

Remember that life happens , and don't forget to build in time for the "known unknowns," such as illness, key stakeholders quitting or leaving unexpectedly, or your boss being unavailable at a conference she failed to mention. Don't forget about the additional delays for holidays, vacations, inclement weather, and flu season, so any project running through December, for example, will need extra padding on even the most conservative deadline!

4. Too Many Cooks

Every warm body involved in any decision exponentially increases the length of the project. Everything else equal, a project with a large corporation can take 2-3 times longer than it would with a solo entrepreneur, if only because of the numbers of stakeholders and decision-makers.

Considering that developers can't estimate how long it will take for 1 person to respond to requests, it's impossible to estimate how long it will take 15 people to pitch in their two cents on every decision, large and small.

So, how do you mitigate this? One small move is to designate one person on your side—ideally YOU—as the sole decision-maker for non-crucial requests, if nothing else. If your development partners have a quick question that doesn't require a full-blown brainstorming session for your team, let them fire off that question to just one person so they can get a quick turnaround and keep moving on the project.

5. The Delays Snowball

Just like rolling up a snowball, the farther you push it the bigger it gets. It is easy to think that postponing a key meeting, for example, one week just delays the project for one week.

The truth? Any delay on your end is going to snowball into a bigger delay in the schedule than just the one week.

When the development team sends a request for feedback or information, they don't sit quietly at their computers waiting for the response. Instead, when there's not an answer by the time you said there would be, they often have to put the project down and move to another. When you finally do respond, they have to shift back to your project, meaning more time and overhead.

There are expensive and cheap ways to melt the delays snowball.

The spendy way is to pay for blocks of time so the developer can sit twiddling their thumbs—on your dime—while waiting for your response. This is great for the developers bottom line, but probably not for yours!

The cost-effective way is to look honestly at your daily, weekly, monthly, or quarterly schedule during the project, be honest with yourself and the development team about how quickly you can respond to their requests, get them necessary information or content, or meet with the team when planned or needed. Being honest about your own time and committing to holding yourself to those expectations will go a long way to keeping delays minimal, and prevent that delay snowball from causing an avalanche at the end of a project.

6. Pay for Milestones, Not Arbitrary Dates

Many software development companies demand the majority, or even all of the payment , sometime before the project is fully complete. As you can probably guess, that final payment clearing the bank tends to result in the development team taking their foot off the gas pedal on your project.

This disincentive can be avoided. If you tie payments to milestones and the final payment to delivery of the final project, this effectively puts your development partners in the same boat with you. Your motivation to finish on-time becomes the development teams motivation!

For more tips on successfully executing technology projects, be sure to sign up for our newsletter using the form below. Have questions? Reach out to us directly at [email protected] or give us a shout at (479) 202-8634.