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.

In system design, be it a network, application or any other piece of automated infrastructure, we eschew single points of failure.  We know that in the real world, things go wrong, and consequently we design systems that have redundancy built in.  If something fails, the system can transfer operations over to a redundant subsystem, and keep on going.  That’s why, for example, websites have back-up load balancers or data servers.  These apparently redundant elements are there to keep the system online if the primary subsystem breaks.

Unfortunately, in the I.T. world, it is common to neglect that the human operators of automated systems are also effectively part of that system.  They can also constitute a single point of failure, and we should be avoiding this problem with humans as well as machines, for the same reasons.

No single operator (be they employee or principal) should ever control exclusive passwords or knowledge about a critical system. To do so makes the system fragile, and sets it up for the kind of snafus that are currently plaguing San Francisco.

In the linked article, it’s described how the network administrator in question was unwilling to allow anyone else to work with the network because he felt they were incompetent, and the configuration for the network was extremely complicated.  I can’t help thinking that centralizing control over the network was a band-aid on a tumor, however.  Essentially the city was running a network that was too complicated for them to staff properly, and was relying on a bad management decision in order to cover for it.

Essentially this is trading risk for cost.  However, it raises the question about whether it was acceptable risk and whether the decision was made consciously, or if it just happened through the ignorance of the network administrator’s supervisors.  I’m betting the latter.   This was sweeping the problem under the carpet, and the city of San Francisco is now paying the cost.  Bad policy.