Keeping it simple

Just before Thanksgiving, I was holding forth about the hidden costs that organizations subject themselves to when they make their business practices and the software applications that support them needlessly complex. One of the very direct costs is in the increased difficulty these organizations encounter in training staff and in documenting procedures and systems. Yet I've always found that users are happier to spend a dollar to add a feature to their software environment than to train on using what they already have. Nontheless, software users know they need to do something more about training. Recently I had the very enjoyable task of working with Malin Coleridge at TechSoup to develop a questionnaire on the "Technology Challenges" faced by non-profit organizations. (By the way, 880 organizations responded - thanks to everyone who took the time to do so!) Last week Malin sent me the results. I don't think the Soupsters have posted them yet, but here's one datum we found: 73% of all respondents agreed or agreed strongly with the statement We need to develop a process and materials for training new users on our computer systems. How I read this: Systems have become so complex that training folks how to use them has grown into a daunting task, and just over a quarter of the non-profits responding felt they had this task in hand. It's not surprising: a recent study by a Dutch researcher showed that 50% of all consumer product returned as malfunctioning were actually working perfectly - they were just too complex for the customer to master. I see this in the Information Systems domain every day - users call us to report defects in the software when it is really working according to spec. This is true even when the function in question was developed closely with the users. Last week I was musing out loud here about that old developer's joke, "it's just what I asked for but not what I want". More to the point, maybe it's not what they really needed. Maybe it was too complicated, and reflected a business practice that is more convoluted and offers more options than serve any useful purpose. In the consumer study, the designers were blamed for the complexity of design. But maybe they do it because this love of complexity is widespread. At any rate, it seems clear to me that the IT conversation needs to be expanded, so that board members, end users, technology advisors, and developers all feel free to bring questions of organizational procedure into the discussion. Slowing the growth of complexity and making sure users are trained and have access to information about the system and organizational proceedures need to be listed among the goals of any further development work. Tags: nptech, complexity, training