Beyond Blinking Lights and Acronyms

Gimme The Names

A lot of the projects that we work on are touted as being labor savings projects.  I say "touted" because often even though the projects are successfully implemented we never seem to see any reduction in labor costs.  Frustrated with this one of my old bosses used to have a stock reply to labor savings projects that usually went something like this:

Requester: If we do this project we'll save 80 hours of engineering effort per week.

Boss:  Gimme the names.

Requester: The names?

Boss: Yes, 80 hours per week is 2 people.  I want to know the names of the people that you'll be firing.

Requester:  (significant pause) Um, Uh, We weren't actually planning on firing anybody.

Boss: Well if no one is leaving how are we getting any labor savings?

Requester: We were planning on using them to do something else.

Boss: Before I'll let you "rehire" those 2 justify to me the merits of this something else.

The boss wasn't really on a mission to fire people but he did want to make sure there was a sound justification for what we were doing.  Fortunately there are some things you can do to make sure you get the economic return you were expecting.

An IT Question: Who Should Pay?

Now that budgeting season is upon us I thought I'd ask a question about who should pay for your IT services.

Should you charge your users based upon how much service they get from IT?  Will this drive them to the lower cost "shadow IT" with its inherent risks and problems?  Since they are paying will they opt out of programs and policies that are in the company's best interests?

Conversely, should IT be free with no charge to the users?  This may encourage them to use IT but will it be done effectively?

My question is "Who should pay for IT?"  What do you think?  How do you do it at your company and why?

"Help" photo by Cobber99

Got a question you'd like me to post for future discussion?  Email it to me using the "Email Mike" link in the left hand column.

If this topic was of interest, you might also like the other posts in the IT Question category.

Letting Users Set the Business Tech Agenda

A couple of items in a  recent article at Information Week called "IT Departments Will Set Less Of The Business Tech Agenda, Survey Suggests" caught my attention. 

"Business users want more innovative software faster and will bypass the IT department if necessary to get it."

"In some cases, the research also shows IT organizations turning a blind eye when business units take risks with smaller, more innovative approaches to software."

No doubt this is a worrisome trend for many in IT.  We sit back and say sure the centralized, integrated approach may take a little longer but if we do it we can have better information, we can have a more complete insight to our customers, we can . . ., we can. . ., we can . . .

What this brings to mind is the old riddle about 4 frogs sitting on a log. 

Q. Four frogs are sitting on a log.  Three frogs decide to jump off.  How many frogs are left on the log?

A. Four frogs.  Deciding to do something and actually doing it are not the same thing.

Likewise, software that can provide what is needed is not the same as software that does provide what is needed.

IT Governance: Issues and Opportunities

I recently ran across a report by PriceWaterhouseCoopers (PWC) called IT Governance in Practice, Insight from leading CIOs.  They interviewed 47 CIO from around the world with what was considered to be mature IT governance processes in place.  The reasons given for implementing an IT governance processes frequently included:

• "Need for IT alignment (60% of the participants);
• Regulatory pressure, e.g. Sarbanes-Oxley (40% of the participants);
• IT Governance is a natural followon from Corporate Governance projects and is enforced by Board/Executive management or headquarters (53% of the participants);
• An identified need for Performance Improvement, e.g. cost of IT, lack of effective solutions, efficiency gains (from a reduction in duplication) (56% of the participants); and
• Improved risk management (37.5% of the participants)."

I don't expect that anyone is surprised by these results.  Fortunately, PWC doesn't stop at just telling us what we already know.  Also in the report is some useful information on obstacles to implementing an IT governance process and, perhaps most importantly some critical success factors.

An Unexpected Obstacle to Forming a Business Analysis Group

In the last post I talked about forming a Business Analysis group to provide a strategic service of helping the business operations to better utilize technology.  In talking about this concept with other people I was surprised to hear of one significant obstacle to implementing this.

A friend and fellow CIO was set to implement this concept.  He had support from top management and the business units and had started to interview candidates.  However under intense pushback from within the IT group he decided to postpone the implementation.

Sometime later I was talking to the president of a large company.  This president liked the concept but was concerned about the effect of it on the IT department.  To my surprise this president raised the same objection as my friend's IT staff had.  Wait a minute!  A company president and the IT staff having the same concern?  This seemed like a very unusual situation.

And just what was this objection they had in common?

Let's Not Bring IT into this

