jump to navigation

I Feel Your Pain November 4, 2009

Posted by Chuck Musciano in Leadership, Technology.
Tags: , , ,
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: , , ,

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]

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]

Where The Prices Are Insane! July 10, 2009

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

It happens four times a year, like clockwork.  Just before the end of March, June, September, and December, the phone calls and emails flood in, all promising the same thing: unheard-of pricing on products you absolutely cannot live without.  These once-in-a-lifetime prices are only available for a short time, if you act now!

What’s being sold at immense discounts?  ShamWow or Snuggis?  A Pocket Fisherman or a 12-CD set of the greatest hits from the 70s?

Nope.  The big sale is on software.  Big software: databases, ERPs, business intelligence platforms, and the like.  Even with the fabulous discounts, the prices still run well into six figures, plus implementation costs.

Who buys software like this?  Is there a CIO anywhere in the world who will write a check and buy software at the drop of a hat?

Done correctly, big system purchases take a long time.  Requirements analysis and market evaluation are tedious but vital to ensure a good fit for your organization.  Understanding the deployment costs and timeframe is crucial for success and can takes weeks to figure out.  Just reading and negotiating the support and licensing contracts is a major exercise all by itself.

Moreover, as CIOs work to gain the respect of their executive peers, the last thing any of us should be doing is running to the CFO’s office on June 30th, looking for a signature to close a deal before 5 PM.  Rushing a deal to save a buck is unprofessional, and any other C-level executive should question our abilities if we behave like that.

That isn’t to say that I don’t appreciate a good deal.  But the right way to approach a quarter-end discount is to start working towards it at the beginning of the quarter.  Everyone on both sides of the table knows that pricing gets tighter as the quarter and year ends.  By doing all the heavy lifting well before that time, we can focus on solid price negotiation without being pressured to short-circuit our diligence when things go down to the wire.

I really appreciate those vendors that come to me well in advance to put together a great deal with plenty of time to spare.  Not only does that let me do my job on my side, it also lets me manage the process with my management team, giving them plenty of time to learn about the proposal.  When I do go forward with the final pricing at the end of the quarter, there are no surprises to delay the process.  By helping my company reach a good decision in a timely fashion, a vendor makes themselves (and my team) look good.

Selling is about relationships and providing solid value over time.  Vendors, please leave the high-pressure tactics to late-night TV ads and used car lots, and give your customers time to evaluate and respond to good offers in a timely fashion.  We’ll all close on more deals with a lot less stress.

Solutions Without Technology May 27, 2009

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

Of the many aphorisms that I enjoy using, one of my favorites is

When all you have is a hammer, everything looks like a nail.

I pull this one out when someone is using some system in an inappropriate way.  People get so comfortable with their favorite tools, they use them for everything even when a better solution is readily available.

This is an easy accusation for an IT person to make.  Most software systems are so complicated that it is easier for a user to twist an existing system into an unusual solution than it is to learn some completely arcane new system.  People just want to solve problems and get on with their jobs and lives.  I know this is hard to believe, but they don’t look forward to exploring and mastering that latest version of some new desktop application.

Those of us in IT would do well to listen to our own advice.

How many times, when asked to help solve some problem, do we immediately reach for a computer?  Typically, the answer is “all of the time.”  We’re in IT; we know how to make computers do interesting things; therefore every problem can be solved with some technology-based solution.

Wrong. Wrong, wrong, wrong.

Many problems do not exist for want of a technology solution.  In fact, many of the day-to-day business problems we encounter are rooted in process, flow, and data collection.  While you can certainly throw software at all of those areas, you can also fix a lot of issues by talking to people, understanding their real needs, and proposing ways to change things in a non-technical way.

Within IT, we have developed a broad range of skills that are not rooted in technology.  Process analysis, data management, project management, user interface design, audit and compliance, risk management: the list is long.  Why, then, when someone is gracious enough to give us the opportunity to help, do we reach for the hardware?  We perpetuate the perception that we are nothing more than geeks, when if fact we have so much more to offer.

I’ve been on projects where the real solution was to have a user interface designer rework a paper form layout.  I’ve seen errant projects saved by sharing good project management skills.  I’ve seen business processes reworked by applying disaster recovery discipline.  In all of these cases, not a single line of code was written in pursuit of a solution.  Instead, IT people spent time listening, sharing, and collaborating to help users do their jobs more effectively.

People in IT chafe at being known solely for their technical expertise, yet we fall into our old habits when confronted with a problem.  We need to follow our own advice, set down the hammer of technology, and look for effective non-technical solutions to many of the problems we’re asked to solve.  We’ll grow in our ability to be of service, and we’ll begin to build a better reputation with our end users.