jump to navigation

Knowing When To Stop October 30, 2009

Posted by Chuck Musciano in Leadership.
Tags: , , , , ,

A recent issue of Wired had a great article on the concept of good enough: when products meet enough needs that consumers are happy. The author gave several examples of good enough: MP3s instead of CDs, Flip cameras instead of high-end video cameras, and even Predator drones instead of manned fighter jets.  In each case, the product is woefully short of perfection, but is still so useful that the perfect alternative is being sidelined in the market space. (As an aside, you may not need to read the entire Wired article; for many of you, my summary will be good enough).

The idea of good enough is certainly not new, and is simply the latest incarnation of the 80/20 rule.  Unfortunately, I think many of us who understand the 80/20 rule are still struggling to implement it in practice.  It turns out it is really hard to know when to stop.

In a world of dwindling development resources, knowing when to stop is crucial to providing maximum service for the minimum investment.  The moment a developer begins working on the eighty-first percentile of a project, they have gone too far.  They need to be pulled off and turned loose on the first percent of the next project.  This is true for everyone in the development stream: the business analysts, the designers, the infrastructure people, everyone.  At some point, they are spending too much time on a project, expending effort that will not result in proportionally additional value.  They need to let go and move on.

[Note that this is not true for testers.  There is no 80/20 rule for testers.  They need to test 100% of the 80% that has been built.  More on this in another post.]

The problem is that no one knows when they have reached the eighty percent point.  Very few projects have a bounded definition that makes it easy to see when enough is enough.  Even when you do have such a bounded definition, user-induced scope creep can easily push that definition further and further out, dragging the eighty-percent point along with it.

It is often the case that a team will unknowingly extend the scope of a project as they work through the details of the spec.  Seemingly appropriate questions lead people down paths that occupy way too much of their time.  Everyone in the room knows how they got there, and why they are discussing some arcane feature, but no one was able to throw the flag and stop the process along the way. It all seems to make sense at the time.

That’s when you need a “sudden interrupter:” someone who comes to the process late, has not been a part of the incremental walk, and can easily see that things are off-track. They provide a bit of cognitive dissonance that allows the team to reset, regroup, and reassess what they are doing. Even if the group decides that they do want to continue their discussion, the pause allows them to confirm that they are on the right track.

I doubt that many people carry the title of Sudden Interrupter, but I’m beginning to think we need a few of them wandering about.  Gentle challenges during any decision-making process are generally helpful, whether you are designing software or refining a budget.  If nothing else, having to explain “why” to an outside observer is a constructive, cathartic exercise. So, go help someone.  Interrupt them!

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio124″ only_single=false]

Missing Users October 14, 2009

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

A common conversation among CIOs these days is how they are dealing with the current recession.  We talk of budget issues, staffing concerns, reduced resources, and a general reduction in our ability to execute and expand our services.  Especially at this time of year, the conversation turns toward next year’s budgets and what we might expect to see in the coming year.

One of my big worries for the coming year is a shortage of users. Not in the sense that there won’t be people to use our systems, but in that IT cannot survive without those critical users that help define, build, test, and deploy our systems.  The economy is affecting the supply of users that are able to help us do things.

For many years IT worked in a vacuum, building things as we saw fit.  The prevailing attitude was that users should be happy with whatever they got, and little time was spent engaging users to ensure we were building the right things the right way.

Many of us (or those of us still employed in IT) realized that this methodology was less than effective and changed our approach.  We actively engaged our user community in every aspect of the development process.  From project charter through requirements analysis, testing, training, deployment, and post-production support, users with specific business knowledge are key to the success of our projects.  Without them, we are doomed to fail.

Unfortunately, the economic pressures being exerted on IT are being felt by everyone else.  People are busier than ever before, doing more with less.  As a result, they simply do not have the time to engage with IT to partner for success.

In a sense, finding that time to help is harder for our users than it is for our staff.  The reality is that many IT shops can easily augment staff by backfilling with contract labor.  If you want to focus a few developers on a new project, you can bring in additional contractors to take over the day-to-day stuff while your developers dive into a new project.