Jeffrey Phillips recently raised an interesting topic about his customers who want to implement his software applications but say "Let's not bring IT into this".  As he notes:

What stuns me is the number of times I'll hear "can we do this without IT" or "let's not involve IT if we don't have to".

I left a comment on his blog, but in thinking about it some more I thought it warranted further discussion.  Many thanks to Kent Blumberg for bringing this posting to my attention.

Make no mistake, this is a common problem.  In looking at it, two questions come to mind:

1. What causes this?
2. What can a CIO / IT department do to change this attitude?

Jeffrey believes this is caused by both the business user and the IT guys.  On the business side he voices frustration with the IT guys saying it wasn't in the budget or we don't have the resources therefore you can't do it.  To me that is a symptom of the business not adequately explaining the situation.  In these situations IT is just the front man for the CFO.  What IT has been told is to work on the things that matter which evidence to the contrary are the items in the budget.  If the project truly has a better return than the competing projects it will get funding and staffing regardless of its budget status.  No self-respecting CFO would fund a lower return project instead of a higher return project just because it was in the budget.

From the IT side the problem is, I believe, a lack of understanding.  Isolated in our cubicles we have no idea of what the business is doing, why they are doing, or how we can help.  IT is more than providing PC and routine maintenance of applications.  We tend to view our role as merely technical and don't want to get involved.  It's more "tell me what you want" rather than "how can we use technology to improve the situation".

OK, so what do we do about it?  Here are some of my suggestions:

Business guys -

• Make your case!  Make sure you have you a strong justification of why your project needs funding.  Kent Blumberg has laid out some guidelines for making sensible capital investments.  A strong factual case goes along way in getting support from both IT and the CFO.
• Involve the IT guys early in the process.  Drag them kicking and screaming if you have to but force them to get involved even if they don't want to.  Let them know you need their help and support and don't let them go without getting it.

IT folks -

• Get involved!  Don't wait for an invitation.  Go out and learn the business, talk to the people, learn what their issues are and how you can help.
• Change the rhetoric.  Instead of talking about what we can't do let's talk about what we can do.  There is always a different approach.  If one won't work, what will?

If both the business guys and the IT folks make a concerted effort to communicate and get involved in issues together maybe we can get everyone saying "let's run this by IT" instead.

What are your suggestions?

If this topic was of interest, you might also like these:

• Creating Customer Loyalty
• Why It's Time to Lose the Snide IT Attitude
• ITBWA - IT By Walking Around
• Or the posts in the "Customer Service" category

Ready, Fire, Aim

Once a project is approved and funded we sometimes get over eager to start the full-blown implementation as if planning, preparation and experimentation was of little value.  In his blog post The Toyota Preparation System or the “Bank of Preparation” , Jon Miller paraphrases Jeffrey Liker's The Toyota Way: 14 Management Principles From The World's Greatest Manufacturerwhen he says:

". . .a typical company will spend three months in preparation, nine months in execution and as much as another year working out the bugs in the system."

Sound familiar?  Ready, Fire then Aim!  This is very frustrating for everyone involved, both for the implementation team and for the key stakeholders.  As a former colleague of mine used to say.  "We don't have time to do it right but we have time to do it over."  In one of my first posts I commented that I felt the key to IT success was: Communicate - Execute - Adapt.  Let's be clear, a year working out bugs is not adapting.  Adapting is making things that work, work better.  It is not fixing things to make them work.  The key here is Execute - doing things right and doing the right things.

By contrast, Miller continues on

"Toyota will prepare for nine months, execute in three and have worked out the bugs in advance."

Although we can all appreciate the logic of this, the plain fact is that unless you are fortunate enough to work for a company that has truly embraced the Lean philosophy most of us don't have the luxury of doing it this way.  Part of the reason is that often the stakeholders interpret a flurry of activity with lots of people involved as progress and similarly few visible signs of activity are interpreted as a lack of progress.

Short of getting the company to adopt Lean (an admirable goal but rather impractical as part of an IT project implementation) what can you do?  Some suggestions:

1. As part of the approval process feature the planning, preparation and experimentation efforts as part of the process to ensure a successful implementation. 
2. Control expectations.  Get stakeholder buy-in about how you will implement and what they can expect to see and when.
3. Use Ready, Fire, Aim as an a trial or experiment so you can adjust before you get in to the full-blown implementation.
4. Communicate - make the planning and preparation visible.  Make regular reports to the stakeholder about what you are doing.  Report the results of your trial and error experiments - what you learned worked and what didn't work.
5. Last and certainly not least - start the ball rolling on adopting Lean.  Maybe, just maybe, it will help on the next big IT project.

