When the game is rigged
I’ve been thinking a lot about Victoria Brouhard’s recent blog post on “no-brainer” decisions. It’s a clever idea. When you’re trying to decide about accepting something like a job offer, ask yourself, “What would it take for me to say hell yeah?”
In other words, how would you change the offer–if you had the power–so it becomes something you couldn’t imagine rejecting?
Key insight
Brouhard’s corollary to this concept is: if you can’t find a way to make it a “hell yeah!” then the answer is definitely no, and you can feel good about it.
It doesn’t just apply to jobs. The “no-brainer” technique (and by the way, it’s short, and I do urge you to read it all the way through) would have been awesome for me in terms of selecting a college, capital-R Relationships, finding a place to live, even deciding what to have for dinner.
Oh dear. Definitely the Relationship thing. Ouch.
On a larger scale, national leaders could have used it in 2002 and 2003 to, you know, decide not to invade Iraq. Because honestly, what would the best possible outcome have been? You’re looking at it on Google News right now in another browser tab.
Here’s what’s cool though
Brouhard’s No Brainer is the same as Schumann’s Guaranteed Fail. If you have my signature article, “Don’t Do That! A contrarian guide to fixing software projects that suck,” and you should, then you know about #8 on the list of eight reasons why software projects suck. If scope and specifications are vague, the project sucks because there is no way for it to not suck. (Yes, that’s an opt-in link. Hope you don’t mind.)
Suppose you apply the Brouhard Formula:
Make a list of all the things you would need to have (or not have) in order for the project to become worthy of Yays and Hoorays.
You would find that list impossible to fulfill, or even to imagine. And that is the point. When you don’t have a clear goal, or you lack a solid justification for that goal, it doesn’t matter how many developers you put on task or how much you manipulate the project plan. It’s not gonna work, because there’s no such thing.
Basically, the game is rigged.
I used to know this cop who liked to say that when you’re playing cards, and you’re losing over and over again, don’t keep playing. Knock the table over and stop the game, because it’s obviously rigged. (Yeah, he liked to wear cowboy hats too, why do you ask?)
This is the equivalent of knocking the table over.
So.
The next time you’re starting a software project, or even if you feel a need to re-evaluate the one you already have, take a few minutes. List all the things that, if you could magically make them happen, would make this software project so awesome you would totally work for free on it. Or at least so awesome you wouldn’t feel annoyed and resentful over it.
If you can’t even imagine such a list, it’s time to kill the project. Or if you’re not in charge and cannot successfully communicate this to the business leadership, it’s time to find another project to work on.
If you can imagine that list, consider that the core of your agenda for things to consider changing about the project.
February 16, 2010 @ 7:51 pm
o, how do you approach the pre-sales/initial sales process of a software dev project where the ability to hit irrational dates set by product management is critical to the success of the business winning/strengthing the business relationship?
February 16, 2010 @ 10:07 pm
Irrational dates are actually a different issue from that of unclear goals.
It’s hard to know a priori that the dates are irrational. If I can take the scenario you gave me, in those stark terms, and assuming we’re talking about a new project rather than one I’m thrust into, I’d most likely say something like this:
It depends a lot on the conversations that led up to that point, of course, but that’s the basic idea. Also, I bring bagels.
I’m sure you’ve faced situations like that, John. What do you do?
February 22, 2010 @ 7:17 pm
I agree, project goals and irrational dates are two separate challenges. I think there are indeed, fundamentally, only two levels you can pull. One is extend the date. The second is reduce what is delivered within the date. In product delivery. where the product is heavily dependent on IT technology, the most challenging for the IT delivery group is when “sales” goes out and promises a “product” that does exist by a date that makes the sale, rather than being based on any IT work plan estimate.
One the deal is made, now the real challenges of negotiation being with the two levels being very, very hard to move.
BTW, very eloquent response to a politically charged question.