Metrics for IT Risk Reduction

Metrics mean different things to different people.

What does the word mean to you?

A Metric is a 'standard of measurement'. And you can't manage what you can't measure. I submit that without visibility provided by accurate Metrics, Govenance is impossible.

Knowledge is correctly understood and assimilated Information.

Information is correctly and logically structured data.

Data is (are) Metrics collected ..... When, Where, How, Why, and by Whom in your area of responsibility?

I'm curious about your view of this sometimes emotive subject!

A model that I notice many times is to Outsource Applcation Development, and keep Legacy Systems Support in-house (the day that an Application goes live is, by definition, a Legacy System). Also, expensive consultants are often used to define and manage the building of new Applications.

What if this model was turned on it's head?

If you used your staff to define, build, test and deliver new Applcations/Systems, and outsourced the Application Support, the benfits would be:

• Delivery if a Fit-for-purpose application built by staff that understand your business
• Increased staff morale (retention), as staff get to do the 'sexy' new stuff
• Reduction in support costs, which should be outsourced in a fixed-price basis
• Reduced risk of delivery failure due to application knoweldge being retained in-house

The majority of IT spend goes on IT Production Systems Support. Surely we have a duty of care in the industry to seriously consider acheiving savings in an area that consumes the largest part of our budget?

We've all heard the one about when you're up to your eyeballs in alligators, it's hard to remember that your initial intention was to drain the swamp.

Meeting your SLAs can be viewed this way. Breathing a sigh of relief that you've met all your targets for the month, not incurred any penalties (or the wrath of the board), and responded to problems in a timely manner may seem like success. After all - is'nt that doing your job properly?

I respectfully submit that in the current climate, a performant and proactive CIO needs to have a different mindset, and that is not to have the problems in the first place.

You've got the visibility of the status quo, and you are managing the ensuant risks. So let's work to remove the risks completely. I know it's hard to optimise any endeavour with the pressures we're all under - and it's so hard to take the time to challenge the status quo. But this is the next step that must be taken. Zero-defect fixes are just one step on the road to having no fixese to make.

It's all about going from being reactive (behind the 8-ball) to being proactive (in front of the 8-ball). It won't be easy, and you will not have many supporters - no-one embraces change easily.

As food for thought, and still relevant today, Machiavelli wrote in 1513:

"There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage, than the creation of a new system.

For the initiator has the enmity of all who would profit by the preservation of the old system, and merely luke warm defenders in those who would gain by the new one"

The next step? Be unhappy with the status quo, and strive to make things continually better. Perform root-cause analysis and start on the road to continual improvement.

There are a minority if individuals in IT that are happy to spend their time maintaining often old legacy systems. They've been there for years, indeed in some cases seem part of the furniture. However, it is my opinion that systems maintenance is seen by the majority as a 'dead-end' or non-sexy job within IT. The 'action' is on new IT projects.

