jump to navigation

Get It In Writing April 13, 2009

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

When I worked in R&D, we shared our building with another group whose job was to improve engineering productivity.  They took their job quite seriously and had a mandate to investigate any aspect of the engineering groups that appeared to be in need of improved productivity.  They weren’t engineers, but they did claim to understand process and project management, and they often used a new acronym, TQM, as a sign that they were on the cutting edge of this kind of stuff.

As you can imagine, the engineers were not overly enamored of this group.  Fortunately, the productivity team must have decided that our R&D group was beyond help, productivity-wise, since my group was rarely the target of their attention.  On the whole, our groups got along pretty well and often shared information.

At some point, a few folks from the productivity group got involved in a fairly elaborate project, working with another division in my company.  They were very excited about this project, which involved some fancy new computer system to collect and analyze a lot of data.  The more this woman talked, the more excited she got about the project, and the more doubtful I became of her chances of success.

After a bit, I asked her about system performance.  The data volume was large and the analysis was complex.  Even with the best current technology, a functional solution would be a challenge to build. Would the system be able to perform well?  Would the users be happy with response time?

She didn’t miss a beat.  “Of course, it will perform well!  We wrote that into the requirements!”

And off she went.  With the stroke of a pen, she had solved any and all performance issues this new system might have.  As you might imagine, the project never finished, for a variety of reasons.

It is easy to listen to this story and laugh at the naivete of non-IT people.  How could anyone design such a complicated system and them make it perform well with a simple written requirement?

The deeper lesson (you knew there would be a deeper lesson, right?) is that someone failed to educate this person as to the real complexity of her project.  Non-IT people cannot understand what we do.  Unfortunately, when we do it well, we make it look very easy.  When it looks easy, people assume that it is easy and base their world on that assumption.  This results in projects that fail to meet user expectations.

Users do not want to know the details of our technology.  But they need to know when things are really hard or really expensive.  If they probe, you can explain why. We owe them enough information, matched to their curiosity, so that they can appropriately plan and manage their world.  If we fail to do that, we have failed them, no matter how well our technology works.

Wwwwhy Designs Fail March 18, 2009

Posted by Chuck Musciano in Leadership, Random Musings.
Tags: , ,
2 comments

Here’s a simple test: pick a web site, any web site.  Try typing the URL the old-fashioned way, with “www” in front.  Did it work?  Most certainly.  Now try it again, with just “ww,” “w,” or even “wwww.”  Did any of those work?  I’ll give you even money one or more of them failed.

Why?  People mistype this stuff all the time!  Don’t you think that some considerate, thoughtful systems administrator would have taken the time to create the “near miss” versions of his web site, just to make it easier on the users?  You’d think that, but they certainly didn’t.  And hundreds, maybe thousands of users feel the effects of one unthinking person.

This isn’t about poor web site name management.  The real issue here is that too many developers don’t take the time to figure out where users might make mistakes so that they can program around them.  The goal of any system is to make it as easy as possible for the user, and that includes silently detecting and correcting mistakes wherever possible.

Much like interfaces that force users to perform mundane tasks better left to the computer (like insisting on perfectly formatted credit card numbers) mistake-intolerant tools force the user to do more work for no good reason.  By definition, humans make errors.  When dealing with other people, we silently recognize and correct minor errors all the time.  People are really good at figuring out intent based on context and ignoring minor faux pas.  Computers aren’t naturally good at this, which is why developers need to consider all sorts of potential errors that might occur in their systems.  Wherever possible, they need to accept the error, anticiapte the intent, and move forward.

This kind of design error is not limited to software systems.  It extends to leadership as well.  Too many leaders insist on “correct” behavior from their team, expecting behavior that exactly matches what they might do when presented with a task.  Good leaders allow for creativity and understand that there are many paths to the goal.  Tolerating multiple paths that reach the same goal is a sign of a confident leader.

This isn’t to say that it’s OK to miss the goal.  It’s not, and failure needs to be addressed.  But are you allowing your people the latitude to take routes you didn’t anticipate and still reach the goal?  Like a system that gauges intent and still delivers the desired result, strong leadership encourages creativity that will find other paths.  In the best scenarios, your people will find a way that is better than yours, and even in the worst case, you can use the less-optimal paths as teachable moments to improve your team’s performance in the future.

How Are Things At Home? February 23, 2009

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

You can divide the technology at any company into two areas: the enterprise stuff and the end user stuff.  The enterprise stuff includes all the “heavy iron” in the data center: the servers, storage, networks, monitoring systems, databases, firewalls, and what not.  This is the domain of the IT professional, where we get to do deep analysis and evaluation of technology, cost benefits, and strategic value.  The user stuff includes everything a user touches: desktops, laptops, phones, email clients, web browsers, and PDAs.  Our ability to manage this technology hinges less on technology and more on what happens outside of work, in the user’s home.

We all have early adopters in our organizations: people who try out new things at home, way before they are actively considered at work.  (I suspect that most readers of this blog fall into that category). These people provide wonderful free evaluation services, figuring out what works (and what doesn’t) so that we can make better decisions for our companies.

These early adopters can make or break a product.  Vista was killed in the business market in large part due to the early negative reactions from these leading-edge home users.  Even though Microsoft made huge progress in improving Vista, that early stigma never wore off.

