I'm working at a startup software company -- 3 developers, less than 15 employees including the CEO. We deal exclusively with Windows Mobile, the .NET CF, and passing the information gathered from our handheld application to and from our website. My director and I just had a meeting over an urgent project that hasn't begun yet, but it should probably get on a roll soon if we are to meet delivery deadlines for a prospective but very powerful and influential client.

He proceeded to explain the project to me as follows:

  • The new project will consist primarily of a .NET CF app that allows the client to conduct multiple soil samples over the course of a single session.
  • The area being sampled by the user should be shown on a map of appropriate size and scale.
  • The map should be dynamically split into grid squares of a size set by the user (in acres).
  • On each grid square, the user will have the ability to take notes and mark individual points via real-time GPS from the on-board receiver.
  • In addition, functionality should exist to help point the user to any grid square given their current position.
  • All information collected should be easily retrieved and read in a very user-friendly manner on the customer's handheld device -- a device which we provide -- at any time.
  • All information collected should be easily sent -- through ActiveSync, wirelessly, or what-have-you -- to our website where it should be viewable/editable in an interface similar to that of the handheld device.

With that description in mind I thought things over (albeit rather quickly). With our current staff size, limited budget, and limited resources, I projected that such an endeavor would take roughly 9 to 18 months. Forgive me if I'm off in left field, I'm a recent CS grad and pretty new to the "real" world. However, the project is currently only realized in my director's head, with no design documentation or specs. My question here is, how far off am I, really? Once again, my director -- who has no background in software or IT whatsoever, but is a subject matter expert insofar as soil sampling goes -- put the project at about a 3-month duration.

Keep in mind that we're currently using an unsupported SDK for the rest of our GPS and GIS needs, and ESRI products are almost too far out of range for us. Current functionality in our other apps goes give us a leg up, with the ability already in place for us to draw areas, polylines, and plot points on a map.

I'm just kind of confused/afraid here, wondering if I'm completely wrong or if I'm right but just without confidence. Any and all advice is appreciated. Thanks!

  • 9
    Your boss needs to look up Hofstadler's Law. Sep 25, 2009 at 18:30
  • 22
    Didn't you take software engineering? :) Do a complete requirements analysis first, then make your estimate, and then triple it.
    – mpen
    Sep 25, 2009 at 18:34
  • 13
    Management often treats "off-the-top-of-my-head" estimates as though they were carved in marble and delivered on a satin pillow. Sep 25, 2009 at 19:15
  • 6
    Based on my experience developing for an agri-based business, this has little to do with software development estimates. Soil testing in the South starts in Feb (if I remember correctly) and he wants to sell them now otherwise he has to wait until June/July when he can hit the North or Nov/Dec to hit the South again... Sep 25, 2009 at 20:06
  • 17
    Off topic: You have a start up software company with 15 employees of which only 3 are programmers? There's your first problem... Sep 30, 2009 at 11:11

14 Answers 14


You may want to approach this backwards:

  • Find out the realistic deadline (e.g., is it OK to deliver this in 5-6 months?). All the #s in this example are somewhat relative to this #.

  • Set milestones for tasks that need to be achieved based on that deadline. E.g. 1 month for req gathering and building up skills/experience on SDKs/hardware/etc.... 2 months for active development. 2 months for testing. 1 month for unforeseen crap resulting from complexity of all this.

    This is a good granularity for first pass, but then you need tor efined with sub-tasks to something with 2-3 days granularity as far as the plan, and preferably time-meshed, e.g. you should have some initial coding tasks allocated to first month.

  • Then, cull the requirements or feature set if you see that you are missing the milestones. Please note that you need this "coding tasks at the beginning" I listed before, as it will allow you to determine the correctness of your pace and estimates for coding well before 3 months pass.

