Part 1 of 2

The world of business software is an amazing place to work. Nowhere else can we move so quickly from inspiration to realization of ideas that can bring customers closer, streamline business models or even turn an industry on its head. Think Dell, Wal-Mart, and Amazon.com. And enterprise software vendors are the Pacific Railroad’s of this age of transformation. They are building out technology infrastructures that allow businesses to design, plan, procure, manufacture, market and sell in ways that would have felt like science fiction only a few decades ago.

Recently, however, the enterprise software industry has come under fire from business customers and analysts for overpromising and underdelivering. High profile failures of Enterprise Resource Planning (ERP) and Supply Chain Management (SCM) implementations have businesses wondering: where’s the “R” in software “ROI”?

The causes for such software project failures are at least as complicated as the “cutting edge” technologies themselves. I believe, though, that the absence of a user-centered culture at software vendors is a major culprit. Many vendors keep the actual users of their products only in their peripheral vision. This is bad from the perspective of product design, and in this first of a two part series I’ll talk about common design mistakes I’ve seen made and offer suggestions on how to avoid them.

But the mistakes don’t stop with design. Many other processes that touch the customer—sales and marketing, consulting, implementation, and support, for example — suffer as well. I’ll tackle those issues in Part 2.

“Best practices” or work practices?

Listen to any business software sales pitch and you are bound to hear that the vendor’s product represents the culmination of years of study of industry or workflow “best practices.” And to be sure, there are many businesses that can significantly lower operational costs and increase sales, productivity, and throughput by studying and adopting process ideas from similar businesses. The problem with best practices as proposed by vendors, though, is two-fold: they do not drive realistic design thinking and they do not deliver the promised value if they are never implemented or used.

As much as vendor process gurus may wish, the people for whom they specify software are not Visio bubbles or UML stickmen. The reality of their work practices do not fit into tidy role swim lanes with clean state transitions and control points. Anyone who has done even a single contextual interview can tell you that the introduction of new software-based workflows into organizations usually results in people working around them — not through them. As part of our projects, I sit down for an hour or two with people who do the real work of a business — providing order quotes, planning production schedules, managing purchase orders, analyzing trends, and so on. Having worked for vendors in the past, it has been profoundly humbling — even a bit traumatic — to watch users try to work with business software products.

After a few such interviews, it occurred to me that without the Microsoft Office desktop productivity suite, the business world as we know it would surely collapse. There are $2,000,000 advanced business intelligence software solutions—built on industry data analytic best practices — sitting idle on desktops as end users continue to use their custom Excel spreadsheets (retail $200).

Action

Temper abstract and idealistic best practice workflows with an intimate understanding of how users in your market get their work done in everyday life. If you are a vendor, you are not delivering value to your customers if they are not using your software. And if you don’t understand the real intents behind their work, you probably didn’t design in the real support they need. If you are a business customer, don’t believe the software best practice hype. Demand that your software partners design from user data — including yours, of course.

Reactive design

As business software vendors grow their installed base, their design processes can become reactive. Each implementation is the response to one more customer requesting enhancements or extensions to “out of the box” functionality. In the worst cases I have seen, such enhancements were necessary to make poorly designed software even minimally usable.

To make matters worse, products are commonly sold whose system work model—the assumptions about how users work that software designers codify in their products — is stretched or shrunk to support unintended work practices. For example, a constraint-based factory planning and scheduling product was sold to a customer to do simple bill of material decomposition. Adding to this pressure are software industry analysts auguring the next generation software features that inevitably end up on customer RFPs (Request for Proposal). And, of course, there is the eternal feature war with larger competitors.

Rather than proactively prevent such problems by designing — and selling — from user data, many software companies specify subsequent product releases by simply aggregating feature requests. They rely on sources like customer wish lists, analysts, and marketing requirements documents. Prioritizing is based on factors like the size of the customer or the technology trend du jour and changes are then rolled into a meandering product roadmap. In the best cases, this results in product releases that contain an abundance of trendy, disintegrated features. Our contextual inquiries have shown the resilience of users. They get their work done in spite of the software, not because of it.

Action

Stop reacting to the feature request and begin designing systemically from user data. Software Design practices that are reactive in nature stay reactive and cannot result in coherent products that support the real work of users. Let user data drive integrated, generative design thinking into products and stop the “feature request/response” cycle. Hold marketing requirements documentation up to the light of real customer work practice and evaluate them objectively.

The domain expert

In many enterprise software companies, the actual product requirements are generated by “domain experts.” These are people perceived to be subject matter experts in the problem domain that the software addresses. In extreme cases I have seen, this is a single person — often a product manager — who is stretched to the breaking point trying to resolve the conflicting demands of sales, marketing, consulting, development, and support organizations.

