StartUp CTO - Estimating the Product Deliverable Timeline and Cost

In my last StartUp CTO post, I talked about the need to build an initial development plan. To start, I suggested a very simplified framework whereby screens and functional components are itemized. In the best of situations, the features are given some type of priority. Sometimes that is done using versions (this feature can wait till version X), Must/Should/Could categorizations, or some numerical prioritization. The startup CTO is then asked to develop a timeline for the prioritized feature set.

A smart CTO will not answer this right away. Even in the best of scenarios where there is really good spec and features are systematically prioritized, developing a timeline is difficult because there are too many unknowns in developing estimates.

To get a good understanding of why this is, let’s looks at the basics of software estimation for a first version of a software product.


Version 0 Estimation

Estimating the development timeline in a startup is somewhat simplified because there aren’t legacy systems, software dependencies, training issues, and other factors that often complicate a development process. A basic first pass software timeline estimate can be derived from the initial development plan. Let’s say your application requires 10 screens and each screen requires 1 day of design effort and 3 days of development effort. Assuming design and development stages don’t overlap, that’s 40 days to develop your product. Seems simple enough right? Well not exactly. Here are some areas where it can get tricky:

• If you’re developing a two or three tiered software architecture that has a separate business logic tier from presentation, then you’ll need to factor in a timeline to develop the database, data access, and business logic components. Most development practices that go this route will utilize one developer for these components and a separate web developer for the user interfaces. They will have to develop more complex timelines that factor in individual efforts and the degree by which developing the front and back end technology can overlap.

• If you have a bigger team, you’ll also need to figure out what components can be developed in parallel and whether larger team are needed for some of the more complex components.

• If your software requires integration with other third party systems, there’s a complexity factor in managing this task…. Learning the third party system, coordinating with outside resources, factoring in additional testing, factoring in additional error handling…

Anyway, you can see that even a simple startup development exercise has its complexities.

The estimation above can be lumped together and labeled as software construction. Now throw in some overhead for building the development environment, prototyping, and throwing in some time at the end for testing and implementing fixes and changes. In addition you will need to factor in some time after testing to setup and install your production environment.

So the overly simplified formula becomes (time to establish dev environment) + (time allocated to prototype) + (software construction) + (testing and changes) + (production environment setup and testing)

But developing an accurate software development timeline requires good starting metrics. How long does it take for your designer to deliver a user interface mockup? How many iterations do designs go through before everyone signs off on it and how long does this take? How long does it take your developer to build the back end of the software (database, data access, business logic) and develop the user interfaces (consumer, internal administration, etc.). Without these and other metrics, even the most simple development timelines can be flawed.

Again, the steps I listed above are very simplified, but are still complex. Startup teams have to look at estimating the development timeline using a different approach. Stay tuned!