Basically, I'm running this (somewhat contrary to usual project management approach) from the "MUST DELIVER BY" standpoint that you seem to have stressed in your post. E.g. Not delivering by hard deadline is NOT an option.

  • The only difficulty is that the boss will have must haves on his list, so it is important to show the boss why his timeline is unrealistic without more or different resources. Sep 25, 2009 at 23:45
  • That's where active tracking vs. detailed project plan comes in... he can show the boss very quick if schedule slips. however, proving projected timelines to anyone who has not had similar development experience is well-neigh impossible task as far as I observed
    – DVK
    Sep 26, 2009 at 0:33
  • 3
    It's not really contrary to what's normal for project management. X is how long we have to do the project. Y is how long the feature set will take. Now tell me which features you want to cut (or resources you want to add) to get Y < X.
    – BIBD
    Sep 28, 2009 at 14:48
  • It's one of the methods I use and one that was taught at my Project Management class, yet one I VERY rarely see employed
    – DVK
    Sep 29, 2009 at 4:22
  • There's also the closely related agile thing - maybe you will get the whole feature set in time - stranger things have happened - but right now you're goal is feature A, and tomorrow your goal will be feature B, and for each feature you develop you'll have a deliverable (if limited) product. You still need to prioritize, of course.
    – user8709
    Jul 24, 2011 at 22:05

You are right to feel confused and afraid. Before you start, remember that there is always the option of finding another job. With that said:

Your boss' eagerness for an early delivery date is merely a reflection of the business' need. If he can't promise the customer the product early next year, then he knows that you won't win the contract, or make the sale, or whatever. The reality of that situation concerns you too - if your employer doesn't win new business then it won't be long before you need to find a new job anyway. So, the first lesson is that your boss is expressing a real need, and that is your need as well as his.

All projects in this situation go something like this: The winning supplier is the one who accepts the craziest timescales and offers the lowest staffing estimates. Three months later, when the customer is expecting their shiny new software to be delivered in a shrink-wrapped box, the vendor if they are lucky will be able to say,

"well, we've run into some problems so it's not ready, but here's something that does 50% of what you asked for. Sorry about the bugs and quirks - we're working on them, and we'll have it all sorted in another couple of months!"

If that 50% functionality is enough to let the customer limp through the next 3 months, maybe training their staff on the partial solution, then they'll probably hold off on suing for a bit. If you can then give them a version that fixes up the core 50% and adds another 30% of new functionality, then they're 80% of the way to getting what they want. Yes, you're already three months late, but if they switch to another vendor it'll be at least 6 months before they get anything. Surely you'll be able to polish off the last 20% of the project in another 3 months?...

...and so on.

This is what will really happen!!

If your manager doesn't admit that then either he's a fool, or (more likely) he's in regular contact with the customer and needs to maintain the feeling of unrealistic optimism needed to convince them to sign the contract.

You can't afford to be optimistic. Plan for the project to be delivered in stages. Start identifying right now which 50% of the functionality is crucial for the customer in those first 3 months. Start pencilling out the 10% of the functionality that will never be delivered. Try to get the customer involved in this process as much as possible - this will help you to manage their expectations, so they aren't totally shocked when reality doesn't quite match up to their hopes and dreams.

And good luck!

  • 4
    Great answer! Have we worked for the same companies? It's all about over-promising and under-delivering isn't it?
    – Ash
    Oct 31, 2009 at 2:40

Even though it is obsolete now, I like using Excel for estimates, as explained here.


You take each major task, break it down until you can give an estimate, then estimate it. By doing this, it forces you to design the application, and the powers-that-be can see what is involved, as there may be many parts that they didn't realize were involved.

You can then track how long it actually took and see why your original estimate is off.

So for the first point, how will the soil samples be collected? Will they be stored in a database or xml file or what? You can then design out how the UI works, and then give an estimate. If they want multi-lingual support have that as a separate subtask and tack on a few more hours.

The initial stab may need to be reworked a couple of times, but you should be able to do this in about 1 or 2 days, and get a rough idea as to how long it will take, and then you can show them the data.

