Solving Strategic Problems: Going Beyond Being a Technology Order Taker

Tools Don’t Foster Collaboration, People Do

Another common request that IT gets from a business is to create a means of collaboration. The typical complaint is that employees don’t seem to talk to each other about their work, and managers, who observe that their employees are not sharing information, see numerous missed opportunities for working more efficiently. For one of our clients, the product regulatory arm of a materials company, the lost efficiency was just one tactical, short-term implication of people not collaborating; they had bigger issues at stake. Most of their workforce was retiring within ten years, and they didn’t have a good way of capturing an aggregate of their hundreds of years of knowledge, which is especially important in the regulatory field. They had a SharePoint portal that no one used. IT initially approached us about re-architecting that portal, thinking that making it more usable would encourage adoption.

During the pre-proposal phase of the engagement, we spoke to IT and the business about their culture and employees. We asked how people work currently, how often their employees are in circumstances that allow them to interact, and why people would want to collaborate. We helped the client to see that numerous barriers existed to their people collaborating: they have no real reason or motivation to collaborate, there are rarely circumstances in which they collaborate, and diverse personality traits meant that a natural synergy did not exist among everyone on the team. The SharePoint site, even though well designed, would not address these issues.

We proposed a set of activities to the client, which outlined what collaboration would look like for this group. We conducted interviews with employees to understand the personalities involved, their perception of the group, and what collaboration meant to them. Once we began to get some ideas about individuals’ motivations to collaborate—things like “it would make me feel good to help someone else”—we led workshops with the employees to start identifying what universal motivators of collaboration might be; and helping to align individuals’ personality-driven motivations with the overall motivations of the group and its culture. Finally, we asked everyone to brainstorm enabling behaviors that would support the cause—for example, “What are the things you will do differently starting tomorrow.”

Once we had established a model for collaboration for the overall group, we identified what the IT and business leaders would need to do to sustain it, including making changes to performance assessments and, of course, the SharePoint site. The site certainly had a role to play, but rather than assuming its existence alone could change deeply embedded behaviors, the client now understood that technology is just one piece of creating a collaborative culture. Similar to the previous example, the business and IT had jointly created a plan for addressing the problem of collaboration and created the opportunity for the group to collaborate rather than just talking about “that SharePoint site IT built.”

Make It Like Amazon

The final example I want to share with you illustrates the value of broadening the conversation between the business and IT. This case study involves the common request for IT to add ecommerce to a Web site, usually followed by, “We really just want Amazon.”

Businesses often have fairly manual processes for sales and ordering products and want to move toward digitizing these processes, enabling customers to order products themselves rather than working with a salesperson or account manager. Because ecommerce is typically a big shift from what groups may do today, they usually say that they want using it to be really easy for people—“just like Amazon.” The problem is that, while building an Amazon-like shopping cart may make these tasks easy for employees and customers, would enabling ecommerce make sense as an overall strategy?

This was precisely the question that one of our clients asked us. Our client sells complicated textiles and materials. IT had recently launched a customer portal that provided basic product information and supporting marketing content, and the business wanted to add ecommerce. They engaged us to validate that strategy with their customers. Despite their asking us to validate their strategy, we knew that they were confident that ecommerce would make sense for their business; they also wanted us to begin coming up with concepts for what the new ecommerce portal would look like.

We conducted discovery sessions with the client to understand the buying cycle for their business and realized that it can be quite complicated. Significant back-and-forth happens between customers and their account managers when choosing products, because the company sells textiles and materials that are inherently complicated. During this initial phase of our work, we made sure that we communicated this complexity to stakeholders—both in business and IT—early on and socialized the idea that selling their products is very different from selling the types of products that Amazon sells.

When conducting research, we elicited their customers’ motivations, expectations, and apprehensions about moving to ecommerce to interact with our client. More importantly, we discussed how they see ecommerce fitting into their existing relationship with our client and what other opportunities they might see for improving that experience. After analyzing the data, our team realized that there were too many barriers for ecommerce to be a success, including the complexity of the sales cycle and the customers’ not having the payment authority to purchase items online.

We had to tell our client that they needed to rethink their original strategy. However, instead of simply saying, “We don’t recommend ecommerce and here’s why,” we gave them additional ideas about what would be valuable to their customers, including document-management tools, tools for salespeople, and online order tracking.

The entire team—business, IT, and us—then conducted a strategy and planning workshop to outline a roadmap for the implementation of these ideas. In doing so, we elevated the discussions between business and IT, progressing from “give me ecommerce and an Amazon shopping cart” to a focus on answering the question: “What can we do to improve the relationship with and experience of our customers?” There was an important distinction between simply fulfilling the client’s request for ecommerce—through which the business would have continued to approach IT tactically—and the business and IT working collaboratively to solve bigger, more holistic problems—enabling the business to view IT as a true partner working to support the business’s goals.

Core Principles and Lessons Learned from IT Projects

While it’s easy to outline a few case studies showing how experience designers can help IT to achieve a more strategic role when interacting with the business, tangibly accomplishing such goals is not so easy. It takes time. And for every success story that I’ve shared, I have about a dozen case studies that never progressed so far or achieved such success. When you approach IT projects in the future, keep the following helpful core principles and lessons learned in mind:

• Senior exposure matters. It is important to form relationships at the right levels within an organization. Even when you’re working with a lower-level leader as your primary client, it is important for them to understand that, for you to do your job effectively, you’ll need to understand the goals of stakeholders who are above them.
• Keep digging. It should be clear from the three examples that I’ve outlined that it’s important to ask questions—even difficult questions. Don’t take action on a project’s initially stated direction without asking, “Why?”
• Have confidence. No client will allow you to talk to diverse stakeholders or make suggestions that are broader than the initial scope of a project unless you do so with confidence. You’re the expert, so act like one.
• Gain trust. Strive for the greatest outcome that you can achieve on projects: earning your stakeholders’ trust. Even though you’ve provided stellar deliverables, if a stakeholder can’t say, “I trust them,” you still have work to do.

Hopefully, by approaching projects with these principles in mind, you’ll start to see the benefits of doing so. However, if you begin to hit barriers—for example, your primary stakeholder doesn’t believe that the questions you’re asking are relevant, even though you say they are—know when to stop pursuing a higher goal and simply stick to the original scope of a project. It’s certainly not worth jeopardizing your original project by pushing too hard.