Method CIO December 16, 2009
Posted by Chuck Musciano in Technology.Tags: Technology, Users
5 comments
It is said that during the filming of Marathon Man, Dustin Hoffman stayed up for several days to appear appropriately disheveled for a particular scene in the film. When his costar, Lawrence Olivier, asked why, Hoffman explained that method actors were trained to actually experience the role they were playing. Olivier replied, “Why don’t you try acting?”
While actors may choose to act or to use Stanislavski’s classic Method, I don’t think that CIOs have that luxury. To be effective, a CIO needs to be a Method CIO: directly experiencing the systems, technologies, and platforms that they will subsequently select, acquire, deploy, and manage. It is not enough to consider technology at arm’s length. Technology must be experienced first-hand to be fully understood.
I have always embraced technology, long before I moved into a management role. Even when I held technical positions, it became clear that reading about new things was not the same as using and exploring them. The technology we use is too unpredictable, with side effects and unintended consequences that can only be discovered through first-hand use.
I can remember the first time I tinkered with a PC, or used email, or set up a network, or created a web page, or configured a RAID array, or used any of a hundred tools that have since become part of the technical fabric of our lives. My expectations of the technology were dramatically different from my actual experience. The longer I used the tool, the more I discovered about it. The lessons learned and the overall experience made it much easier for me to understand the system and be able to decide how and when to use it.
Even as I’ve shifted away from a direct technical role, I’ve stuck with my decision to directly experience as much technology as I can. That’s why I blog, and use social media tools, and experiment with mobile devices. It’s not that these tools hold a sudden fascination for me. Instead, they are simply the next generation of potentially useful technologies that may or may not matter to me and my company. I’m expected to be able to evaluate these tools for their personal, professional, and corporate potential. I can’t do that effectively without directly using them until my curiosity is satisfied.
Obviously, no one has the time (or the wherewithal) to try everything that crosses their path. We have to use some discretion to sort out the potentially valuable tools from those that may not be worth a look right now. Even the list of potential tools can be long and unmanageable; that’s when we need to engage other like-minded folks to experience those tools and share their impressions. Others who share the enthusiasm for the “Technical Method” can be a tremendous help in sorting through the ever-increasing amount of stuff that comes our way.
With all due respect for Sir Olivier, I think that Method CIOs develop a deeper understanding of the technology they manage. Were Dustin Hoffman ever to turn his attention to IT management, I suspect he would agree.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio144″ only_single=false]
No Coffee, Please December 7, 2009
Posted by Chuck Musciano in Random Musings.Tags: Change, Users
2 comments
At a recent industry event, I settled in for the luncheon keynote speaker. As you would expect, they came around and poured coffee. I dutifully added cream and sugar and took a few sips. Perfect!
When I was half-finished with my coffee, the waiter came around and refilled it. Aaagh! This completely upset the careful balance of cream, sugar, and coffee. Now I was stuck: put up with too-bitter coffee, or try to make corrections with partial portions of cream and sugar. Either way, my coffee experience has been disturbed, if not ruined.
As I gave up on my coffee and decided to just eat the mints from the bowl on the table, it occurred to me that many of us in IT run around with coffee pots. With the best of intentions (always have a full cup!) we disrupt the carefully crafted experiences of our users.
We talk a lot about change management and preparing users for the impact of system modifications. Change is inevitable, and there is no way that we’ll be able to preserve everything a user likes about a system as we add new capabilities. Even little changes in menu ordering or form layout can cause great consternation among people who have grown used to a system.
It is one thing when we recognize an impending change and work to avoid end user difficulties. Big system rollouts usually have lots of formal change management to make life easier during transition. But how often do we send out little changes and ruin our users’ coffee, so to speak? It doesn’t have to be a system change; a change in process can be disruptive, too. Vendor changes to support or licensing terms are hard to deal with, even when they work in our favor. Even changing a phone number or replacing an old piece of equipment with a new one can inject an unwelcome change into someone’s life.
Change is hard, whether it is big or small. And the size of the change is in the eyes of the changee, not in the changer. As we constantly improve and upgrade our world, let’s be careful when and where we decide to pour coffee. Hopefully, we’ll have fewer users left with a bitter taste in their mouth.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio140″ only_single=false]
There’s Not An App For That November 30, 2009
Posted by Chuck Musciano in Leadership, Technology.Tags: Communication, Relationships, Technology, Users
3 comments
I’ve been in a few CIO briefings of late that have revolved around the topic of business process management. There is little doubt that much value can be found in formally capturing, defining, and managing the hundreds of processes that keep our companies running. Even the simplest processes can have costly inefficiencies that can make a big difference in delivering good service and maintaining efficient operations. A good BPM exercise can find and eliminate those issues and yield a good return on the effort.
For many of these initiatives, much time is spent selecting and implementing the right tool. Certainly, having a sound workflow system to drive your processes helps. The right system can automate mundane tasks, track all sorts of things, and make sure people know who needs to do what when.
As with most tools, however, it is easy to get so wrapped up in the tool that you lose sight of the real goal: creating a better process. While it may be fun to connect lots of boxes with lots of lines, you’re creating a monster, not a better way.
I was once a party to just such a monster, several years ago. As part of a workflow design team, we were tasked to formalize and automate a process within our company. This process had several gates, at which point someone could reject the item and stop the process. This had been a bit of a sore point in the past, so we were careful to design in ways for rejected applicants to appeal their rejection.
This quickly escalated into a multi-level appeal process, with committees and advisors and automatic hearings. It looked great on paper and took seven pages to draw out all the various options and choices that could occur. We were pretty proud of this “better” way of doing things.
Finally, we all came to the same conclusion: this was a disaster in the making. First, it would be extremely difficult to implement. Second, it attempted to automate tasks that really needed to be handled by people. And third, it would cause confusion and chaos among the users.
The real answer to the problem was far simpler: when an item was rejected, the rejecting party was expected to call and explain the circumstances to the rejected party. The whole group realized that actual communication had an important place in the automated workflow.
That lesson hasn’t changed. Tools are useful, but they can only go so far. We cannot automate the most important part of any business: the interaction between team members as they get work done. We need to use tools to remove the drudgery so that people have more time for the high-value interaction that really counts. Freed from mindlessly shuffling paper (or email), people can actually discuss issues and work things out. Communication is the most important thing we do; unfortunately, there isn’t an app for that.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio137″ only_single=false]
I Feel Your Pain November 4, 2009
Posted by Chuck Musciano in Leadership, Technology.Tags: Development, Interfaces, Software, Users
add a comment
Users are in a tough position. They’ve evolved to the point where they cannot do their jobs without computers. The systems that they use are becoming more and more sophisticated, with equally sophisticated interfaces. Worst of all, they have little or no control over how those systems are built.
Our users rely on us to build systems that are easy to use, reliable, and consistent. They have no idea how we do this, not do they care. They trust us to take care of the awful details of system design and development to make things that they find useful. Regrettably, I don’t think we on the IT side of the house do as good a job as we could on their behalf.
We often make design decisions that cause users great angst. I’m not talking about sweeping design changes; I’m thinking more about the small, subtle things that can make a big difference in a user’s life. The layout of a screen, the ordering of a menu, the arrangement of a list can dramatically affect the usability of a tool. Poor usability results in unhappy users.
Many times, these kind of decisions get made on the basis of how complicated it can be to implement a better alternative. In short, we reduce development time and expect the user to deal with a less-effective interface. We reduce developer pain at the expense of user pain, and that’s wrong.
I’ve written about this before. One of my biggest peeves in just about every web site on earth is that you cannot enter anything but digits into a credit card number field. The developer will not set the field to “numeric only;” instead, they’ll put some awful text near it that explains that you should not type dashes or spaces in the field. Here’s a big idea: how about you write some code to strip out dashes and spaces, so I can type the number in a way that make sense to me? The developer saved twenty minutes; users spend collective years trying to type things correctly.
There are countless examples of this in every system we use. Time and again, developers and designers make their lives easier by asking users to do a little bit more. The problem is that the development time is incurred once; the user time incurred over and over and over again, for years.
We owe our users better. They trust us to build systems they can use. We need to feel their pain, take it on ourselves, and remove it from their day-to-day lives. Users are the most important part of any system; we need to show that we understand that by building things that respect their time and energy. Show your users some love: build things that put them first.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio126″ only_single=false]
The Happy Path November 2, 2009
Posted by Chuck Musciano in Random Musings.Tags: Software, Technology, Testing, Users
2 comments
In our last episode, I argued for a more consistent application of the 80/20 rule as we design and deploy software. I made an exception for testing, however, which prompted a comment asking why testing gets exempted from this rule.
As the saying goes, testing only proves the presence of bugs, not their absence. The goal of testing is to find as many of these bugs as possible before moving code into production, in the hope that we will avoid inflicting them on our poor unsuspecting users. Unlike a system in which we intentionally design and deploy the first eighty percent so as to get some value to the customers more quickly, we cannot test just eighty percent using a similar rationale. We need to test everything we build as best we can.
There is a limit, of course. You can’t test forever. The trick is to know what to test, and to test those parts thoroughly.
A co-worker of mine often talks about the “happy path.” The happy path is the path through a system where everything works, the data is correct, the system stays up, and the users are well-behaved. We tend to test the happy path first because we understand how the system should function and want to ensure that the basic features should work.
This results in testing scenarios like this
- User selects an item and adds it to their cart
- User enters billing data
- User enters shipping data
- User clicks “Check Out”
- Transaction is processed
If this works, has the system been tested? Yes. Would you move it into production? The right answer is “no,” but I’ve used a lot of systems where the apparent answer was “you bet!”
We need to move off the happy path and wander in the weeds. What if the quantity exceeds stock on hand? What if the user enters too few digits from their credit card? Or too many? Or adds a space, or a dash? What if the zip code doesn’t match the state? What if? What if? What if?
It doesn’t take long to test the happy path. It takes forever to test everything off the happy path. You need to spend a lot of time wandering away from the happy path, and maybe there is a reverse rule for testing: 20% of your time on the happy path; 80% of your time off of it.
For some reason, I was born off the happy path. Even at a young age, I was doing things like sticking Christmas lights directly into outlets (they explode and leave a mark on the wall) and riding my bike with my eyes shut (you hit parked trucks and knock yourself unconscious).
I have developed a reputation as the guy who can break things, much to the chagrin of every development team I have ever worked with. I wish I had a nickel for every time I’ve been told “no one ever tried that before.” As much as it annoys developers, people who can break things are crucial to building solid products. Better that we break them instead of a user.
We need to find and engage the non-happy-path people in our teams, and make sure that they spend a lot of time testing everything we build. Admittedly, you cannot test forever, but having the right people test for as long as possible can make a world of difference.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio125″ only_single=false]
The Effective CIO 