jump to navigation

Spring Forward! March 8, 2008

Posted by Chuck Musciano in Random Musings.
Tags: ,
add a comment

Ah, you can tell the seasons are changing.  Temperatures are rising, trees are budding, and most important of all, we have to set all our clocks forward one hour.  It is time for the biannual time shift known as Daylight Savings Time.

From an IT perspective, DST is just an irritant.  So many systems, so many clocks, so many potential job streams to be broken.  In the spring, jobs scheduled between 2 and 3 AM don’t run; in the fall, they all run twice.  Somewhere, some system will not change, and everything will be off by an hour until some attentive user calls the support desk.  Last year, the great DST Change that mandated that we start earlier and end later just about killed every Exchange mail administrator in the United States.  Even now, the echoes of that debacle show up in weird time-shifted appointments that linger from late last March.

Indiana has always been held in special regard in the IT world, due to their truculent insistence on not converting to DST like the rest of us.  How many hours of development and testing has been dedicated to accommodating 77 counties in Indiana?  We’ll never know.

Fortunately, these counties have allowed us to learn something I suspected all along: DST wastes energy.  Long advertised as an energy-saving initiative, DST actually causes people to use more energy than Standard Time.

In 2006, these rogue counties in Indiana finally threw in the towel and converted to DST with the rest of us.  This provided a golden opportunity to study their energy usage and compare it to previous, non-DST usage patterns.  The final result: DST uses 4% more energy that standard time.  As reported by the Wall Street Journal, here’s why:

  • People run their air conditioning more in the evening when it is warmer
  • People run their heat in the morning, when they get up in the cooler early hours
  • Heating and cooling costs more than offset the saved lighting costs in the evening

This last bullet is my favorite.  It surprises a lot of researchers that it costs more to heat and cool a house than it does to illuminate it.  (This does not surprise those of us who pay the bills).

In the end, affected Indiana families paid $8.6 million more in energy costs due to the change.  Their US Representative, Julia Carson, had promised $7 million in savings.  That’s a net loss of $15.6 million, not including the conversion costs for businesses who had to reprogram every device they ever owned since the dawn of computing.

In the end, this serves to reinforce two important lessons:

  • The Law of Unintended Consequences never fails to be applied
  • The government never improves anything it touches

Still, there is a light at the end of this tunnel.  If nothing else, that extra hour of daylight we get from DST should allow us to grow more corn, producing more ethanol to eliminate our dependence on foreign oil!

Those Who Forget History… March 4, 2008

Posted by Chuck Musciano in Technology.
Tags:
1 comment so far

One of my favorite magazines is going through a reorganization, having been bought out with the promise of being kept in print.  I’m referring to Invention & Technology, which offers up a widely varying history of technology, four times a year.  Here’s hoping they find they way out of their current difficulties to keep publishing.

I find the history of technology fascinating.  The lesson learned, over and over, is that what we are doing today, with our fancy computers and network gadgets, is no different from what other people did with sewing machines, or dishwashers, or airplanes, or cameras.  Throughout history, and certainly in the past 150 years, technology has brought about sudden and unexpected societal change.  That change is accompanied by bad investments, poor project management, horrible design decisions, unexpected outcomes, and undeserving heroes.

In many cases, the stories that originate in the 1800s provide the backdrop of the foundation of many modern companies.  Josephine Cochrane invented the dishwasher as a way to make a living after her husband died; her great-grandfather, John Fitch, had a working steamboat service in production 20 years before Robert Fulton. Josephine’s machine was a tremendous success, but women were not well-regarded as heads of industry; she sold her company which became, after a few name changes, KitchenAid.

Electricity was all the rage at the turn of the last century. Varying load demands led power companies to only generate power at night, when demand was more consistent. Earl Richardson, a supervisor at a California power plant, developed an electric iron to encourage housewives to use power during the day.  The iron was popular since it provided heat all the way to the tip of the iron, unlike other irons of the day.  The resulting appliance company? HotPoint, of course.

On and on the stories go, concisely captured for our review and edification.  We ignore them at our own peril; the lessons they teach about innovation, persistence, and leadership are as pertinent today as they were way back then.  Fortunately, the full twenty years of the magazine are preserved online, with a nice search engine atop the archive.  Take a moment to see how all these problems were solved by our forefathers; you just may find the solution to the problems you are battling today.

You Can Be Too Nice February 27, 2008

Posted by Chuck Musciano in Leadership.
Tags: ,
add a comment

Yesterday’s Wall Street Journal had a good article on the perils of the too-nice boss: one who is reluctant to confront problems for fear that he or she will offend someone or hurt their feelings.  This is such a common problem among leaders at all levels that I thought it was worth addressing further.

One part of being an effective leader is that you must be able to confront people with bad news and negative feedback.  It is crucial to their success (and thus yours) that you be able to do this confidently and with the goal of correcting whatever is wrong.

No one likes to be the bearer of bad news, especially when it is personal and potentially hurtful.  As leaders, we must learn to be tactful and sensitive so that we can reach people and help them through the issue at hand.  Everyone has a different personal style, but we should all be careful to handle negative feedback delicately but consistently.

Many managers, for fear of being disliked or making people unhappy, will simply avoid an issue.  This is the worst possible approach, for several reasons:

  • The problem does not get solved.  More than likely, it gets worse when left unchecked.
  • The problem person may be blissfully unaware, but everyone else is not.  Teams are excruciatingly aware of problems among themselves.  If you fail to address a problem person, the rest of the team will lose respect for your leadership.
  • People will stop bringing issues to your attention, since you do nothing about them.  At some point, you’ll no longer even know what needs to be fixed, and your team (and you) will fail.

