Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
I need a way to make fast estimates:
For example I'd like to know how long it takes to take a mobile device from nothing to production... let say that a customer wants a IPHONE like product(scope) ... than planing,developing,testing etc...
I know that the general direction is Google... but I don't know how and if there are other ways...
I think there are two fundamental methods of estimating the duration of a project:
If you don't have the luxury of comparing to a similar-enough project, then you're probably forced to use the second method; luckily, it CAN be just as accurate.
Have a knowledgeable person (or people) estimate the project duration. This is really an entire continuum, ranging from low- to high-fidelity estimates.
At the simplest, this method means having someone who is very knowledgeable and experienced in the subject field learn as much as they can about the scope of the project, the available resources, the technical solution, etc. and then having them estimate how long they think it will take based on this information and their experience. This method can be made slightly more scientific by asking several people the same question and determining the variance of the answers. You can generally get a fairly good and very fast estimate at this end of the spectrum; let's call it go with your gut.
At it's most complex (i.e. expensive) this method involves generating a very detailed schedule where tasks are small and durations are estimated at the task level. The schedule is then generated via critical path analysis. The evidence-based schedule method advocated in the Joel on Software blog is a refinement of this technique (or perhaps even a combination of the two primary methods. It's key innovation is adjusting the lowest level task estimates with a historical factor to account for how much the person who generated the estimate typically underestimates--based on their past estimating performance. When done right (and this method's complexity makes it hard to do right without practice) this is really the only way to generate a believable schedule for a one-of-a-kind project. It's also probably the only way you have any hope of actually managing a complex project to a schedule.
Wideband Delphi
I agree with other posters: get input from lots of different sources on your estimates.
Software Component
It's not the complete scope of what you're asking (hardware + software), but Construx has a nice tool for estimating the software component. It uses simulation based on your project type and scope estimates, or you can use your company's data also.
First fast most of the time means rough, so bear in mind the quality of fast estimates.
Second if you want to spend almost no time analyzing what the product should be the only approach will be experience + gut feeling and quality of answers will depend tremendously on your past experience with similar projects. If it is n-th iPhone app you're working on your rough guess might good enough.
However if you're unfamiliar with project and still want to reduce time needed to build a reasonable estimate I'd advice following:
Gather and use historical data. When you work on different projects try to store your estimates and real times you spent on tasks. This would allow you to learn how much you miss your initial estimates for different tasks.
Break the work down to fairly small pieces. Usually we estimate way better when we deal with small chunks of works than we do with big ones.
You may also try to split the work into similarly-sized tasks. This way you can use historical data to directly estimate how long it would take you to complete the project. We were using this kind of approach in our Kanban team and were able to come up with pretty reasonable estimates in short time.
I can point you to two techniques that are quite interesting for new projects and low confidence in your velocity.
First one was once posted at Ask About Projects forum and I liked it very much:
http://www.askaboutprojects.com/questions/1858/agile-project-management-estimation/1873#1873
The second one is called Magic Estimation ;-)
http://campey.blogspot.com/2010/09/magic-estimation.html
Both are team/collective wisdom techniques. You should not stick too much to estimates found in Google or somewhere else as the scope you're estimating is only one of the factors determining the final score. The other one (very important) is the people that will be actually doing the job. There are also other factors that depend your team/organization context. So even you find the raw estimate for some iPhone app project, you still need to assure the same environment and a set of skills in your team to do the same job within the same time period.
First build your WBS up to work package level. Describe every element with some additional sentences to describe what it is (or is not). This is not a full analysis and it doesn't take much time, but it is often overlooked.
Then use the techniques others have posted here.
My first gut reaction is DON'T USE ANY TOOLS...get some paper, a pen and write down what you plan on doing from a top down (work break down structure or mind mapping) approach. You can't estimate how long it's going to take to get somewhere, when you don't know where you're going (really know) - and all a tool does is make your bad estimate look real (and commits you to the client...aka contract).
Unless you have A LOT of prior experience with similar projects or have access to people who do (and will work with you), my recommendation is to take a different appraoch to the project - either prototype to production, Agile sprints....
may be not a tool. what you need is a Method Of Work.
the first step is WBS. which means work breakdown structure (WBS), in project management and systems engineering, is a deliverable oriented decomposition of a project into smaller components. It defines and groups a project's discrete work elements in a way that helps organize and define the total work scope of the project.
The second step is to allocate the resources. You should, you need business analyst, chief architect, develpers, testers. You also need the hardwares, iphone, mbr, etc. You need an office.
The third step, when devs+QAs is avaialbe, they need to set up the work env.
Then technical selection. To choose the correct or appropiate technical skill set for your product.
Then prototyping.
Then demostration to your customers and get feedbacks from them.
Change your product design and implementation according to the feedbacks you collected.
then demo->change-->demo-->change..... .....
I have found quite nice articles on estimation techniques. See http://www.infoq.com/articles/estimation-toolkit & http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/
Additionally - I have recently had a interesting discussion that after you have requirements to estimate it would be helpfully to ask yourself: "What's the business value of it? How business would benefit from it?" It would give you a chance to make sure that you understand what should be done so your estimates would be more accurate.
Great comments already posted but I would like to add this: break this silly notion that there exists a "correct" estimate. There is no such thing. I have found that people tend to believe there is this one true estimate--both cost and time--that exists for any given task, work package, control account, or project. If your estimate is missed, then apparently it was NOT REALISTIC.
Practice probabilistic estimation, get used to trying to identify that distribution curve that shows likelihood of some minimum amount of time, a maximum that never really touches zero, and a MODE time. Setting your deterministic estimate that becomes your baseline when you truly understand the probability becomes a much easier and credible task.
