ITSM India Podcast


Monday, 23 September 2013

Can ITSM Help to Organize Events Better? A Case Study

As a practitioner of IT Service Management, I am often questioned on the relevance of ITIL® beyond IT, and here is a classic example of my experience .

Recently, I had the experience of attending the Edinburgh International Science Festival at Bangalore and it was quite an eye opener. The event organizers had offered tickets online through a couple of websites, and also in person. I happened to sign up for this event on the last day and was left with only the option to book through We reached the venue to get our e-vouchers validated with credentials only to find a long queue at the entrance.
I was surprised to see that there were two Service Desk staff sitting idle as they were monitoring the tickets from other websites, while one person at ticketgenie was struggling to take care of a few hundred.
A simple option of Capacity Planning based on requests received could have handled the validation and issue of hard copy tickets much faster.
I did go and talk to the other folks working about the option of adding more counters to facilitate quick processing, but nobody seem to pay attention. This clearly demonstrated that there was no Incident Management process in place to resolve requests and yield better customer satisfaction.
After a heated debate, we did enter the premises to find that each activity or experiment had a specific time slot to be adhered and booked in person. Each slot could accommodate only specific number of people for the 35- 40 minute interval. This meant that parents had to do the standing on the queues while children would go on their own to watch the experiments and science shows. So the fun of parent and child watching and working together on robotics, electronics, light and sound experiments was totally missed. This demonstrated absence of understanding customer requirements and expectations which is the fundamental prerequisite of hosting a Service Desk.
One striking difference in the whole episode was the food service (Chinese, Indian, Continental, Asian), which had provisions in plenty to accommodate the rise in demand with ease. This confirmed that good business practice was driving things from the front (with the customer in mind) . It was evident that Demand Management process had been well ingrained to facilitate business outcomes.
As expected, a monsoon played the spoilsport and had the last laugh with a heavy downpour. People were forced to stick to indoor events, and then persistent rain caused a total power outage. It was shocking (pun intended) to note that the backup generator did not start as expected which means neither IT Service Continuity nor business continuity plan were in place. The rest of the experiments and shows had to be suspended indefinitely as there was no target resolution. I wondered to myself whether, if they had understood the principles of Problem Management or Knowledge Management, they could have have effectively handled these issues based on previous experiences and best practices.
I hope that these aspects would at least be considered in alignment with ITSM during the next event to make it a rewarding and memorable customer experience.

This post was published originally on Sep 18 at HDIConnect

ISO 27001:2005 - 10 Lessons Learnt from the Journey!

I have had my share of consulting/implementing and auditing experience on a few of the ISO standards and to me ISO27001 has been the most difficult and significant learning experience.
As I talk about the information security standard ISO27001:2005, the 2013 version is due sometime later, but the final draft suggests it is going to remain pretty much intact with easy integration with other management standards.
Here are my 10 lessons learnt during my journey towards driving ISO27001 certification at various organizations worldwide.

Basis:  Service provider has 2 categories of project: type a) managed projects, and type b) resource augmentation projects, to deliver goods/services to customers.
  1. Scope & Exclusions
    Though scope is a common aspect of all ISO standards, I would caution to explicitly mention exclusions.  Some of the common functional groups might not be willing to participate directly or indirectly in audits and it is imperative to have them cleared prior to stage 1 audit. 
  2. SOA
    With scope being finalized, the statement of applicability needs to be run with all project teams and functional stakeholders to qualify applicability of annex controls and justify with reason of exclusion.  I have seen this to be an iterative exercise and until everybody understands the rationale, the whole exercise becomes futile.
  3. Risk assessment & risk methodology
    I have seen most organizations have some standard risk management framework and templates  handy for the projects or at business unit level, however the support functional risk assessment is not available.  It would be imperative to take stock of how risk is managed at support function as their lapse would affect the outcome of your certification.
  4. Security plans
    This is the trickiest of documents from practicability standpoint. For example, managed projects would need to have a robust security plan considering the fact of meeting contractual requirements and SLAs. For resource augmentation projects, it would be a choice to make a security plan adhering to your service provider organization and spell out clearly to third party/client about non availability of resource means, SLAs cannot be met.  This has to be documented clearly and approved at the memorandum of understanding (MoU) between 2 parties.
  5. Security controls for offshore and onsite resources
    Today most organizations have employees work at client locations (onsite) and also deliver work from offshore (remote) locations.  Be clear on the scope of your ISO27001 certification including locations. E.g., if you only have offshore locations in scope, but all resources for both onsite/offshore covered, onsite security controls would still be applicable and needs to be demonstrated for compliance.
  6. Business continuity plan (BCP)
    Identifying the criticality of service and contractual need will ascertain the business continuity plan at your center or business unit level.  Is it not applicable for projects?  I would say it depends mostly on how you have signed contract with your client or your account teams before arriving at BCP for projects.
  7. Effectiveness measurement
    This is one of the fundamental differentiators to show senior management why institutionalizing ISMS yields us real benefits.  With regular review of corrective and preventive actions, it gives all involved the urge to follow and adhere to security controls.
  8. Training, awareness and education
    This is an ongoing exercise and there needs to be a specific focus on enablement and readiness for all regular and contract workforce (CWF) working in organizations. Most importantly the process of onboarding and exit checklist must be specific to projects of both categories.
  9. Cooperation and collaboration
    With 11 domains and 133 controls to be complied, it is lot of hard work from all project and functional teams to cooperate and collaborate and meet SOA requirements.  Mutual respect and willingness to go the extra mile would be essential to go over brooding issues and stalemates.
  10. ISMS standard has to become part of culture
    All these steps and controls are aimed to create that culture of information security among all the teams.  This has to be adopted in true spirit to inculcate the culture and provide the clients and customers the required confidence and trust in all dealings.
These are some of the aspects that I have seen to be critical, to get your certification and ISMS institutionalization a repeatable success

This post was published earlier on July 22nd at ITSM Portal