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.