Ok, I confess. To become an IT professional was not my first choice. In fact I have a degree in Forestry, Land and Water Management. However, in the 1990’s the opportunities to get a job in this area were scarce and I moved towards the domain of Information Technology. Maybe this explains why I look from a somewhat different angle to IT problems than many of our colleagues do.
For example the problem of failing IT projects. The common opinion with regard to IT projects seems to be that they always take too much time, never deliver what has been promised, exceed their budgets and excel in unexpected problems. In contrast, it is believed that projects in other trades, like engineering, construction and building, deliver mostly in time, according to specifications and within budget. The overall image of IT is one of an immature “industry”.
Let’s have a closer look at an example in the area of forestry and wildlife management. The last ten years or so, many wildlife crossings have been built in Europe and in the United States. These crossings allow animals to cross men-made barriers, like roads and railways, in a safe way. The idea is to rejoin natural habitats of animals and to support natural animal migration.
Wildlife crossings usually are shaped as tunnels, viaducts or corridors and I have not yet heard of any big failures in their architecture, engineering or construction. However, the effects of these wildlife crossings are not always cheered by everyone. This is because not everyone likes to have deer, bears, swines, wolves or foxes in their direct environment. Apart from that, in specific circumstances an enhanced animal migration may lead towards a faster spread of animal diseases, although the health of wildlife in general will improve.
But in the area of forestry and wildlife management no one will blame the constructors or builders of a wildlife crossing for ruined crops or damaged gardens. The responsibilities of the ecologists that promoted the idea, the politicians who decided that they wanted the crossing and the constructors of the infrastructure are separated in our judgement.
The same is true in traffic management. When a bridge is successfully built but the newly created route doesn’t reduce the traffic jams, no one will blame the bridge builder. In non-IT projects we distinguish between the initial idea (wildlife management, traffic planning), the decision making (management, politics), the actual construction (construction & engineering companies) and the usage (implementation).
However, regarding projects in the area of Information Technology we lump all this together and, in whatever part problems arise, we blame “IT”. When something undesirable happens after the implementation of an IT infrastructure or a new application, for example an employee who misuses an Internet connection, it is very likely that “IT” is blamed and is pressed to find a solution.Initiative, decision, construction/engineering and usage are all seen as within responsibility of the IT project.
Now “IT” has become mature and is part of everyday’s life, I suggest that we differentiate between initiative, decision, construction and implementation.
In addition, in case something goes wrong in one of these aspects, we clearly define what went wrong:
- Was it a bad idea to start this project? Were the engineering and construction OK combined with a successful implementation, but were the results of the new situation not as expected? (In analogy: The wildlife crossing was realized, but isn’t used even by the smallest mouse or hedgehog);
- Was it a bad decision to start the project? (In analogy: The wildlife crossing is used, but the impact is undesirable) ;
- Has something gone wrong in the engineering or construction within the project? (In analogy: The wildlife crossing couldn’t be built, or is ruined by the first two deers);
- Is it the implementation that went wrong? (In analogy: Shortly after finishing the project, the road for which the crossing was made has been closed).
It is the responsibility of advisors in generic and specific areas to point into directions that, all effects included, are optimal. It is the responsibility of decision makers to decide upon initiatives and projects. Architects, engineers and constructors are responsible for the design and construction of the solution within the given scope and according to the described requirements. After the delivery of the project’s results, the acceptance and implementation for use belongs to the responsibilities of the receiving organization.
In no other discipline than IT all these roles and responsibilities are seen as belonging to that discipline. So I suggest that we stop doing this in IT as soon as possible. Yes, to develop a business strategy in 2013, you’ll need to have quite some knowledge about IT, as you’ll need knowledge about transport and transportations, about environmental situations, about workers positions etc. Yes, to take an educated decision about your organization’s future you’ll have to know something about IT, as you also need to know about safety regulations, logistics etc. And yes, when your organization is going to work in another way, probably there will be quite some IT-related subjects in this change. “Having an IT component” does not automatically mean “being the responsibility of IT projects, or IT people”. Most of the world is using “IT” intensively, so it is part of everyone’s job to understand the IT parts well to the level that his responsibility requires.
“IT people” are responsible for the architecture, engineering and construction of the technology used.
When we differentiate in the responsibilities in the so-called “failed IT projects”, many of those projects will turn out not to have failed on IT at all!
By ing Bob Schat
Principal Solution Architect
Order your copy now or view the sample file on our website. (NB: Dutch title!)
Wildlife crossing Autoroute A5, Fôret de Chateauvillain, France. Source: APRR
Wildlife crossing B38, Odenwald, Birkenau, Germany. Source: Havasiwf.org
Wildlife crossing A1, Hoge Veluwe, de Borkeld, The Netherlands. Source: Zwarts en Jansma architecten