To address these issues you should go to a more formal 
requirements process that forces the customer to sign off 
on their requirements. Letting them know that any changes 
effect cost and schedule (positively or negatively). 
Acceptance criteria is signed off with the requirements.
[download]

This assumes that you haven't done this already. This is my point. You have done all of this and you have learned many various ways of doing it according to what is the flavour of the month. It may be the MSF, the UP or whatever. But I could just have easily added the following to the list (though they show the more cynical side of my feelings towards corporate UK).

• Do not ask your service provider to hack in data to the app because of a promise you have made and then swear at them when someone gets a few emails by mistake
• Do not use your position in the company to allow you to change your mind arbitrarily and force through whatever it is you want even in the face of all the project work done so far
• Do not assume that your service provider will be more than happy to work a string of 14 hour days to meet your arbitrary promises because if they don't you will look bad
• Do not attend board level meetings promising what the application will do without first referring to the business case, that you have *taken with you*, each time you make a promise.
• Do not assume you can make the project go quicker by simply putting more people onto it. Especially by not thinking you can just employ a load of school leavers or apprentices who have zero experience. Don't assume that your service provider can simply train them up. No - it isn't like your nephew doing it in their bedroom for a school project.
• Because you don't understand your service provider it doesn't mean they are lying to you or pulling the wool over your eyes. They aren't making fun of you either.
• If the answer doesn't meet with your experience then ask yourself who is the expert. If it is the other person then perhaps you should trust them rather than spend the next three weeks doing it your way - because you can - and only have to do it the other way as nature originally intended.

etc etc etc.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.