The Future of IT – 01/04 Introduction

Few weeks ago, when I published the article “The Future of IT”, I was planning to write something about technology.

But, as most bookworms turned practitioners, I know that a white page is tempting.

Most writings about the future are actually the typical side-effect of an attempt to find order within chaos- moreover, when it is an unknown chaos that you are trying to describe.

This article is published in four parts (no more than 1000 words each).

Of course, I tried to keep it readable- no more than 150 to 250 words per section.

This is the first, introductory article.

I will start with the concept of forecasting, then the logic of building forecasting models, to finally land on the key issues: the experience I used to develop the forecasting framework, and the conceptual model.

Forecasting the past
Building models
Beyond technology
A cultural approach
Conclusions: IT systems design


Forecasting the past

An American management consultant colleague, when I asked him why a certain research company always assessed at 90% or more potential markets or technological evolutions, told me: because they are well known for forecasting the past.

The secret? Have a large network, get a “preview” from major players before it is on the market, and then, ops!, publish a “95% probable” forecast.

A violation of the ethics of confidential information management? No, a win-win.

The major players can use an influential platform to build market demand on what they are ready to deliver, while the research company can show to be almost always the most reliable forecaster.

But also after each economic crisis, talking heads struggle to deliver a coherent explanation.

While trying to avoid the blame of seemingly lacking the same level of absolute understanding and insight when it was most needed- to avoid the crisis.

to the table of contents


Building models

In IT, it is a long story- I remember discussions about a planning model called COCOMO.

But since we started studying “probability”, “chances”, and so on, it is really tempting: down with the complexity of human relationships, let’s just crunch some numbers.

And before then? Well, we had crystal balls.

The idea? Enter few numbers and parameters on what you want to do, and a model will deliver the budget, effort, and so on.

My challenge? I first received it in early 1990s, and challenged its logic.

To prove my challenge, I went to the source- and looked at the “demographics” of the COCOMO model- the mix of technologies, projects, and so on.

Guess what? The model was built on a base of projects that did represent technologies, costs, methods, etc, common decades before (the author eventually produced an update).

It is not just quantitative forecasting (i.e. man/days, dollars, etc), as qualitative forecasts are even more linked to current reality.

Let’s say: you were in the early 1960s- would you have guessed that something as simple as the possibility of integrated circuits with low voltage and power consumption (and, therefore, heat dissipation) could produce our current computer-in-a-pocket technology?

to the table of contents


Beyond technology

How do you avoid forecasting the past? By trying to identify what is immanent, linked to the existence of something, and not to its current expression.

In my case, I came to information technology through an interest in knowledge transmission, i.e. studying the brain and cultural anthropology, before punching my first Fortran IV (a scientific programming language) program.

I will skip all the other learning steps (just: I sold my first computer program while still in high school).

Let’s just say that, before 1990, I had been selling or using professionally (including programming) the following hardware: punched card computers,IBM 360/370 mainframes, Apple II and Lisa, various home computers, Digital VAX and MicroVAX, IBM S/36 and S/38, AT&T 3B, desktop and “luggable” (10kg!) Personal Computers, a kind of private pre-Internet based in The Netherlands, used to exchange messages between companies.

The reason for all those acronyms? Go on wikipedia, and search- you will see that most of those bits and pieces had less computing power than a current Intel-based NetBook.

Despite what some gurus write, I still believe that IT is a supporting function.

The use of IT should be embedded in processes, i.e. invisible. I think that too many organizations mistake the availability of technology with the need to use it all.

If I were to focus only of my “official” IT career (from 1986), I would say: I always found some common elements, linked more to the way the organization was interacting with technology, than technology itself.

to the table of contents


A cultural approach

In this section, I will simply guide you through a streamlined version of the model that I use to assess the corporate culture of a new customer requiring support for IT or organizational needs.

The model is more complex, but this is the outline, as represented in the table:

structure
any IT system is associated with the way an organization is designed to work; yes, mission, strategy, and all the mumbo-jumbo that we consultants love to change every two years to keep selling services to our customers
language
build an organization (not necessarily a business!), and soon you will find somebody creating a way to communicate “our values”- it is what I call the “organizational (official) language”
code
well, the language is fine; but to work, the formal organization is often not enough, and “shortcuts” are developed, while waiting until the structure is adapted; but, as this is often unofficial, a parallel organization with its own communication code is created
context
so far, structure+language+code were looking only internally- but an organization is supposedly built to interact with its environment: call it stakeholders, customers, etc
action
there are some pre-defined actions, but, frankly, I try to see actions after the context, as sometimes there is no real logic within actions, except that, in the past, some stakeholders required those actions
results
the interaction between all these elements produce some (more or less) desirable results

In the best scenario, results are monitored to influence the evolution of the organization.

to the table of contents


Conclusions: IT Systems design

Let me state again the consequences of my small “model”: in the best scenario, results are monitored to influence the evolution of the structure.

In the worst case, the structure evolves because somebody decides to do so.

In the real world… organizations constantly shift between these two extremes.

And where does ICT come into the picture?

If you read the previous section, you probably saw something: I talked about organizational needs, but I do not see the organization as one of the steps.

My view? All the six elements belong to the organization.

Both the work-force and the external “stakeholders” will change, demanding a level of interaction that will challenge existing roles.

In the 1990s, for a customer I designed a model to “migrate” its culture to adapt to new technologies.

My concept: IT systems serve an organization, and an organization does not exist in a vacuum.

to the table of contents

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s