To do that effectively would require some understanding of these, however. In
particular, "cloud" has several meanings, some of which might make perfect
sense, and some of which might be dropped on the floor.
Ideally, yes. However, I contend that on the C-level with the size of
corporations we are talking about, issues become very abstract, and
management reads the abstract of reports, much like the Joint Chiefs
of Staff don't deal with the After Action Reports of a platoon, but
with the state of the whole theater of engagement. Those require
different skills and a different thinking (more big picture vs
details).
I'd expect the CEO to know and care at least about management, and hopefully
marketing and the company itself.
Absolutely. But it's the big picture, rather than the performance of a
single salesperson / developer.
Yet Google seems to manage with less than half the, erm, org-chart-depth that
Microsoft has. Clearly, there's massive room for improvement.
That's neither here nor there. You can debate endlessly how much
bureaucracy is needed, but it is quite clear that some bureaucracy is
needed.
This really doesn't. How does _bureaucracy_ ensure that more than, say, the
apprenticeship you described in the steel industry?
Because it enforces a uniformity of process. An apprenticeship in a
trade teaches said *trade*, but not management skills, or sales, or a
host of other things that are necessary to run a company.
Nothing's stopping you from switching contractors, or switching to a different
approach entirely -- there's more than one way to get power.
That has been decided before the first contractor is hired. Consider
the cost of even planning a power plant or a skyscraper. That's a lot
of sunk cost if you switch horses mid race.
Then what's the point of the "final approval" that you're waiting for?
When the plans for the product are agreed upon. A project can fail
before that, but not after the bid for contracts has ended, at least
not easily, and certainly not cheap.
That seems to be true almost by definition, but major improvements in IT do
affect non-IT companies. Shipping companies and airlines benefit from improved
ways to find routes, track packages or flights, and adapt quickly to changing
conditions (like weather). Supermarkets and retail outlets benefit from
improved ways to manage inventory -- to track it, anticipate spikes and
problems, and react to things like a late shipment.
Absolutely. The microprocessor revolution *was* a revolution, and
VisiCalc changed the way the game was played, just as DTP reduced the
cost, and made it easier, to create marketing brochures, for example.
It may be that all the important problems in these areas are solved, but
again, it seems risky to assume that.
At this point, change is more incremental and evolutionary, than
revolutionary. Of course, something can change that, but it's not
something I'd bet on (or against) to happen, and I certainly wouldn't
base a business plan off of that.
The point of this example is that you don't necessarily know up front what the
"requirements" are. It's not required that you be able to perform such
analysis, and it might not have been feasible when the original program was
written, but it's certainly valuable today.
Most large IT projects fail because requirements are unclear, or
change. XP, agile, and scrum want to change that, but that doesn't
necessarily happen.
You have to keep in mind that the problem domain is well understood by
the stakeholders, and well enough to formulate processes, and to run a
business. Ancillaries might change (like how accounting standards, if,
how, and when payroll taxes are collected, and so on), but in general,
these sorts of problems can be anticipated, and planned against. It's
not rare that, say, GM would switch health insurance providers, or had
to deal with different health insurance providers, so you keep your
software flexible enough to manage these changes. Production costs can
change, as can the parts required to produce, but, to put it bluntly,
only the variables that you plug into the equations to know how many X
you need to produce Y change.
Determining what a production run would cost, and what you need to
deal with isn't that difficult (it comes down to multiplying matrices
with each other, more or less), and thus you know how many units you
can sell at which price.
Computers make this easier, but they didn't change the essentials of
business economics.
Similar with an airline that has to deal with weather events: Weather
always existed, and pilots deal with it. Routing is, oddly enough,
less important: Air traffic travels in pre-determined traffic lanes,
to minimize the risk, and to minimize the required personnel to
control this traffic.
And while these can change (IIRC, New York is reworking its approach
and departure vectors for the NY airports), it takes a long time to
arrive, and then implement these changes. There's plenty of time to
adjust, and it's not, in a sense, business critical for United
Airlines from where the planes reach their destination. What is
important is that more planes can put into the same space without
increasing the risk, but that's not something new, either (TWA and
PanAm were locked in a furious war over trans-Atlantic routes after
WW2, for example).
Where things get absolutely tricky, is when you have to integrate
business processes of different corporations, after a merger or an
acquisition, but that's something that takes years, too (like Google's
acquisition of FeedBurner or YouTube, or AOL buying TimeWarner, or
Thyssen and Krupp merging).
--
Phillip Gawlowski
Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.
