>>>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.
>
>Alan, you mention changes wanted by the customer during development as a cause of further delay. You focus on bells and whistles. However, delays can also be the result of what we call in Dutch 'voortschrijdend inzicht', which litterally probably translates best to 'growing insight'. The client thinks he understands what he wants, but later on he changes his mind and realizes that he wants something else. We, the developers, often have negative feelings about such changes.
>
>However, I think that this also happens a lot: The developer thinks (s)he understands what the customer wants, but later on the developer realizes that the customer wants something else. The implications for the design, the estimates, the planning and the assesment of the progress can be huge.
>
>In the best case, the developer can point to a vague functional specification. In the worst case, the developer thought too easy about reading and reflecting on the specs.

The worst project I ever worked on was one where there was no source code but the owner (State of California Water Department) said, “We have a FoxPro 2.0 DOS program we want in VFP. Here is a copy and we want the same features as the original”!

Little did I know that each form used function keys for additional functionality, which was not discussed until I delivered the prototype. In addition, each form used different function keys for the same functionality.

Specs can be a great unknown. :)