What Ford didn’t say was, "If I had listened to people when they
told me what they wanted, I'd have offered a new model instead of
insisting the Model T was all they'd ever want, nearly wrecking my
company with my stubbornness."
The world is more complicated than the simple stories we prefer.
I understand that speed and agility beat size and strength. Everyone knows this is the central truth of the modern business age.
What I don't understand is why, if everyone knows this, mergers and
acquisitions are so popular. And I understand even less why so many
companies tell the FTC they can only compete if they merge, because
they need to be huge to get enough economies of scale to compete.
While we're at it ...
I've been told, over and over again, that we long-ago left the
industrial economy behind, replacing it with either a service economy,
an information economy, or some combination of the two.
The proof: We've sent most of our manufacturing offshore to China, turning it into ... an economic ... superpower ...
Hey, wait a minute.
It's hard to escape the conclusion that the big and strong, who don't
care where they manufacture so long as it's cheap, are acting like Uri
Geller, using misdirection to point the rest of us in the wrong
direction while they keep the serious money for themselves.
I figure it this way: The age of the dinosaurs belonged to the big
and strong ... the dinosaurs. The mammals used their speed and agility to
be too nimble to catch.
To me, that seems like a more accurate metaphor for the world economy.
Speaking of what we've been told over and over again that doesn't
line up with How Things Really Work, here's an example that's closer to
home: Nearly every published application development methodology.
Look closely at their applicability to internal IT. You'll find the
same flawed chain of logic: (1) It works for developing commercial
software -> (2) The software internal IT builds is just like
commercial software, only simpler -> (3) Therefore, using these same
methodologies will make internal IT phenomenally successful.
Two problems: First, where commercial software developers generally
develop software (talk about your blinding insights), internal IT
generally buys commercial software whenever it can (otherwise there
would be no market for the commercial software developers -- another
blinding insight) and integrates each new package into its application
portfolio.
Package integration is, of course, just like application development, other than being entirely different.
That's the first problem. The second is the nature of the product.
For a commercial software developer, the product is software (and the
blinding insights continue unabated). For internal IT? Not hardly.
Installed software, no matter how well it runs, is by itself worthless.
For internal IT, the job isn't done until workgroups throughout the
business put the new or improved software to productive use. Most
internal IT organizations are in denial about this point, and have been
for decades, because ... all together now ... the commercial methodologies
stop when the software fulfills all requirements and meets all
specifications.
If these IT organizations were, instead, convents, they'd go by the
name "Our Lady of Perpetual Argument," because that's what always and
inevitably happens following "successful" project completion: An
unending argument as to whether the software meets the specifications,
whether the specifications were right, and whether the business
manager’s face looks more like a potato or a radish.
As if any of this matters.
Contrast this situation with what happens when internal IT figures
the job isn't done until the software is in productive use: The
arguments become discussions.
Arguments are, in any business setting, for losers. Arguments are
about winning and losing, and if IT and a business division argue, one
will lose. That means the whole business loses no matter who wins,
because either way the business will have spent time, money and effort
implementing software that isn't in productive use.
Discussions, in contrast, are about solving shared problems. In this
case, the shared problem that the new software doesn't support what the
business intends to do. As is the case in any discussion, both sides
win or both sides lose, depending on whether, working together, they
succeed.
It's the difference between "win/win" and just winning.
