How long would this project take?

This is one of the questions I get most often and one of the hardest to answer.  The best way to answer this question is to answer in FTEs (Full-time Employees).  It is fairly easy to do because you just find some features that don’t have a lot of overlap and you assign them to different people.  Once the features have been divided to the smallest groups possible, you could the number of people and that is your answer.  You cannot develop this project any faster than this.

“It takes 9 months to make a baby no matter how many women you assign to the task”

Men and months are only inter -changeable when a task can be partitioned among workers with no communication between them”

“Adding more engineers to a project makes a late project later” (because people who should be working are now training new people on the project)

– The Mythical Man Month

Unfortunately for me, most people also want to know how many calendar months a project will take as well.  This is tricky because up to 90% of software costs happen after release.  This comes from bug fixes, absent features, performance improvements, supporting new platforms (android can be a big culprit here), or just re-writing some poorly written code to reduce technical debt.  Even before the project is released, defining how to handle every error case gracefully can’t be known upfront.  To a certain extent you will always be asking, “I have a problem I want you to solve but I can’t tell you what the problem is.  How long will it take to solve it?”

Even though providing estimates is hard, developers ultimately need to figure out a way to come up with one.  While there is no exact answer, I have found 3 ways of approximating how long projects will take:

  1. The best way to figure out how long something would take is by using a comparable project that the coder has already done.  This is pretty possible for simple web pages or apps.  Or anything that requires standard CRUD (future post to explain that).  Note that this is much more possible when the project is small and simple.  It is also common to be able to use this method on version 1.0 but not on future versions because you are distinguishing yourselves from competitors and therefore writing code that has never before been written.
  2. My good friend and past co-worker John Walker (not this John Walker) likes to use this method.  Divide the project up into the smallest tasks possible.  Write down how many hours, days, weeks, or months you think each task will take.  Apply the following conversion: If it takes hours, say it takes a day. If it takes days -> a week.  Weeks -> month.  If it takes a month or more, you have no idea how long it will take or what you need to do.
  3. I came up with my own way of doing estimates which ends up being pretty similar to John’s.  Divide each task into the smallest sub-task possible.  Estimate the worst case for how long it will take  each piece to complete.  Add up all of the estimates and multiply it by 4.  Round up to the nearest prime as a sarcastic way of protesting the futility of this exercise.

For large unique projects developers can rarely know how long it will take.  It’s like asking “how long will it take you to find a cure for cancer?”  However, most management teams refuse to accept that answer and so developers do a little dance where they figure out what you want them to say and then try to add a little padding.  What else can they do?   It is common for corners to get cut because people are trying to meet a deadline that should have never been created.  You need to understand that sometimes estimating is hard and allow for changes to the schedule to happen.  Until your coders can break their tasks into pieces smaller than 1 month, do not plan on any marketing events surrounding your release.

The last thing to consider is that when you are creating new features on top of an existing project (ie. version 2.0, 3.0, 4.0…) you should add an additional 20% for rework (coders call it refactoring) of the existing codebase.  This is to pay off technical debt (read the article in the link) or invest in code that will pay off in spades down the road.  People view Google’s 20% time as a way to create new innovation, but I’ll bet most of it is really just paying down technical debt.

Estimating how long something will take is hard and frequently impossible.  Even if you have been able to do it successfully in the past with small projects, it will get more difficult over time.  It is a good idea to make sure your developer is applying some kind of padding to his numbers.  Many younger coders haven’t always figured this out so you may have to just multiply their estimates by 4.

This entry was posted in Uncategorized. Bookmark the permalink.

3 Responses to How long would this project take?

  1. free_bird39 says:

    Rick, great insight here. This being said, marketing can’t run off of “it’ll get done when all problems have been solved.” What advice do you have for major enterprise software projects that take, say, 6+ months? Do you just double the amount of time and tell that to marketing, figuring you don’t know when but for sure it can be done in a year, if not 6 months? Does that make sense?

    • ricochet2200 says:

      This is a great question and one I don’t think anyone has answered well yet. I’ve notice big companies will give vague timelines like “coming in 2016″ which gives them a full year leeway.

      As you approach your release, you become more sure of when you will be done and can then get more specific. Here is a link to a common graph that illustrates what I’m trying to explain: http://www.construx.com/uploadedImages/Construx/Construx_Content/Resources/Books/Cone02.jpg. If I were to modify this graph I would remove the bottom half. I have never seen a project done in 1/4 the time, but I have seen plenty go 4x (as explained in this post).

      I think a year out you can avoid specific dates, 6+ months out you can usually predict the quarter, and I like to be in testing before I give a launch date. Good testing takes a long time and will give your marketing team time to make the launch they need.

      • free_bird39 says:

        Right, yeah, good points. So marketing starts with year, then quarter, then month type of thing. Blackberry obviously has made this mistake before, as they continually, continually changed release dates…though their problems obviously ran deeper

Leave a Reply to ricochet2200 Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>