Monthly Archives: August 2011

Do You Give Permission To Collaborate?

Early last week, several news outlets, including the New York Times published articles about Ford Motor Company and Toyota Motor working together to jointly develop hybrid fuel systems for trucks and sports utility vehicles.

Each of the news releases I have seen emphasize how this agreement could help reduce costs in developing new technology, along with the possible applications and uses of the co-developed technology.

Collaboration

What this joint agreement is really stating is that both of these organizations have agreed to collaborate on the development of this new technology.

As a leader, the question that I want to ask you; Do you give permission to your teams to collaborate in this way?

I ask this because this collaboration between Ford and Toyota happened because;

The partnership sprang from informal talks between the chief executives of the two companies, Alan R. Mulally at Ford and Akio Toyoda at Toyota, that began when the two accidentally crossed paths at an airport

We can only imagine the conversation; “I’ll have my people call your people….” But I think two corporate CEO’s doing this provides a clear message that collaboration is important.

Note: While this draft was being written, this article came out by IT World Canada on how lack of internal collaboration can harm your business – a great read.

 

 

Renovations, And IT?

A Brief Story

A few years ago, a fiber glass shower unit in our en suite bathroom developed a crack. It seemed simple enough at the time, we called our trusted contractor of choice and asked for it to be replaced.

Of course, that is when the proverbial crap hit the fan.

The shower insert? it had been custom built, and was not a standard size ‘off the shelf’ unit that could be directly replaced. We also found out that custom ordering a replacement unit would be more expensive than just building a custom ceramic tile shower.

But of course! the added width of the new tile side wall of the shower meant that about six inches of bathroom counter top had to be removed, which did not work due to the counter placement of the two sinks. So, next we add new a counter and new sinks.

Next, what about the existing ceramic tile on the floor of the bathroom, can we match the new tile shower with it? No – that tile was discontinued a decade ago, plus there was 12 inches or so of the floor tile that needed to be cut out to build the new tile shower….. So lets add new floor tile as well.

A cracked shower unit meant a complete bathroom renovation.

And in Small Business Technology?

It happens there too. This device won’t work with that software. Or that software can be used if this thing is added.

You try and plan as carefully as you can, but it still comes around once in a while and bites you in the backside. This is a reason that large organizations have definite standards in their network architecture and dedicated interoperability requirements.

For us in smaller businesses – it is a good reason to have a dedicated relationship with your vendors. You really want to know these issues up front. Because you don’t want to get caught half way through what you thought was a walk in the park.

On Total Cost of Ownership (TCO)

Several times I have used the term Total Cost of Ownership or TCO in posts on this blog. For this particular post, I want to define it a little better, and show how it can affect SMB’s in their IT Costs.

Technology research firm Gartner Group coined the term back in the ’80′s as a cost analysis model for measuring the costs of an IT asset over its entire lifecycle. At one point they even had a Compact Disk based program that allowed businesses to plug in their IT costing numbers and the tool would assist in qauntifying this TCO.

I have generally used the term TCO only in reference to purchasing physical devices such as computer hardware, although the original TCO toolsets were designed to support acquisition of larger IT ‘systems’ such as complex software that consist of both software and hardware components etc. For these larger, more complex systems, the tools were not perfect, as they do not account for true derived value (eg one system may have a significantly higher cost, but also a significantly higher benefit) and they also could not account for time value of money and other quantitative financial measures.

So does TCO matter?

The answer is yes. The concept of Total Cost of Ownership is still key for managers in the small to medium business because it forces us to stop thinking that the initial purchase price (one direct cost) of any IT asset is the actual price that you are going to pay.

Your purchase price does not include the ongoing and often hidden costs (indirect costs) that accrue with an asset over that assets lifecycle. When purchasing any IT asset. (including something as simple as a single personal computer) These direct and indirect costs will include both dollars and time in;

• Planning and acquisition
• Deployment
• Management and support
• Retirement/replacement

Direct Costs

The direct costs are the easiest to understand and at least some of them are the costs we usually associate as the common expenses of the IT asset purchase. These can include capital expenditures or lease fees for servers, or other IT assets. The labor required for deployment or any potential professional services or outsourcing fees. Direct costs can also include budgeting for help desk labor hours, training labor etc.

Indirect Costs

Indirect costs are generally a little more difficult to categorize. These type of costs include assumed costs for providing ongoing support through a concept called “shadow” support. (when advanced and skilled users provide support) For example, the mail-merge expert helps out other staff members get mail-merges working correctly. And secondly there is the calculation of downtime. This refers to the lost productivity due to planned and unplanned system unavailability.And it is this hidden downtime factor that I have written about.