It has been my experience that almost every time I’ve approached someone about a problem, they have risen to the occasion, fixed the situation, and later come back to thank me for recognizing the issue and getting them to take action.  Many people often need a little prodding to see an issue, a little coaching to find a solution, and a little support to make the solution work.  As leaders, that’s our key role.  Don’t let your fear of confrontation undermine your ability to truly lead.

Is There An ROI For ROI? February 25, 2008

Posted by Chuck Musciano in Leadership.
Tags: , ,
1 comment so far

One of the mantras for effective IT management is ROI: computing the Return On Investment for a proposed IT project. If the ROI shows that the investment can be recovered in some reasonable timeframe, the project is approved.

This kind of analysis works well for tangible projects in which the return and the investment are both equally measurable. If you are replacing one piece of hardware with another, or renegotiating a service contract at a fixed price, ROI can be very helpful as part of your decision process.

In general, you can easily compute the “I” of any project. Hardware, software, service, support, consultant fees, travel costs, employee salaries: these are all easily measured and tracked.

Unfortunately, many IT projects yield an important return that is completely subjective. How do you measure the “return” on an effective disaster recovery plan? How about license compliance or endpoint security systems? In general, any project whose end result is the avoidance of an undesirable situation cannot be evaluated using ROI. Hopefully, the rest of your management team probably agrees with this and won’t ask you to try.

Other projects are more fuzzy. Projects that yield efficiency or process improvements are often subjected to misguided ROI analysis in an effort to numerically justify an essentially intangible project.

I once consulted with a firm that justified an internal portal on the grounds that implementing an internal search engine would save (literally) millions of dollars. The reasoning went like this: if every employee searches for a document once a day, and each search is just one minute faster than the old manual method, and there are 50,000 employees in the company, you can save 50,000 employee-minutes a day, or about 833 employee hours, or about 104 days of effort each day across the company. At an average salary of $20/hour, you are saving $16,640 each and every working day! With 250 working days each year, you’ll be banking $4,160,000 every year! They argued that this was actually quite low, since they really expected searches to save more than a minute each, and their average salary didn’t include benefits. They really did all this with a straight face and a big PowerPoint presentation.

I asked if they would be receiving an actual check for $4 million each year. They looked at me blankly. I asked again how they expected to account for this enormous amount of money each year. Again, blank stares. It was clear I didn’t understand their methodology (and wasn’t drinking their Kool-Aid). I stopped asking and kept working on the system.

In general, if you are attempting to do an ROI analysis, and you find yourself factoring in average salaries, or total employee time, or some similar item, just stop. The only time you can use salaries and people is if you can count the number you will be laying off as a result of the project. Headcount reduction counts toward ROI; headcount repurposing does not.

The reality of being a CIO is that we often need to assess and greenlight projects based on intuition, good business sense, and the ability to manage risk and reward. Many projects will improve employee efficiency and give time back to be used for other business purposes. Workflow, collaboration, communication, sharing: they all make a huge difference in our businesses. IT is a key enabler of all these things. They yield intangible benefits with a real impact on your business. Don’t diminish them by trying to reduce them to a simple number. The real value of these things is truly immeasurable and the benefit to your business five years from now is completely unimaginable.

Bottom line: stop looking for numbers where they don’t exist, and start unlocking value wherever you find it.

These Eyes… February 16, 2008

Posted by Chuck Musciano in Technology.
Tags: ,
add a comment

I am a huge fan of mobile devices. I was one of the first people to use a Casio Zoomer back in 1992 and moved on to Palm devices in 1998. I recently made the Great Conversion to a Blackjack smartphone and upgraded to a Blackjack II last November.

I love seeing what new things you can do on these devices, and am always willing to try new tools and applications on my phone. But there is a limit. Some things were not meant to be done on a phone.

The fundamental problem with phones is that the display can only convey so much information. As tools get more and more sophisticated, it seems that the designers are trying to display more and more information on the display. Microsoft seems intent on running the entire Office suite on my smartphone, and phone browsers struggle to handle the complex content of full web pages.

I finally realized why this is happening. The people designing and building these tools have 25-year-old eyes. Many of the people using these tools have eyes that are… much older. Tiny little sharp letters and itty-bitty icons work great for young users. They are completely wasted on us more mature technophiles.

Have you ever tried to use Mobile Excel? Somehow, being able to see five or six cells of a spreadsheet at once leaves a bit to be desired from a usability perspective. Even as tools get more sophisticated in their rendering capabilities (the latest crop of zooming browsers is very cool), there is still only so much you can see at once on the screen. Even when I zoom out until I can just barely read the text on the screen, I still find myself panning back and forth just to read a single text flow in a document. Attempts to reflow the document often break the layout and make the document difficult to understand.

This is all the result of what I call “Mount Everest development.” Many tools are ported to mobile platforms just “because it is there.” It may be clever and a testimony to someone’s development skills, but it is ultimately useless.

When IBM PCs first became popular, one of the most important things you could buy was an Irma board. It added the coax connector and software that let your PC emulate a 3270 terminal. Migrating a 3270 mainframe display onto this new platform was useful, but hardly scratched the surface of what the device could really do.

The real breakthrough on these devices occurs when clever ways to exploit the form-factor emerge. Instead of dragging the tools of the past onto the platforms of the future, we need to figure out how to use these platforms in ways we never previously imagined.