Ken Turbitt Blog
Aidan Lawes Blog
Paul Gostick Blog
Dr Jenny Dugmore Blog
Shirley Lacy Blog
Alim Ozcan Blog
Juan Jimenez Blog
Ian Clayton Blog
Nas Ozcan Blog
Aidan Mills Blog

The General Data Protection Regulation Benchmarking Survey
How are organisations facing the challenge of complying with the most radical overhaul of data protection laws in a generation?...

Ten Strategic Technology Trends for Government
Technologies that enable new service models for digital government must be at the top of the list for government organizations as they prioritize technology investments...


The Robots are Coming: Are CEOs Ready for the Era of Automation?
CEOs agree that robotics is going to make their companies more efficient, with 94% of those who've already adopted robotics saying that it's increased productivity in their business...


The 2015 Chief Digital Officer Study
More companies are appointing a Chief Digital Officer to join their C-suite - but are they doing it quickly enough?...


18th Annual Global CEO Survey
The United States has overtaken China as top target for growth for the first time in five years...

5 August 2010 | Aidan Lawes Blog
Send to a colleague | Add to MY ITP

Harnessing the Lifecycle
This week Aidan looks at why the lifecycle approach could and should be applied to training development...

The structure of the current ITIL publications is based on the service lifecycle – Strategy, Design, Transition, Operation and Continual Improvement. While not perfect, it’s not a bad model to work with as a development/operational cycle. And it applies to more than just services – products could equally follow the same cycle. Inherent within the lifecycle approach are a whole series of disciplines that ought to be standard practice in any arena – but sadly, all-too-frequently, aren’t.

One area to which the lifecycle approach could - and should – be applied is training. A training organization looks at its marketplace, competences, strategic objectives, etc and decides whether or not they wish to deliver offerings in a particular segment. Business cases will be built and discussed, risk analyses will be performed, resource requirements and availability will be assessed, and, possibly after some refinement of the plan, a decision will be made to proceed. All these aspects are articulated in the Strategy book.

The next step is the Design phase, wherein each individual “course” is designed. This involves working out the overall objectives and timescales, and decomposing these into manageable units for delivery – each of which will have its own objectives and timings. The optimum approach for achieving the relevant learning outcome will be decided. Lectures, discussion sessions, group and individual exercises, self-learning, experiential packages – all can play a part in defining the best solution for the situation. This design can be captured and encapsulated in what is commonly referred to as the session plans. Of course, if we choose a particular method of delivery for one or more sessions we will have to consider what resources are required and whether we can guarantee that they will be available. This may mean new technology, extra tutors, additional rooms, etc all have to be planned for.

Once the design is fixed we can start to Transition into live running. We’ll plan when we intend to run the first event, start the actual development (build), publicise it and train those who need it (tutors to deliver, sales staff to sell places, etc), adjust the infrastructure (procure kit, update support systems, etc) and when ready, hand-over a “package” to be delivered to eager-to-learn delegates.

Hopefully we can then deliver multiple instances of the event (Operations) to hordes of people, where we realize the benefits of venturing into this particular area by returning a healthy profit to the business.

Feedback is captured from the delegates and from those delivering events in order to assess how effective the course is and if necessary adjustments can be made (Continual Improvement). The improvements may simply require tweaking one or two slides or an exercise (operations); it may involve re-ordering sessions or changing delivery methods (design); in extreme cases, the results of running a number of events may lead to a strategic rethink.

Throughout the cycle, the importance of documentation and recording is stressed. If we don’t have baselines and definitions and keep records of changes made, how can we make meaningful comparisons or achieve any sort of consistency?

With the ITIL courses – which are teaching the philosophy of the lifecycle approach! – It isn’t always obvious that this is the way organizations develop their offerings.

Firstly, the exams and associated courses have all been developed centrally, without any obvious evidence that these are the right events and qualifications for the marketplace. Training organizations sometimes appear to be developing offerings merely because they exist, rather than because their customers are demanding them. They blindly produce “a course” matching the exam spec, effectively teaching the delegates to pass the test rather than educating them properly in the subject matter. In my experience, plenty of customers are saying that these courses are not what they need. Each training organization really should be looking at their customers’ needs and devising learning programmes to meet them. This may mean a learning event that is different in timing, content, focus, etc from the “official” syllabus. But that doesn’t make it ineligible for accreditation and in the fullness of time may mean the official courses are redefined.

Secondly, for some organizations, course design seems to consist of knocking up a set of slides containing bullet points and diagrams taken directly from the books and driven entirely by the words that are in the syllabus rather than looking at the overall objective of the event, decomposing it into manageable units and thinking about how best to cover each topic. As for documenting the design in session plans, for some providers this seems to be anathema – much better to keep it all in one person’s head!

Thirdly, while most providers do have feedback/review processes and do make improvements, often these are only performed at the operational level – no one goes back to the design document and changes it. Hence, when an event is audited, there is usually an enormous gulf between the registered design and the actual delivery. This isn’t a recipe for success.

If the ITIL approach represents good practice, then why don’t organizations that wish to teach it apply more of its principles to themselves?

Any feedback and comments are always welcome!!

(ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.)

Aidan Lawes Email to a colleague | Add to MY ITP

terms & conditions