The quick note takeaway

The actual calculations in the TCO toolsets will vary by large amounts depending upon your industry, and your level of IT maturity – in other words, the more automation in your IT operations, the less expensive this total cost of ownership can be.

But as a general average, Gartner provided this little rule of thumb; On average, consider your indirect costs to be approximately five (5) times the direct asset purchase price – per year. (yes – annually!)

The Danger!

Here is the danger. Using the above rule of thumb, you calculate that the powerful business class name brand laptop with lots of processing power, RAM, DVD-R, and huge disk space at $2400.00 will have a full TCO cost over five years of about $12,000.00

So you look at the Bill & Teds computer Co. No-Name special unit at $400.00, which over the same five years would only be about $2000.00

However, if you do this, you actually risk increasing the TCO cost due to the indirect costs listed above. Lack of productivity, downtime as substandard componenets fail, upgrades trying to get the device to improve. (see this previous article) All of these indirect and hidden costs can dramatically increase the cost of that asset over its lifecycle.

Update: Some newer numbers on TCO by Gartner are referenced here

Cheaping out on SMB IT

A short article by Courtney Ruben at Inc. titled; Study: IT on the Cheap Causes Problems echoes my thoughts on IT spending in the small to medium business. One example in this article outlining how SMB’s can leak dollars out of their IT spending.

The above by Courtney Ruben article gives a few statistics, but lets take a quick look at this one;

The most needed upgrade: Faster processors, cited by over a third (35 percent) of businesses.

Upgrade

That is the deadly part as far as IT costs right there.Pennies

Faster processor, more RAM – it does not matter. What matters from a cost perspective is the lost productivity from sub-par gear in the first place, and then the cost in time for IT staff to perform that upgrade while another business staffer sits on their hands during that same upgrade process.

Sometimes trying to save pennies will cost you dollars.

Photo Credit DaMongMan via flickr

On Time, On Budget (But Irrelevant)

This should be shocking to me – but unfortunately,  - well,-  it is not. Let me quote;

As far as IT was concerned, the project went well because it came in on time and budget – the other issues were irrelevant. But for the other departments, they could only see the issues that had caused them major problems.

Now, this particular story is written specifically about an Enterprise Resource Planning (ERP) installation – but the point I want to make is that this weakness happens too often in many aspects of IT.

Let me emphasize this with an earlier quote from the same piece;

I had the chance to talk to the IT manager on site…. there was a definite sense that he was as far as he was concerned, their project had gone very well indeed, and he was more than a bit proud of that.

You see the problem.

Read the article, IT says project was perfect, everybody else is fighting through data and performance issues. To me, this is an IT leader playing dump the chump games. Something along the lines of;  ‘hey I did what I had to do – any other issue is your problem!’

The SMB Takeaway

This is a case where an IT Manager needs to be sat down for a little chat about performance improvement.

The quality of all IT service delivery is not nestled solely into the on time / on budget line item of any initiative or project.

IT Service Delivery is IT responsiveness in all aspects of your business. IT leadership must be looking at the entire realm of the delivery of your technology services. If the service delivery is not working – the service is not working. Period.

If IT says the “server is there”, however no one can access the “server” – guess what – it ain’t there. This is like a mechanic saying your car is working because the engine is running. Sure the engine may be running but if the transmission is dead or the wheels have fallen off – the car is not running.

As the above author pointed out, this happens when people myopically view their own small, specific area, with no thought given to the bigger contextual picture.

Do not allow your IT leadership or teams to fall into this trap.

Photo Credit Paul Menard via flickr

We Can’t Describe What We Don’t Understand

There is a quotation attributed (I believe) to Henry Ford, which simply stated that if he had asked people what they wanted in mobility – they would have just wanted a faster horse. And more recently, unless you are in Steve Job’s inner circle at Apple (AAPL) if you were to describe your perfect idea for an MP3 music player, your description would not likely have been the iPod.

Quite simply, we cannot describe things we have not seen or imagined, and secondly, we cannot describe things for which we do not have the vocabulary. And I am not disparaging anyone’s intelligence with that term – a PhD in Mathematics and a PhD in Economics will have different uses of language and differences in vocabularies.

And this is an issue that we live with frequently in the technology field – it is too easy to fall into this vocabulary or unknown unkowns trap.

In IT?

We call them Requirements Sessions or Business Analysis sessions. Somebody in a technology field attempts to pin down the steps or processes that your top sales folks use in an attempt to improve software work flows, generate requirements etc.