Now, if there is some tasks that will take too long because of an unsupported SDK or lack of training, then they can decide to perhaps get a better SDK or hire a contractor, when that part is needed, to develop the part that the developers can't do.

But, this way it gives them a way to determine their budget and timelines.

  • It's not obsolete. Joel's just found a better tool. The better way doesn't exist if he didn't first use the method you list. Sep 25, 2009 at 18:49
  • 3
    Someone should propose a new SO badge for using Joel's name (not in vain) N times :)
    – DVK
    Sep 25, 2009 at 19:01
  • Best way to get upvotes, IMO.
    – Kyle
    Jun 8, 2012 at 14:18

Break down the project into as many detailed tasks as you can.

Then estimate each task separately. Sum them up and give a time budget (usually in man.month units = the amount of work that 1 man can accomplish in one month). In your estimate, include documentation, integration and testing. Also allow for a buffer to cover holidays, support on other project, etc.

Finally, divide the total estimate by the number of resources and you'll end up with a decent ETA (estimated time of arrival).

You can compare your result with your co-workers and average/re-assess if needed.

  • 1
    This is great advice except for the units. Break it down into tasks where nothing takes longer than 3 days. Then you will have a very good idea of the time needed. Sep 25, 2009 at 18:42
  • Yes jmuchiello, this is what I meant. The man.month estimate is for the sum of all tasks. I guess I wan't clear enough and will rephrase my answer.
    – Damien
    Sep 25, 2009 at 18:55
  • 1
    +1 for reducing the granularity. Estimating is HARD, and even more so as the size of the task increases. You may find that after breaking it down, you'll change your mind about how much effort is required. And if your director still thinks your estimate is too high, you can point to your work breakdown structure and have a better change of convincing him that those steps are necessary, and that you've estimated them properly.
    – Jim Lewis
    Sep 25, 2009 at 19:00

There's probably a mis-communication.

Maybe he misunderstands what his requirements are. Maybe you misunderstand what his requirements are. Don't argue over positions: instead of proving yourself right, try to understand him better.

Agile exists to help with problems like this.


The situation described is very common especially on software development definition and planning stage and it is incredibly important to learn how to handle it. When making new things, frequently it’s not only the solution that is fuzzy, but the problem statement itself lacks clarity and requires re-definition.

Essentially the scenario implies at least one of the three things:

  1. Your boss doesn’t know what he is talking about nor has realistic expectations.

  2. You don’t know what you’re taking about or not smart enough or just plain lazy.

  3. You and your boss have wildly different idea of what the problem is or what the solution is going to be or probably both.

It’s not difficult to see how the first two implications are really offensive. It’s very easy to naturally digress into situation when you might take the position implying that your boss is a loony incompetent dreamer and simultaneously for your boss to adopt the view involving you being both slothful and incompetent techie who’s unaware of business realities.

Hence the only sane way out that will help you maintain good relationship and make some progress on the work that keeps the company going seems to be the third option. Normally one of you would say: “Right, such a big discrepancy in the figures can mean only one thing: we understand the problem or the solution rather differently, lets talk through the problem and the solution again, now in much greater detail, until we see where these differences are and manage to get to a common understanding”.

Eventually it might turn out that both the understanding of the problem and the proposed solution were incorrect. It might turn out that you need to work to a target, meet a deadline to cash the sale; maybe with a simple solution which is just 60% there and then further expand it to 80% in version two, instead of honouring the initial 100% scope and including less valuable but dev time hungry features that can be easily sacrificed.

In a small start-up no one can be defensive; it’s hard enough to bring the new work in and everyone needs to be very resourceful about solving problems given the circumstances. Thus you and the boss need to equally persist in trying to re-formulate the problem and looking for a realistic solution until you agree on a single sensible way to go about the project.


