“If I had asked people what they wanted, they would have said ‘faster horses,'” Henry Ford famously said. The lesson is clear: Your inner muse is a more reliable source of information than all the market surveys you can afford.
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.
One of the requirements for project success is “Know what done is before you begin.” Even that may be too ambitious. At a minimum, you need to know what done is before you can delare “it is done.” In business applications “done” is decided by the business. IT may, at best, get to participate in the decision.
Moving “muscle work” to lower cost locations is good business. The US is not a low cost location for much of the muscle work. The point where local equals lowest cost keeps climbing up the chain of work complexity. This wasn’t invented within the past decade . . . or even within the last century.
Finally, we keep having to learn that big things are very hard to make work well. Chrysler and GM are the latest demonstrations. The Federal Government is a long running reminder.
John Blair
When HP bought Compaq, all we heard was how desperately we needed the “synergism”, etc. that being a humoungous IT firm would bring. As the merger dance was reaching peak frenzy, FastCompany’s cover story was “Size Isn’t a Strategy”. Ah, but size appeals to man’s ego – bigger kingdoms make one appear important AND intelligent. That, it appears, is more important to many CEOs than being successful.
Hope all is well and that your webinars are successful. Sounds like a great approach.
My thoughts on the globalization trends, look at it, as much political as it is economic. Incentives have been made by the US Government to Globalize. I think political stability is as important as economic stability. I don’t think we have to worry about China as we did in the past and for that matter India. They are both dependent on us to some degree and don’t want to be put in a situation that we cut them off economically. As long as we don’t loose the ability to make things ourselves we can always cut them off as leverage. In many cases India and China are using our designs and tools to make the things we buy. It is not that hard to screw things together even if it costs more.
Your win lose statements make me think that the project did not have the correct goals. Use and acceptance rate seems to be the criteria for success. It is almost inmaterial what the specs are. I think this is why Agile development is becoming more prevalent for internal development. Find something that really works.
Regards,
One of the major advantages of internal IT development is that you have actual users, not projected ones. So in the successful projects of my experience, we worked with 2 or 3 end-users from the beginning — lots of mock-up scrreens, partial functionology, detailed examination of use (standing over the shoulder for an entire run, for instance). The result may not have been ideal in some theoretical sense, but it was actually used by the actual user.