A Goat, A Rope and a Gonkulator

Ah the joys of corporate IT

I had a recent discussion with some folks on a project I was involved with. The meeting was essentially a general accuse-all goat rope with fingers pointing in every direction. Goat rope is a nicer way of saying cluster fuck, in case you were wondering. Why was the project so horribly planned and so terribly executed?

The usual things were bandied about: not enough money, too much money, not enough time, wrong skills, impossible requirements, insufficient caffeine, etc. It was the routine blame game and excuse factory until one nameless architect had the guts to speak up with a refreshing view: we don’t have planning or delivery problems, we just aren’t focusing on the solution!

This derailed the circular firing squad for a moment. Pressed to explain himself further, the architect gave some examples of how we had gummed up the process by focusing on process and not spent enough time on solutioning. He offered an historical example:

When NASA began its space missions, they found that the simple ball-point pen wouldn’t work in zero gravity (ink won’t flow down to the writing surface). To solve this problem, they spent a decade and $12 million. They developed a pen that worked in zero gravity, upside down, underwater, and in a temperature range from below freezing to over 300 degrees. When the Russian space agency encountered the same problem, they equipped their cosmonauts with #2 pencils. The moral? We have to stop worrying about the problem and process and focus on the solution by gosh!

Well now. This went over like the Second Coming. The obscure architect was a rock star, feted for breaking the logjam with innovative thought. The thoughtful comment was refreshing for sure. Refreshing, but wrong.

I tried being reasonable, I didn’t like it

Unfortunately for the faceless architect, I happened to be on that call. As he was speaking, I quietly opened my specialized under-desk refrigerator I keep for just such occasions and hauled out my giant bucket of rhetorical cold water.

I thusly commenced the deluge.

NASA didn’t over complicate the situation because they weren’t focused on the solution. It was precisely because they were focused on solutioning that they wasted time and resources coming up with a pen that, while very cool and in my own personal inventory, solved the problem just as well as the inexpensive pencil. We don’t have problems with our project because we’re spending too much time talking and not enough time solutioning. It is exactly the opposite. We started with a solution in search of a problem and have spent months spinning our wheels on trying to force those square solutions into the round problem hole.

I’m not saying you’re wrong, but…

Listen, folks who lean toward being solution oriented (looking at you engineers and developers) have a tendency to create solutions that showcase their abilities. There is often an attitude of including something in a solution ‘because you can’. The phenomenon of an IT person who specializes in Oracle, for example, discovering to his amazement that every single problem he encounters can be solved with Oracle is really not that surprising. Obviously this is a generalization, but the fact remains that many IT people consistently place focus on solutioning that plays to their strengths and knowledge. And why not?

The issue with this is, the people who like to create solutions are typically not the best equipped to fully understand the context of the problem. They are structured by nature to take action, to find a way around the obstacle. Their gaze is fixed on the end result, the grand design of what will be in the future state. It should have all the properties of flexibility and elegance and sophistication commensurate with their intelligence and capabilities. With this horizon-centric, forward looking perspective, the original purpose for the effort is usually sidelined.

Keeping it in focus

The focus shouldn’t be on constructing solutions, either at NASA or on our woeful project. The focus should be first and foremost on understanding the nature of the problems at hand. In our situation it was abundantly clear that we couldn’t come up with a solution or progress toward it because we didn’t have a good understanding of the business problem we were trying to solve. The recrimination and ill feelings involved with the blame game occurred because nobody on the IT project team could convincingly describe what the problem was. Without that understanding, any solution would be a hodge-podge construct, a committee-designed Frankenstein, a gonkulator with functions that superficially mapped to each of the business requirements and therefore ‘solved’ the problem on paper but at substantial cost, time and effort. And in case you track cool words, a gonkulator is a magical piece of technology that serves no practical purpose or provides a technical solution to a problem that doesn’t exist. It’s usually designed by committee or a room full of bad architects. In this case, we would have created a space pen to solve the issue when a pencil would have been just fine.

The lesson is not that the solution needs more solutioning. The lesson is that the problem needs better understanding.