On Tue, Nov 25, 2008 at 10:35 AM, sbeam <sbeam at onsetcorps.net> wrote: > Then maybe you need to re-consider how you are setting expectations for the > job. Everything needs to be written and detailed in specifications/ > functional requirements and _signed_ before work begins. If there is any > question about whether or not something is out of scope, then you haven't > done enough planning. Some clients can be difficult but you should be able to > just point to the reqs and resolve any dispute in minutes (ideally). Writing stuff down is not a panacea. Consider the following scenario. You are engaged by a department with a budget of $x for this project. You collect all requirements (or so you think) and clearly define the scope. In user acceptance test, a member of the client test team says a part of the system does not align with the way end users execute the related process. You go back to the requirements and it is clear that you built the system exactly as specified by the client project team (who are a part of the administrative unit and not the end users, who are, say, field workers). You discuss this with the administrative unit and explain it will cost more money to re-work the system due to changed requirements and potentially increased scope. The client understands and meets with their finance people and attempts to find additional funds, but cannot. Do you absorb the cost or do you stick to your guns and say "no change"? If you don't care about future work, you may stick to your guns. But if you care about future work, you are risking a rejection of your delivered system by the end users and it may be more beneficial for you to absorb the extra work. This happens all the time in larger, bureaucratic organizations. There are ways to defend against it, but to take a position that you will never deviate from the specified requirements is short-sighted and not optimal from a reputation-based and relationship-based sales perspective. -- Matt Warden Cincinnati, OH, USA http://mattwarden.com This email proudly and graciously contributes to entropy.