>>I just love those in-progress meetings that start out with 'We've been thinking and we wondered if it is possible to add this functionality to the program...' :o)
>
>If you still have not learned that this is the way the things go I have no idea what to say.
>
>Have you ever met a customer with a clear idea? Somebody who know his needs?
>People have normaly a general view. The details of an project need to grow. Software is a process rather then a thing. Also customers needs grow up and programmers brains need some time to get ideas.
>
>All what you can do is:
>Hold your software open to changes. (i.e. clear objects, n-tier, inheritance, data driven apps and the like).
>
>Make clear contracts about what is included and what is not.
>
>If you know that things go the way they go, don't try to change the things. Change your calculation and time estimation. 15% extra to your estimation is lower limit!
>
>And keep in mind that you are on the bright side of life. It is a tiny problem to change several thousend lines of code.
>
>Car makers do the same same thing. But they do it in steel. Belive me, that hurts more. They have no undo and no version control ...
>The accuracy as mentioned below is made out of human bones.

***************************************************************************
I work for Toyota/General Motors. We do have version control but what hurts is is recalls! :) Do it right the first time! Like you said, when you do it in steel (and plastic) the impact (pun) is different. :)
***************************************************************************
>
>Agnes
>>
>>Of course they still want it delivered on time!
>>
>>
>>>>Hi Terry
>>>>
>>>>>Good leadership, a sexy project, incentives and equity might overcome prima donna issues. If there is a pot of gold at the end of the project a team of prima donnas could do it.
>>>>
>>>>You may be right at that.
>>>>
>>>>>The real trick [as always] is in the planning - assessing the market and translating those requirements to a simple, understandable plan that will deliver the project on schedule and on budget!
>>>>
>>>>I agree, that's crucial. However your last phrase is the kicker. "on schedule and on budget"
>>>>
>>>>The most difficult thing in any software project (of significant size) - tracking and assessing 'progress'. To do so you need to have good estimates of the work scope and the time required. As a project manager (I project managed Civil Engineering and other non-software specific projects before becoming a programmer) the one thing that I find that continually frustrates software projects is the Estimation/Progress cycle. It comes down to to two key questions:
>>>>
>>>>[1] How to come up with a reliable estimate of time (and hence costs) for developing a software application
>>>>[2] How to ensure that the actual development is on schedule
>>>>
>>>>The consistent inability in the software industry to consistently and reliably handle these two elements is why the majority (and I have seen estimates as high as 85-90%) of all major software projects are late and over budget.
>>>
>>>Add an item [3] to that list. "Proper change control procedures". A large part of that 85-90% figure comes about because of changes introduced by those (usually in management) who 'sort of' bought into the project, but now figure they can introduce all the little bells and whistles to which they couldn't get agreement beforehand. Of course the project scope becomes wider without properly re-assessing budget and time estimates.
>>>
>>>>If someone could come up with a reliable way to objectively assess how much has been done, and how much remains to be done, and to estimate the times required to the levels of accuracy that are achievable in other industries, there is a fortune waiting for them <bg>
>>>