Busting IT bureaucracy: minimum viable processes in IT management

This article is part of a series highlighting key takeaways from my recently published book, Truth From the Trenches, A Practical Guide to the Art of IT Management. As a seven-time CIO, I’ve had an opportunity to observe the good, the bad and the ugly aspects of IT management up close and personal. Truth From the Trenches is my attempt to share my experiences with emerging IT leaders to help them avoid the chronic problems that afflict so many IT organizations.

Business executives frequently complain about the collective impact of government regulations on the cost and complexity of everyday operations. IT organizations are burdened by a variety of processes that have the same collective effect. Some of these processes are externally imposed while others are self-inflicted. 

Most IT staff members are well aware of the administrative burdens created by their internal work processes. And they should be — they helped invent many of them! Nevertheless, staff members routinely complain that certain key processes are hopelessly over-engineered and far too sophisticated for their needs; while other processes are poorly defined, inconsistently enforced or made up on the fly.   

IT’s business partners are equally frustrated, if not more so, with IT’s work practices. They tire of submitting trouble tickets, project requests and business cases to address concerns and opportunities that seem obvious to them. And they tire of tracking their issues and requests through the labyrinth of technical teams within the IT organization.

Large enterprises have roughly equal access to the tools, talent and best practices that are required to build effective IT organizations. Under these circumstances, process efficiency can become a source of competitive advantage. The real challenge is constructing just-in-time processes that balance efficiency and effectiveness. IT processes need to adhere to the Goldilocks principle: not too complicated, not too simple, but just right!

Process, process and more process

The vast majority of management processes within an IT shop are either imposed by other business functions, created by the IT leadership team, or established by individual work groups.

Imposed processes consist of such things as capital investment planning, fixed asset accounting, quarterly spending reviews and control audits to ensure compliance with SOX, PCI and HIPAA regulations. If not properly managed, the annual budgeting process can become an all-consuming activity, distracting management’s attention for three or four months at the end of every fiscal year. In a similar vein, important HR processes like annual performance reviews, merit pay administration, promotion planning, succession planning, development planning and employee engagement surveys can consume inordinate amounts of time if poorly managed.   

Self-generated processes established by IT leadership teams usually focus on ways of working more collaboratively and transparently with business partners. Cost chargeback or showback systems are a popular means of attributing IT costs to specific functional groups or business units. Project governance committees that assist IT in prioritizing project requests or monitoring the progress of major initiatives are also quite common. Some IT shops hold quarterly business reviews with key functional clients or business leaders to review recent accomplishments and near-term plans.

Finally, within the IT shop itself, individual work teams such as the database analyst team, the server administration team, the network administration team, etc. commonly use ticketing systems to manage routine support activities and work requests. If you want one of these groups to do something for you, their immediate response is “open a ticket.” Significant enhancements to core systems are governed by formal change management procedures and must be sanctioned by a change approval board.

Much like government regulations, each of the processes referenced above is well-intentioned. But their collective impact can be stifling. Processes are never free — they always require some investment of time in both their design and administration. Although many processes were developed to improve business collaboration and operational efficiency, they commonly fail to achieve their intended results and can sometimes have exactly the opposite effect!

Why is that? Consider these examples: IT may construct an elaborate cost chargeback system, but the intended audience for such a system — the business executives — may still feel they are paying too much for IT services. Ticketing systems are a logical way of recording issues and requests, but they may not streamline internal operations if they aren’t accompanied by a clear set of prioritization rules. A tremendous amount of effort may go into prioritizing IT spending plans for the next fiscal year, but at the end of the day the CFO may simply award a percentage increase to the IT budget based on affordability, not on IT’s detailed planning efforts. IT leaders need to periodically step back and ask themselves: Are the practical benefits being realized through any given process really worth the time and energy being devoted to its day-to-day administration?

Imitiating The Lean Startup by constructing minimum viable processes

Eric Ries popularized the concept of a “minimum viable product” in his book The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. A minimum viable product has just enough features to be useful to its target audience. It allows a startup company to test a new concept with prospective customers and establish its value proposition. IT organizations should plagiarize this concept relentlessly in continually refining their internal processes. They should design processes that are “good enough” to achieve near-term improvements in operational performance and then elaborate such processes in response to changes in the needs and sophistication of process participants. IT leaders who inherit processes from their predecessors should routinely employ the 80/20 rule to determine if 80% of a process’s value can be achieved with 20% of the current administrative effort!

Contrary to the advice or admonitions of IT industry analysts, there is no one-size-fits-all process framework that should be adopted by all IT organizations. Every organization needs to develop its own portfolio of processes based upon the complexity of the business it supports; the skills and maturity of its staff members and business partners; the personalities of key decision-makers both inside and outside IT; and the current business credibility of the IT organization itself. Consistently erring on the side of adopting minimum viable processes will inevitably produce the greatest benefits with the most sensible investments of time and effort.