There has always been a fundamental impedance mismatch between business and technical folk. They seem to be living in two different worlds, each with different rules of engagement. In fact, this is because they have different values – different things that they care about.
On the business side you have project managers, new business types (aka salespeople), and other bean counters. These people basically care about money: making it and not losing it. Making cool stuff is a fortunate side effect at best.
On the tech side you have developers and (in a way) UX types. These people love solving problems. Give them a problem, they want to solve it – preferably in the most awesome, beautiful and elegant way possible. On a deep, soul searching, emotional level, they don’t give a flying crap about the money.
Funny things happen when members of these two groups speak with each other. They describe things using the same words, but they mean fundamentally different things.
It’s very common for the business types in Group A to approach the problem solvers in Group B and ask them a question like “would it be possible to add some snazzle on the frozbot”? At this point the problem solver gets a far-away look in their eyes and replies “yes, it’s possible”.
Hey, business types: the problem solvers are talking about something entirely differently than what you have in mind. If you’ve just inferred from their response that you can squeeze that new feature into the project, you’re wrong. At least potentially you’re wrong. You actually don’t have any more information than when you started, because the problem solver’s answer actually contains no useful information to you whatsoever.
What you wanted to know was:
“Can I get this extra feature into this project, it in a way so that I continue to make money?”
What they just really answered was:
“Yes, with nigh infinite time, resources and money, this snazzle can be retrofitted onto the frozbot, in a fabulous dimension of mind over matter where this crappy project doesn’t exist”.
Which, business person, was, of course, not your question.
You see, you thought the money part was implied. And, to another business type, it would have been. But as was noted above, the problem solver is not inferring that part.
So I propose you stop asking the question “Is It Possible” altogether. It’s a useless question. Instead, I suggest you ask “does it FIT”.
My new favorite acronym – FIT. Feasible Inside Triangle. The triangle being, of course, the classic project triangle of Scope, Schedule and Budget. By including the triangle within the question, the problem solver has to take its constraints as part of the equation.
This is an adjustment at first, but they’ll get used to it. The barre has been raised. Business types can expect a lot more up-front pushback to “does it FIT” than “is it possible”. A lot more “no way”s. However this is better than the alternative, where people say “yes” and then a project disaster ensues. FIT forces people to be realists.
This communication barrier between business and problem solver types is really dysfunctional, and has probably led to millions and millions of dollars of waste. Let’s stop lying to ourselves about feasibility in projects, and keep our problem solving powers relevant to reality.
0 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.