Remodeling the IT organization as a Services Provider

The strategic challenge of an IT organization's remodeling for the future is that it wants to become an organization whose agility is actually  the key to its ability to deliver relevant, quality-assured services.

In a simplified view, the difference between a departmental structure and a business unit structure is, essentially, the lines of operational reporting required to account for the objectives that distinguish the department from any other department, or likewise the unit from any other unit.

Departments have responsibility mainly for managing operational resources that support business functions.
Business units have responsibiliy for accountable functions that map directly to business policy and business performance targets.

When an IT organization arranges itself to operate like a business, it will become policy and performance oriented in terms of the targets for business compliance and business impacts in the relationship that the business has with its customers and partners.

Talent within the IT organization will need to be assessed in terms of the roles that staff need to keep operations flowing towards business compliance and business performance.

As a result, the concept of operational performance metrics comes to the fore. These metrics attend to how selected methods of activity succeed in operational events and time periods for which outcomes such as compliance, customer satisfaction, efficiency, and customer retention are known to be good.

When it comes to talent in the IT organization, four key flavors of interest will map to those same outcomes:
- Compliance comes under risk management
- Customer satisfaction comes under requirements management
- Efficiency comes under resource management
- Retention comes under relationship management

Expertise in risk, requirements, resources and relationships is therefore fundamental to any notion of talent in the organization; and execution of course will rely on practical skills applied under the guidance of the expertise.

The combination of expertise and practical skills will be what most people think of as "competencies", so it is fair to construct a framework or at least an outline of the valuable competencies that must be available to the organization.

Conventionally, we have thought of "skills and experience" as the way to characterise the relative value of a staff member. But a more truthful reckoning of what was usually being acknowledged is a baseline and history of "tools and assignments". Depending on whether the history was predominantly one of breadth or of specialization, talent could be cast as success rates in situations involving "overviews" or involving "focus". This works fine when the essential matter is to determine "resourcefulness" in current conditions. Wise generalists and genius specialists both tend to get promoted, not just recruited. But it is complicated to think about resourcefulness when the challenge is an unknown or volatile future. Agility may quickly outweigh optimization.

A shift in perspective -- from that of staff positions to operational roles -- is part of moving towards competency. By analogy, operations are like a dramatic performance, and roles are the cast of the performance. The structure of the drama relies on the interaction of the roles. The director is preoccupied with the logic of the interactions. The director will work on that logic, attempting to streamline and optimize its force as the "cause" of the production "effects". The audience (or customer) gets the impact of the "production", and the players who are the best "inter-actors" are the ones with the most "talent" -- that is, for the demands of the situation, they are the ones with the most competency.

Interactions between managers of relationships, requirements, risks and resources are not fundamentally altered by the size of the organization. Small or large, the same bases have to get covered, so current IT staff will need to look at the scope of their current tools and assignments and understand what they have now that should be used for the purpose of the interactions of the four "Rs". Within the existing staff, the more readiness exists to support the Rs, the more talent is said to be present.

We can look at the Rs in light of the idea that the IT organization will take what is has and deliver capabilities in the form of services, just as if the services were products. The goal is to determine what products are both (a.) the most successful ones amongst customers and are (b.) the most likely ones to enjoy high sustained quality from the IT organization's production.

Aside from the analogy of a stage drama, there are several well known reference models appropriate for IT re-organization. The most important one currently is ITIL, the IT Infrastructure Library. ITIL adoption is now pervasive and, consequently, is written about extensively by already successful practitioners. In ITIL, the interactive logic of operations is expressed as management processes, and processes are conducted co-operatively by roles. The effect of the co-operating processes is to create and deliver warrantied high-value services.

In the sense of providing services as if they were products: the outfit called Pragmatic Marketing has long offered a framework of interrelated competencies that account for how products are strategized and produced for targeted customers. In effect, it is a product management model that can guide thinking about a product called "a service", and it indicates where competencies need to be filled by roles.

Another familiar model, whether deemed successful or not, is matrix management, also extensively documented but often not presented with rigor that transcends a company's persistent idiosyncracies or tendency to change for other reasons.

Thanks to web search engines, looking into any of the above will likely lead to the discovery of many other specific models, so these others will not be itemized here. However, as a way of forecasting what a re-organization might provoke, it is useful to consider how the four Rs might generally affect each other.

Logically, if you're a provider, customers are more or less represented by what kind of requests they have, so their Requirements provide the rationale for having a Relationship with them. The scope of requirements, which can be tracked and analyzed, is compared to the practical chance of fulfilling them in production, so this chance (which includes both means and opportunity)  is a representation of Risk. Acceptable levels of Risk set the boundaries of operations, and Resources are applied to production within those boundaries.

This arrangement of dependencies is not one saying, in reverse order, that resources "cause" risk, or that risk "causes" requirements, etc. But if not having satisfied customers is the current state, then the causes of that problem may be found in poor understanding and control of requirements, and/or risks, and/or resources.

We may also consider that where the current state is not a problem but instead is an option or opportunity, managers of the four Rs may each have a perspective on what can be moved, added or changed to create a viable production path to the option. In this case, they will need to assure that they wind up in alignment with each other rather than creating a scenario that cannot be realized on time or sustained long enough.

IT Providers who produce services focus long and hard on determining how to be sure that, in operations, requirements are not too risky to themselves or to the customer. This is done mainly through what is generally called a Service Level Agreement (SLA), and when the customer buys the service they buy this form of product quality guarantee. SLAs are terms and conditions that pre-set expectations about the service as a product, so that the provider is not compelled to do something it is not really prepared to do.

Meanwhile, a catalog of services not only shows a potential customer what products and quality is offered; it also shows them how to ask the provider for things in a way that is easy for the provider to understand. Without the threat of underachieving, the provider can actually spend more time looking into additional options. To show that the provider has a range of services and competencies, the provider can make a different catalog available for each different major type of customer.

Back to roles:

Customers will want a representative from the provider who is a good-to-great navigator through the catalog.

Meanwhile, new services might also be crafted from managed realignments of existing resources. (Resources include equipment, money, time, knowledge and labor).

Technology engineering will never stop, but the need for that expertise to be in-house will continue to change with industrial scale innovations that make it possibly unreasonable for companies to "roll their own" when the requirements for satisfying customers and partners do not disqualify solutions already available from elsewhere. This makes business and technology analysts critical to spearheading the transformation of an IT organization into a services provider, and engineering staff must be aligned to production as creators of exceptional resources working under sophisticated supply chain managers.

While much of the above is more the implications about remodeling instead of instructions, what is definite is that IT remodeling is a strategic project, or else it will probably fail to be better instead of just different.

Posted by Malcolm Ryder at 12:05 PM | Comments (0) | TrackBack