Do Less, Produce More!

Post date: Jan 21, 2012 12:47:29 AM

In this downtrodden economy, the concept of "do more with less" has become routine and cliche in our industry. Particularly in Higher Ed. Although "do more with less" is no doubt desirable, I believe a more realistic spin on that catch phrase is "do less, produce more!"

A do less, produce more model consists of working smarter, making rational decisions, and setting reasonable constraints. Information technology organizations should be spending more time on strategic and innovative thinking, but most of them are too bogged down in the minutia caused by integration chaos. These organizations have to reduce diversity, not in their culture or their workforce, but in their technology footprint. To do this, the I.T. leadership team must better understand their role in the organization. They must define and enforce a set of rules that transcend guiding principles or best practices and solidify the ability to meet the goal of do less, produce more. This starts with setting policies, requirements, and restrictions that prevent irrational decisions and self-destructive behavior, like:

• • purchasing the cheapest network hardware, but increasing the cost of support threefold due to the intellectual investment and cross-platform integration requirements.

  • implementing quick proprietary one-off software solutions to satisfy immediate customer demands, but increasing the cost of delivery and support tenfold, through the addition of new languages, new platforms, new framework libraries, and new protocols.

As examples, lay ground rules around what languages developers can use, what protocols they can use to exchange information, and what canned frameworks should be used for dependency injection and RESTful service development. The ability of one developer to implement a new system in 90 days using Ruby on Rails doesn't really make your organization more agile when everything else is written in Java and all the other developers and support staff are trained in Java. Instead, it results in the organization owning two ways of doing everything and introduces the need to support a whole other facet of the I.T. infrastructure and personnel skill-set to continue delivering that new "cheap" application for years to come.

Technologies will continue to change, best of breed equipment and software will forever be a moving target, and cutting edge tools and techniques will always be emerging. New trends are intriguing and interesting to technical staff, and avoiding them may seem like suicide; however, technological romances will hold an organization hostage. Sticking with what they know, an organization can solve more of the mundane problems that plague end users day-to-day with less effort. Once they begin to accomplish that, then they create time for themselves to explore and create cutting edge technologies, rather than chase them.