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?


  • 1
    This question is about IT governance, rather than the field or practice of project management as defined in our help center.
    – Todd A. Jacobs
    Mar 22, 2017 at 18:47
  • Hi @CodeGnome, I'd be honest I had a look on multiple sites and none get closer than pm SE for asking my question. I wish I can ask it elsewhere but this is the best place so far. Sorry about that.
    – Andy K
    Mar 24, 2017 at 9:39
  • Hi, although there's potentially a good question here, as it stands is more of 'I have a tool, how can I make it fit in my need' rather than 'I have a problem, what's the best tool to address it?'
    – Tiago Cardoso
    Mar 31, 2017 at 20:07
  • hi @TiagoCardoso, I tried to come with a solution rather than a problem. I can put another question where I'll frame it differently... What's your intake...?
    – Andy K
    Mar 31, 2017 at 20:10
  • Better to rewrite this one mate, focusing on your actual problem. Once you do it, the community can further edit it to make it a more sound and valuable question. Cheers
    – Tiago Cardoso
    Mar 31, 2017 at 20:26

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.