Actually I like this kind of challenge. It is a great fun in development to anticipate the potential change requests and make the app the most flexible way, so the possible requests for the new functionality may be implemented in a matter of minutes.

And there comes the moment when the client comes to you and asks "I know it may be too late but we really need this functionality" And you say: "I knew that you would ask for that".

Of course, you may tell them instead "Well, that will cost you...", then change a couple of properties and charge them for a week of work. :)

>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)
>
>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>
>>