To Deliver Value in Your IT Projects, Understand Context First
Usability and raw functionality play a part in the value of a software system, but value starts earlier in the process.
A recent Boston Globe story on the problems a hospital is having with its electronic health records system describes the frustrations doctors and nurses at a Boston-area hospital are experiencing after moving to new software. While basic usability is a common complaint, there is more to the issues than simply design.
Some of the problems with the system are related to the user interaction design, such as overly complex data-entry processes. Others are about the implementation of the hardware, such as monitors that are oriented so that doctors must face away from the patients when viewing and entering information.
We’ve all learned to expect interfaces that are easy to use and learn, though for some specialty applications, complexity is inevitable. Some customers seem comfortable with complexity in a system that provides utility. Still, one wonders how a system that was built to serve such a specialized use can frustrate so many of its users. Part of the answer may be in the system’s history.
An article in the IEEE Annals of the History of Computing describes the origins of this particular health records system. The authors describe how it evolved from the Massachusetts General Hospital Utility Multi-Programming System (MUMPS), a hierarchical database architecture with a built-in programming language developed in the late 1960s. Historically, MUMPS was used to build medical databases. There was a premise that each hospital was unique, so there was little standardization or discussion of interoperability. Obviously, this led to problems when it came to keeping consistent records and making them available to other clinics.
The heart of the problem with usability in hospital records systems appears to be that they are an attempt to build a common system over very different models of how hospitals work. This is not to say that a high degree of standardization is always the best approach, but building a tool that layers its own process atop a wider variety of processes can be very challenging.
This just highlights the importance of organizational and user context in successful IT projects. The difficulty in getting the context right is why writing a user story is a powerful tool for building the right thing.
The canonical user story follows the template “As a role, I want goal/desire so that benefit.” Customers are often quite happy to specify what it is they want, but it’s the role and benefit for building something that informs key design and implementation decisions.
Building without understanding can lead to a “big ball of mud” from a usability and architectural perspective. To deliver value, you need to be sure you’re not applying technical solutions without thinking about good architectural principles first. Too often, we build what we can without taking the time to question whom we are building it for and why. A user story is a simple but effective tool to determine how much we understand about the context of a problem.
