Monday, November 25, 2013

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.


Wednesday, November 20, 2013

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. 
Project Management Institute. (2012). "Organizational Agility".  PMI's Pulse of the Profession.
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.

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.