And this lack of a shared vocabulary or end state vision is where the problem can lie. The IT folk have a difficult time understanding the sales teams vocabulary, and the sales teams eyes glaze over when IT tries to paraphrase it technical or process lingo.

Heaven knows that I have run into this more than once, So let me demonstrate how easy it is to fall into this trap, while avoiding technology completely.

Our Story

My dearest spouse was doing some shopping. At one point she called me on the phone and asked me to measure the box spring in our bedroom, in her words; ‘measure it from one side to the other‘. I explained that our box spring  was King Sized, so the size should be standard. My wife insisted that this measurement of the width of the box spring was required, I asked her to give me a few minutes, I would  grab my trusty tape measure and get the measurement. (it was 75 inches)

As scheduled, my wife called back a few minutes later and I gave her the results.

Ahh! But then she made a comment that she was looking at purchasing a new duvet for our King Sized bed.

And the light went on. 

You see, my wife did not need that measurement of the width of the box spring.

We have a problem with our bed. And it is not the box spring. It is actually the mattress that sits on top.

Our mattress is a pillow top style mattress that is several inches higher than a regular mattress, making it difficult  to purchase linens, duvets or other accessories that  fit it properly.

The measurement that my wife actually needed, but was unsure how to articulate, was the full width of the bed, plus the height of the mattress multiplied by two. (in our case the height is 15 inches)

Except her vocabulary was for me to measure from the top of the box spring on one side, travel upwards over the top of the mattress, then back down to the box spring on the opposite side. Comparatively my vocabulary was one side to the other must mean the width.

See how easily I assumed that.

Our Vocabulary

In this case, we did have a shared vocabulary based on the issues that we have in fitting this bed with linens that we could build upon. This allowed us to overcome these assumptions.

In our businesses we may not have much shared vocabulary at all.

When we don’t have that shared vocabulary – all we can do assume, or to fill in the blanks with our personal understanding. Which may not even be close to accurate.

And Second?

When it comes to technology or processes, I advise people to temporarily ignore the measurement or statistics long enough to tell the story first! I think you would be surprised how incredibly powerful stories are  in getting us into a shared vocabulary.

In our mattress case, the story could have been my wife stating; ‘I’m shopping for new bed linens for the pillow top….’

Knowing the end result being looked for before diving into the weedy details and measurements can put you on track to using the same vocabulary.

In our business, this story taken from beginning to end will provide a road map, or framework that we can refer to when we get tangled up in these different vocabularies. As an example, a story in a distribution warehouse may be ; ‘when this comes in here, we need to separate them, repack, and label them to ensure that they accurately get to there…’

Then later on, when you are knee deep in process flows or maps trying to determine the ‘what about when…‘ or ‘what if…’ issues that invariably crop up. Go back to your story. That can give you back a shared vocabulary, and a shared vision of what your end result will look like.

 

 

Knowledge Hostage

I do ramble about documenting your IT. (maybe too much)  Sure you can call it fancy names like knowledge management, or any term of the day that you prefer.Retirement

Which ever term you wish to use, there is a huge  factor conspiring against you to make it critical that your IT teams are creating quality content about all IT infrastructure and services.

The largest generational cohort in history, the Baby Boomers are hitting retirement age.

These men and women are leaving with decades of implicit knowledge, but equally important they are leaving with current state knowledge of the what, the how, the when, and the who, of many aspects of your business.

I know there are millions of statistics floating around, however, occasionally simple stories work better.

I was talking to one individual who worked at an organization that still was using an older IBM AS/400 mini-computer – and where the last person that could truly operate this older IBM AS400 was a senior Director, yes close to retirement.

In my location it is almost an industry, people to take retirement options and then consult with the organization they left – usually at higher salaries.

I was speaking to some senior executives at a mid-sized business that were concerned about the last person familiar with an old, and heavily modified piece of enterprise software leaving.

 The SMB Takeaway

Are you an executive knowledge hostage?

A hostage to the knowledge locked in peoples heads, not only the implicit knowledge of experience, but also consider the immediate nuts and bolts of where key data is, programming changes to key systems, etc?

Is there a framework to ensure that someone else can operate that old system, or knows that old software?

This type of IT documentation does not need to be bound in hard cover and published by Harvard Business Press. It must be living content.

But without it? you may become a hostage to the knowledge locked in someones head.

And that is a risk you don’t need to take in your IT function.

Photo Credit: Steven DePolo via flickr