Managing Transition: 5 Constraints in getting from Dev (Creation) to Ops (Consumption)

This is probably the area we deal with most often in our engagements and is worth taking a moment topic over the topic generally.

It is also an area which can make me enter rant mode.

Q1: Why do so many organisations make the issues of transition a technology only problem?

A1: Transition is an enterprise problem.

How well you transition is the measure of how agile you really are

Q2: Why do so many organisations believe you transition with nothing/limited in place and a a silver bullet solution can be bought?

A2: There is no silver bullet solution. Just hard work to create the correct environments, components and ways of working

Q3: Why do so many organisations want to automate sh*t?

A3: What do we call fast sh*t? Diarrhoea Walk before you run. Do not automate until you understand.

Rant over.

What do MacKayser mean by transition?

• Transition is the method for moving what has been developed (created) into what can be bought (consumed) by your customer.

• The execution of innovation

What is involved with transition?

1. The non technology elements associated with business change

2. The technology elements

What are the 5 Constraints?

1. The business change and technical change are unaligned (DEMAND)

2. There are usually no or limited reusable data sets, test scripts or suitable environments (AUTOMATION)

3. The functional and user requirements are challenged leading to scope creep, unplanned change and delays (DEMAND, REQUIREMENTS & TESTING)

4. Time constraints and business pressures lead to poor quality product being introduced to operational services with the obvious consequences (EMPOWERMENT)

5. Technical change is always last and there is usually no definition of what complete is. (VALIDATION)

How MacKayser manages and controls transition

Remember our focus is on Revenue Generating Services (RGS).

All agreed demand has been approved the RGS owner.

A) We mange TRANSITION from the DEFINE stage (DEMAND)

Within DEFINE:

* all the requirements to all layers are written and agreed by all parties. * all test are identified for all layers

* all dependencies are defined and understood for all layers

B) We extend the operational concepts of Service Management across all stages as well as monitoring, reporting & analytics, security and governance & compliance. At each stage the accepting teams are empowered to say not yet if the quality of handover is not of the agreed standard. (EMPOWERMENT)

C) We take a risk based approach to technical TRANSITION and technical TRANSITION only starts when technical package is complete from CREATE phase. (VALIDATION)

D) All the releases will be 'ZERO DEFECT'. This does not mean they are perfect BUT it does mean all identified tests required to be run have passed. (DEMAND AND TESTING)

E) We understand, define then automate wherever possible. This includes the TRANSITION phase for technical, security and compliance components (AUTOMATION)

F) The transition is only complete when both the technical and related business elements have been fully validated. (VALIDATION)

None of the above comes without hard work and we are willing to work with you to achieve your goals.

Remember you cannot automate thin air and you cannot repeat what is undefined or ill-defined.

If you would like more specific information or would like a follow up discussion to address your specific issues please email:

followup@mackayser.com