Does your IT organization have an effective governance framework to ensure success regardless of the business services you provide or projects your execute? These are two major challenges faced by CIOs and IT organizations today. If you don’t address these challenges now you will never be viewed as a strategic partner to the business.
Think about it. If you provide services that incur disruptions and/or execute projects that are late, have cost overruns, or are flawed with resource issues, why would your C-Level peers ever let you into the inner sanctum of the executive suite. The logic is simple. If you can’t manage your own business unit then why would your C-level peers want you to help manage their business units.
So now is the time to revisit the governance model you use to ensure the successful operational stability of business services and successful execution of your projects.
The number one challenge faced by CIOs today is operational stability. Business personnel do not want any disruption to computers, telephone systems, or business applications they use each and every day. Think about it! Customers place orders, pay bills, and check on inventory status. Companies use business systems that interact with their suppliers, distributors, and customers across their entire value chain. These business systems need to be operational and any disruption impacts sales, profitability, and customer relationships.
The number two issue is project success. Almost every business project requires an element of information technology. As a result, the main focal point of every project is the CIO and the IT organization. Therefore, the CIO needs to be proactive to ensure an effective governance framework is utilized on every project to minimize risk and achieve success based upon the financial targets, timeline objectives, and resource constraints.
Achieving operational stability and project excellence are important components of a strategic IT organization. Each is complex and needs to be addressed separately. So in this week’s column I will focus on the governance model for operational stability. Next week I will focus on the governance model for achieving project excellence.
ACHIEVING OPERATIONAL STABILTY
Following is a graphic that depicts a Governance Framework for Operational Stability. There are four components that comprise the framework:
1. Guiding Principles
There are three guiding principles: a) Less is More; b) Sound Architecture; and c) Change Management Process
2. Measure What’s Important
Key metrics used to measure operational stability
3. Governance Process
Operational Stability and Remediation Processes that provide oversight to mitigate operational stability issues
4. Services Portfolio
The business services that support the business processes and associated support/technical services that are used by the business or support the business services
The following is some more detail for the Guiding Principles and Measure What’s Important areas. Future columns will focus on Operational Stability Remediation Processes and Services Portfolios.
1. GUIDING PRINCIPLES
Less is More:
You can significantly improves your operational stability by having fewer servers, routers, and other technical components. When I was a young boy in the 1960’s I worked at my father’s gasoline station. At 8 years old I was able to fix a flat tire, change the oil, tune-up and engine, and replace brakes. Cars were simple back then. When I lifted the hood of a customer’s car my car there was an engine block, battery, regulator, carburetor, electric coil, and a few other mechanical/electrical devices. If your car had an engine problem it was only a few items that could malfunction. Today automobiles are complicated machines. If you don’t believe me lift the hood of a 2012 automobile and see if you can identify any of the components. And when you open the car door on some models you can sometimes hear the “click” of the computer hard drive engaging.
Today’s automobiles are complicated electronics activated and controlled by computers. Every one of the components under the hood and throughout the automobile is an opportunity for failure. Now think about a data center and all the complex array of servers, routers, cables, etc. There’s even an opportunity for additional points of failure as you contract with multiple vendors who provide a variety of support and consulting services. The more components you have the more the chance for failure. The less components the fewer opportunities for components to fail. For an IT organization this means that you should strive for fewer hardware vendors, service providers, and vendor contracts to manage. Doing so will result in less of a chance for a malfunction and/or failure to occur. So remember…less is more.
A sound architecture is a necessity for all the information technology to work effectively as well as efficiently. Without a sound architecture operational failures can occur, systems may not operate efficiently, and the business could experience difficulty in conducting every day business activities. Let’s look at two examples of architectures that do not involve information technology. This will help you better understand the necessity for a sound technical architecture.
A Dysfunctional Architecture:
A great example of a dysfunctional architecture is Winchester Mystery House (http://www.winchestermysteryhouse.com/) in San Jose California. The home was built around 1890 by the architect Chris Gounalakis for a wealthy eccentric names Sarah L. Winchester. The house appears to be very elegant when you look at it from the outside. But when you go inside you begin to realize that the architecture is very dysfunctional. The sprawling mansion contains 160 rooms with 2,000 doors, 10,000 windows, 47 stairways, 47 fireplaces with 17 chimneys, 13 bathrooms, and 6 kitchens. There are windows that are built into the floor, staircases lead to nowhere, doors that open onto blank walls, and upside down posts. There is even a staircase which rises only nine feet. It has 44 steps with each step only 2 inches high. Imagine living in a house like this. Each room, staircase, and door are beautiful examples of workmanship but together they don’t function as effective living quarters
A Sound Architecture:
A CIO friend of mine told me about his company’s new corporate headquarters. When the board decided it needed a new corporate headquarters an architect was hired. The architect met with the board and executive team to better understand what they desired in a building. He asked them a set of questions. A number of major requirements were defined as follows:
a) The building should be have four floors
b) The building would house approximately 250 people comfortably
c) The elevator banks needed to be in a central location to make it easy for people to navigate the building.
d) Every floor required a kitchen with a microwave, industrial size refrigerators, plenty of counter tops and storage areas.
e) Restrooms should be conveniently located
f) Conference rooms and offices should have glass walls to evoke an open air environment
g) Sufficient electrical outlets and circuit breakers needed to be installed to handle multiple devices
h) Back- up generators were required in case of storms or electrical disruptions
There were other items identified as well. The objective was to make the work place as comfortable as possible to the employees as well as provide an open air environment to foster team work.
The architect drew up a plan and reviewed with the board and executive team. A number of changes were made and incorporated into the final architectural drawings. Before a shovelful of dirt was excavated the architecture drawings were finalized and agreed to by the board, executive team and an employee team representing all the employees. Everyone agreed that the plan was well thought out.
When the building was finished and company personnel moved in everyone was just astonished. Everything was perfect. Employees felt as part of a team. The glass walls of the conference rooms and offices conveyed an open environment and enabled effective teamwork. Everyone thought that a kitchen on every floor was a great idea and it proved to be a great informal meeting place. The building, as a number of employees stated, was “just the perfect place to work.” This is a perfect example of a planning a sound architecture -making sure all the pieces fit together logically.
The lesson learned from the Winchester House example is that on the surface everything looks fine. But once you are inside the house all the functioning elements-rooms, windows, staircases, fireplaces-don’t make any sense. The good news is that today the home is a tourist attraction and a famous landmark of San Jose. The second example of a newly constructed corporate headquarters represents a perfect example of how an architecture needs to be planned out and envisioned before any construction begins.
A sound architecture for your home and office is important. The same rule applies to information technology organizations. IT infrastructure is a complex array of equipment, wiring, hundreds of business applications, and other components that have to work in harmony for the business to run efficiently without disruption.But remember. The IT Architecture is no more than a mirror image of how the business operates. When business units don’t have a sound business model that reflects a set of seamlessly integrated processes that create value for its customers chaos will result. And what happens is that the IT organization ends up supporting a variety of business processes with applications and other business services that don’t connect, just like the hallways of the Winchester House. As an IT leader you can take the initiative to help the business understand that to have an effective IT Architecture required the business look at its business processes to make sure that they are aligned and support the business strategy.
Effective Change Management Process:
In today’s technology driven marketplace business applications, which support the day-to-day processes that operate the business, are very complex. As a result, IT organizations need to make sure that applications are only updated through a rigorous changes management practice. We all have experienced the scenario when a business application stopped functioning because a well intentioned engineer or developer had a great idea and said, “I can get this done real quick. All I have to do is change a couple of lines of code.” Well, guess what. Good intentions sometimes lead to unfortunate disasters. Here’s an example:
I remember when I was managing an implementation of a major project suite. We spent four months installing, configuring and testing before we released the solution to production, where the 2,000 employees could manage their expenses. Three days into production release one of the junior IT engineers had a great idea.
Some of the users experienced a lag time when entering certain data into the application. Instead of following the change management process- testing the fix on the developmental platform, then on the test platform, and then documenting and obtaining approval for implementation on production system- the junior engineer thought that he could fix the problem quickly by just changing some code on the production system. Well, you can guess what happened: the 5 minute fix brought down the entire application suite for 3 days. It was a mess.
The lesson learned here is to never make any code changes or even change any hardware components without a rigorous change management process.
Developers and engineers want to do the right thing. They have the right intent and right heart, but they will inadvertently change things. And things break. So make sure you follow a proven change management process.
2. MEASURE WHAT’S IMPORTANT
Cindy McKenzie is senior vice president of IT & Enterprise Application Services at Fox Entertainment. A seasoned executive, Cindy is a stickler about ensuring that the applications Fox Entertainment employees use on a day-to-day basis are up and running all the time.
Steve O’Connor is Vice President and CIO of AAA Insurance, He also is a stickler at measuring application performance and maintains a set of key metrics.
What Cindy and Steve have in common is that they only measure what’s important and communicate to the business on a regular basis.
In conducting research for my new book – The Strategic CIO- I’ve spoken to a lot of CIOs about the types of metrics they use to measure the effectiveness and efficiency of applications. Following are the four that are most commonly used in measuring operational stability.
Uptime- This metric measures the time that applications are available and functional within the parameter of the Service Level Agreement (SLA) agreed to with the business. For example, you have an online Customer Service Application (CSA) that the business requires to be up and running 24 hrs a day, 365 days per year.
This can be converted to 10,080 minutes per week ( 24 hours x 60 minutes x 7 days). The Service Level Agreement (SLA) for most customer facing applications fall in the 96-98 percent range. Let’s assume for this example that your Sales organization requires the CSA be up at least 98% of the time. This converts to 10,584 minutes per week (.98 x 10,800 minutes). This is the goal that your IT organization must strive to achieve.
To achieve a 100 percent uptime metric is very costly. You might need a second instance of the application or a back up data center and/or additional hardware and software. These are management decisions that need to be made based upon the investment required to achieve the 2 percent differential of a 98 percent and a 100 percent uptime SLA. Regardless of the percentage agreed to uptime needs to be measured, documented, and communicated to the business on a weekly basis.
One of the most significant challenges for the CIO is how to communicate the business value that IT personnel provide the business. It’s not just writing quality code. It’s about enabling the business to create value. A value metric most people understand is sales dollars. So you might want to consider measuring uptime not only in minutes but also in the sales dollars generated through the use of the application. This is a great example of how you can communicate the importance of maintaining the uptime of applications to your IT personnel.
You also should consider developing a “lost revenue” metric that measures the sales revenue lost as a result of the application not being available to users. This is not a difficult metric to calculate. You start with the revenue generated by the customer service application for a designated time, let’s say the last 12 months, and divide it by the uptime SLA metric as measured in minutes. Let’s look at an example
-Your company’s on-line sales for the last 12 months were 480 million dollars. The average monthly value of sales generated through the on-line customer service application is 40 million dollars (480/12).
-Your uptime SLA metric for the customer service application is 98 percent, which calculates to 10,584 minutes(as described above).
– If you divide the 40 million dollars by the monthly uptime metric of 10,0584 minute your result, rounded to the nearest dollar, is $3,780 of sales revenue per minute.
This means for every minute the customer service application is available for use it will generate, on average, $4,000.00 in sales revenue. The converse is also true. For every minute the customer service application is NOT available your company could will not generate the $4,000 in revenue. When customer facing applications are down customers will sometimes move on to a different company’s website to order product. Your company loses revenue. More importantly you may even lose the customer forever.
Remember, the goal of the IT organization is to work with the business to achieve business outcomes, in this example it is about generating sales revenue. That’s very important to the company. In fact, I know some CIOs who base a major portion of their IT Directors bonus compensation on achieving uptime SLAs.
Abnormal Terminations - This metric measures the number of occurrences that an application terminates abnormally over a specific time period. We all know someone who has experienced the infamous “blue screen” phenomenon on their computer or when we attempt to log into an application and it just doesn’t connect. These are examples of abnormal terminations. This is the most frustrating experience for users. These events must be measured, diagnosed, and fixed so they never happen again. The best way to do this is to elevate the reporting of these events to the CIO. This visibility gets everyone working to eliminate abnormal terminations. I even know of one CIO who keeps a file of abnormal terminations and requires the application owner to report on the root cause analysis and remedial action taken. In addition, the application owner has to provide the CIO proof that the particular cause of the abnormal termination will never occur again.
Performance – Performance issues occur when a user doesn’t experience the performance expected from the application. A customer enters the URL for your web site to inquire about product information and the system “hangs” for about 2-3 seconds before the web page materializes. It’s the longest 2-3 seconds one has ever experienced! We’ve all been there. Talk about frustrating.
The analogy to this is listening to a news broadcast on your television. Imagine if at the beginning of the 6:30pm news the news anchor does his/her introduction and then hesitates, not moving a muscle, and just stares at the camera for 2-3 seconds before saying another word. This is not very entertaining. In fact, it’s totally unacceptable and very frustrating.
What do some CIOs do to eliminate performance issues? They set up performance and tuning teams that pound away at an application to test its performance based upon the functionality parameters of the application.
Performance issues need to be logged, investigated, tested, and remediated. The key to eliminating performance issue it to test them constantly under different use conditions. So make sure you have a rigorous process in place which includes performance issue documentation, root cause analysis, remediation plans, and quality assurance testing. And make sure your report regularly to the business community as to the status of performance issues and remediation plans to mitigate future occurrences.
Defects – When an application isn’t performing as advertised then there is a defect issue. Let’s look at an example. A customer calls your customer service representative for some product information and at the same time wants to place an order. The customer service representative logs into the order-entry application and enters the customer name.
The application functionality was designed to automatically populate the account number, address, as well as other information so that the customer service representative doesn’t have to type the information that the data base already has recorded from previous transactions. In this example, not all the data does not pre-populate correctly. The shipping information and associated logistics routing information is missing. So the customer service representative has to ask the customer for the information and enter the data.
Upon completing the order entry process the customer service representative logs a ticket to the help desk to report the functionality issue. This is not only frustrating for the customer service representative but more frustrating for the customer who has to provide the same information communicated in previous calls. This results in customer relationships issues. So now you have a Sales VP having a very unpleasant conversation with the IT Director or even the CIO, depending on the customer, to figure out how the IT organization is going to solve this customer satisfaction issue.
Performance testing is a means to minimizing defects. Have you ever seen the automobile commercial where you see a car inside a enclosed room with its windshield wipers operating while rain and wind pound the vehicle. This is an example of performance testing. Business applications must go through the same rigorous testing process. The metric for measuring performance should be “0” performance issues. However, the reality is that with the complexity of systems today performance issues always occur. But the goal is to never have the same performance issue repeated.
A defect remediation process needs to be in place within your IT Organization. The teams need to analyze, determine root cause analysis, and eliminate defects. And don’t forget to report defects and resolution to the business community. The worst mistake you can make is to not communicate the status of defects to the business community. Remember, communication and expectation setting is a critical key component of building and maintaining a good working relationship with your business peers.
As the CIO or IT Director your number one issue needs to be the operational stability of the business services you provide the enterprise. This is the number one issue that IT organizations face today and in the future. The services you provide to the business are used each and every day to provide products and services to your company’s customers and business partners across the entire value-chain. These services need to be operational and stable.
The pace of change in today’s rapidly changing marketplace will result in business services being redefined, eliminated, and reinvented. Regardless of the business services you provide you will still need an effective governance model to ensure that these services are delivered flawlessly.
So remember the following three guiding principles and four key metrics that will enable you to provide operational stability for the services you provide to the business.
1. Less is More: The fewer components, hardware vendors, service providers, and contracts you have to manage the less chance there is for operational failure.
2. Sound Architecture IT infrastructure is a complex array of equipment, wiring, hundreds of business applications, and other components that have to work in harmony for the business to run efficiently without disruption.
3. Effective Change Management Process: Developers and engineers want to do the right thing. They have the right intent and right heart, but they will inadvertently change things. And things break. So make sure you follow a proven change management process
Measure What’s Important: Ensure that uptime, abnormal terminations, performance issues, and defects meet or exceed the service level agreements you business peers require.
So remember: if you have an effective governance model around you will earn the trust and respect of your C-level peers. You will also be able to partner with them to discuss their challenges and together develop solutions that achieve specific business outcomes that create customer value, increase revenue and ROI, enhance shareholder wealth.
Next week we will discuss the governance model for ensuring successful project execution.
I’d love to hear your feedback on this weekly column. I can be reached at email@example.com.
Phil Weinzimer is president of Strategere Consulting working with clients to develop business and IT strategies that focus on achieving business outcomes. Previously Mr. Weinzimer was Managing Principal-Professional Services for IT Business Management at BMC Software. He has also held Managing Principal positions in the Professional Services organizations for ITM Software, CAI, and Sapient.
Mr. Weinzimer has written a book concerning customer value entitled “Getting IT Right: Creating Customer Value for Market Leadership” and has a forthcoming book, “The Strategic CIO: Creating Customer Value, Increasing Revenue, Enhancing Shareholder Wealth”, will be available in 2013.
Mr. Weinzimer can be contacted at firstname.lastname@example.org