In the third and final part of this month's IT/Biz Alignment column, we conclude our "open letter" to your company's business and IT community -- begun in Part 2
-- by detailing how services, alternative funding mechanisms and, yes, people play a role in an effective organizational alignment.
(In Part 1, we looked at major trends shaping IT organizations and how IT should fit into and enhance evolving business models.)
The central IT organization should organize itself to provide sets of ongoing and special (temporary) services organized in some specific ways.
Business strategies should drive the whole process. Business strategies (which must be clarified and validated) developed by the lines of business lead to lines of business IT strategies which, in turn, provide input to the enterprise IT strategy (defined as services).
These services represent the specific services that the lines of business (as clients) would accept, reject or modify, as appropriate, and include such activities as desk-top, laptop and PDA management, data center management, communications management, applications management and security management.
In order to deliver the above services and build the kind of relationships with the divisions that will benefit the company, the central IT organization needs to organize itself adaptively.
Alternative funding mechanisms should be explored, separating day-to-day operational expenses from infrastructure investments. While traditional charge-back mechanisms can be used to pay for day-to-day operational expenses and -- via a built-in cushion -- some infrastructure reinvestment, there should also be a central fund for major investments. This fund can be generated via a corporate tax or via new allocations from the enterprise. Incentives should be created for the lines of business to invest directly or indirectly in infrastructure investments and re-investments.
In addition, those activities that the enterprise considers to be of great importance should be centrally funded if the businesses are unlikely to fund the activity. A prime example is business resumption planning and disaster recovery. Other activities - like process improvement, end to end planning, and related !'disciplines!( - often go un-funded by the businesses. If the enterprise considers such activities to be of great importance, and the incentives to invest at the lines of business level are inadequate, then the enterprise should (a) change the incentives or (b) fund the activity centrally.
A core competency analysis should be conducted for the purpose of determining which support services should be provided by in-house personnel and which should be provided by outside consultants and vendors. Economies of scale, efficiencies of operations, expertise considerations and an overall core competency assessment should drive decisions about what to do in-house and what to outsource.
Industry trends are clear, however: many companies are stripping out those activities that dilute their missions and are enhancing those activities that represent the core or essence of their business. Moreover, the pace of technology change, the obsolescence of skills, and the volatility of the industry all suggest that alternatives that permit us to move quickly should be explored.
We should adopt a life cycle-based approach to insourcing/outsourcing options, with the predisposition to control the business strategy 3 requirements 3 specification 3 design process and manage the implementation and support process.
We should monitor industry trends to determine when to move to hybrid or outsourced IT products and services. For example, in 1990 very few organizations outsourced their help desks, while by 2000 nearly 70% of all Fortune 1000 companies outsourced some help desk activities (with the trend expected to grow dramatically). Industry trends are important to monitor because they reflect the maturity and cost-effectiveness of products and services.
We should select the right insourcing/outsourcing model depending on the circumstances:
-- In-source when the tasks involve requirements --> specification --> and design - and when in-house expertise is deep and available.
-- Outsource implementation via complete and "transitional" outsourcing models where there is a high potential for "knowledge and process transfer" and where the transfer area is a targeted core competency.
-- Outsource when the target is at the back end of the life cycle, when the prospects for knowledge transfer are low, and when the area is not - and should not become -- a core competency.
There are also options surrounding the ownership of hardware and other computing assets. Emerging trends indicate that an increasingly number of organizations are leasing computing equipment of all kinds. Leasing versus buying options should be analyzed thoroughly and often.
The Program Office should address the opportunities and risks associated with outsourcing (among other issues). Once decisions have been made, the PO should coordinate vendor support.
Investments in the right personnel are critical to success. As we move toward a pure service model, organizational decisions, and decisions about insourcing & outsourcing, and our need for the !'right!( talent will rise dramatically.
Our needs will migrate from mainframe-based programming to client/server and network-centric systems integration and then !V inevitably !V to the Internet as our primary communications and computing platform. Skillsets will have to be enhanced in systems integration, architecture design, and project/program management to make this journey successful.
As we re-organize, there needs to be:
-- An emphasis on services.
-- Consulting support for each of the service areas.
-- A Program Office (PO) to manage the percentage of work that is outsourced, the account executive structure, and the central IT organization/lines of business prioritization of work; the PO is comprised of representatives from central IT organization and the divisions.
-- A technology Council that links the services and management of the central IT organization to the lines of business and divisions.
It's naive to believe that behavior will change by redrawing organizational boundaries or by codifying new responsibilities. In order to make the proposed technology organization effective several things must be true:
-- Skillsets must be re-examined: skillsets that supported mainframe-based applications, data center operations, and related activities are less valuable today -- and will certainly be less so in the future -- than architecture design, systems integration, distributed applications (so-called network centric applications), project management and program management skillsets.
-- Incentives must be re-examined: we must revisit the reward structure to make certain that the skills, talent and activities that mean the most to the company are generously rewarded, while those of less importance are rewarded accordingly. It is essential that the "right" message be sent here: employees must believe that (a) there is a clear vision for the business/technology relationship and (b) they will be rewarded for their dedication to this relationship.
-- A new breed of business/IT professionals must be fielded, professionals with an understanding of broad and specific technology trends, business trends, and how to convert the intersection into system requirements and system specifications. Such professionals will work directly with the businesses to understand how technology can be cost-effectively aligned with business strategies.
And Away We Go
There's obviously lots to do. And it won't all happen overnight. The reality of our profession is that they will still be brush fires to extinguish, vendor crises to manage, and financial disasters to avoid. But while all this chaos continues to swirl around us, we nevertheless need to think about how to make our business/technology organization less contentious and more efficient. A series of discussions will begin immediately to decide how to implement the kinds of changes described here. Thanks. (End of open letter.)
This generic organizational structure can be implemented - complete with embedded biases - in your organization.
Organization Effectiveness Metrics
It's critical that you measure the effectiveness of the organizations you create. Annual surveys, interviews and other instruments should be used to determine if things are working - or not. It!&s best to have the assessments made by consultants with no vested interest in the results.
Depending on what you choose to outsource, you should also develop a set of metrics that will permit you to (a) first compare what you!&ve got now to what was the case before outsourcing and (b) if the outsourcer!&s performance is up to snuff. Of course there should also be metrics to determine if in-house professional are performing adequately, should you decide not to outsource.
Organizational structures should be volatile as they adapt to new business models, new technologies, and new corporate structures. Prepare for changes long before they need to be implemented!