Design Thinking in Enterprise IT

"...the beginning is the most important part of the work..."

-- Plato, The Republic

This quote from Plato is really about the importance of early education for children, but it comes to mind for me in doing any enterprise IT project as well. Time spent in the beginning to determine requirements, scope the project, and get buy-in is always time well spent. All too often, the IT organization announces a major technology change that doesn't align with business goals. This results in the end user feeling frustrated and excluded from the decision making that went into the new system.

Examples of this are IT's selection of a new CRM tool based on its criteria rather than in partnership with the sales organization, or IT's deployment of a new collaboration tool that no one truly adopts or uses --or even needs. These kinds of misses are way too common. They can be the result of IT professionals understanding a lot about technology and not as much about what the business requires to meet its goals. A good IT pro knows the pay-off of talking with the business users ahead of technology decisions to understand more about their pain points and their objectives and how technology can help with both. These kinds of conversations take the shape of a "design thinking" exercise.

In a Harvard Business Review article introducing the concept, Ideo CEO Tim Brown defined design thinking as: a method of meeting people's needs and desires in a technologically feasible and strategically viable way.

This definition resonates with me as it encompasses the goal of any good IT conversation with the business group: "How can we meet your needs and desires, using technology that is available and aligned with our strategic objectives?" That is a worthy conversation to have -- and one any consultant will tell you isn't an easy one to conduct. Reasons I've heard from people about why they don't do this more often in enterprise IT organizations are:

  1. It will take longer
  2. We don't want them to make it harder for us
  3. I never thought of asking the users what they wanted
  4. We've always done it this way
  5. We're just replacing something, so we'll give them what they've always had

The best approach is to start with a literal tabula rasa -- a blank slate. I've walked into these kinds of discussions before with no visuals, no charts, just a blank piece of paper. From that starting point, we open the conversation with, "If you could start from scratch, how would you like this system to look for the end user?" From there you can begin sketching a vision, all the while taking detailed notes about what they say they don't want. Sometimes you learn more from those statements than from any other part of the conversation.

At the end of the discussion, you walk away with a better understanding of what is or isn't working today, what they'd like to see in the future, and a fairly clear idea of how you can leverage technology to put the pieces together. And, to resistance point #1, it may take a little longer, but investing the time up front will avoid issues downstream. Getting user requirements and using those to guide your solution design is the best way to guarantee success.

Many IT people are pretty sure they know what the solution should be, and that's a great thing. However, a motto I learned at Leadership Camp in high school has stuck with me all these years: "People tend to support the things they help create." The design thinking conversation puts everyone in that partnership and creation mode; they are a part of the development of the solution and, as such, are likely to feel ownership and involvement, two things that will help them support the plan going forward -- and head off the "look what IT did to us this time" post-implementation fallout.

The key to doing this is to come in with an open mind. Leave bias at the door and listen, listen, listen. The business end users know what they need. They sometimes might know a solution that will fit their needs. Our job is to take what they have expressed and find the best solution for their situation, not the solution that we assumed would work.

This may sound easier to do when you are making a large-scale change to a system, like a complete replacement. Design thinking conversations are equally good at helping to ferret out where problems exist. Take the time to sit down with your customer and ask them to show you how they use the tools they have. Understand how their role fits into the delivery of products or services for your company. And become a part of the process -- stepping outside our IT domain is the most important thing we can do to move from being a service provider to a business partner. Design thinking will help you have the kinds of discussions that lead to innovation and real change.

Follow Erin Leary on Twitter

@erinkleary