The ‘IS’ and ‘IS-NOT’ of ITIL – A Cursory Look @ Some Popular Misconceptions

ITIL, formally an acronym for Information Technology Infrastructure Library, is a set of detailed practices for IT Service Management (ITSM) that focuses on aligning IT services with the needs of the business.
ITIL is a best practice framework and is non-prescriptive.  It outlines guidelines for tasks and activities from a best practice perspective associated with roles and responsibilities. Though descriptive, being a non-prescriptive framework, it gives flexibility of adoption suited to Business needs of adopting Organization.
Though ITIL initially evolved for the IT Industry in the 1980’s, over the years, it has grown to a greater comprehensive framework outlining a lifecycle approach to services. The latest publication, the 2011 version, named ITIL ® 2011. ITIL can be adopted by not just the IT world of service providers, but, the non-IT Service providers too.
With a gist of best part of ITIL outlined, say as in above, there have been certain popular misconceptions that have plagued its usage in the industry. listed below are some of the popular misconceptions and the real understanding behind ITIL. We will endeavor to get you Part2 of some more misconceptions with the next in series of the blogs.

Misconception # 1: “ITIL applies to the ‘Operations and Support’ Domain of an IT Industry.”

Well, this conception is correct! But only in part.  Applicable to the part of ITIL service Lifecycle publication that outlines best practices for Service Operation Lifecycle where the intent is to, ‘Realize the value’ or value of service is experienced by the user community for the Services they have signed up for.
In essence, ITIL ® 2011 covers the entire life cycle of a Service/Solution/Product, right from its inception (aka, various synonyms existing – ‘kick-off,’ ‘initiation,’ ‘envision’) in the service strategy phase where ‘VALUE’ for the service is created.  The service strategy phase involves management of strategy, Portfolio, finance, demand and a customer experience function with purposes of establishing business relationship management to further customer collaboration and customer loyalty.
Having said so, ITIL is unlike project/program management where ITIL covers the entire gamut of solution from inception to not just deployment to production or production support, but, also, the solution’s warranty, thereby supporting the complete product lifecycle as an approach.
Busting the misconception here – ‘Practices such as Lean, Agile, DevOps can’t be complete without ITIL for a holistic solution involving SDLC plus warranty.’

Misconception # 2: “ITIL ‘IS-NOT’ applicability to development Teams.  Only applies to operations teams.”

Well, this conception can be true to an extent assuming the aspiration of service provider organizations’ is to be doing a routine ‘Application Development’ outlined in the popular SDLC approaches.  But, in today’s world of X-a-a-S, the industry is fast moving away from the traditional look at, ‘Products/Solutions’ offering ONLY, and expanding to explore a holistic approach to E2E (End-to-End) service offering for a better market segment capture and its market share.
What does this mean?
Key for the service provider organization is to perform, ‘Application Management’ & not just limit with, ‘Application Development.’
What’s the difference?
The management piece of application management also involves warranty support.  This is where the customer gains and would look to the E2E offering of service he would be interested in signing up.  The onus here on development Teams’,  ‘IS‘ to not just design and develop the functionality, but also cater to the needs of warranty for the product being developed, thereby delivering real VALUE to the customer leading to winning customer satisfaction backed by an additional element of customer loyalty.
How does all this relate to operations teams?
Development teams having designed and developed the product/solution, do a handover to the operations teams for its support.  It is here in this lifecycle phase of service operation that VALUE for the service is experienced by the user and helps ascertain service design meeting customer’s requirements.
Busting the misconception here – ‘ITIL states that best practice approach is for the service provider organization to provide services that meet the needs of the business. As such, development and operations teams are not two opposite ends of the ocean, but one leading to the other for a collective gain to both, customer and service provider organization.

Misconception # 3: “ITIL does not apply to IT engineering teams.  Applies only to support personnel. As such, doesn’t need exquisite skills.”

Oh yes!  Lets’ take this ON.
IT engineering teams most often in the IT Industry seem to be comprised of a combination of teams belonging to solution management (@ Strategy involving customer intimacy through envision and kick-off’) backed by project/program management, development, and Test.  The solution framework they employ most often would comprise of envisioning phase to test.  For deploy, they may most often either include Operations team or may not.
What would it involve concerning the below essentials for the solution to be delivered –

1. It includes certain decisions around Portfolio, Demand, Finance ably supported by a Management of Strategy?
   • When do we say Portfolio, portfolio encompassing pipeline of expected services to those already existing (or live) and retired?
   • Demand concerning pattern of business activity & study of user profiles?
   • Finance, regarding budgeting, account, and costing?
2. Involves solution design covering aspects?
   • A good service design that meets functionality, performance, resource, and capabilities?
   • Management Information Systems and the tool considerations are looked into?
   • Technology and management architecture – the how of it?
   • Relevant process designs
   • Measurement methods and metrics for a good reporting?
3. Development regarding build, test and deploy the solution
   • Requirements documentation outlining the High-level and Low-level design next is to start code and test.
   • Deployments involving Dev, Test, Prep-Prod and Prod environments?
   • Pending test considerations, a GO/No-GO to prod?

This is where, ITIL’s descriptive, though non-prescriptive recommendation stems and serves as guideline –

• For point # 1 : Guidelines are called out in the service strategy phase of ITIL. It talks about the 4Ps essential for an effective VALUE Creation for the solution on Perspectives, Position, Plan and Pattern.
• For point # 2 : Guidelines are called out in the service design Phase of ITIL. It talks about the 4Ps of service design encompassing Products, Partners, Process, and People. VALUE created in service Strategy would be preserved in the Service Design phase.
• For point # 3: Guidelines are called out in the service transition phase of ITIL. This phase talks about build, test and deploy and involves primary processes around change, release and configuration Management. It talks about early life cycle approach to solution development & delivery. Also, outlines knowledge management preservation along with validation and testing before release and deployment of the solution. Validation and test of the solution in relevance to acceptance criteria for a GO/No-GO to Prod.

Then, where do the operations teams fit? What is the myth to be busted here?
Busting Misconception # 3– ‘’It is not where the PM, Dev and Test teams reside as part of the organizational structure. But, it’s’ around the R&R for the solution to be designed, developed and deployed”. The RACI aspect of ITIL outlines the accountability and responsibility at the task level, the capabilities needed and organization’s readiness.
Contact YASH today to know more about Information Technology Service Management
Lakshmi Nanduri -Program manger @YASH Technologies
Lakshmi Nanduri

• Information Technology Infrastructure Library
• IT Service Management
• ITIL