>>>>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.
>>>>
[snip]
>>>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. :)

As Alan pointed out 'the specs (along with assumptions etc) are supposed to be clear, detailed and complete''/i>. Your example is exemplary of too many cases where we INITIALLY think that the specs ARE clear and only later come to the conclusion that we misunderstood or underestimated the implications of certain words, lines, paragraphs and so on.

I'm not saying here that the customer in such a case did set up a trap that we've then fallen into. That may occasionally be the case, but other times the customer is not really guilty.

Having said that, I'm not saying either that the other times the developer is the one to blame. 'Selective perception' is a psychological phenomenom and it may well be responsible for it. In the beginning, the focus is more on 'getting the job', which makes us somewhat eager/greedy. In that stage it's difficult to remain objective and tell yourself that it could be a tough job.