Most non-tech people tackling tech projects will vastly underestimate how long it will take to get a workable version completed, and most web developers are less than useless at helping you figure it out. And we are not talking about being off by small numbers. I've seen estimated time lines of 6 months turn into 3 - 4 years. Why? 

Predicting when a tech project will be finished is extremely difficult.

The major reason for this is that a lot of times (if not all the time), you will be to some extent discovering what the product is or should be as you are making it. Since you are shooting at a moving target, it becomes next to impossible to predict when you will hit it.

Here are 3 things that we do that keep our client’s projects on track, keep the feeling of accomplishment alive, and complete products.

1. Put it on paper & remove the mystery

Before you spend tons of money having a web developer build out something that exists in your imagination, get together with them and sketch out what you are wanting to do on paper. It’s a lot less expensive to sketch something than it is to build an entire website and then decide you built the wrong thing.

You won’t realize deficiencies in your idea until you are able to see some version of it visualized in front of you. Having these sketches removes a lot of the ‘moving target’ problem, since you have a good chunk of what needs to be built drawn out in front of you. It won’t completely eliminate the problem, but it certainly adds a lot of clarity.

2. Split it up into concrete action items

Once you sketch out what you are going to build, you need to map out what pieces make the most sense to build in what order. When you do this, think about if any of the pieces would be useful by themselves. Would a subset of the features you want to build be useful? Pick whatever makes the most sense as a first micro-project, and set a short deadline.

Doing this over and over will result in progress and you getting more comfortable predicting how long it will take your web developer or web team to build pieces of your project. That will give you a general sense about how long the overall project is going to take.

They say that a long journey is a series of small steps. A (successful) large project is a series of smaller projects being completed.

3. Set shorter deadlines

In my opinion, trying to estimate a project in terms of months or years is probably a mistake. Even in simple projects, there are just too many unkowns.

Also, estimation implies some kind of specification or roadmap (see #2). If you map out the next 8 months, you limit your ability to make discoveries along the way. If in month 2, you make a discovery that your user's really want a feature you never thought of, you can either a) add it and extend the deadline, or b) miss out on a feature your user's actually want.

The solution is to work exclusively in short cycles. We typically set up cycles of 3 - 6 weeks for a set of features that we are certain about building. If something comes up that we really want to build, we just wait until the end of the current cycle to think about it.

The nice thing about this work flow is that at the end of the cycle, we have a 100% completed set of useful features. If you allow new work to interupt your pipeline, you risk that you have a bunch of work that is 90% finished but can't be shipped.