Maybe not perfect…but this is how I see the interaction between project and the support processes. There shouldn’t really be a conflict or issue… it is possible to align them neatly.

These days, most companies rely on IT and IT infrastructure to support part or all of their business. Therefore the need to fix major incidents is becoming more and more pressing, since companies tend to lose money when services are down.

Most companies also have change and release control in place, which balances stability vs flexibility in their organisation.

Emrgency changes and the emergency change process (ECP) are then what reconciles the urgent need for an immediate fix (read change) versus the control and management required for normal change.

In an outsourced environment there are some more parameters that will complicate the matter. Who will authorise the emergency change? how is it charged?

I’ve seen several companies that have defined the ECP as ‘fix now, do all change steps later’. This (almost) always is a certain path to disaster. Furthermore there is no framework or best practice that tells you to do this… And you are opening the door for a specialist to change the IT environment whenever he feels like it, (ab)using the Emergency change as the means to get things done.

So, how to cope with this?
The easiest way to deal with this is formalize the Emergency change Process for each critical service or system. This ECP will list the criteria to invoke it, who will be on the crisis team (including a contact list with backup/escalation), and what the steps to be taken are (eg. minimal testing requirements). Defining these is usually done with the release of a new service or system.
The biggest advantage is that there is little room for discussion…The rules are set (and agreed with the business).

After the change has been implemented, a formal handover to the CAB of the change needs to be done, in order to ensure that:
– Everyone is aware of what exactly was changed
– What the impact is of the implemented change on other systems and/or services
– what the impact is of the implemented change on other ongoing changes/releases
– we know what could have been done to avoid this (lessons learned)
– make sure we know what the current version/state of the production environment is
– asses the need for the emergency change

I also advice to launch a problem (after the implementation) to make sure the RCA of the incident has really been handled.

I am currently working on a wooden table for my terrace. I have laid my terrace (myself) last summer and already enjoyed it. However it became quickly clear that the shabby table we had was not suited for the new terrace.

So Sonja (my wife) picked a table (in one of those fancy magazines) and i agreed to make it during the winter. Of course she didn’t go for a simple square table, but chose a round table on a central stand.

step 1 : draw the table. (plan will be uploaded at a later date)

step 2: decide on the wood

the table needs to stand outside all year, so has to be in a good quality, wheater resistant wood. Teak was my first choice but turned out to be too expensive.

Instead I chose Afzelia bipindensis . It is african and higly resistant to outside circumstances. (and less expensive as teak)

to be continued…(pictures, hands on tips, etc…)