What your boss has is an idea. What he needs is a complete analysis of the project. What are the problems that are going to be solved, what is the feature set for the application. You (and the other developers) really need to sit down with him and discuss, at great length, just what he has in mind. A good rule of thumb is that for every hour of keyboard time, it should have been preceded by at least 10 hours of discussion. Managers are like that - they do a quick two minute explanation of their idea, then want an exact estimate right then - like that's even possible (NOT!).

As the second comment to your original post suggests, you need to perform a complete systems analysis of the project from start to finish. Make it as detailed as the boss will let you - and push for a deep level of detail - then start arranging the pieces and assigning estimates to them. Add a "Scotty Factor" of at least 1.5 to the total and you will have a rough idea of how long it will take under ideal circumstances.

There will always be things you will not foresee even if feature creep and requirements changes don't add their burden of extended time.

The key here is detail - the boss needs to understand that while he has the big picture in mind, it's the details that make the project. And if the details aren't laid out in plain sight for all to see, pick at, rearrange, modify, etc. then there will be no project to deliver. You will have to do battle with the boss - managers absolutely hate details - they like to wave their hands, say "take care of it" and expect miracles to happen. It's called the "Hero" syndrome - some poor fool steps in, does 16 hours days for months on end and delivers a bastardized version of the project that barely functions and the boss says "see, it can be done".

Count on it - and feel free to show this to the boss - I've been doing software design for over 31 years now and I have yet to come across a project that doesn't operate under the above guidelines - at least one that succeeded!


If your estimate is 9 to 18 months, it will end up being closer to 24 to 36 months. It's the nature of development in every business environment I've worked in. There will be inevitable spec changes and scope creep along the way. Needed information and resources will be delayed. The unforeseen will be seen. Maybe I'm just jaded by every single project I have worked on thus far in my career. =)

From the description of the project, I don't believe 3 developers could complete all that in three months under the most ideal of circumstances, much less in the "real world". Especially when you add that while you're developing, part of your time will get pulled into other things: meetings, support of existing production apps, customer support, ad hoc reporting, etc, etc....


It always helps to have something tangible (that they can look at) to present to management. I recommend a spreadsheet (or an MS Project export) with every task you can think of that will go into this project broken out into chunks that, when totaled up, yield an acceptable estimate.

They should be able to look at your document and see that, hey(!), it's going to take a month to develop a prototype of this component, 3 months to test, and so on.

Also helpful is to provide best, expected, and worst case estimates.


It's unlikely any of us here has enough information to make a more accurate guess than you. That said, I don't think you're in left field. It may be that your team could do a lousy job in three months, assuming everything goes perfectly. It may be that even in the best of all possible worlds, you still couldn't get it done in three months.

Ask your director what his/her rationale is for the estimate. You may discover something you weren't considering, or you may be able to add things he/she wasn't considering.

Tell him that you're sticking by your estimate, but try explaining it this way. There's a large amount of uncertainty right now, and your estimate is 12 months -25% or +50%. As things become clearer, the estimate may change and the margin of error will shrink. If it's politically helpful, you can expand the margin and tell your boss it's 12 months -75% or +150%. Then the 3 months is in there, but so is 2.5 years.

If you get overruled, do your best anyway, and it will be a learning experience (hopefully not too painful) one way or the other.


I would eyeball that at a year.

Location-aware applications are cutting-edge development. All the risks of standing on that edge apply here.

You're looking at at least two distinct applications, probably three, and some background jobs cleaning up data and doing additional analysis and reporting.

What I would do is ask for a month to develop a prototype. Preferably on live hardware, but at least in a simulator. You have a lot of technology decisions to make.

Once you have your prototype, you can start iterating to develop features and bi-weekly demos. It will probably be months before you can produce a reliable estimate.

  • 1
    Yeah, I'd guesstimate it too at 12-14 months. Nov 24, 2010 at 18:37

Most likely neither your boss nor you have a complete idea about the proposed app, as it is just an idea on a napkin. Rather then arguing about the estimates perhaps you should do a few spikes, just to test your estimates, is that an option?

