Solving Strategic Problems: Going Beyond Being a Technology Order Taker
Published: April 21, 2014
A few months ago, I gave a presentation to some information technology (IT) leaders, and my topic was how designing great experiences for people should enable IT to earn a more strategic role within their company. I created this presentation after years of observing the interactions between IT groups and their business counterparts within a company, as well as the subsequent involvement of external IT firms, including mine.
The common flow of interactions that occur between business and IT follows this general structure: the business believes there’s a need among their users for something, so they identify some high-level requirements and solicit IT’s help. A series of budgeting, scheduling, and scope-definition activities ensue, until everyone agrees on what they’ll develop, when, and how. Cue an external partner’s involvement through an RFP (Request for Proposal) process, whereby IT seeks proposals for the work they’ve been discussing. External IT partners begin a long proposal-submission process—listing their questions about the RFP, filling out response templates, creating implementation and resource plans, and outlining rates and budgets. This process proceeds until IT selects an external partner and the work commences.
I would like to say that this well-worn approach is tried and true, but I can say only that it’s been tried and is not very true. In saying this, I’m not referring to typical implementation hiccups that occur during a project’s execution—things like delays in the timeline, sub-par user feedback, or changing requirements. We all know that following UX methods—with early UX involvement, iterative and participatory design, rapid prototyping, and close collaboration with developers—can make implementations a success. Rather, what I am referring to is the seemingly successful implementation that, upon following up a couple of years later, we come to find out that the company never adopted—for example, that SharePoint collaboration space that no one used; that SAP system that no one used, despite its automating what had been a manual process; that SiteCore CMS that no one used for updating content.
We’ve seen all of these things happen—whether to projects that we’ve worked on ourselves or to systems that our organizations rolled out. These IT designs seemed to have all the makings of a strong solution, but missed a critical and oft-forgotten element: the right purpose. The problem with that tried, but not-so-true interaction flow between a business, IT, and their external IT partners is how transactional it is.
Typically, no one digs deeper into the issues that the business originally identified to determine the root problem they really need to solve for people. But this is where experience designers can add tremendous value to IT projects, and it ultimately leads to IT’s earning a more strategic role within their organization. In the remainder of this column, I’ll share a few examples of how experience designers can help to elevate the discussion between IT and business, by helping IT to take on a more strategic role and delivering more long-term value to clients.
A Portal Would Solve Everything
One of the more common requests that IT gets from a business is the need to build a portal. One of our Engineering clients wanted to create a portal because employees in the group had their own sets of project-related documents on their individual computers and these conflicted with each other. A project manager might communicate with an external customer, giving them one date, while an engineer would give the same customer another date.
An IT client came to us and said, “We need a WordPress portal where we can display all of a project’s status information directly to our clients.” They had documented their high-level requirements and wanted to engage us for prototyping, design, and implementation. We asked them what research they had done, and they said they had spoken to their external customers about what they would want on the site. We explained that we typically do discovery research ourselves because asking customers what they want on a site isn’t usually the best approach to learning what we should recommend for a user experience. However, they felt comfortable with their insights, so we didn’t push them any further regarding our doing up-front research with their customers.
We did explain to them, however, that we needed to take a step back: For us to create a site that met their organization’s needs, we would need to get into their heads and understand more about their business, their employees, their customers, and their processes and ways of working. They agreed, and we conducted a day-long workshop with a few project stakeholders, discussing:
- customer and employee profiles
- their engineering process, including the types of communications that occurred and the tools and technologies that they used
- major touchpoints with external customers
- where they believed this new portal would be most beneficial to their process
The Need to Dig Deeper
Through this discussion, our team learned that the employees already had a boatload of portals, databases, and centralized spreadsheets at their disposal, which they were to use to manage and track project progress. We also discovered that meetings and communications happened very frequently among engineers and project managers and customers. We honestly did not understand why this new site might be necessary when they had so many existing tools and ways of communicating status. Why did they have so many problems with everyone in the group aligning on project status?
So I asked this loaded question: “You seem to have a lot of existing resources in place that should help to keep everyone on the same page. Why do you believe this new tool would be a success when these other tools already exist?” And the business responded, “Because this one will be visible to external customers, so it will have to provide the most accurate information.” I continued my questioning, “I guess I don't understand why you would even need this. What is really the root problem here? We don’t want to build something that people won’t use.” Their response: “Well, I guess one issue is that the project managers and engineers don’t trust each other.”
Aha! Now we were getting somewhere!
So I told them, “Well, I’m not sure a portal would create trust, but let’s see what we can do.” Working from this honest insight, we shifted the goal of our workshop to discussing candidly whether it really made sense to develop the portal and, if so, what would make it a success.
Everyone agreed that there were numerous, similar tools that already existed. But issues relating to a lack of trust and miscommunications were so entrenched within this group that they needed to use the creation of this new portal as a way to start addressing those problems. Because the portal would be visible to external customers, everyone had to align on dates and status. Therefore, one of the key criteria for the portal’s success was that it needed to be fully transparent in providing data, engendering trustworthiness for both external customers and employees. For example, if a project were delayed, the portal needed to show that. These goals became our anchor for the design. The team could constantly ask, “Does it feel like I can trust this information?” This was a critical area that we probed during validation testing with customers.
The other key criteria for success was that we needed to consider the portal within the greater context of the employee culture, acknowledging that there are deeper issues they needed to resolve. When doing validation research with employees, we asked not only about the portal’s ease of use, but also broader questions about employees’ ways of working, how the tool would work with their existing resources, and employees’ interactions with one another. When we provided our findings, we included a roadmap that showed how to begin addressing the other problem areas within the group.
The portal launched a year later, and feedback has been positive. The client acknowledged that this tool would not be a silver-bullet solution; and they started fixing the other issues that we had highlighted, relating to processes, group dynamics, and communications. More importantly, the business clients gained greater understanding of their people and operations—all from what was otherwise strictly an IT implementation project. The result of this was that they began thinking differently about internal IT support and external IT partners.
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.