setting ITIL as a common framework for multiple IT teams around the world

Question

My manager and I have been tasked to manage/incentize multiple IT teams in different geographical regions (with multiple time zones and different cultural understanding).

The teams are not experienced ones yet, lacking basic discipline on how to test, review and roll out.

I was thinking of setting up a methodology like ITIL or Information Technology Infrastructure Library to lay the foundation for a mutual understanding, e.g you don't roll out without a test or without basic communication to the users.

• Would ITIL be a decent framework for that?
• If ITIL was not the 'thing', is there another methodology for that?
• Has anyone got any experiences with this and would be willing to share it, please?

Thanks

Answer 1

I'm not all that familiar with the details of ITIL. When I've run across it, what I have usually found is the process was stagnating the origanization.

What I would advise is flip things around, instead of laying in a large process (with all the documentation, training, ramp up, etc), start where you are and develop something from there. This falls under the loose concepts of Kaizen, start where you are, which comes from the Toyota Way.

Here is the outline I would recommend:

1. Do absolutely nothing. You're new, you don't know how all these teams work today. Spend the first 90 days learning.
2. Do a Gemba Walk (Google the term). It's another thing from the Toyota Way concepts. Go to each location and observe. See how things are running. See their challenges. Hear what they have to say.
3. Do Value Steam Mapping: Identify the three most common things your teams do or will do. Map out the timeline for getting from idea to done. You are particularly looking for wait times, when you're waiting on someone else and on "throwback" points where the project can get thrown back to an earlier phase (QA, for example).
4. Decide on your goals. Now you need to decide what you want your organization to be. Create goals based on these. These goals should be "Why" or "What", not "How". Enough guidance that the teams can then figure out the best way to get to those goals. Remember, goals need to be measurable, or you'll have confusion. "Is fast" is not a goal, "reduce delivery time by 50%" is a goal.
5. Start. Just start. Don't create process, don't go into details. Just start.
6. Inspect and Adapt. Now you start looking weekly or even daily at how things are going. Tweak things to work, document what works and move on.

You should also be prepared that different teams will end up with different "How" processes. If they are meeting the "What" goal and they've documented the working process, then that's fine.