Boss doesn't believe my time estimate... advice/backup?

Question

First of all I'm not 100% sure if this question is really meant for SO (sort of subjective) so feel free to remove it if necessary. Thanks in advance for answering, though.

For the sake of introductions, I belong to 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!

Answer 1

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

http://www.joelonsoftware.com/articles/fog0000000245.html

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.

Answer 2

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....

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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!

Answer 10

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.

Answer 11

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.

Answer 12

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 their 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!

Answer 13

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.