Was just reading a white paper that a co-worker of mine was using to help explain the basic objectives of ITIL, and it was reflective of its publishing time, mid-2007, when many of us were struggling to figure out exactly how the alignment of V2 processes and the V3 lifecycle would work. There are mnay good summaries (the ITIL Pocket Guide is great...if you already know it anyway), but you might use this approach to explain it.
While many people think ITIL is about processes, that is at best an incomplete point of view. ITIL is about changing people's perspectives about the tasks at hand we perform in IT. It's not about the technologies, or even the whole end-to-end IT services, but how (or whether) these services effectively underpin our customer's business processes and enable the business's outcomes; revenue, profit, market share, or simply meeting the organization's mission and vision.
IT Service Management then is about how we produce, maintain, and sustain services to deliver VALUE to our customers (in the form of services that enable them to perform better, faster, or more cost effectively than they might otherwise). The Service Lifecycle that underpins ITIL describes 5 key aspects or stages of this effort. While there are much more authoritative conversations about the following, if you get the following big ideas, you're on your way to really understanding ITIL.
1) Service Strategy - In life, we don't get everything we'd like. This is usually because of constraints; time, money, a jealous spouse, you get the idea. The goal, therefore, is to maximize the value we can create (and that we get!) given the limitations we have. IT Service Strategy works the same way. There may be many things we would like to do, but given our time, money, and other resources at our disposal, which ones will we commit to do, and how do we decide? The concepts of Service Portfolio Management, underpinned by Financial and Demand Management, populates good Business Cases for how we can choose wisely.
2) Service Design - Once we've decided that to provide a particular capability would be a good idea, we need to align our customer's requirements and desired outcomes with our service targets. This includes decisions about the service's utility (what it does) and its warranty (how well it does it, how well it's protected, how much of it there is, etc.). Service Design takes theoretical models of what a service MIGHT be and transforms it into actual working services, with transition, operational, management, and measurement supports.
3) Service Transition - Regardless of whether we're looking to add a new service, change an existing one, or retire (or transfer) one altogether, transitions create risk. In particular, risks of causing business impact and disruptions when we deploy changes. Transition is about managing those risks and delivering the intended value that drove the business objectives and goals in the first place, and ensuring that we effectively move services out of development and into production...without blowing stuff up.
4) Service Operation - Once services are live, customers have one basic wish...keep them up and running so they can work. Service Operation describes proactive and reactive ways to manage, maintain, and support live services to keep them available and keep the business processes flowing.
5) Continual Service Improvement - The magic word here is continual...not occasional (or never, except when the boss is really mad). All services and all processes can improve; we learn, and the magic trick is to be culturally agile enough to make many, many small iterative improvements to your services and processes as you learn them. This can be as easy as building a knowledge base of known incident resolutions and Known Errors, or can involve detailed trending analysis in the search for performance enhancements. If CSI becomes "normal" in your culture, you'll learn what many other types of organizations have learned over the last 60 years; that while managers the world over seek "quantum leaps" in improved IT performance, most of the time real organization maturity requires time and a consistent willingness to "hit singles", or make small improvements that consistently build up lots of small, incremental benefits.
I don't pretend that this is ALL you need to know about ITIL, but many people who hold ITIL certifications miss the bigger picture. Yes, there are processes, functions, roles, etc. They are a means to a bigger end; customer outcomes that help that customer meet its mission and compete and win in its market space.