As Dustin said this sure looks like a text book example of an agile process. In order to minimize the risk on this project you might choose to deploy a version each month or so. If the customer is happy about the product, well that is perfect, but if he cancells the project during the development your company have only lost X month of work, rathen then the full 18 months.


With that description in mind I thought things over (albeit rather quickly). With our current staff size, limited budget, and limited resources, I projected that such an endeavor would take roughly 9 to 18 months.

Giving an off-the-cuff estimate like that is a really bad idea, because usually they are wrong. There are a number of tips given in The Pragmatic Programmer.

I think the most relevant to you is their suggestion for what to say when you are asked for an estimate. The only response is "I'll get back to you." You need to spend some time thinking about the requirements, understanding exactly what you need to do and what might already be done, building a model (either on paper or in your head) of the final system, relating the work that you need to do to similar projects you've done in the past, analyzing the resource availability, and so on.

Slow down, take your time, and be diligent. Never made off-the-cuff estimates to anyone.

If you have the opportunity, you could also take a look at parametric methods of estimation, such as COCOMO or SLIM (the Putnam Model). These take historical databases, but with the right base information and fairly accurate parameters, they generally give good estimates. Another option would be to consult the rest of the team and carry out some form of Wideband Delphi estimation.

Forgive me if I'm off in left field, I'm a recent CS grad and pretty new to the "real" world.

Estimation takes plenty of time. The best way to improve your estimates is to keep a log for every project. At the start of the log, record your estimates about the project size, scope, and required effort. Throughout the project, keep track of what happens. At the end, record the final size, scope, and effort. With sufficient time and practice, you can get better at estimation.

Also, no amount of courses or reading will help you get better at estimation. I've read about the PSP and the PROBE methodology, I've taken a number of courses on process management and project management. I've studied software engineering economics. I've even read Steve McConnell's book on software estimation. I've learned plenty of good techniques and strategies, but nothing has made me better than estimation then performing estimation, making mistakes, and learning from them.

Because estimation takes practice, I'm surprised that they are having you estimate such large-scale tasks. You probably have little-to-no experience working at the project level, so I'm not sure how you can be expected to estimate on your own. If I was your manager or lead, I would have you involved with estimation, but not estimating the entire project.

However, the project is currently only realized in my director's head, with no design documentation or specs.

This is problematic. Estimations come directly from the understanding of the project. You need some kind of requirements, specification, or end goals in order to even begin to estimate. You also can't estimate off of what is in someone else's head. I, personally, don't estimate unless everything is written down. My estimates correspond to what has been documented, and if what's document changes, then my estimate is also going to change.

Having a paper trail is always a good idea, too. It helps to ensure that the right people are always accountable. That could be in any decision, from an estimate to a project postmortem.

My question here is, how far off am I, really? Once again, my director -- who has no background in software or IT whatsoever, but is a subject matter expert insofar as soil sampling goes -- put the project at about a 3-month duration.

As a software developer, you are probably a better estimator than someone with no software experience is, at least of software development tasks. I forget the quote, but I think it was said by Barry Boehm or maybe Watts Humphrey, but it was something along the lines of the best estimators of engineering tasks are the engineers themselves. When planning an engineering task, the engineers are the ones who need to be involved at every step.


I once wrote a program that does 70% of what you're talking about (it even was for soil samples), as well as a bunch of other stuff (it was a soil sampling robot, so there were robot controls) in about 6 months as the only developer. The UI wasn't on the mobile device, but was a control program on a laptop... perhaps not dissimilar from your website? I also split the design and construction of the robot's electronics with another engineer during that time.

If you have a team of 3 knowledgeable developers who are familiar with the hardware, OS, language, and problem domain, I would think 3-4 months would be a reasonable estimate.

Not the answer you're looking for? Browse other questions tagged or ask your own question.