This is rarely possible with non-IT staff.  Business people, especially those that assist with IT projects, usually have deep knowledge of your company’s business rules and processes.  If they are added to a project team to contribute that knowledge, you cannot easily hire an outside contractor to backfill that knowledge gap.  For the most part, IT skills are fungible; non-IT skills are not.

This has deep implications for our ability to execute and deliver results to our companies.  As we seek funding to do things, it can be easy to overlook the non-IT assets needed to make those things successful.  Funding can’t expand those resources, yet our success depends on engaging those very important people.

What to do?  There is no easy answer.  First and foremost, coordinate early and often with you business partners to ensure their availability and willingness to help.  Be very respectful of their time and engage them for your most important work first.  And like most things in life, these times will pass, things will improve, and we’ll re-engage with our previous fervor.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio117″ only_single=false]

Chief Guinea Pig October 12, 2009

Posted by Chuck Musciano in Leadership.
Tags: , ,

As technology penetrates every aspect of the business world, those of us in IT find ourselves deploying tools more and more frequently.  These tools are more tightly integrated to everything our users do.  In days gone by, we provided green screens for data entry and green bar for rudimentary reporting.  Now we control every aspect of communication, including voice, email, and text messaging, and provide interfaces to every system in the business.

Most shops do a lot of testing before rolling out new stuff.  Typically, testing begins on the IT side of the house and ends up on the user side, with qualified end users signing off before something goes into production.  Is there a place in that process for the CIO?

I think there is.  I think I have a responsibility to know how our systems function and what the overall user experience is going to be. I’m the first to admit that I am not qualified to test the business processes behind these systems, but I do think I have a voice in the general experience.

Generally, I consider myself the primary guinea pig for almost everything we deploy in my company.  I usually try out each new laptop, many new phones, and almost all user interfaces that we develop.  I try to see how these tools would impact a typical end user.  Are they easy to use and understand?  Do they have confusing options or weird configuration choices?  Would users be confronted by tedious, pointless interaction sequences?

In short, if I were an end user, would I be happy with the device or system? I feel strongly that I should never ask a user to use a device or participate in a process that I have not personally experienced.

In conversing with other CIOs, I find that some do not wish to engage at this level.  They don’t have time to go through this process and don’t feel that they are qualified to make a reasonable judgment. However, most of them do have trusted coworkers that fulfill the role of guinea pig for them.  They value the testing experience; they’ve just outsourced the task to someone else.

There have been times I find myself doing the same thing.  Some new phones are only available on other carriers; I’ll find someone I trust to see if the phone is acceptable.  Some business processes are beyond my reach (or security level), but I’ll find someone else to give me the unvarnished truth about a new system.

CIOs should be operating at a strategic level above the details.  That altitude, however, does not absolve of us from having the ultimate responsibility for the quality of everything we deliver to the business. Ironically, our distance from a tool or system gives us a different perspective from the developers who toil so closely with it.  By being closer to the forest than the trees, we can often see problems that are overlooked by the tactical developers and testers.

Although it may drive your developers to distraction, simply asking “why?” as you walk through an interface or use a device may ultimately create a better experience for your end users. And that, regardless of your preferred level of engagement, is what our job is all about.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio116″ only_single=false]

Field Of Rakes October 9, 2009

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

In the surreal sitcom My Name Is Earl, Earl (our hero) is at one point confronted with a series of challenges that he must complete to rescue Catalina, his brother’s true love. One of the more painful trials is that he must run through the Field of Rakes, blindfolded.  The rakes are positioned tines up, so that each mis-step results in Earl getting smacked in the face with a rake.  Earl’s painful sprint will seem eerily familiar to anyone who has spent any time in IT.

It is easy, in IT, to build your own Field of Rakes.  Each time we disappoint a user we add a rake to the field.  Even the simplest of problems can turn into a rake that will pop up to smack us in the face when we least expect it.

