Sometimes, there are research and development projects where nothing is known in advance about the technology, concepts, and client. However, the manager still needs time estimates. What can I do to produce useful estimates?
5
-
5Take whatever your estimate would be in a known technology and move the decimal one place :P– RigJul 25, 2012 at 17:50
-
5Read Steve McConnoll's software estimation book and understand what makes a good estimate. An estimate has uncertainty to it - if it didn't, it wouldn't be an estimate. Saying "This may take anywhere from three months to six months, after spending a month on it, I will be able to narrow it down" should be acceptable.– user40980Jul 25, 2012 at 23:44
-
1@MichaelT - great comment. The one thing guaranteed to make imprecise estimates more palatable is refining them over time so management get an increasingly accurate estimate of work remaining. The one thing guaranteed to piss them off is a project that is permanently two weeks away from completion.– Carson63000Jul 26, 2012 at 2:57
-
This is what prototypes are for.– user1249Jul 26, 2012 at 3:13
-
@Carson63000 I had a simplified version of the cone of uncertainty in that phrasing. The key thing to take away from that illustration is that an estimate of 2-12 months doesn't mean it ends up at 7 months at the end, but rather the estimate may converge from 2-12 to 4-12 to 8-12 to 10-12 to 12. Also note that the original cone has a range of 16x when the initial concept is done.– user40980Jul 26, 2012 at 13:27
Add a comment
|
6 Answers
Honestly, as Nassim Nicholas Taleb writes in his book The Black Swan: 'we just can't predict'. Mainly due to the unknown-unknowns. It is generally best to communicate this very fact, the fact that you can't predict, instead of communicating an estimate.
As Taleb writes: it is better to be broadly right, than precisely wrong. So be sure to communicate the fact that you have hard times estimating, and use things like 'learning curves in new tech' as one of the arguments. This means that the range of your estimate will be big: 'this project wil cost between 100k and 500k.'
By saying such a thing, the one asking you to estimate something realizes that things are not so simple.
-
3+1 : This is the only correct answer. Teach you manager to embrace unknowns - it's much easier than estimating them. - Also look up the work of Steve McConnoll over at construx.com.– mattnzJul 25, 2012 at 22:44
-
2This is one of the most wrong answers here. You always can estimate anything. There are tools and techniques to support it. The only difference is the uncertainty. You might very well have 4x or 5x variance between your estimate and the actual value (especially early in a project), but that doesn't mean that you shouldn't try to estimate to serve as a starting point for future estimates.– Thomas Owens ♦Jul 26, 2012 at 1:36
-
2@ThomasOwens You are right, you shouldn't just walk away for it. But my bold statement was intended to be interpreted: don't fool yourself, or fool your boss, but be open in the fact that the estimation is going to be hard! Because honestly, not every manager asking for estimates realize how hard/impossible it is to make one. Jul 26, 2012 at 8:00
-
In my personal work experience, when doing freelance work on fixed price basis, my average hourly rate is way higher on small projects (like little add-ons to existing projects), than on bigger projects (often from scratch). It's not even linear. In hindsight, I should not have taken those bigger ones on a fixed price, or at least discuss up front that the estimate is very hard to do, and try to convince the client to work on a different basis to spread the risks a little bit. Jul 26, 2012 at 8:03
The absolute first thing you need is some idea of the scope. The more concrete the better, but any form of requirements can be used to produce initial estimates. Customer requirements, vision and scope, and concept documents can be used early on. As the requirements and operating environment begin to become more clear, then the estimates will improve. A greater understanding of the client (especially the interfaces between the client and the developing organization), the team performing the work, the technologies to be used, the system architecture, and a detailed design will all contribute to a more accurate estimate. This is visible in the Cone of Uncertainty.
If you are using a parametric modeling tool, such as SLIM or COCOMO (Intermediate or Advanced only, as Basic doesn't account for cost drivers), then there should be adjustment factors for the unfamiliarity of the technology. As an example, COCOMO has a large number of cost drivers, including some that are specifically geared toward familiarity with the target platform as well as the language and tools being used to develop the system. SLIM also accounts for the overall experience of the development team, which should include considerations of the tools and technologies being used.
With this technique, the output of the modeling tools are typically validated because they have successfully been used to estimate previous software projects over many years in many organizations. However, the output is only as good as the input to the tool.
If you aren't using parametric models for estimation, you'll have to simply consider these factors when producing your estimates. It becomes more of a judgement call, but you can consider activities such as reading documentation, setting up the new development environment, and developing sample applications on the target platform or with the target languages.
In these instances, you will need to break down your estimates by task and be able to use your professional judgement to back it up. Hopefully, you have historical data and other concrete evidence to base your estimates on. Otherwise, it's more of an uphill battle.
answered Jul 25, 2012 at 18:03
Separate major training and research time from development time. Break the project into multiple sub projects that have happy endings. Make sure you create a proof of concept after the training.
If you are new to the technology, you will never get close to the actual development time. Raise this as a risk at the beginning of the project and be generous in your estimate. This applies to core technologies you and your team are not familiar with.
Depends, I used FPA (Function Point Analysis) most of the time, but we were into this "enterprizey web development", I mean, you know, Forbes 500 web companies.
There the task can be always divided into two parts: one, which fits FPA really well: you have input interfaces, output interfaces, internal logical files (aka. database tables / types to be exported), and you have these complex, unknown systems.
In the easy version, the complex task is a component already written, it's just hard and unknown to interface with it.
The hard version is when it needs to be written, then pilot-based estimations, COCOMO, whatever.
Two things, however, of importance:
Every kind of estimation system has to have a calibration time for your organization. You never develop alone, at least there's a customer waiting for your code (or you wouldn't be so desperate about this, writing code for your own sake). The question is not "how fast can it be developed?", but "how fast can it be developed with you all?"
Once I had a manager who read that Black Swan novel and was maniac about it. He was telling us that it's impossible to estimate, and I was doing my usual precise to +-10% estimations relentlessly...
-
"I was doing my usual precise to +-10% estimations relentlessly." - the problem is the prospect that one day this won't be true. In Russian Roulette, you can have five full pulls of the trigger before being ruined. For a company that pulls the trigger a thousand times a year, just a 1-in-1000 risk of ruinous error, will almost guarantee catastrophic failure of the organisation.– SteveAug 13, 2022 at 10:13
I do projects that fit that description somewhat regularly and I haven't figured this out yet! Thankfully where I work I'm given the latitude to do what I need to and not have futile time limits. The projects are not always successful and that's just a part of what the work is with so many unknowns. The company gains knowledge each time though.
Sorry that doesn't help at all.
Estimate how long it will take to do a similar project using familiar tech. Multiply by 4. Add some learning time.
If the estimate is too short you will look naive and arrogant. if the estimate is too large you will look ignorant and incompetent. Choose wisely.
-
4Why 4? Why not 5? 10? 33.3? ... Is there science behind your answer or are you just picking a random number? Including that in your answer might make it more useful. Jul 25, 2012 at 23:19
-
on a related note, don't be shy of large numbers. My colleague once estimated some module rework in 935 (nine-three-five) days. Boss said we don't have that much and ordered 60 days. Colleague did what was possible in 60. Result was quite troublesome but he was never blamed for that. Have to admit that 60-days version, however troublesome, allowed us to get a pretty important customer - ie boss' push made pretty good business sense. BTW in the end we managed to get that module in shape, but that happened several years later and efforts it took were more in the ballpark with 935 estimate– gnatJul 25, 2012 at 23:33