More on saying “no” to customers, stakeholders, etc.

Pawel Brodzinski had a good comment (here) on my post about saying “no” the right way (here), which links to his post laying out his full perspective on the customer is always right principle.  I replied to his comment — agreeing with the principle, but cautioning on its application — which I’ve posted below:

Sometimes it is about saying no — or as the Japanese say “Yes, but.” There are times when we don’t take business, especially when we are being “forced” to do so. But if we aren’t taking their money, is that customer really a customer? IMO, no, at least not for that topic.

Of course, I agree that the customer is always right — which makes it critical to be choosy about one’s customers. But the application of that principle is tricky. PMs who allow scope creep to happen on their projects often justify it with a customer service rationale — “the users asked us to build it.” But are the users really the customer of the project? Aren’t the executives who chartered the project and the company they represent the customer? Too many IT staff and PMs are very confused about who is the “real” customer.

Back to your example [from Pawel’s comment]: when presented with such an opportunity or change request, we can certainly say “yes we can build functionality X.” But there is almost always a trade off that needs to highlighted, at least in the typical enterprise project or program The release will have to be pushed, or the functionality will need to be delivered in a future release, or we’ll need more resources, or we’ll have to assume more risk, or there’s a platform dependency, etc.

In other words, there are choices that the customer — the economic buyer in our terms — needs to make based on his/her strategy and where this project/program fits in. I believe that PMs need to be able to illuminate and influence these choices so you can get to “win/win” where ever possible.


7 Responses

  1. OK, I have flattened the case a bit in my comment. The thing I’ve omitted is financial aspect of the case. I definitely wouldn’t advise you to develop any feature a customer wants for free.

    My point was rahter on deciding whether to do what the customer wants (assuming a price is fair). Sometimes our customers/their users want to push our software in direction we’d like to avoid. But that’s always a price for that.

    I fully agree with you that’s about tradeoffs. For the vendor it’s additional, maybe unwanted, work (aka cost). For the customer it’s price or a delivery date or abandoning other features.

    Another point I agree with is that we should be choosy about our customers… If we have a comfort to be so. I’ve seen many organizations which would take whatever they were given. If you struggle to make ends meet and your cash flow report shines with red you can’t be picky any more.

  2. Hi Pawel,
    I think we both have the some basic idea… it is always tough to stick to such principles when one gets to “hard” cases.

    That said, the longer I’m around, the more I’m convinced that taking truly bad business is like jumping off a cliff without a parachute. Lord knows, I understand the need for cash flow — I’ve been part of two start-ups, one that was close to an IPO — but my experience is that lousy deals only accelerate and tighten the death spiral. When we took bad business — and we knew those deals were marginal at best — we ended up creating SW applications modeled on sub-standard processes, doing work and not getting paid, or both.

    If one’s firm has to take bad business to survive, there better be an exit strategy to get to a more sustainable model.

  3. Hi Pawel and Paul,

    I find the conversation really interesting and exactly the type of issues I had to face in real live.

    My discussion started off by discussing what skills a “good” project manager needs. I think we all agree that negotiation is one of these skills. We also agree that the average PM does not normally have this skill. We can also agree that this problem will not go away.

    We need to ensure that skills like negotiation and perception management become part of the basic skills that we teach our PMs. Being a good PM needs to go beyond the basics that PMBoK teaches.

    Most PMs do not know how to “trade” with clients. Do we encourage them to come up with creative solutions? Does our organizational processes and culture allow for this? As a management team we also need to ensure that the support for effective negotiation is in place and that the PM is empowered to do this.

    I believe that this should be the one skill that allows us to bridge between Customer Satisfaction and Scope Management.

  4. […] More on saying “no” to customers, stakeholders, etc. […]

  5. Hi Schalk,
    Thanks for the comment. Exactly… it is a topic where PMs just don’t know what to do. Even worse, I’m not sure many believe it is something that they should master.

    BTW, love the “van Gogh” avatar…

  6. […] Negotiation, Project Manager skills A really interesting discussion has started to develop here at Crossderry between Paul Ritchie & Pawel Brodzinski.  The main point focuses around do we […]

  7. […] sucks in each of above metrics. We all are more or less picky about projects and, as a result, about customers. The more mature the organization is the more picky we become. And that’s wise, since it isn’t […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: