Martin's pointed out the right ways of dealing with this stuff. When you take on the project, the appropriate work orders need to be agreed to that show what's expected of each party and by when. This includes requirements around what the application should be doing. If the customer doesn't meet a deadline that they agreed to, then they need to understand that this has impact upon the rest of the schedule. If the client has new requirements, then that's a "change request" (CR) against the original work order. If they don't like your estimate for T&M to implement the CR then they can either withdraw/amend the request, or they can hire someone else to do it. This is standard contracting/consulting stuff which everyone should know if they want to grow a business whilst CYA at the same time. It protects the customer and it protects you. > If as in this particular case you are assigned to work with someone > whose job is to populate the cart (not the financially responsible > party) who does not care nor understand the requirement process, all > that you will hear is, "Why can't you do this? This program is > inadequate, is dumb, you baffoon!" I still don't really understand the situation here. Unless you report to this particular individual, I don't understand why you need to listen to any of this sort of stuff. If they have a problem with the application, then they should escalate it to project sponsor. You can then present your case as to where you think the problem lies (namely, not in the application, but rather in someone who can't follow instructions). The project sponsor or their project manager then makes a decision on what to do. Cheers Ken ________________________________________ From: thelist-bounces at lists.evolt.org [thelist-bounces at lists.evolt.org] On Behalf Of Bob Meetin [bobm at dottedi.biz] Sent: Saturday, 30 May 2009 8:32 AM To: thelist at lists.evolt.org Subject: Re: [thelist] how do you manage/respond? * Every time the customer comes up with a new requirement, you simply work out what it would cost to implement (in terms of cost *and* schedule (and risk to anything else you're doing)), and check that they're happy to proceed with it. * ==>> This sounds good in concept and is reasonably doable if you coded the application but when you're implementing an open source application and have to dig/research through unfamiliar code the simplest changes may take many hours if they are even doable. If as in this particular case you are assigned to work with someone whose job is to populate the cart (not the financially responsible party) who does not care nor understand the requirement process, all that you will hear is, "Why can't you do this? This program is inadequate, is dumb, you baffoon!" What I am looking for is the business and perhaps politically correct way of managing this type of situation moving forward.