The Case to Reform IT

If IT is to survive, it is time to move to a new paradigm. Changes over the recent past have rendered the flawless and timely deployment of information technology as a critical success factor for most businesses. It is difficult to think of any business that is not dependent on successfully employing information technology. Examples can be found in all verticals. In fact, finding a vertical that is not IT dependent is challenging.

At this time, it is imperative that IT consider moving from its old operating model to a new one.

Old Model

What characterized the old model? Among the factors characterizing the old model are:

• IT is an organization. All IT resources in the enterprise need to report to and be controlled by the IT department
• All information technology purchases must be initiated by, approved by and controlled by IT – NO EXCEPTIONS
• The primary form of communication between business and IT is based in processes. Capital deployment processes and requirements gathering processes are just two examples among many.
• The Requirements Document forms the basis of the contract between IT and business for all new or changed deployments
• The IT budget is separate from the business budget and must be separately managed. The CIO is responsible for that budget. Containing its growth is a frequent budgeting objective.

And the list can go on – each reader can add bullet points to the list and most can recognize their organizations and history in these bullets.

It is time to change. The notion of all information technology resources reporting to the IT organization is as obsolete as suggesting that all human resources need to report to the human resources department.

Consider A Different Model

As an alternative, consider the following:

• The CIO is a partner of each business unit, participating in strategic direction and supporting strategy deployment. No longer is IT pitted against the business to control its destiny and to ensure that only IT initiated and approved direction gets implemented. While IT controls corporate infrastructure, it does so with the sole objective of meeting business expectations and both current and future needs, in a cost effective and responsive manner.
• The only information technology resources reporting directly to the CIO are those resources supporting multiple businesses and the enterprise as a whole. That would include technical infrastructure planning, deployment and management, legal and reporting compliance, human resource development and retention and program management standards and compliance (PMO). Careful examination of which resources should report centrally rather than report to individual businesses needs to be driven by common sense, economics and a mindset that if something can be done better centrally (e.g. email or help desk), it is in the best interests of IT and the business units to figure out how to make it work.
• Information technology resources associated with a business report to the head of that business
• IT manages the careers of those resources. Included in its management scope is human resource development, co-hiring between business and IT, career development, leadership continuity, equal participation in salary and promotional decisions, professional development and program deployment process development, support and program assessment.

This model does not assume that anarchy prevails.

Technology resource deployment is managed by IT for the enterprise. Its goals include business responsiveness. Business units operating under this model are not authorized to contract for IT resources outside of a collaboration with IT. For example, deploying cloud tools must be a joint decision, and the governing philosophy is one of meeting business needs in a timely and economical manner while preserving a rational and supportable infrastructure for the enterprise.

System Deployment Example

Let’s examine how system development and deployment would operate under this model.

The setting of requirements, it is argued, is essential to developing or deploying IT capabilities. Far too often, business sets the requirements and IT becomes accountable to deliver on them. Collaboration between the two often takes the form of a hand-off.

I suggest that this is an obsolete model, one that pits IT and its business clients against each other, in a game of chicken to see who fails first. And as experienced in numerous environments, more often than not, there is a failure.

A better model is a collaborative model. For this purpose, I will use a system deployment project, one in which the organization acquires a license to deploy a vendor software product and proceeds to implement that decision. It applies equally well to development projects, with some tuning.

• Start with understanding and documenting current business processes. How are you doing the work that is subject to your proposed project? What are the strengths and weaknesses of the current process? This is a joint business and IT role, with the shared goal of improving the business by first understanding its current operation, then improving on it.
• Next define the changes to the current process that you (meaning a collaborative Business and IT team) wish to make. Document the changes creating a target process design, and estimate the benefits of the recommended changes. Benefits can come in many forms – for example, revenue generation, cost containment, compliance, entering new markets, improving service capabilities, and more. Be clear and specific about the benefits. This will not only be helpful in justification of the project, but also will prove valuable as trade-offs between system scope/capabilities, cost and time are addressed downstream.
• Develop a document which defines the capabilities you are seeking to realize these business benefits. To borrow a chapter from Agile, developing use cases at this point in the process rather than a traditional requirements document will provide a jump start to testing, and will assist in focusing on the full capability set that you desire. Set phases (sprints) to deliver capabilities on a schedule, rather than waiting for full deployment to complete to begin recognizing benefits. Be certain that each phase has measurable benefits – and measure their achievement!
• Survey the market. Even if your bias is to develop your own system from scratch, understanding the options available in the market will broaden thinking and likely will enrich the target process design.
• Look at the match between available commercial products and your target process. Considering benefits of the target process changes, examine carefully if your target process can be changed to fit the capabilities of market alternatives. This is an often skipped step, resulting in custom developments where minor process modifications can result in a more cost effective and market effective solution using commercial software with minor enhancement to meet the business need faster than a custom development.
• Select a solution, and select a minimum of two vendors who can potentially meet those business needs. Negotiate with each, finding the best solution that each can offer. Criteria for selection, among others, include responsiveness to business needs, ease of implementation, degree of customization (less is more) and of course cost, vendor track record, risk assessment and others. Base contracting with the selected vendor on meeting requirements and use cases. These must be a part of the contract, so that there is no misunderstanding of deliverable capabilities.
• From here, implementation begins, guided by a tight and complete project plan that is developed, assigning accountable parties for each task. Communication is essential to success, as in any project. There is no YOU and WE, but only US as implementation moves forward.

In Summary

So in summary, information technology has a large and growing role in business enterprises. No longer is it simply a back office nicety. It is in the front line of business, and in fact, the use of information technology is the business in many cases.

There is clearly a centralized enterprise-wide role for technology infrastructure provisioning and management – clouds, email, security, compliance and backup/redundancy are part of that role’s function. But there is also a large impactful role of working to optimize business needs. Business facing technologists need to implement and where useful, drive technology solutions to business problems and opportunities.

Perhaps it is time to call the question – many have argued that CIO = Chief Innovation Officer. Nonsense. The business needs to lead its business, with strong participation from all relevant disciplines, including IT. Perhaps the best posture for an IT organization is to (1) own infrastructure as defined above, and (2) ensure that business units are staffed with competent technology experts. The IT organization needs to set standards, policies and best practices for those in technology roles, and oversee the career development of those resources. Direct line reporting is unnecessary – direct influence however is a requirement for success.

This view is perhaps out of step with those arguing for centralized IT with increased power. And many reading this blog will say that they are already doing much of what is advocated here, and hence the direct reporting of IT resources to business unit leadership is not necessary.

Clearly this is not a prescription for every IT organization in every company. But it is a direction that should be evaluated to assess its benefits for overall enterprise technology success.

I would value the opportunity to discuss your views. Please contact me at rak@simassoc.biz.