What are your suggestions?

LBJ Was Right! - (Mastering the Three Worlds of IT - Part 2)

In an earlier post I talked about the first of two themes in a paper entitled Mastering the Three Worlds of Information Technology written by Andrew McAfee .  This is in the online version of the Harvard Business Review which is providing free access (at least for now).  The 2 themes are:

1. Non-IT management is critical to the successful implementation of projects
2. He presents 3 models of IT and discusses the implications for management in terms of which they should invest in and what they should to maximize returns.

Now on to the second theme.  The 3 models are:

1. Function IT (FIT) These are stand-alone technologies that make processes more efficient.  Examples include spreadsheets and engineering design programs.
2. Network IT (NIT) These are the technologies the interconnect people and allow them to communicate with each other.  Examples include email and groupware.
3. Enterprise IT (EIT) These are the technologies that companies use to add structure to how groups of employees or the company and their business partners interact.  Examples include CRM and ERP systems.

McAfee argues that FIT and to a large extent NIT projects are usually implemented easier and more successfully the EIT projects.  The reason for this is that with FIT and NIT it is often the users that select the technology and the usage is voluntary.  McAfee gives the following example, "an R&D engineer can use a computer-aided design (CAD) program to improve the way he does his work without making any changes in how the rest of the department functions."

Conceptually I agree with McAfee but there are difficulties in the practical application of this.  Taking his example a further step.  What happens when one engineer using a CAD system hands his work off to another engineer who has selected his own FIT, another CAD system that is incompatible with the first engineer's?  So, is such a system a FIT or should it be an EIT?  Sometimes it starts as a FIT and evolves to an EIT.  The application issues of the selection /adoption / exploitation techniques become much less clear in the real world.

By contrast McAfee states EIT projects often need top down control that require employees to accept the system but even then push-back is often strong enough to cause the project to fail.  He states:

"The biggest mistake business leaders make is to underestimate resistance when they impose changes in the way people work"

By way of example, he cites a example of a hospital that set up an IT system for online ordering of prescriptions to replace handwritten orders.  The advantages would be:

• instant checking of orders for harmful doses or drug interactions
• demonstrated ability that the system would reduce medication errors

The doctors complained and refused to use the system citing:

• the computer based system was slower
• the computer system was inconvenient
• the built-in error checking didn't work

As a result the new system is used in only a few departments and most doctors continue to hand write prescriptions and fax them in.  He states:

"The system's champions were caught completely off guard by the doctor's reaction to the monitoring and standardization capabilities that the hospital sought"

I just have to believe that the doctor's had no problem with the project objectives and no doubt whole-heartedly endorsed them.  How this was accomplished is another thing entirely.  In this case it seemed to me the problem is obvious by the phrase ". . .system's champions were caught completely off guard by the doctor's reaction . . ."  The problem is that the champions and the users (doctors) are two different groups.  Why shouldn't they be one in the same?  As McAfee goes on to state:

"The most important participants in this task are not IT specialists or consultants but business leaders from the areas affected by the new technology."

Perhaps Lyndon Johnson said it best (and in my plain way of thinking, most eloquently)

"Better to have 'em inside the tent pissin' out than outside pissin' in."

What are your thoughts?

IT Outsourcing

Outsourcing has been an issue within IT for quite a period of time.  With the kind of familiarity we have with outsourcing, you might think we would be much better at it.  At a recent meeting of the Houston chapter of the Society for Information Management (SIM), Mark Peacock of Archstone Consulting briefed us on the results of a various analyses that Archstone had completed in conjunction with the Aberdeen Group and also Duke University.

Mark reported that based upon a survey with IT leaders on the various types of IT outsourcing (data centers, IT security, data network management etc.) the level of satisfaction was rather mediocre. Typically about 50% of the respondents indicated an adequate rating with 20% to 35% giving a rating of poor to sub-optimal leaving only 15% to 30% with ratings of above-expectations or excellent.

It will come as no surprise, I'm sure, that reducing cost is the biggest driver behind outsourcing.  I suspect that this intense pressure for cost savings has in many cases led to situations of inappropriate or poorly negotiated/managed outsourcing deals.  Quite logically the satisfaction with outsourcing will be rather low in these cases.