Microsoft learned their lesson.  The early adopter feedback on Windows 7 is almost universally good.  Not coincidentally, I’m beginning to pick up positive buzz from other IT executives about their plans for Windows 7.  Give Microsoft credit: they don’t quit and keep trying until they get it right.

The iPhone is a different story.  Users are adopting these devices at home and love them.  They come to work and want to use them with enterprise email on our networks.  Unfortunately, many IT people (myself included) do not believe the iPhone is secure and manageable enough for corporate use.  As a result, we’ve got a lot of cranky users who can’t use their iPhones at work.  While this provides an opportunity to teach people about security and systems management, it still leaves users feeling disappointed.

Gone are the days when corporate IT led the way in bringing technology to the masses.  Now we are followers, led by the consumer market and ever-more-savvy end users.  To be successful and to stay ahead of the curve, we need to pay attention to what our users are doing and constantly ask them “How are things at home?”

Staying Out Of Holes February 18, 2009

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

Since the dawn of computing, we’ve worked really hard to make technology easier and more accessible.  Computers started out in protected data centers, with mere mortals kept far, far away from actually using the machines.  Today, we’ve pushed powerful tools into the hands of end users that enable them to do all sorts of amazing things on a regular basis.

As users become more comfortable with these tools, they try to acquire more of them.  That’s a great thing, until those well-meaning end users get in over their heads and wind up holding a technology tiger by the tail.

Let’s be honest: computers, especially enterprise computing systems, are inordinately complicated.  They are not easy to buy, install, configure, or maintain.  It takes a a team of experienced professionals to make sure that a company buys the right systems, deploys them correctly, and maintains them for maximum business advantage.  When end users try to take that on themselves, disaster invariably ensues.

Every CIO can tell a story about some non-IT organization that tried to buy some cool system without bringing IT into the picture.  Typically, the first call comes about halfway into the implementation, when the project is behind schedule, the gory details are being exposed, and the poor users have no idea how to get out of the hole they have dug for themselves.  By the time IT gets involved, lots of money and time has been wasted, and the cost of recovery far exceeds the project estimates and often outweighs any potential benefits of the system.

It is easy to blame these scenarios on the users.  The real blame lies with IT.  We need to build trust with our users so that they feel comfortable turning to us when they need a new system or have a problem to solve.  The worst situations occur when IT is so inaccessible and arrogant that users prefer the pain of a bad implementation to the pain of dealing with IT.

Beyond earning trust, we also need to educate our users so they understand why our systems work the way they do, and how we integrate new technology to benefit everyone.  Systems architecture is of little interest to end users, but we must teach them how we fit all the pieces together so they can see how we bring all these conflicting systems together.

Finally, IT brings a lot of non-technical benefits to any technology acquisition.  In my experience, users make a good effort at finding a tool that has the right featurs to meet their needs.  Where they completely miss the mark is with the contract and service details around the purchase.  Users have no idea how to negotiate good pricing, or how to see through the smoke a vendor may be blowing their way.  They don’t know about service level agreements, or good maintenance pricing, or how to write a contract that indemnifies them against a product failure.  They don’t know how to evaluate a vendor for financial stability, or to know if their solution is a risky leading-edge idea or an outdated platform on its last legs.  We know all these things, and we need to provide that assistance to our users.

Like almost every other aspect of our job, it starts with communications and trust.  Begin by reaching out to users when they aren’t facing big problems.  Calmer times give you the opportunity to explain what we do, why we do it, and how we can help.  When users do reach out to us, bend over backwards to help them navigate the world of technology.  Respect their needs and take time to figure out what they really need.  Work hard when users aren’t in a hole, and you’ll eventually keep them from digging a new one.

Never Secure Enough January 28, 2009

Posted by Chuck Musciano in Leadership, Technology.
Tags: ,
3 comments

Many are predicting that 2009 will be a big year for The Cloud, wherein many companies will move many of their applications to the cloud, away from premise-based servers and storage.  A lot of the conversation about this revolves around network speeds, processor virtualization, and storage aggregation.  Although all of that is important, I’m more concerned about security.  More specifically, who in the cloud can see my data?

When I host an application internally, I have extremely tight control over access.  Not just who can use the system, but how the administrators can access the system and the underlying data.  We have layers of controlled access with specific checkpoints and audit trails.  Every access must be justified, documented, and audited on a regular basis.

When I shift a system to the cloud, I typically retain the ability to manage end-user access, but have no control over administrative access at the other end.  Of course, the hosting company will swear up and down that every precaution has been taken to keep anyone from ever seeing my data.  In reality, I have no idea what they really do behind the scenes, and I have no way to completely verify their claims.

The recent Twitter hack is a great example of this.  An admin at Twitter used a plain word (“happiness”) as their password. This was hacked by a person using a simple dictionary attack, trying every possible password until they broke in.  Once inside, they had immediate access to the Twitter management tools and proceeded to gain control of a number of high-profile Twitter accounts.  Fortunately, Twitter is a lightweight application with no important data that could be compromised. Still, people were embarrassed and disrupted by the penetration.

A chain is only as strong as its weakest link.  A system is only as secure as its weakest access point.  When you move your systems to the cloud, your data is only as secure as the worst password used by the least experienced administrator.

I believe I’ll wait a bit longer before moving to the cloud.

[tweetmeme source=”EffectiveCIO” alias=”http://j.mp/cio161″ only_single=false]