Building Agile Organizations: Common Good Services and Adaptibility

The economic downturn in the business world generated business commentary that can be useful for today's changing higher education market.  "The agile organization puts its 'non-negotiables'... in the center, while empowering the local units... to be more responsive and adaptive to local markets, customers, and trends." (Outlook 2009 Accenture).  Let's take that statement and consider how it might work on a campus, with centralized and decentralized information technology operations.

What are our "non-negotiables" that we believe must be part of central IT?

How can we encourage local support to be responsive and adaptive to department needs?

Let's look at each of these questions.  Non-negotiables are those IT solutions and services that benefit the campus community.  The higher education IT organizations appear to favor the term "Common Good Services," originally attributed to the University of Minnesota.

Purdue University provides a nice example of how they use the idea of central services to make organizational decisions in their document Common Good Services Philosophy.  In that document, they speak about the recognition of core services:
""Common Good Services" refers to that set of basic, non-specialized computing resources that is
beneficial for nearly all members of the Purdue community.  Common Good Services are those
basic information technology services that most community members would agree are critical to
conducting business (academic, business, student, and research) at a modern research university."
These services are always on and not customized to a specific department.

The University of Texas at Austin uses the Common Good list to identify services that are funded and available through a core data and network charge, so there's an established funding link.

I like how these organizations have identified those core services and clearly linked them to their specific applicable funding models and to their decision processes.  Also, using the philosophy to explain why something is centrally funded versus funded by a local department is very useful.  

How can we use this to enhance an adaptive IT organization?  By clearly establishing the solutions and services that are core and part of the common good, we are transparent in priority setting and funding models.  We can use this to explain how we spend our budget funds, as so much of what we maintain for the common good can lack transparency to senior leadership.  

Common good services provide a consistent service level, in a practical way.  Faculty members and students, walking from one academic building to the next, can expect a consistent level of network services, for example.  Redundant processes and duplicative costs are removed, freeing resources to work on other priorities.

The common good services can provide a reliable, consistent, and stable foundation on which to build more responsive and adaptive solutions at the edge.  If we provide a consistent core, and then encourage local units to build responsive and locally customized solutions on that foundation, we can promote organizational adaptability and responsiveness.  The Outlook 2009 Accenture article on agile organizations suggests:

"The bureaucracy that results from an overly centralized model can stifle innovation and result in delayed market responsiveness.  On the other hand, an overly decentralized model can result in inconsistencies in response, slower product development, organizational redundancies and excessive costs."  

On my campus, while we've clearly identified our core services to our community, we haven't done as well as Purdue in documenting the philosophy.  I can see where doing so would help our community understand what is centrally funded and what is at the edge.  It would also help our IT managers understand how certain decisions are made and how they can help work with that model.  This will be a step in our process of building a more agile IT organization.

Resources for Agility: Knowledge as a Resource

I suggested that we need to track resources beyond the typical project management trio of resources of time, people, and budget.  If we are truly building agile and nimble IT organizations, just tracking those three items (time, people, budget) will not create the environment needed for success.  The consumerization of IT is making it easier for the departments we serve to simply bypass the university IT organization.  Policy that forbids bypassing central IT will only work so far and so long before our communities determine that IT simply is an obstacle to their own success.  We need to offer our constituents options that compare favorably to externally provided resources, or when that isn't possible, we need to offer valued-added services in the selection and management of externally provided resources.  Simply comparing time, people, and money resources on projects will not yield a full description of any service.

Another resource we need to track is knowledge, as represented in the skills and talents held by our IT staff members.  For example, we may have the right number of people for a project.  We may have managed the project portfolio so there is time to execute the project.  There may be adequate funding for the project.  But with the device and software proliferation we are seeing in the industry, there may not be adequate knowledge to execute the project.  In prior times, we likely would have embarked on a technology training program to bring our IT staff members' skills current to the technology direction. But if we do that today, how well will we compare to a service-provider who can start the project today because they already have the skills?  Can our communities wait for us to retool?  So knowledge is another resource we have to track.    

What does it mean to track knowledge as a resource?  We need to keep technology skill inventories so we know the list of skills that are present and ready to use.   When we hire for a position, we need to identify the organizational skills gap and we need to hire to fill a skills gap.  But increasingly, we also need to hire people who demonstrate an ongoing ability to learn, to add on skills, to up-skill their current knowledge, and do so at a pace that matches the environment.  

The hiring process needs to emphasize the selection of an employee who can demonstrate the ability to personally manage many skills.  For example, hiring a strong and specialized Oracle database administrator may fit an organizational requirement.  Likely our interviews and selection process emphasize Oracle database management skills.  But really, to be successful, that DBA also has to be adept at managing modules that are installed on premise and modules operating in the cloud, managing e-mail, managing workload in a ticketing system, processing system downloads, communicating system needs to a VM / storage architect,  articulating identity management and login protocols, and reviewing firewall rules with a network security engineer, among other skills.

