Don’t Just Manage, Transform! Part 1

By Baruch Sachs

Published: May 19, 2014

“Simply managing anything seems to be just taking care of the basics. When you merely manage something, more often than not you are treading water. Transforming something is the real way to progress.”

Here is a confession: I have never been a real fan of anything with the word management in it. Why? Well, because simply managing anything seems to be just taking care of the basics. When you merely manage something, more often than not you are treading water. Transforming something is the real way to progress. Transforming, growing, shaping—these are the fun and most challenging parts of leadership. This idea is not applicable just to what we might think of as conventional people management; it has a wide range of applications and is definitely part of user experience.

No one ever embarks on a redesign by stating that their primary goal is to better manage the user experience. Almost always, the word that is associated with a big project has something to do with transformation. If you had the chance to transform a series of disparate systems and user interfaces into a single, elegant, omnichannel user experience, why would you settle for just managing that? Sadly, it’s what many enterprise software projects end up doing.

Organizations don’t start out that way. Most start out with lots of enthusiasm and almost wide-eyed confidence that their new project will change everything. There are grand plans to do things right, at the start of a project. This vision extends to user experience more and more these days. Why? The pressures to produce consumer-quality user-interface designs have never been felt more strongly in the enterprise world than they are today. And why not try to achieve this goal? If I can leave behind my old desktop computer with its outdated Web browser and move to a personal device that is a quarter of its size—all while gaining access to more robust applications with intelligent user-interface widgets that know when to give me exactly the right amount of the data that I need—why wouldn’t I want to have that same experience on my job?

The pressures to produce consumer-quality user-interface designs have never been felt more strongly in the enterprise world than they are today.

Many C-level executives at the world’s most pervasive companies are feeling the same way. So they embark on a laudable quest: to transform their enterprise applications into seamless user experiences that make their workers more productive and provide a consumer-grade customer experience to boot.

However, many hours and dollars later, few of these endeavors actually achieve what they promised. In most cases, examples of enterprises striving to become better than they were end up just managing the mess a little bit better. After experiencing this over and over at clients, the natural tendency is to look at the reasons why this happens. Surprisingly, cross-referencing all of my projects over a period of several years has left me with two main themes regarding why enterprise software projects tend to fail in their goal of delivering stellar user experiences:

  1. Big data and no appetite to really change the problems
  2. A lack of real planning

Big Data and Its Detrimental Effects on User Experience

“It’s not possible to give your enterprise applications a sparkling, consumer-friendly design without addressing your underlying organizational issues. This is where the detrimental effect of big data occurs.”

Big data is all the hype these days—what you can do with it, how you can use it. However, in the end, it is really very much like the great California Gold Rush of 1849 that happened in the United States. A lot of land, but relatively little gold. Some got rich in that Gold Rush, but most went broke. If you look at big data improperly, it’s not really much different. After all, data—the information in the requirements document for any application—is inextricably intertwined with how a business works. It is because of this strong linkage that it’s not possible to give your enterprise applications a sparkling, consumer-friendly design without addressing your underlying organizational issues. This is where the detrimental effect of big data occurs.

Most enterprises are collections of takeovers, mergers, and acquisitions. Along with that reality come not only myriad data sources, but the technology that integrates it all. Integration is a costly and time-consuming part of any software development project, and it is usually one of the first things to get pushed off to the future, in some faraway iteration of a project. The problem is, when integration goes away, so, too, does the ability to provide a seamless user experience. Users want the ability to see data sets across applications—without actually using multiple applications. When enterprises sacrifice integration, they also sacrifice user experience. These days, when a user experience is particularly poor, there is increasing danger that a second or third iteration of a project will never happen, resulting in a somewhat cruel cycle.

Most companies have the data, they just don’t possess the will, time, or money to make it work elegantly for someone who is trying to access it.

Lack of Planning

“When you are really transforming something, you are … planning, strategizing, and anticipating what is needed far in advance of doing the actual tactical work. It’s that in-depth pre-work that usually does not get done.”

The old adage “Rome was not built in a day” seems to apply here. But what that saying does not specifically convey is that, when you are really transforming something, you are doing much more than hard physical labor. You are planning, strategizing, and anticipating what is needed far in advance of doing the actual tactical work. It’s that in-depth pre-work that usually does not get done.

Project managers, program managers, and people that I otherwise respect have told me many times: “We are agile, so UX will just happen.” While this premise is justifiably laughable to anyone belonging to the UX community, it is a reality with which we must contend.

To truly transform a user experience via a software development project, you first need to understand the goals of the project. Not weak goals such as replacing a legacy system, but goals that are tied to real business needs. It is also necessary to go a step further than just identifying and understanding business goals, then throwing some technology at the issue. Instead, it is necessary to identify the business’s goals in tangible terms. This almost never gets done, and the lack of this sort of planning greatly affects an organization’s ability to successfully deliver stellar user experiences.

My Next Column

In Part 2 of this series, I’ll explore specific activities that UX teams can undertake on these types of projects to mitigate the risks that I have identified. I welcome your comments and requests!

1 Comment

A need-of-the-time topic and good analysis, Baruch.

I feel the very same way every time I get an assignment, though in some cases I succeed, most of the time, I’m not satisfied with the final work.

The implications I face in such projects are:

  • technology constraints—For instance, same technology being used across applications. Customers will never be ready to accept changes in any form to those areas of applications where they communicate to other applications.
  • visual consistency with other applications—The idea to change the visual experience of the applications with contemporary visual design patterns are again constrained by the old design patterns to remain consistent with the other applications.

It is always right to be consistent within a family of applications, but how can one realize the transformation along with such constraints?

Because it gives little scope to incorporate a change at the same time demands the transformation. Your inputs will be very much helpful. And looking forward to Part 2.

Thank you.

Join the Discussion

Asterisks (*) indicate required information.