Open-ended System Requirement Study Period ...

A requirement study stage should not be left "open-ended". There should be key review milestones specified for checking the accuracy of the study and make any necessary change if required. No matter it is based on Water-Fall model, RUP, etc, the principle is still the same -- the outcome/deliverables of any stage must be specified in the scope of work (SOW).

If based on a small software house scenario, assuming the job is gotten through Purchase Order (PO), and if there is no contract is signed, and if there is no SOW is bound with the contract, then at least there should be Project Schedule that shows the milestones for review. During each review, meeting minutes should be taken to protect your effort (if next time there is any dispute).

Of course, time is short and expectation on requirements can be challenging, but some creative ways can be used to gain common understanding and be bound/attached to the System Requirement Specification. For example, the system analyst can use Use Case, UI prototype (on paper or on computer), Flow Chart, Story Board, etc. As long as can common understanding between the provider and customer can be reached.

If our problem is: "The customer is sitting on the documents", then it is the project manager's job to "kick" the customer to respond. Or put the clause "If we do not hear your feedback for changes to be made within 5 working days, we assume the specification content accurate." And in addition to that, don't just wait for it to happen in front of your email program, call the customer or see him/her to check the progress.

Another important area is to get the "right people" to be involved. Don't let those unspecified stangers come into picture last minute. It is okie for people to come and go, but any delay related to this should be recorded and justified for extension of time.