The itSMF Higher Education SIG invites you to attend an online presentation by John Borwick, Manager at Higher Education IT Management, LLC, discussing how to build an organizational capability with practical considerations, and stay energized as the change agent. How do you cope, and excel, when you know how your IT department needs to evolve but no one else seems to understand? The process of introducing an organization to a new way of doing things can be very frustrating and uncomfortable. This presentation is a pragmatic complement to improvement frameworks such as the ITIL CSI model and John Kotter’s 8-step change model. This webinar focuses on what it’s like to be the person pushing for change, and how to build short-term wins, “anticipated pains,” and feedback loops to successfully “ride the maturity model wave” from one level to the next. Speaker Biography: John Borwick has worked in higher education for over 10 years–principally at Wake Forest University from 2003 to 2012, where he was a systems administrator, team lead, assistant director for data delivery, associate director for continual service improvement, director of service management, and finally director of the portfolio management office (including service management and project management).

1. How to Ride the Maturity Model Wave
John Borwick
Manager, Higher Education IT
Management, LLC

2. Higher Ed Special Interest Group
• Opportunities to share with – and learn from –
colleagues at other universities that are
implementing IT Service Management
• Addressing the challenges that differentiate
the academic and corporate environments
• Contact the Higher Ed SIG through
HigherEdSIG@itSMFusa.org

3. John Borwick
Higher Education IT Management, LLC
John Borwick, PMP®, is currently the manager of
Higher Education IT Management. Prior to that
he worked in higher education for over 10
years–principally at Wake Forest University from
2003 to 2012.
John knows higher education and he knows IT–
in particular, he knows how to ensure IT
management systems support University
outcomes and the staff responsible for providing
those outcomes.

4. Higher Education IT
Management, LLC
“Helping Higher Education IT effectively deliver
value to campus while minimizing waste.”
 One-on-one coaching
 Custom engagements
 Blog
http://www.heitmanagement.com

5. Agenda
 Example of “Riding the Wave”
 The context for change, generally
 Why “Riding the Wave”?
 Models/Frameworks
 Making the improvement
 Additional resources

6. Example of
“Riding the
Wave”
http://www.flickr.com/photos/teresamorgan/3845888706/

7. Example: new e-mail
distribution tool

8. Example: new e-mail
distribution tool
Identify improved tool
Proof-of-concept
... ?
Tool implemented

9. The Context for
Change, Generally

10. Galileo
http://www.flickr.com/photos/ubmathur/3445953058/

11. Why can change threaten
people?
 Don’t understand it
 Following rather than leading
 Vested interests in the current way
 Risk to their power
 Power from knowing vs. learning

12. Mental models
http://www.flickr.com/photos/plaisanter/5362834664/

13. Equilibrate mental models
 Help people
learn your
mental models
 Understand
where they are
 Speak to them
where they are

14. Why
“Riding the
Wave”?
http://www.flickr.com/photos/mikebaird/2599226912/

15. “Riding the Maturity Model
Wave”
 Skill
 Balance
 Focus
 Energy-intensive
 (Lack of) control

16. Why can this situation be
frustrating & uncomfortable?
 No one shares your mental model
 You feel like things could be so much better
 You’re living in the future state
 Just want it done already!

17. Models/Frameworks

18. Maturity models
 Level 1: Initial
 Level 2: Repeatable
 Level 3: Defined
 Level 4: Managed
 Level 5: Optimizing

19. Maturity models
 Level 0: Not Performed/Unaware
 Level 1: Initial
 Level 2: Repeatable
 Level 3: Defined
 Level 4: Managed
 Level 5: Optimizing

20. ITIL CSI Model
1. What is the vision?
2. Where are we now?
3. Where do we want to be?
4. How do we get there?
5. Did we get there?
6. How do we keep the momentum going?

21. Kotter’s organizational change
model
1. Sense of urgency
2. Guiding coalition
3. Compelling vision for change
4. Communicate the vision
5. Remove obstacles
6. Create short-term wins
7. Build on the change
8. Anchor the change in the culture

22. PDCA Cycle
Act/Adjust Plan
Check Do

23. Iterative development
A P A P A P
C D C D C D

24. Making the
Improvement

25. Making the Improvement
 Context for the improvement
 Your role
 Release management
 Two examples

