Easing CIOs` Pain for Meeting Business Expectations

By John Parkinson  |  Posted 12-12-2007

Easing CIOs` Pain for Meeting Business Expectations

In an ideal world, CIOs would manage a well coordinated stream of requests for new and enhanced business capabilities from their customers: the managers of the businesses IT serves.

Requests would be well articulated and sufficiently detailed so it would be easy to estimate the resources required to meet them, and on delivery every new capability would precisely match the need originally described. Resource leveling would be no problem because demand for new IT business capabilities would flow evenly. Technology refresh cycles would never interfere with business operations because the IT infrastructure and business solution platform would be sufficiently well architected, abstracted and modular. Complexity would be minimized by a standardized and consistently deployed solution architecture.

Businesses could take advantage of any new technology that offered sufficient maturity, stability and return on investment. CIOs would lead wonderful lives.

But in the real world, it doesn't work that way.

Businesses are bereft of natural cycles, so it often seems as if demand comes from all directions at all times. That makes it difficult to prioritize and hence difficult to allocate resources efficiently. The range of disparate demands for new capabilities is so wide it's almost impossible to deploy a coherent, well architected solution platform and technology infrastructure.

Business managers often show up with demands for "how" a solution should be provided as well as "what" is needed. Vendors sell around the IT organization, undermining whatever standards are in place and increasing operational cost and complexity.

Approaches to solutions come and go. CIOs lead lives of continuous hassle.

There is no magic bullet for dealing with these real-world challenges. After all, CIOs have been trying to fix them for more than 30 years; CIOs are smart people and if it were easy, they'd have done it by now. But there are some well established if not yet commonly deployed practices to make life easier. Using them won't make life wonderful, but it will reduce many of the hassles CIOs face and let IT contribute real value to business success.

Page 2: Demand Management

Demand Management

Demand Management

The single most critical practice is to coordinate demand for new and enhanced business capabilities via a well defined, well understood and consistently employed demand management process.

Many requests for new or enhanced business capabilities have common or overlapping solution elements, but CIOs only discover these commonalities if they can analyze enough of the aggregate demand to see the patterns. One of the best practices here is to be proactive--to get out into the business and talk to business managers about what they need, and in the language they use.

This isn't always easy (IT isn't always welcome), but it's essential to get a broad picture of what the business needs, immediately and in the long term, across as may functional areas as possible. That way CIOs avoid or at least minimize solving problems or providing solutions in silos, and they get opportunities to leverage the solutions they provide or plan to provide to other business users.

In addition to talking to business managers, CIOs should seek out information about business strategy and desired business outcomes to get a high-level picture of business goals. That will help assess priorities and, therefore, allocate resources effectively.

Competitive intelligence is another rich source of ideas to take to the business, because it uncovers the capabilities a business's rivals think are important enough to invest in. It's often easier for IT to gather and analyze this kind of information than it is for the business. That's because technology vendors often talk openly with their customers about the projects they're doing at other companies, and even though they don't usually say explicitly what technologies are being implemented or why, savvy CIOs can often make good guesses.

Another best practice is to assess the demand for new or improved business capabilities that could be based on emerging or established but not yet widely deployed technologies. However, it's important not to jump straight to technical solutions, which is too often what technologists do.

It's better to understand what capabilities are needed and only then look at solution options. So, for instance, business executives who want to know which employees are in the office and whether each person is busy at any given time want presence and identity services, though they may have never even heard of such services or understand the terms that technologists use to describe them.

Page 3: Rationing Demand

Rationing Demand

When business managers demand new or improved business capabilities, those demands need to be rationalized. There is no easy way forward here; it's a continuing negotiation between IT and the business. The business will almost always want more resources than IT can reasonably deliver.

CIOs must ration the demand so that it matches available capacity in terms of investment capital, time to market, people and skills. This is where IT can and should pitch its business partners to provide funding for new capabilities for standardization and platform coherence--not because it makes life easier technically, though it does, but because standardization and coherence provide the business with more capabilities for its money and gets them deployed faster.

Next, the CIO should look for the minimum solution footprint that will satisfy new and existing aggregate demand. This is where common business services emerge. Working with customers, it's best to identify what can be shared and what needs to be unique for each specific capability being sought.

A primary asset for the CIO is a group of solution architects who understand the business well and know what available technologies make it possible to deliver. CIOs should also leverage corporate and industry standard business process models to understand and optimize the flow of information and work.

Although CIOs would like to discover that every business capability can be satisfied by assembling common solution elements--think horizontal capabilities such as messaging, directory services, identity and security--that's probably not going to happen.

Some of the elements will be common to only one or two business areas, or unique to a single area--think vertical solution capabilities such as credit checks, warranty management or underwriting. As the architectural review effort proceeds, the business and the solution architects must put a value on each unique element because uniqueness will cost more in development and lifetime total cost of ownership.

When done--it will probably take several iterations to get a workable agreement--there'll be a solution architecture with a supportable business case, a required level and schedule of investment and an expected ROI.

Page 4: Common Vs. Unique

Common Vs

. Unique">

Common Vs. Unique

Now, the architecture must be spun away from the business domain and into the technology domain. Knowing what technologies are available and what they can deliver in technical capability, performance and scale, a group of technology architects is asked by the CIO to select the minimum number of technologies needed to implement the solution architecture--in essence to design an optimized technology provisioning strategy. Here again, CIOs must look hard at what can be common and what must be unique, and examine the cost and value of uniqueness. To keep things manageable, the common and unique portions of the work must be split, but as a series of platform architectures is developed, the individual architectures must be recombined to ensure that the teams achieve overall coherence and consistency.

It generally takes several attempts to get consensus on all this, and CIOs often have to cycle back to the business domain, sometimes negotiating with solution architects serving as proxies for business managers--sometimes negotiating with the business managers directly--before the work is finally done.

The final step is to make detailed provisioning decisions--build vs. buy, for example--for the technologies that have been selected.

Along the way, CIOs can create a comprehensive map, from capability requirements to solution elements to implementation technologies, that will be used to support continuing solution lifecycle management and technology refresh efforts.

Because they know what business capabilities depend on what solutions and what solutions require which enabling technologies, CIOs are able to conduct a reliable impact analysis to determine how to make the changes and upgrades simpler and less disruptive. When changes are necessary, they know who might be affected and can communicate and plan accordingly.

Once the portfolio of work has been identified, there's one final check to make: determining the appropriate ROI model and level of expectation for each element of the portfolio.

Not every project--however critical to the overall plan--yields the same level of return, and every business justification must reflect that: Who gets the benefit? How much will the benefit be and what will it take to achieve? CIOs need to be able to answer all these questions before the work is complete.

This is a tough discipline that a good many IT ships do not enforce very well. Too many projects get launched despite failing the "good for someone" test, a sure route to eventual failure.

Veteran IT consultant John Parkinson is a columnist for CIO Insight.