But who does what? How do we use those individuals that have been there for years (with their knoweldge of the business and it's culture, built up over a long period of time) and use their knowledge on new projects so that the solution truly is fit-for-purpose?

I respectfully suggest that legacy systems/applications support is a prime area for outsourcing for the following reasons:

• Existing staff will, for the most part, have a much greater sense of job satisfaction working on new solutions (with an ensuant reduced attrition rate), and will not be considered the bottom of the IT 'pile'.
• Existing staff understand your business.
• Legacy systems being replaced require a finite 'hump' in support while the new system is being written (sunsetting).
• The Risk is low, because in the unlikely (?) event that the outsourcer does not deliver, your support capabilities are still available in-house to back-stop
• Good outsourcers of legacy systems application and system support should have a proven track record of managing maintenance activities, and have mature processes and toolsets to bring to the table (with solid references to support).
• Good outsourcers should be able to give you a Fixed Price, against existing SLAs, with savings up to 30% on your in-house costs
• You should only outsource stable, repeatable activities - and legacy systems support is a prime candidate. (Don't outsource to get something fixed - it will cost you a fortune in Change Control.)

Summary: Outsource the non-Sexy IT jobs that are stable and repeatable. Value the knoweldge of your long-standing existing staff and give them the 'sexy stuff'.

I'd like to carry on by discussing Output based Contracts - but that's a topic for aonther day!

Back in the days of punched cards, paper tape and a computer that filled a room, a much bigger portion of IT cost was the 'Tin and String'. Users accepted that new functionality took months to implement, that they had to take what they were given (and work pretty close to the 'Mainframe'), and that complaining was not the order of the day. Programmers ruled, and Users simply accepted their fate.

In many ways we've come a long way since then. The cost per functional unit of any IT solution has dropped dramatically. Users can now pretty much get what they want off the shelf (COTS?), and don't expect to wait very long or pay very much for it. Also, the power of computing that we all expect at home puts a lot of pressure on the work IT department to deliver powerful, fast and fit-for-purpose solutions.

CIOs have to deliver faster, cheaper and more reliable solutions, while being business-intimate and responsive to the demands placed upon them. Supporting (maintaining and importantly upgrading) existing solutions to keep pace often puts extreme pressure on any IT department staff. Notwithstadning this, I'd like to throw another 'curved ball' into the mix. With a large portion of the 'Baby Boomers' about to retire - just how is Knowledge of the existing Systems and Business Knkoweldge going to be retained? Also, with the current squeeze on existing headcount, some knowledge is just being 'laid off' out of necessity.

I'd be interested in how you are addressing:

• Application Knowledge Capture to keep those legacy systems running, enhanced and stable (the day a systems goes into production, it is, by definition, 'Legacy')
• Business Process Knowledge Capture to stay up to speed with being able to support your business and understand is current and every changing needs.

I heard an interesting comment by Warren Buffett, the world's second richest man, last week defining the difference between Success and Happiness. "Success is Getting what you Want, Happiness Wanting what you Get". Applying this to IT, are your Users Successful and Happy? Are they getting what they need, and needing what they get? In my last blog I noted the dicothomy between how we in IT perceive our delivery, and how the business perceives our delivery.

The ultimate dilemma is how to continue to be business-intimate when we are facing losing those all-important staff that are either about to walk out the door to enjoy a (hopefully) long retirement, or simply become a growing portion of the 'at risk' statistics. Some of these staff have been around for years, and I would like to propose that in many cases, their knowledge of your business is more important than their IT skills, which is often what we predominantly measure them on.

Business Knowledge is every bit as important a metric as Application or Systems Knowlege. The business is comprised of human beings with business knowledge - but without an understanding of that knoweldge, or the ability to get it, document it and use it within IT will seriously let 'our' side down. We are no longer just Techies or Geeks that can impose our will on the businesses that we rely on for our bread and butter.

At a conference last week, Peter Hinssen stated that "... no-one uses the phrase 'Knowledge Base' any more. It's a dirty word." Perhaps a business collaboration tool similar to Facebook (we all know how to intuitively use that and it's intrinsic value) would enable a business to build a Knowledge Base in real-time by the people that acutally understand the business? But that's another topic ... recognising that a gap exists takes us half-way towards solving it.

Human Capital is every bit as important as Technical Capability.

Now, as it's my birthday, this Human is popping down the pub to practice his technical ability in turning a Vector into a Scalar.

If all projects were the same, then we could run them like an assembly-line, with very accurate estimates to complete, and low delivery risk. But 'if' is a big word. Some environments encourge risk-taking, while others simply cannot tolerate any risk. I do, however, suggest that some principles can be applied to all Projects to minimise if not mitigate the risk of failure, over-run or cancellation.

You don't know what you don't know .... and it's what you don't know that comprises the majority of risk exposure. A Risk is just an Issue waiting to happen. If all projects had the same risk exposure, duplicating success would be easy.

I like Dr Robert Charette's statement that 'No project was ever cancelled quick enough'. By the time you've got enough information (not just data), and the knowledge to make a decision to cancel, you've been burning money and time. I suggest that timely and accurate metrics are therefore paramount for all projects. If the project is'nt important enough to know it's exact state - then why is it still running?

My hobby for many years was building my own airplane. I was constantly amused to see ads in the magazine for homebuilders stating 'for sale, project 80% complete'. Having spoken to many of my friends who have bought a part-built project, the ad should have read 'for sale, project 80% with 80% to go'. OK, tongue in cheek ..... but I bet you've worked on projects like this! I had a Porject Manager many years ago that would not let me declare a Work Package as over 50% completed until it was.

If you have a project that cannot tolerate failure, you must put in place a regime that will give you early and accurate warnings that it may be coming off the rails - before it does.

How many Projects are planned, estimated, a Risk Map produced, and then it put on the shelf to gather dust while the project quietly becomes just another failure statistic? I certainly know of many Lessons Learned documents that have met this fate.

No matter how good the Project Initiation is, without accurate and timely Oversight and Gevernance throughout the Project execution, the risk of Project Failure is still high.How many times can you afford to get it wrong?

Is it sufficient to publish a mission statement starting "to be perceived as the best in the IT industry at ...."? I once took exception to this approach, believing that delivery against documented Service Level Targets using industry-recognised Project Management reporting tools was sufficient to prove that I was meeting my customer's needs. I also considered that the end users if the IT solutions that I was responsible for providing were the only persons that really mattered. I viewed my staff (and indeed my colleagues on the board) as only a vehicle to deliver against my measureable objectives; the former to provide working systems, and the latter to agree to my business case for capital investment to provide those working systems.

In IT we love to measure 'things' to prove to the world that we are delivering. It's in the nature of our profession. We rarely consider the import of Moore's Law, which states, depending on which idiom you agree on, that "... any measure, when used as a target, ceases to become a good measure". So, even if we are measuring those things that we believe are adding value to our customers, are these measures a true reflection of actual fit-for-purpose delivery?

Only a picture of 'hard' delivery metrics from project reporting tools, tempered with a picture of 'soft' metrics of our current customers perception, reported against similar if not identical Key Performance Indicators, can provide us with a balanced picture against which to truly understand a genuine 'status quo'. I believe that most Balanced Scorecards do not embrace enough of the 'soft' metrics. Why is this? Is it that our finite occupation does'nt understand them, or simply that we don't trust them?

I was once happily reporting excellent delivery against my targets to the board, to be told by more than one of my fellow directors "that's not what I'm hearing ....". I was blind to what they were hearing ..... I was too busy 'meeting my targets'. Only armed with an up-to-date Customer Satisfaction Survey did I realise that I was indeed meeting my targets, but those targets were not relevant and business-oriented, and therefore not providing what my customers really needed to support their business needs.

Fixing what we perceive as technical problems on an IT production platform may not fix those perceived business support problems being experienced by our customer.

Not too long ago, a study reported that over 50% of IT staff believed that they add value to the business. However, over 50% of those business users did not believe that IT added value to their business.

I respectfully submit that there is a Perception Gap here which needs to be addressed if IT is to be considered a true business partner in the reality of today.