26. Making the
Improvement:
Context for your
improvement

27. Stakeholder identification
 List stakeholders
 Sense of ownership & incentives
 Power dynamics
 CIO telling stories
 Need all levels on board
 Quiet != On board
 Working with your manager
 Stakeholder analysis: what do they care about?

28. Impacted processes
 How might the improvement affect other
processes?
 How might other processes affect this
improvement?
 What new pains will this improvement create?

29. Organizational analysis
 Capacity for absorbing change
 Ability to understand the change
 Revolutionary vs. evolutionary
 Risky later vs. up front

30. Making the
Improvement:
Your role

31. Vision/“True North”
 The Expert
 The core few things that must happen
 Are we done?

32. Negotiator
Stakeholder A Stakeholder B
Item #1 WIN WIN
Item #2 WIN WIN
Item #3 LOSE WIN
Item #4 WIN LOSE

33. Negotiator: Quick Wins
 Who doesn't want a quick win?
 Listen and understand stakeholders
 You know the possibilities; they know the
value to them
 e.g. creating a listserv that sends opt-in emails

34. Negotiator:
Guiding Coalition
 Never begin with a finished draft
 Pay attention to how much you are talking.
Questions vs. answers
 Position others to take the next step
 Understanding the pain that will be created
 Letting others connect the dots

35. Other notes on your role
 This Is Not About You
 Be a facilitator
 Patch together process interfaces as they
change
 Temporarily do what’s needed to keep the
improvement going
 Do rather than talk. Bias towards
experimenting and testing

36. Making the
Improvement:
Release Management

37. Release Management:
Organic system
(Credit to the Lean Enterprise Institute)
 Knock-on effects
 Help people effect the change. They become
change agents
 “Remove Obstacles”

38. Release Management:
Create feedback loops
Open-Loop
INPUTS Process
OUTPUTS
Feedback
Loop
Closed-Loop
INPUTS Process
OUTPUTS

39. Release Management:
Communications
 Formal communications plan
 Formal training options
 Informal training
 Help shift mental models

40. Release Management:
0, 1, 20%, 80%, 100% coverage
0 -> 1 Proof of Concept
1 -> 20% Improve
20% -> 80% Sell, sell, sell
80% -> 100% Peer pressure/mandates

41. Release Management:
Deliver value as you go
100
% value delivered
80
60
40 All-or-Nothing
Incremental
20
0
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6
Time

42. Release Management:
Position for Future Success
 Understand the pain that will be created
 Begin building shared mental models to
address that pain

43. Making the
Improvement:
Two examples

44. Change management
implementation
Stakeholders
Stakeholders: helps project managers, frustrates
developers. Role of auditor, IT leadership.
Mental models: necessary evil vs. enabling capability
Vision: every change? Review proportional to risk?
Mental models
Quick wins: how can the process help developers?
Vision example of change management helping.
One
Quick wins
Patch together: meeting attendees, one-on-one
training
Things to patch
Future pain: release management, reporting
together
Future pains

45. Change management
implementation
Stakeholders • Project managers
• Developers
• University audit
• IT leadership
• …
Mental models Necessary evil vs. enabling capability, …
Vision Every change? Review proportional to risk? …
Quick wins How can the process help developers?
Celebrate faster time-to-resolve, …
Things to patch Inviting people to CAB, one-on-one training,
together …
Future pains Release management, reporting, …

46. Creating an “Application
Support” Team
Stakeholders
Mental models
Vision
Quick wins
Things to patch
together
Future pains

47. Creating an “Application
Support” Team
Stakeholders • Developers
• Service Desk
• New Application Support team
• …
Mental models Segregation of duties, how to define “support” vs.
“development”, …
Vision No more incidents to developers, …
Quick wins One type of support ticket goes to the new team,
knowledge base entries, …
Things to patch Access levels, who talks with users, …
together
Future pains When to transition work between teams, adding
support teams to project teams, …

48. Review
 Example of “Riding the Wave”
 The context for change, generally
 Why “Riding the Wave”?
 Models/Frameworks
 Making the improvement
 Additional resources

49. Additional Resources
 Leading Change by John Kotter
 Getting to Yes by Roger, Ury, and Patton
 COBIT by ISACA
http://www.heitmanagement.com/surfing

51. Thank You
HigherEdSIG@itSMFusa.org