The lesson I took away from all of this is that CIO's need to be in the forefront of the outsourcing movement to make sure it is used correctly and strategically.  If we don't we are in danger of being bowled over by the quest for cost reduction by any means and find ourselves forced into bad outsourcing deals.

The key to this is a careful analysis to determine what can and should be outsourced versus what should be kept in-house. Mark presented an excellent graphic that highlighted the various component that are potential outsourcing candidates:

• Controls - such as Program Management, Strategic Planning and Risk Management
• Applications - such as EDI, Web, Financial Applications
• Infrastructure - such as Unix, Storage Area Networks, email
• Common Services - such as Requirements Definition, Training
• Common Processes - such as Project Management, Asset Management, Capacity Management

As CIO's we need to go through each of these to determine which are strategic and need to kept in-house and which are tactical and could be outsourced.  Along with that we need to work through the economics and justification for our decisions.  Which components fall into which category of course vary by company and industry.  This is not simple task but the alternative may be having to live with a bad outsourcing arrangement that was forced on us.

What are your thoughts?

Show Me the Money - Getting Your Project Funded

Getting your project approved and funded is never easy and it even more difficult when you don't know how to best present your case.  We in IT seem to think that if we throw in enough system architecture diagrams and festoon the proposal with acronyms the merits should be obvious.  The results say otherwise.  In regard to the use of acronyms refer to Schaffner's Rule of Communications to Someone in a Different Profession. However, this alone isn't enough.

For a good outline of how to prepare proposals for capital spending check out Kent Blumberg's blog post on "Making sensible capital investment".  If you follow these guidelines you just might find you have a higher success rate in getting project funding!

Mastering the Three Worlds of IT

Andrew McAfee has just published an interesting paper entitled Mastering the Three Worlds of Information Technology in the online version of the Harvard Business Review which is providing free access (at least for now).  There are 2 major themes in this paper:

1. Non-IT management is critical to the successful implementation of projects
2. He presents 3 models of IT and discusses the implications for management in terms of which they should invest in and what they should to maximize returns.

For the sake of brevity, I will only discuss the first theme in this post and will defer discussion on the second theme to a later post.  Nicholas Carr has also reviewed this article in blog posting entitled "Too Many ITs".

Carr states that McAfee’s argument "that IT success in business today is less about technology than about good old-fashioned management is not new."  While this point may be important in terms of an academic review I think the concept is one that bears repeating.  The reason I say this is that many still do not understand this point.  At the risk being accused of repeating an overused cliché, success in implementing new technology really is about people, processes and technology.

McAfee states:

"I believe that executives have three roles to play in managing IT: They must help select technologies, nurture their adoption, and ensure their exploitation."

McAfee goes on to clarify:

"Everyone who has studied companies' frustrations with IT argues that technology projects are increasingly becoming managerial challenges rather than technical ones. What’s more, a well-run IT department isn’t enough; line managers have important responsibilities in implementing these projects. An insightful CIO once told me, “I can make a project fail, but I can’t make it succeed. For that, I need my [non-IT] business colleagues.” Managers I’ve worked with admit privately that success with IT requires their commitment, but they’re not clear where, when, and how they should get involved."

Amen Brother!

I believe that many people view new technologies as a silver bullet – If I install this software my salesmen will be more effective and sales will go through the roof!  Unfortunately, we in IT are often guilty of fostering this misperception in order to “sell” the project.  Under the silver bullet approach technology implementation solely equals IT installing software.  The truth is that technology implementation is really communication, process redesign, organizational development, training and employee and management involvement at all levels both inside and outside of IT plus IT installing the software.

I believe this is a concept well worth repeating as often as necessary.  What do you think?

To Be Continued . . .

Developing a Credible Business Case

Lewis Cardin of Forrester Research recently published a Best Practices paper entitled “CIO Success Depends On A Credible Business Case” (October 2, 2006).  In it he makes a strong argument that CIO’s need to make a compelling and credible business case for why a project should be approved.

 

Mr. Cardin cites as one of the critical steps:

“Align IT and business terminology as Step One. Before focusing on the financial aspects of a business case, make sure that IT and the business agree upon a common set of terms that define the logic around the business case. A large US pharmaceutical company learned that the use of a common language for business case terminology is the most important first step in preparing a credible business case process.”

In other words, we in IT need speak in the language of our audience.  Drop the IT jargon and approach the project as a business person.  If we do, I think we’ll find a much more receptive audience.

 

What are your thoughts?