I suck at project estimation

Today I sat down with the project manager that I'm working with on this contract project to figure out how long it will take to build the product. Actually, all we really did is map out the time for requirements, which we're pretty sure will actually take more time than the actual development (as well it should be).

But based even on our preliminary SWAG on the client's needs, and a look at the horrible system we're going to replace, I have such a hard time guessing how much time it will take to build. With solid requirements, my feeling is that it shouldn't take more than six weeks. All of the hard work will be done in the requirements and design process.

As kind of aside, what do y'all use for requirements tracking, and does it have some kind of bug tracking capability as well?

8 Comments

  • U are not the only one with problems there. With software, this is a very hard because the client doesn't really know what they want.

  • I use a visio workbook with UI/Service pieces ranked easy/medium/complex/manual, and an excel workbook to automate visio to extract the objects. The excel workbook has constants for how long to develop an easy service for example.



    We then use the diagrams for development

  • A thousand years ago, I remember sitting in a NYC FoxPro user group meeting with one of the gurus of the FoxPro world and we were talking about the business of being a software developer. Estimating was the biggest point of discussion and confusion. The formula that this guru shared with us was "figure out what you think it will take and multiply by three".

  • No, you don't suck - the entire industry gets this one wrong. We've been getting this wrong for several decades now, and I assume that we'll continue to get it wrong for several more.



    You are not alone!

  • Estimations are all about iterative development, It is about to impossible to give good estimates upfront, especially in large projects. Iterations will help. And previous stats may help as well.

  • Don't you think we already do that? The point that this is way before use cases.

  • There are as many different ideas about what a Use Case is, as there are people using them. I take it to be any text that describes a process in the system to be developed. They can be detailed or very brief. At the highest level, you can describe a whole system in less than half a sheet of paper.



    I usually start generating Use Cases from the first contact with my customers. At this stage, I keep them very high level. If it takes me more than an hour to do then it is a sign that I have used way too much detail. After this, I just refine the High Level Use Cases into a number of lower Use Cases until I run out of time, money or motivation.



    Therefore, in my way of working there is no Before Use Cases.

  • Hmm a lot of interesting posts here , I need to subscribe to this blog :-)



    But well, have you looked at DSDM (http://www.dsdm.org/)? It's quite focused on small iterations which are thus easier to plan and to estimate. Do you really need the requirements of the finalal system now? Won't they have changed by the time your have implemented the first few prototypes?



    Just my 2 cents

Comments have been disabled for this content.