We work hard to do the big things right: system upgrades, new technology deployments, and major projects get lots of attention so that they don’t go awry.  That makes sense; big projects involve a lot of rakes, and the last thing you want to do is add several hundred rakes to the field in one fell swoop.

Unfortunately, we often get the big projects right but fail on the little things.  Individually, the little things don’t present much risk. After all, it would be pretty easy to run across a field with a single rake.  But all those little things, taken over time, can fill a field with lots of rakes.

What can add a rake to your field? Anything and everything.  Denying a request for special software.  Failing to follow up on a support call.  Getting stuck between two competing users, so that you’re guaranteed to get a rake from one of them.  Missing requirements from a user.  Mismanaged expectations on a contract negotiation.  Ignoring what people really need and acting like you know best. I could go on and on, and every seasoned IT pro could add to this list.

How do you avoid adding rakes?  Easy: listen, care, and communicate.  Continuously. Every rake is the result of our inability to communicate and relate to someone.  As service providers, it is inevitable that we will disappoint people.  How we handle that moment and compensate for the problem determines whether we get a rake.  People know we cannot be perfect, but will only be gracious about it if we sincerely and diligently work to meet their needs.

Even with our best efforts we’ll still get a few rakes, and our run across the field may be a bit painful at times.  But diligent attention to people is the real key to IT success.  My Name Is Earl was a series about karma, good and bad.  All those rakes represent your karma, collected over your career. Focus each day to look for the rakes and remove them from your field.  May we all run through empty fields!

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio115″ only_single=false]

Can You See Me Now? September 30, 2009

Posted by Chuck Musciano in Technology.
Tags: , ,

The mobile devices we carry grow in capability and sophistication every day.  It seems that what used to be phones that did clever things are now mobile computers that happen to make phone calls.  Is there a limit to what we’ll be able to use these devices for?  I think so, but it has nothing to do with power, memory, or computing capacity.

The real limit has to do with the length of your arm. I’ve found that I can no longer hold my phone far enough from my eyes to read the display.  There may be an app for that, but I can’t see it.

Seriously, there is a harsh correlation between our aging eyes and our inability to actually read the screens on these oh-so-clever devices.  Regrettably, many of these devices are designed and programmed by people with sharp, youthful vision.  In the hands of more seasoned users, the display icons, text, and even the buttons are too small or dim to see.

Setting aside the apps and the UI, I suspect one of the reasons for the success of the iPhone is that big, glorious screen.  When the text is big enough to read, you can still fit enough content on the display to be useful.  This is a big deal for those of us who spend a lot of time squinting or reaching for reading glasses.

But, some will say, there have been big-screen mobile devices before the iPhone.  What about them?

Prior to the iPhone, devices had stylus-centric interfaces.  When you are poking at things with a toothpick, developers tend to cram lots of tiny buttons and widgets on the display.  The iPhone has a finger-centric interface, with finger-sized buttons.  Finger-sized buttons are big enough to be read by those of us who are old enough to remember rotary-dial phones.  I’ll point out that the size of an icon on an iPhone is about the size of a finger-hole in a rotary phone dial. Coincidence?  Yes, but a meaningful one.

I suspect that we are about to hit a wall in the usability of mobile phones.  The display can’t get much bigger without making the phone annoyingly large in your purse or pocket.  Increasing the screen resolution packs more pixels on the display, but that just lets you create sharper widgets that are still too small to be seen by anyone over 45. I’ll take low-res and sharp over hi-res and blurry any day.

As a result, the amount of information can be displayed on a phone is about to hit a limit imposed by your age, the lens of your eye, the size of your hand, and the distance between your ear and your mouth.  That information limit will affect the complexity of applications that get developed. Until we get some breakthrough in implantable display devices, the applications on our phones aren’t going to get much more elaborate.

And for all you smirking young developers out there, have pity on us older folks.  Test your UI on your Mom to make sure everyone can see it.  And just you wait.  Your time is coming, my friend.  Your time is coming.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio111″ only_single=false]