In some cases, the domain expert is an “industry refugee.” For example, I knew a logistics manager from a large consumer packaged goods company and a production planner from the High Tech industry who fit this description. In my experience, though, the enterprise software domain expert is often what I call a “career product manager”—someone who actually never functioned in the roles for which he or she designs software but has focused on a particular problem or industry segment long enough to establish credibility.

Career product managers and industry refugees both introduce unique problems into the product design process. Career product managers bring a theoretical understanding of the problems faced by software users but little — if any — experiential understanding. As a result, their design thinking is often guided by concepts — like the “best practices” mentioned above — that are perfectly rational from the perspective of an “ideal” process but which must change significantly given the realities of user work practice.

As an example, I was once involved in a software solution definition project for direct materials procurement—the processes by which a business purchases the parts it needs to manufacture a product. Before the project started, we believed that for supplier relationship models in which the supplier was responsible for managing component inventory levels for customers (e.g., supplier managed inventory or SMII), the customers would not need visibility to detailed supply information like planned shipment receipts. After all, the domain experts led us to believe, that is one of the main value drivers of SMI relationships for the customer—tracking receipts and ensuring adequate supply coverage becomes the supplier’s problem. But when we watched the real work of the procurement and purchasing managers, we quickly realized that this level of visibility is very important regardless of whether the supplier or the customer manages the inventory. They were not, as we previously believed, simply sending forecasts and looking at an on-hand inventory number.

And while industry refugees can head off some of these types of problems, they often go too far in the other direction by assuming that since they once did the work, they know the “best practice.” In my experience, though, industry refugees are significantly removed from the work they once did and bring only their own work model to bear on the design problem. As a result, he or she ends up specifying the perfect software solution — for themselves. Add to this a generally lower level of technology competence compared to software industry veterans and you can arrive at narrowly applicable solutions with half-baked or otherwise infeasible technology architectures.

Action

Vendors, get your career product managers out of their offices and into the work environment of the people who use your software. Theory-driven products don’t stick and end up on shelves or returned for refund. Make sure industry refugee product managers realize that their perspective is only one view. It must be supplemented by the voices of other designers and users who are also in touch with real work in the domain.

Customers, build trusting relationships with your software partner product managers. Bring them into contact with real software requirements as experienced by your employees. Make sure you understand how your partner really conceives, develops, and delivers its software products.

Requirements solicitation

There are probably as many requirements gathering techniques used by vendors as there are requirements gatherers. In my experience, they basically boil down to conference room discussions or conference calls with project stakeholders and power users or lengthy Word documents with bulleted lists of “Thy system shalls,” disembodied from the work context that makes the requirement meaningful. Use cases and UML artifacts used during analysis can improve the structure and communicability of the requirements but they are not adequate on their own.

Regardless of how system requirements are collected and structured, they must ultimately support the design process in some form. And if your input is a set of well-structured — but disembodied — system requirements, your output will probably be a well-structured — but disembodied — software solution as experienced by your users.

I have argued with many vendor product managers about the “best” way to gather requirements. The “best” way, of course, depends on what you are after in your designs. If your goal is to build what a client project manager wants you to build, a bulleted list and a PowerPoint screen mock-up is an unwieldy — but feasible — way of working. If building precisely what an end user tells you her or she wants is what you’re after, use Joint Application Design or Participatory Design as your way to achieve the goal. But to really support and successfully extend the work practice of your users — and thus deliver sustainable business value to your customers — you must uncover and design to the intents of their work. I couldn’t get this kind of information in chat sessions or on a white board. So I used Contextual Inquiry with real users and removed all doubt. As we Texans say, “If you want to know how many teeth a horse has then go out to the barn and count ’em.”

One Contextual Design project I worked on studied forecast and order management practices for a producer of integrated circuits. Before we started, we reviewed all documentation available to us. During the interviews, two things that produced little or no volume in the requirements docs came out loud and clear. First, users relied on a large number of faxed purchase orders. Second, extensive “cross-cubicle” communication between account managers was necessary to support their sales process.

Although we entered the project with fantasies of an automated, paperless process utopia, we realized that we had to account for the large amount of “traditional” business conducted via faxed POs. Making this “out of scope” would have fragmented the account manager’s work practice. And if we were going to propose this solution across geographically separate business units, we would have to accommodate the need for quick communication and the passing of work context across account managers. It took field data to shine this light on our designs—and our solution was better off for it.

Action

Vendors must stop soliciting requirements and start experiencing them. Understand that design decisions that are not guided by information about what your users really do is costly in the long run in terms of increased implementation risk through field customization, customized solution support, and time and resource investment in product features that are never used.