Level 2 in a Level 4 World - Much Simpler than Possible
In this context, revisiting the classical question that has been entertained
internationally by scholars of project management — why do IT projects fail?
The answer is — because we treat them as IT projects. The classical "organizing"
project management archetype, even with new terminology injected to position modern
lingo, will not achieve success if the people you are playing with will not be
organized on your terms.
|
IT projects, per se, are not a problem. There are many examples of highly
successful IT implementations where the information technology is simply applied
to existing business processes. Such "automation", if you will, does not feature,
nor require, an open system governance network. This type of IT initiative would
be classified in the DBM as either Level 3, if the tool requires development
to map onto the existing business processes, or Level 2 if the tool
can be calibrated to suit within existing tailoring parameters. Depending on which
Level it is, the performance of the project will achieve the expectation set earlier
for that level.[4]
|
|
"The mark of a good theory is that it can explain, in a coherent way, all or
at least most of the relevant facts and is not contradicted by any of them. A
bad theory is one that is contradicted by some of the relevant facts. An outrageous
theory would be one that is contradicted by virtually all the relevant facts."
-David Ray Griffin
|
|
The IT controversy that spawned the question: "Why do IT Projects Fail?" is
in reference to enterprise transformational initiatives that result from an infusion
of IT technology. The IT is merely a catalyst for the greater impact of testing
the legitimization of the enterprise in its existing terms of reference.
|
This is enterprise Darwinism, survival of the fittest. With its external determinacies,
IT based enterprise transformations are nothing short of a recalibration of the
utility of the enterprise within its external context. Stakeholders of the enterprise
face a choice. They can embrace the external determinacies, often referred to
as an end-user base, and thereby allow the dynamic baselines of the project to
remain fluid at the expense of yielding a product. When this option is followed,
as is often the case in the initial and euphoric phases of the implementation,
the instability of the dynamic baseline eventually depletes resources, leading
to a lack of stakeholder confidence and ultimately a frustration of the implementation.
The result is Project and contract cancellations or "failures".[5]
|
|
The Streetlight Effect
A policeman sees a drunken man searching for something under a streetlight and asks what the drunk has lost. He says he lost his keys and they both look under the streetlight together. After a few minutes the policeman asks if he is sure he lost them here, and the drunk replies, no, and that he lost them in the park. The policeman asks why he is searching here, and the drunk replies, "this is where the light is."
-David H. Freedman
|
|
Opting for the alternative, shutting out the external determinacies to achieve
a timely and cost effective product, amounts to disregarding the "sands of change".
This is a denial of the changing world around you — the buggy whip syndrome.
Here, you will yield a product that no one will use and you will have fortified
your organizations position to obsolescence!
With this in mind, here is how IT enterprise transformations roll out. We start
with the former — embrace the outside world in a bid to ingratiate ourselves.
Meanwhile we apply the Level 2 model. Though it is not representative of what
we are doing, it sets up a hypothesis that meets stakeholders' ambitions and lets
us "get off the ground." This is like "street light effect" per the insert.
The conceptually reduced plan is simpler than possible. Level 2-esque
performance expectations are nailed down and performance dashboards are deployed
to capture the result.
Meanwhile the essence of the undertaking — the requirement to recalibrate
the utility of the business line within its larger external determinacies does
not appear on the radar screen. This is, in a nutshell, why IT projects fail.
4. David Ray
Giffin, The Hidden History of 9/11, The Internet archive of the CBC, 2006.
5. David H. Freedman, The Streetlight Effect, Discover
magazine, 2010.
|
Governance
versus Management 
