You are the expert, you must have done this a million times before.

In I.T the common man's understanding is that the expert knows how to do things that the common man does not. The expert is paid for activating and supplying the knowledge bank that solves certain problems and/or delivers certain features. There is certainly some truth is this.

But firmer reality is, the expert often does not know how to do something before she begins; she begins and the way forward opens up in front of her.

As she progresses, the way forward continues to incrementally display itself to her professional eyes.

Exploring our Thinking About Working Together

One in a series on "Thinking as a Software Engineering Challenge".

Consider the proposition that I.T. projects fail when 'Our Thinking about Working Together' is not sufficiently Understood or Engineered.

Skill-sets can be under-resourced; technologies can be poorly chosen; technical issues can be left unresolved; deployment challenges can be critical; budgetary constraints can be insurmountable; timelines can break-down. Many reasons at the level of technology and project management can provide the politically acceptable rationale for abandonment of investment.

Charging by the Question

In my I.T. work for many years I have engaged my creative process into client work in return for payment by the hour. In a sense this never works. Creativity happens outside of time. It spans time but time is not a true measure of its effort or value.

Value and Recognition in I.T.

In I.T, there are two closely related concepts, or metrics, that determine:

a. the willingness of client to continue financing the practitioner and
b. the willingness of the practitioner to continue supporting client needs.

From the perspective of the client the metric is "Value", and that for sure is also a highly considered aspect in the mind of the practitioner, as they must facilitate that value as part of the energy system that drives the creation.

Whose Job is That?

Thinking in Organisational I.T. Systems.

Any system in I.T. is predicated on a particular way of thinking about needs and the way those needs are best met.

Thinking is huge, and unformed and goes off in lateral directions, especially when many people are involved together. The task in I.T. is to capture and constrain thinking towards a deliverable system.

What value people in an I.T. system?

The people building an I.T. System are not outside that system.

The people building an I.T. System are not separate to that system.

The people building an I.T. System enable and constrain that system.

The relationships between those people building an I.T. system are also reflected in the capabilities and limitations of the system.

What value this blog?

This blog is an ongoing documentation of one professional's perspective.

We each bring our own unique perspective to the table, as we work together on I.T projects whether they be Drupal or otherwise.

What value each other?

We can think of an I.T. project as a journey.

Some projects are undertaken by one person, but that is the minority. Most projects need a collection of people to work together towards a shared idea of outcome. Even if the collection of people is constituted by a single developer and a single person as client that is in some sense a melding of disparate perception into a common journey.

When the project is carried forward by multiple people spanning one or more organisations the melding of perspective is a significant task in itself.

Is I.T about technology?

The thinking that leads people to assume that I.T. is about technology is of course unfortunately embedded in its own naming.

Technology is just one aspect of the multi-levelled process that drives the retention and delivery of information, knowledge, communication and process via computing systems.

The thinking of the people who design and build the systems, as well as the thinking of the people who use such systems are an intricate part of I.T.

Without the thinking the technology is impotent.

With the thinking the technology is given life.

What about a product? Is it of value? Does the value depend on its completion?

In my memory of 23 years in IT I cannot find an instance when a product became complete.

It is just that budgets are terminated or thinking of human drivers turns in other directions.

A product may be frozen when budget for the underlying process dries up and such process is thus abandoned. At that point of abandonment of necessary process, the product may continue its useful life for a time. But that does not imply completion.

All IT products are subject to improvement to the extent that thinking is aligned in the direction of further entering into process.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer