"I can get you expiring coupons but the store locator will have to go."
"You are not a team player. Do both or I'll get you replaced with another resource."
"You are not a team player. Do both or I'll get you replaced with another resource."
My most effective scheduling tool was a list of proposed features, each with an attached estimate. The client suggested features, I estimated them, and the client chose the order of implementation.
If the client wanted to add, remove, or reorder features, great! We'd get out the list and make new estimates. The schedule and cost would change based on those estimates. By making the schedule highly "visible", and working to update it with the client, I gave them what they wanted (fine-grained control over "what" and "when" and "how much") without trying to stuff 6 weeks of features into 2 weeks. And if I estimated something incorrectly, I didn't charge for the extra work.
I can remember only one client who liked to bully his contractors. (He was also bad about paying his bills.) I wrapped up that project quickly, and politely refused any further work, even when he offered me a small fortune.
By doing it your way instead of presenting the client/your boss/whoever pays your bills with a binary choice (this or that) you present them with a menu of items with an associated cost. They know their budget and you give them the freedom to expend it the way they think is best.
> And if I estimated something incorrectly, I didn't charge for the extra work.
Very honourable, and a really good way to show your customers you are confident and willing to eat your mistakes. Things like that will create a bond of trust between a supplier and a customer in a very short time, and you probably have sold to the same customers several times if that was your attitude.
> Very honourable, and a really good way to show your customers you are confident and willing to eat your mistakes. Things like that will create a bond of trust between a supplier and a customer in a very short time...
Things like that will create a systematic overpricing of contracts. That's not a criticism of the GP, by the way, just of fixed price contracts in general.
One alternative I have heard of is to present a list of estimates along with their uncertainties and possible risks. Keep the client up to date as any risks come to pass or are eliminated. That should also help to build trust between the client and supplier.
Only if you're dishonest.
Also, you wouldn't want to turn a scope document into one containing mathematical equations and Heisenberg's uncertainty principle.
If there is no trust, no amount of documentation will help you. So unless you're Google suing Apple, clients that don't respect or appreciate your work are better addressed as ex-clients.
Of course you could be the client who strikes the jackpot because the supplier underestimated the job - in which case you probably won't get a great result.
What bothers me though is when this happens (and at least for me it always does) in a corporate environment, where this is clearly managing and therefor the job of the manager.
I don't mind helping with management as well as doing the actual coding, but then I'd like this added responsibility to be acknowledged so that time can be allocated for this, and that my salary can be adjusted to be closer that of a manager.
Unfortunately at many workplaces I've seen management are mostly playing politics amongst themselves, and then occasionally bully developers into taking over full management responsibility when some developing is to be done.
Being taken off a project and being replaced with someone else isn't going to look too good either way, especially not if the someone else manages to do what you said couldn't be done (you're obviously sure enough of yourself that that would never be the case).
I'd say it is more realistic in other places than it is in Japan and similar social cultures.
The limiting component is one's sense of honor and loyalty to one's company. In a culture where honor iand loyalty sn't so prized, a manager would have no problem firing an employee in an attempt to deceive people.
Sure, it might blow the deadline, and everyone will know that, but it will shelter the manager from responsibility. If the manager can intimidate the engineer into accepting the new feature on the old deadline, then the manager can claim it is the engineers fault for blowing the deadline. If the manager can't intimidate the engineer, and instead fires him, he can claim he would have hit the deadline if he didn't have such an incompetent staff underneath him. Either way, it's not his fault. Sure, it might screw the company, and it will definitely screw the engineer, but at least the manager is safe.
And yes, there are a lot of organizations like this where responsibility does not follow authority. But it requires a complete disregard for one's sense of honor.
From the conversations I've had with my dad regarding Japanese culture -- he was stationed there while serving in the military --, I get the impression this sort of dishonorable behavior is almost inconceivable over there. That might be why it seems so unrealistic to you. :-\