I just say, "Yes. And this is what it will cost you to do it right:"
- Projects X, Y, Z will all be pushed back 2 weeks.
- Prerequisite Project <x> will have to come first.
- <x> weeks overtime for <y> people = $z.
- Joe and Mary will have to be pulled away for 3 weeks.
- Interim solution <x> will only take 1 week, but <y> won't work.
- We will need your top supervisor full-time next week.
or, best of all:
- We don't know. We need a project to find out.
Note that "doing it wrong" or "doing it quick & dirty" are not options.
People understand "this is what it will take" a lot better than "no". They also understand the trade-offs and sacrifices needed. Then they will work with you to make the best decision for everybody.
I just say, "Yes. And this is what it will cost you to do it right"
You have a number of "this is what it will cost you" options which will only work if the party you are negotiating with is reasonable. There are teams and managers out there who will happily assert that they can violate the laws of space-time in order to avoid making the sacrifices you'll tell them they need to make.
Note that "doing it wrong" or "doing it quick & dirty" are not options.
What if you are told directly to do it "quick & dirty," and you refuse? Is that not the same thing as saying "No"? Or by never saying no, do you mean never say no without providing what qualifications would turn it into a yes? What do you do about people you know will attempt to spin things later on to bolster their claims that they weren't advised of the costs ahead of time?
In other words, what do you do about people who don't have an impeccable sense of ethics? It seems like you would need that before you could feel safe being this agreeable.
"You have a number of "this is what it will cost you" options which will only work if the party you are negotiating with is reasonable. There are teams and managers out there who will happily assert that they can violate the laws of space-time in order to avoid making the sacrifices you'll tell them they need to make."
Generally speaking though, it's less a matter of reasoning with them as it is a matter of finding the right buttons to push. Is it that their goals are misaligned from yours? Phrase your response in terms of their goals; they can't be too out of line if they need something from you. Do they not trust you? Point out that they're going to have to trust you whether you do it your way or theirs.
If they're being genuinely unreasonable and out of touch with reality and they are completely unwilling to change their approach, I'd personally rather spend my time finding ways to not have to work with them. Chances are they really aren't though. They just have a different way of looking at things that you can't meet without learning to think like they do a bit.
But what if they don't trust you until you can do things that they ask ? The difficult situation is people who do not trust you and ask you to do their own way until they do - not realizing that doing it their way is exactly what prevents you from doing your job. It is fairly typical in my experience, but I have not found a way to deal with it effectively.
I agree with you in spirit. The worst place I ever worked had managers like this in spades (not sure if they had any other kind).
But if we're honest with ourselves I think we have to admit that this is our fault. Why does the pointy haired boss even know about the "quick & dirty solution"? We always talk about how much better other engineering disciplines are, "you don't see bridges falling over every time someone makes a new model of car!" we say, but why is this? It's at least partially because no engineer offers a "quick & dirty" option for making bridges. They never say "well, we could use this material and skip all these steps to get done in 1/10th of the time for 1/5th of the cost but it's probably going to fall over" [1].
This is the key point. Of course for bridges purchasers are going to want the cheapest and fastest thing they can get. They aren't given an incomplete solution as an option so that's why they don't ask for it. If we want things to change in our industry we have to do what the GP suggested. Don't mention non-solutions, aren't you an engineer (at least partially, I know many of us think of ourselves as artists)? In fact, if a manager says "lets just do this quick & dirty" you should take that to mean that they still want a completely correct solution that just doesn't address some of the requirements (e.g. "handle email quick and dirty" might mean leaving out SSL).
>What if you are told directly to do it "quick & dirty," and you refuse?
This is the place where they shouldn't know this term. It shouldn't exist. No one asks a bridge builder for "quick & dirty" they ask for cheaper & faster. So the bridge maker considers all the possibilities that still leave a completely working bridge and answers based on that.
The bridge builder recognizes that no one is asking him what is the cheapest/fastest way to possibly make something that looks like a bridge. What good would that do anyone? We also need to understand that no one is asking us for what we mean by "quick & dirty". Are they going to expect it to fail 70% of the time? No? Then what they're actually asking for is a correct solution but they want it fast, cheap and without unnecessary frills.
[1] I have no doubt that some joker will find an example on the internet of exactly that happening. When you do, understand that you've found the exception that proves the rule, not that refutes the point.
I have yet to work for a manager that knows the difference between the right solution and the "quick and dirty" solution. Estimate out what it would take to do it right and then tell them that's how long it will take to do the "quick and dirty" solution.
The answer is to maintain a documentable trail of what went into the decision. Make sure that the details of the discussion are in meeting notes, an email thread, etc. Absolutely positively do not agree to anything on just a verbal agreement.
You might still be stuck "doing it wrong" or "doing it quick & dirty" but you've got enough CYA material not to be the scapegoat.
Really? I expect to hear No (clarification: I am a project manager/ geek herder). That's fine. I don't need my developers to be wasting time working out convincing arguments and workarounds to requests - I trust that they want to be helpful and if they are saying no, there's a good reason. Hell, assuming I am on top of stuff, I can figure out what the reason is - and in the rare occasion when I can't, I just ask.
I am here so that my developers don't have to worry about this shit.
Yeah, if your PM is not shielding you, you can try that approach above - at least it makes you not look obstructive. However, people burn out doing that after a while, especially when they have to explain this stuff to people who don't want to understand them. In which case a simple "How does this compare with my current top priority X?" is generally sufficient.
A friend (in a completely different line of work) said that the reason that directors (he works in TV) liked him was that he never said no, he always gave them options.
Yes you can have the helicopter for that shot you want but you'll need to lose this, this or this from the rest of the episode.
I agree. Generally speaking, saying "I'm the developer, and I say this is wrong" is no better than "I'm the manager and I say do it now".
I think the best approach is usually to say "I can do that, but understand that you're putting the next project behind to do this one". Granted, that won't change their mind. But you will have an excuse for being behind next time.
This is great advice. The best thing about it is that it dispels any notions that:
a) the thing you're doing is simple
b) it can be done quickly (which turns the situation from: "he won't get off his lazy ass and do it" to "i'm asking for way too much, and this is going to risk the project")
Most of the time, I'd argue that you can't really say 'No' at all. Not if you want a happy client. If you do say no, then you'll just end up delivering an end product that isn't exactly what the client wanted and didn't have that feature they requested. I can't imagine any situation where that results in a happy client.
So what do you do? I say: Get the client to say 'No' for you.
Getting people to understand the trade-offs and sacrifices for what they might consider a "quick 'n easy" feature is the name of the game here. You've got to flesh out all the assumptions that they have when making such a request so that they understand what the impact is on schedule, budget, and code.
But what they still don't understand is why Projects X, Y, and Z will have to be pushed back for 2 weeks or why Joe and Mary will have to pulled away for 3 weeks just to do this "quick", "simple" thing. At this point, what I usually do is spec out the entire feature (front-loading all the mockups, copywriting, etc) on the spot or in a meeting immediately following. The reasoning is that "If you want this feature tomorrow, then it has to be designed today." And well, practically speaking, you can't implement it by tomorrow if you don't know what you need to do yet anyway and, worse still, you'll build the wrong thing if you don't at least discuss it in some detail with your client first.
If the feature isn't important enough to spec out in detail now, it's not important enough to be done by tomorrow.
In my experience as a solo webdev freelancer (so take it for what it's worth), clients usually see my point and give in when they realize that we're trying to compress about a week's worth of back and forth emails, phone calls, and let-this-idea-sink-in time into about an hour--sometimes even realizing that they don't really know yet what they want.
Bingo! I say, "here are your choices; A> will get you this, B> will get you this, but not this... " etc.
"Quick and Dirty" is still an available choice, but I warn them thoroughly of the drawbacks and risk.
Basically, if you wanna pay me, I'll still do it your way, but I will also provide ample warning, oftentimes in writing. Few/no people will still choose the bad way, due to the warning.
If their "Q&D" choice is just going to lead to certain disaster, then no, I write off that business as not worth my reputation or frustration, entirely.
But after my explanation(s), I've never had a customer choose the lousy way, and they always accept my explanation and guidance. It's all in the pitch!
It is, because it's a direct conflict of interest between the one implementing the "ugly solution" and the ones who are later going to need to read it, debug it, refactor it, etc. Who are, in fact, most likely to be colleagues, in this context.
I just say, "Yes. And this is what it will cost you to do it right:"
Note that "doing it wrong" or "doing it quick & dirty" are not options.People understand "this is what it will take" a lot better than "no". They also understand the trade-offs and sacrifices needed. Then they will work with you to make the best decision for everybody.