Central IT in Higher Ed: Can We Ever Become Agile?

Central IT in Higher Ed: Can We Ever Become Agile? Common Solutions Group May 15, 2008

Origin of this CSG Topic • Virginia Tech’s exceptional presentation at the winter CSG meeting • The extraordinary work accomplished by the web team • Clearly not sustainable… • … but what lessons can we learn? • Can we apply some pieces to “normal working conditions”? • e.g.: spread out information and the authority to make decisions to the edges? • What pieces of the bureaucracy can we lose? • Lessons to be learned from local IT shops? Common Solutions Group - University of Michigan

What does agile mean? Why does it matter? Part I Common Solutions Group - University of Michigan

What We’re Not Talking About • This presentation is not about agile software development • Which is - in and of itself - a VERY interesting topic… for another day • It’s about agile organizations • i.e.: “Agile Product/Service Delivery Strategies” • OK… I will say a word or two about agile software development • To help me segue into another inspiration for this topic: PM as CYA methodology Common Solutions Group - University of Michigan

Agile Enterprise • Most research on agile organizations (“the agile enterprise”) focuses on the corporate world (surprise!) • “Marketplace Agility” • “Agility the key to survival in the 21st century…” • Etc. • A fascinating, full-semester course at Cornell (35 hours) covers it • But this presentation won’t focus much on this research, because higher ed is different Common Solutions Group - University of Michigan

Higher Ed is Different Central IT’s organizational agility probably won’t be the key to our respective institutions’ “survival”… …but agility is a critical component towards building trust in the university community Common Solutions Group - University of Michigan

But Some of that Marketplace Stuff Applies Does this sound familiar? I’m agile. I’m bureaucratic. Common Solutions Group - University of Michigan

Characteristics of Agile vs. Bureaucratic Organizations Bureaucratic Agile • Stable • Hierarchical • Bureaucratic (duh!) • Predictable • Rely on stable customers/clients • Adaptive/creative • Flat organizational structure • Fewer “rules” • Innovative Common Solutions Group - University of Michigan

Characteristics of Agile vs. Bureaucratic Organizations (2) Bureaucratic Agile • Strict divisions between departments • Power concentrated at the top (those at the top are most knowledgeable and the only ones who can make decisions) • No strict divisions between functions • Power, information, knowledge spread out • A sense of urgency Common Solutions Group - University of Michigan

More Ingredients • Informality • Coming together for a mutual purpose • Common personal values; believing in the work Importance of under-the-radar activities Common Solutions Group - University of Michigan

This Rest of This Morning’s Agenda • Overview • Survey Results • Why Aren’t We Nimble? • Sometimes We Do Get it Right • Case Study: IT, Innovation, and the State System • Discussion/Wrap Up Common Solutions Group - University of Michigan

Survey results Part II Common Solutions Group - University of Michigan

Why aren’t we nimble? Part III Common Solutions Group - University of Michigan

It’s Hard to be Big and Agile Ooyala's 28 employees are building a system that runs videos for independent Web sites, and eventually they plan to sell video ads in the same way Google hawks text ads for other web publishers. The startup has raised $10 million in venture capital, which doesn't even come close to matching Google's resources. But the Ooyala founders say what they lack in institutional backing they make up for in speed and the ability to communicate with one another by turning around in their chairs and talking.Google was like that too, about eight years and 18,000 employees ago My emphasis. http://money.cnn.com/2008/05/09/technology/where_does_google_go.fortune/ Common Solutions Group - University of Michigan

Local IT And Agility • By virtue of its size, local IT can be more flexible, agile, innovative, and responsive than central IT. • And it almost always is Central IT can respond in one of two ways* *Sometimes we respond in both ways! Common Solutions Group - University of Michigan

Two Ways to Respond • The local IT folks are nice people, but they’re not real IT professionals. • They don’t have to support mission-critical applications • They deliver products and services to a limited audience, so things don’t have to work all the time - OR - • How can we take advantage of local IT agility? • E.g.: WebFinancials, Faculty Reporting, etc. at Cornell • Still a long way to go • Can local IT write applications to make it easier to support them centrally? Common Solutions Group - University of Michigan

Customer Service and Agility Brad Bird:Our goal is different because if you say you’re making a movie for “them,” that automatically puts you on an unsteady footing. The implication is, you’re making it for a group that you are not a member of—and there is something very insincere in that...So my goal is to make a movie I want to see. If I do it sincerely enough and well enough—if I’m hard on myself and not completely off base, not completely different from the rest of humanity—other people will also get engaged and find the film entertaining.

Customer Service and Agility Steve Jobs: It sounds logical to ask customers what they want and then give it to them. But they rarely wind up getting what they really want that way...

Customer Service and Agility Satoru Iwata: If you are simply listening to requests from the customer, you can satisfy their needs, but you can never surprise them.simply listening to requests from the customer, you can satisfy their needs, but you can never surprise them.

Customer Service and Agility One of Google’s strengths is the speed at which they can roll out products. Every time you look something new is cooking — that’s what makes Google such an interesting company to watch. In order for them to operate at these speeds, basic functionality in their products is included — but they don’t try and guess what bells and whistles people want. Each product or service they launch has an associated discussion group the community actively participates in. The suggestions made there are in large part what ultimately decides what additional features get included in the product.

Governance and Agility • We need to manage our resources but… • Control over “skunkworks” can impede agility • Do we need a parallel group that does innovation?...again? Common Solutions Group - University of Michigan

Project Management and Agility Common Solutions Group - University of Michigan

Project Management and Agility “Our PM methodology saved us millions of dollars and helped us get the project done ahead of schedule” - vs. - “We expected more of our projects to get done.” “The process sometimes took longer than the work itself.” “It seemed like a heavyweight methodology for small projects.” Common Solutions Group - University of Michigan

Billing models, etc. and impact on agility Common Solutions Group - University of Michigan

Other Obstacles Internal External • Boards • Lawyers • Risk management • Financial controls • Procurement process • Government regulation • Sources of funding & budget processes • Procurement oversight • Project controls • Public relations Common Solutions Group @ University of Michigan

Sometimes we do get it right Part IV Common Solutions Group - University of Michigan

When Things Go Right Cornell’s PS 8.9 Upgrade Lisa Stensland Manager, CIT Project Management Office Common Solutions Group - University of Michigan

Stanford Communications Convergence A study in organizational agility

Communications Org Context • Culture of networking and voice • Series of managers, always separate entities • Classic voice technology • Campus and hospitals requirements

Looking for an opportunity Two cases – one reactive, the other planned • Avaya - decision to replace an EACD solution that simply wouldn’t work • Cisco Call Manager – richer feature set to the hospitals in order not to lose business • In both cases, an incumbent technology had to be challenged and deployed in 90 calendar days.

How to get them to drink… • a vision that makes sense to all internal service owners and that they can see themselves in • Use prototype demonstrations to show possibilities • Getting on the boat, because it’s leaving?

Differentiators in Agility • Not surprisingly, it takes a leadership with a clue about technology trends • Taking stock of the staff • Aggressive timelines and “emergencies” can be your friend • Small victories • Prototype to demonstrate and motivate • Get (or take) a mandate for action, then act!

Organization Agility • Moderate consensus with autocracy • Make technology choices that foster agility • Don’t use FY as a timescale • Small successes: fail fast and recover

Case study: IT, Innovation and the state system Part V Common Solutions Group - University of Michigan

Discussion / wrap up Part VI Common Solutions Group - University of Michigan

Central IT in Higher Ed: Can We Ever Become Agile?