Let's review how baseball teams select players for whom they wish to trade.  Maybe a team manager starts by picking the position - like first base.  Sure, the team wants a .300 hitter and low error rate.  But when you read about it, they look for hitters that will have high hitting percentages in the particular home ballpark. Does the candidate bat better against left-handed or right-handed pitching? Management will look at how well that hitter hits in the post-season or at various positions in the batting order. Management may dig even deeper, looking at fielding percentages in different player-on-base scenarios.  And so it goes, digging deeper and deeper into the stats to see exactly which player is really the best fit.  

I'd like to get to a point where we know all the "specialized skills" and "deep skills" that we need in our IT organization.  Also, we should analyze technology directions requiring new or upgraded skills, and have that articulated into our skills inventory.  The skills inventory also needs to identify gaps and match gaps to hiring and training processes.    Our training programs need to be looking out and building training plans for each employee that builds added skills, not just replacement skills, into the future, filling gaps in our inventory.  Employees that can handle this level of adaptability over time and quickly respond with new skill building are going to be the valued team members.

I wonder if we can use our growing knowledge of analytics to managing knowledge as an IT organizational resource.

   

Creating the Agile and Nimble Organization

I have been thinking about the challenges we are facing in our colleges and universities, and how to build the teams and the IT organizations that are ready for future challenges.  Martin Ringle, CIO at Reed College, and I have chatted a little, and Marty extended an invitation to present and participate in a strategic discussion at the NorthWest Academic Computing Consortium (NWACC).  I accepted with pleasure; I thought the interaction with such a talented group of IT leaders would be inspirational (and it was).

Knowing that I needed to be ready was the best motivation to pull my ideas together.  First, all the talk about MOOCs and cloud computing had pushed the idea that our organizations need to change. There are many articles about higher ed IT being in a period of transformation; for example:

"A Transformative Period:  Is Higher Education IT Having an Identity Crisis?"  Grama, Joanna Lyn. EDUCAUSE Review Online, June 2013.
 
If we are indeed in a transformative period, a different organization model, one that is more nimble and agile (not to be confused with formal agile methodology), would be better equipped to be successful.   If that's so, what are the characteristics of an agile and nimble organization? How do we know when we have fully addressed those components?  I'm going to make that the focus of my blogging efforts for a while.

I started with a basic review of business literature and found these documents from the business world:

❖Blanchard, Stacy, Cheese, Peter, Silverstone, Yaarit, and Smith, David. (2009, October).  "Creating an Agile Organization". Outlook: The Journal of high-performing business. http://www.accenture.com/us-en/outlook/Pages/outlook-journal-2009-agile-organization.aspx 

❖Project Management Institute. (2012). "Organizational Agility".  PMI's Pulse of the Profession. http://www.pmi.org/~/media/PDF/Research/Organizational-Agility-In-Depth-Report.ashx

❖Selingo, Jeffrey J. "Attitudes on Innovation: How College Leaders and Faculty See Key Issues Facing Higher Education," The Chronicle of Higher Education, 2013

❖The McKinsey Quarterly. (2006) "Building a nimble organization: A McKinsey Global Survey".  The McKinsey Quarterly.  http://leadway.org/PDF/Building%20A%20Nimble%20Organization.pdf

The business world experienced this transformative state after the 2008 economic crisis.  The literature from that realm suggests the following response mechanisms as key success components:

• Quick response to strategic opportunities
• Shorter decision cycles
• Focus on change and risk management
• Integrating the customer voice
• Building interdisciplinary project teams

From those readings and analyzing other general news comments, I've built the following list of components that I am calling the "Agility Resource Model":

These eight characteristics would represent the resources we need to manage if we are to create agile organizations.  The numbers, for now, are placeholders indicating an equal slice.  I am working on building a model behind the resource display that would allow an organizational leader to do some assessment and analyze how well leadership is addressing each of the eight resource factors.

Those who traditionally manage projects will recognize the time / people / money resources that are managed in any project.  But if we are creating organizations that need to be resilient and response in changing times, we cannot limit our thinking to those three resources.  Transformative periods, characterized by turbulence, instability, and ambiguous, unknown futures, require organizations to be nimble.   IT organizations need to present adaptability in addition to speed; they must be quick to adapt. We need to change tactics and direction quickly, and once headed in a direction, we need to maintain a fast pace.  We need to demonstrate responsiveness to impacts that will inevitably occur; we need to respond, not panic or succumb to being overwhelmed.

Over the next few weeks, I'll explore this topic in more depth.  As always, I appreciate your comments and feedback.