Absolutely, I have found that you need to agree on some kind of scope and schedule with a contract…..I’ve written many of them over the years – and I have found that the contract or statement of work more often (SOW) will go into this info to some level. Not super detail by any means though. It lists out major features/requirements – that you hope are in priority order (and if not, you prioritized asap before starting work so you work on highest business value first!).

I have also found that the details for scope/requirements are typically worked out and negotiated during the life of the project….and 95% of the time scope changes along the way and we adjust. Adjust, meands that depending on the customer/vendor worked with – you might need to negotiate additional costs as the scope details are found out or change. This forces hard decisions to be made to answer the big question of “is this really important?”. So WHO EATS THE COST?…..the answer is typically negotiable….and many times it becomes a shared cost between customer and dev team.

Now this comes from my experience with large Fortune 100 companies typically…….and I can imagine that the smaller the company – the more they will demand detailed SOW/contract. What has your experience been?

–Donna

In many cases whilst good design principles can reduce the impact of change we must appreciate that changes may result in (a) major rework to the code and architecture already completed (b) a reworking of user stories in question plus subsequent/previous stories as often there is connective tissue across stories. This story re-modeling exercise in itself can present a substantial cost in larger projects even if they are broken into smaller iterations. Changes need to be evaluated from a business and technical perspective, an estimated cost of change and schedule quoted to the customer who may decide the changes do not merit the extra spend or impact on schedule. This is especially the case in distributed software development teams I think, where the benefits of customer co-location are not possible.

Who eats this cost? It is usually the software provider so be careful to include the cost and time implications of these exercises in your budget or alternatively make it clear these exploratory changes must be paid for on a time and materials basis by the customer. That is, if they cannot be handled within the agreed project estimates.