Design thinking: A new approach to fight complexity and failure

Design thinking: A new approach to fight complexity and failure

Summary: Design thinking offers an alternative to the rigidity of traditional project management and can help drive successful projects.

SHARE:
TOPICS: CXO, IT Employment
29
Design thinking
Photo credit: Michael Krigsman

The endless succession of failed projects forces one to question why success is elusive, with an extraordinary number of projects tangling themselves in knots. These projects are like a child's string game run amok: a large, tangled mess that becomes more convoluted and complex by the minute.

In my view, the core problem lies in mismatched expectations, poor communication, and a host of other non-technical causes.

During the last few years, the practice of "design thinking" has become popular among some enterprise practitioners and observers. Design thinking helps structure team interactions to cultivate greater inclusiveness, foster creativity, and align participants around specific goals and results.

I first learned about design thinking during conversations with people like Chirag Metha, an enterprise software strategist and design thinking expert; Chirag is one of the most thoughtful folks I know and writes a great blog on enterprise software. With these qualifications, of course I asked him to write a guest post explaining how design thinking can help project teams run successful implementations.

Chirag Mehta is an enterprise software generalist with 15 years of experience in strategy, design, architecture, product management, and product development in areas such as ERP, CRM, BI, middleware, and infrastructure. He is a top independent blogger on cloud computing, an adjunct faculty member, and advisor to many entrepreneurs. Chirag is passionate about design thinking and has coached others at Stanford d.school.

Chirag works for SAP, driving business development and early adoption of new applications built on SAP's in-memory computing platform. Previously, he was a strategist with SAP's office of the CEO (and CTO), where he served as trusted adviser to the company's CEO, Chairman, CTO, and executive management on topics such as design thinking, cloud computing, SaaS, Web 2.0, BI, in-memory computing, location-based applications, social media, and sustainability.

Thank you to Chirag Mehta for writing this guest post.

--------

IT projects fail all the time. Business blames IT, IT blames the system integrator (SI), who then blames the software vendor. After all this blaming and shaming, everyone goes back to work on another project without examining the project management methods and processes that caused the failure. And, so, they fail again.

There's no one definition of design thinking. It's a mindset and set of values that applies both analytical and creative thinking towards solving a specific problem. Design thinking is about how you think and not what you know; it is about the journey and not the destination.

Having followed Michael Krigsman's analysis of IT project failures, it became evident that design thinking can play an important role in improving enterprise software development and implementation. The design thinking approach offers a means to address the underlying causes of many project failures — poor communication, rigid thinking, propensity toward tunnel vision, and information silos.

I have distilled important lessons from design thinking into six principles that can help stop project failures. Along the way, we will draw comparisons with Agile development, since that distinction is often a source of confusion when discussing design thinking.

Continue reading for the six principles »»

These six principles, based on design thinking, can help any project team operate more successfully.

1. Put a multi-disciplinary team in charge. You can't pin down project failure on one person or one topic and yet we continue to use a person-centric method to manage projects. No one on a project team wants to fail. If you collectively put responsibility of the failure or success on the shoulders of the team and get them trained and motivated to think and behave differently, you will mitigate much failure.

Multidisciplinary teams champion the user, business, and technology aspects of a project in a more comprehensive manner than would otherwise be possible. Typically, an IT team talks to business stakeholders who then talk to end users, which creates communication gaps, delays, and inefficiency. Far better to create a single team that includes participants from all areas, creating a single unit that includes multiple perspectives.

Try to staff your project team with "T-shaped" people, who possess a broad understanding and empathy for all the IT functions, but who also have deep expertise in one domain to champion that perspective. This approach can ensure that your solution is economically viable, technologically feasible, and delights the end users. A more balanced team also humanizes the project and its approach. Stay small and resist the temptation to set up very large teams. If you believe the "two-large-pizza-team" rule, those projects are team-driven and tend to be more successful. Start-ups can build something quicker because they are always short on people. As your group gets bigger and bigger, other people tell you what to do and team members feel less connected to their work as it relates to the outcome.

2. Prepare for failure in the beginning. I recommend kicking off the project with a "pre-mortem workshop." Visualize all the things that could go wrong by imagining that the project has failed. This gives the team an opportunity to proactively look at risks and prepare to prevent and mitigate them. I have sat through numerous post-mortem workshops and concluded that the root causes of failures are usually the same: abstract concepts such as lack of communication, unrealistic scope, insufficient training, and so on. If that's true, why do we repeat the same mistakes, causing failure to remain a common situation? Primarily because many people find it hard to imagine and react to abstractions, but can relate much better when these concepts are contextualized into their own situation.

3. Be both vision- and task-driven. Design thinking emphasizes storytelling, shared vision, and empathy towards all stakeholders involved in a project. On many projects, participants focus exclusively on their own individual tasks, thus becoming disconnected from the big picture.

While design thinking strives to connect participants to the larger vision, Agile development can be very task-driven. Everyone gets a task without necessarily understanding the big picture, or vision, or even seeing the connection between his or her tasks and the final outcome. In this situation, a project can fail and people may not understand their role, thinking they failed due to someone else's work. If participants don't realize their tasks contributed to a failure, they won't try to learn and change.

On the other hand, vision-driven approaches are very powerful. People perform their tasks, but the story and vision persist throughout the project; the same story gets told by different people throughout the lifecycle of the project to avoid that big picture fading away. All the tasks have a bigger purpose beyond their successful execution. Even good project managers miss this point. At review meetings, it is important to evaluate what the team did right but also revisit the vision and examine how recent outcomes fit the overall story.

4. Fail and correct then fail again. Design thinking contradicts other methodologies that focus only on success. In design thinking, failing is not necessarily a bad idea at all; however, we fail early and fail often, and then correct the course. In many projects, people chase success without knowing what it looks like or expecting to fail; therefore, they do not learn from the process.

One of the challenges with traditional project management is the need to pick one alternate and run with it. Turns out that you don't know everything about that alternative and when it fails, due to the irreversible decision that you made, you can't go back. Far better to iterate on a number of alternatives as fast as you can before deciding which one will work. This approach requires a different way of thinking and planning your project.

5. Make tangible prototypes. Agile proposed creating unstructured documentation as opposed to making structured requirement documents. But, unfortunately, that is not enough to solve many problems. One of the core characteristics of design thinking is to prototype everything, to make a tangible artifact and learn from it. The explorative process of making prototypes makes people think deeply and ask the right kind of questions. It's said that "a computer will never give a wrong answer but it will respond to a wrong question." The prototypes encourage people to focus on what I want to know as opposed to what I want to say. This is very important during the initial design phase of the project.

One of the biggest misconceptions about prototypes is that people think they are too complex to make and are overhead or a waste of time. This isn't true at all. Prototypes can be as simple as a hand-drawn sketch on a paper or as complex as fully functional interactive interface. The fidelity of a prototype is based on what kind of questions you want answered. People tend to fill in gaps when they see something raw or incomplete, whereas hi-fidelity prototypes can be too complete to solicit meaningful feedback. As I already mentioned, most people respond better to an artifact as opposed to an abstract document. Prototypes also make the conversation product-centric and not person-centric. They also help to get team members on the same page with a shared vision.

6. Embrace ambiguity. One of the problems with traditional project management methodologies is that they make people spend more time in executing the solution and less time on defining the problem. Design thinking encourages people to stay in the problem space as long as they can. This invariably results in ambiguity, which is actually a good thing.

Ambiguity fosters abductive thinking — a mindset that allows people to explore what is probable with the limited information on their hands without concerns about proving or concluding that it actually works. It helps people define a problem in many different ways, eventually letting them get to the right problem they eventually should focus on.

This also supports the emergent approach that design thinking advocates as opposed to a hypothesis-driven approach. In a hypothesis-driven environment, people tend to focus on proving a premise created by a small group people. Rushing to a solution without defining the problem, and having no emergent framework in place to include the insights gained during later parts of the project, certainly contributes to failure.

Organizational barriers to success »»

Organizational barriers to success

Even the best methodology requires organizational commitment to success. For design thinking to work, it is also necessary to address these common organizational issues, each of which can impede progress and limit successful outcomes.

Lack of C-level commitment. Although design thinking is applicable at all levels in an organization, executive management must bless it by publicly embracing and practicing design thinking. Top-down initiatives and training only go so far.

When the employees see their leaders practice design thinking they are more likely to embrace and practice it themselves. The same is true with adoption of social media and collaborative tools inside an organization. The best signal to your employees is by showing them a firm belief in the method by practicing it firsthand and sharing positive outcome.

Resistance to change. People in any organization are usually fundamentally against change, even if they believe it's a good thing. They don't want to get out of their comfort zone and therefore practice the same methods that have resulted in multiple failures in the past. Changing behavior is difficult but fortunately design thinking can help.

One of the ways I have taught design thinking is by taking people away from their primary domain and having them solve a very different kind of problem such as redesigning a ticket vending machine or a fast food restaurant. My team was hugely successful since it was a completely different domain and it didn't interfere with their preconceived notion of how a project should be executed. People's reservations are tied to their domain; they are willing to adopt a new method and new way of thinking if you coach them outside of their domain and then encourage to practice it in their comfort zone.

Lack of industry backing. Despite being informal, undocumented, and non-standards-based methodology, Agile experienced widespread adoption. I would attribute this success to two things: a well-defined manifesto by lead industry figures and organizations publicly committing to adopt the methodology. Design thinking lacks these attributes.

Even though industrial design companies such as IDEO have evangelized this approach, there's still confusion around what design thinking actually means. This also makes it difficult to explain design thinking to a wider audience. If a few organizations publicly endorse design thinking, create a manifesto, and share the best practices to gain momentum, many of the adoption hurdles will go away.

Lack of key performance indicator (KPI) frameworks. Design thinking faces the same challenge that most Enterprise 2.0 tools face: lack of measurable KPIs.

For number-driven leaders, lack of a quantifiable framework to measure and monitor the impact of a new methodology is a challenge. Some leaders are good at adopting new ways of doing things and others are not. In these cases, isolate a project that you can't measure and start small. Contain the risk but pick a project that has significant upside, to keep people engaged and motivated. You may still fail, or not achieve a desired outcome, but that's what design thinking is all about.

It's worth noting that Agile, as a software project methodology, has well-defined quality and reliability KPIs such as beta defects, rejected stories during a scrum cycle, and the delta between committed and delivered stories.

Fail early and course correct the next time. Remember that adoption and specific practice need correction and not the method itself. Don't give up.

Final thoughts »»

Final thoughts

During my extensive work on design thinking — practicing, coaching, and analyzing — I often talk with people who believe that design thinking is merely a methodology or approach for "visual design." This view is a false perception. Design thinking comprises a set of principles one can apply during any stage of the enterprise project lifecycle along with other project management methodologies. This approach is valid for the CEO and executive management all the way to the grass roots.

Another common point of confusion is the distinction between design thinking and Agile methods of software development. The primary difference is that Agile offers a specific set of prescriptive processes while design thinking encapsulates a set of guidelines and general principles. Although not the same, the two approaches are highly complementary (even on the same project), because both recognize the benefits of using iterative work cycles to pursue customer-centric goals.

Always remember that real people work on every project. The best methodologies are inherently people-centric and help participants anticipate likely causes of failure. Visualizing failure early in a project is an excellent means to prevent it from occurring. We're all human and may make mistakes but certainly no one wants to fail.

Design thinking can make potential failure a learning tool and not a final outcome.

--------

Thank you to Chirag Mehta for writing this guest post.

Topics: CXO, IT Employment

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

29 comments
Log in or register to join the discussion
  • RE: Design thinking: A new approach to fight complexity and failure

    "One of the problems with traditional project management methodologies is that they make people spend more time in executing the solution and less time on defining the problem."

    Well, if you spend too much time defining the problem, you might never get around to solving it.

    In fact, I would say the opposite is in fact true right now - how many times have we complained that companies are too slow to react? They're huge monoliths. The top level takes too long to execute any solutions. If solutions aren't executed, nothing ever gets done.
    CobraA1
    • RE: Design thinking: A new approach to fight complexity and failure

      @CobraA1 Fair point, except many companies have little understanding how to prepare properly for an implementation. As a result, mismatched expectations surface downstream as failure-causing events.

      Preparation is not just a function of time, but also of thoughtfulness and intelligence. Spending time without intelligent guidance is simply a waste.
      mkrigsman@...
      • RE: Design thinking: A new approach to fight complexity and failure

        @mkrigsman@... 'tis true too. It is a balancing act.
        CobraA1
    • What exactly is the "design" behind this thinking?

      @CobraA1 you raise a good point. <br><br>We're clearly unhappy with the results and the problems are so widespread that we automatically blame the methodologies. However, when you examine the methodologies, you find that they're actually not to blame. It's the EXECUTION that's the problem. In this case it's not the game, it's the players...
      PragMatador
  • RE: Design thinking: A new approach to fight complexity and failure

    Yes, there are cases of poor execution as well and design thinking is not going to necessarily solve the issue of people being indecisive or complacent. However, solving a wrong problem is same as not solving a problem or solving it wrong; both situations lead to a failure. I have found that not spending enough time on finding the right problem is the primary reason for solving a wrong problem. Design thinking helps people to define the right problem before they decide to execute on it. I'm not suggesting people to spend disproportionate amount of time on finding the right problem as opposed to solving it, but just a reminder to balance both the aspects.

    Thanks!

    Chirag Mehta
    tochirag
    • RE: Design thinking: A new approach to fight complexity and failure

      @tochirag Yes, critical thinking is the best place to start, but we have all experienced "Paralysis by Analysis." The alternative is "Analysis Paralysis" or "Shoot. Aim.", which is equally bad.

      What you are getting at, I think, is root cause identification. Have a look at http://www.tomhcanderson.com/2010/05/21/eli-goldratt-on-thinking-analytically/ Eli Goldratt has a lott of good and pramatic things to say on the subject of design thinking.
      Trevor Miles
    • Need more Case Studies...

      @tochirag While I appreciate what you're trying to do here, it's clear that these "principles" have limited practical value to put it very mildly. Out of respect for Mr. Krigsman, I'll reserve more pointed and critical comment but I strongly urge you to seek practical application of these ideas in large, complex IT projects and measure the outcomes. Case studies will help you "condense the nonsense" as Terry Tate would say. I also invite you to read my point-by-point review further down in the responses.
      PragMatador
  • RE: Design thinking: A new approach to fight complexity and failure

    [q]"1. Put a multi-disciplinary team in charge"[/q]
    With one of the challenges of failure being the blame game (no one taking responsibility but instead pointing the finger at others), I find this suggestion rather ironic. This suggestion creates a system where the workers have more places to point the finger rather than fewer places to place the blame.

    Management by committee is generally inefficient, it often leads to never ending conflicts of ego centric ideas and eventually, in general, those best at playing group politics are the ones that get their way.

    I do not intend to imply that ideas should be top down. A person-centric team, with the correct person directing a team, does not exclude abstract methods of problem solving by team members nor does it prevent input and ideas from different parts of the team.

    [q]"You can't pin down project failure on one person or one topic and yet we continue to use a person-centric method to manage projects."[/q]
    If you can't pin down failure to one person then it was not truly a "person-centric method" of management.

    If different departments can play the blame game, then no one was truly in charge and many were only given the illusion of authority.

    [q]"On many projects, participants focus exclusively on their own individual tasks, thus becoming disconnected from the big picture."[/q]
    This is usually the result of a disconnected person in charge. I have worked with managers who had almost no overall awareness concerning the status of the different divisions of a project and often many on the project would take advantage of the situation. In the end the project would fail and those who were slothful would point the finger elsewhere and the manager pointed the finger at a different department.

    I have also worked with managers who often knew more about the status of each division of a project than many who were in charge of each division. When the person that is directing a project is actually doing their job, others who are on the project actually focus because when the project organizer is fully involved the teams are fully aware that the teams have no opportunity to pull the wool over their manager's eyes.


    I am sure that your described system would work, but it takes a diligent organizer to pull it off. Just as it also takes a diligent organizer to efficiently manage and direct a person-centric team.
    John238
    • RE: Design thinking: A new approach to fight complexity and failure

      @John238 Thanks for your comments and views -- appreciate your taking time to share them.

      While each of your points may be valid, there is an underlying problem when taking them as a whole, in my view. The basic reality is that coordinating a team (including project participants, technical resources, and business stakeholders) is the key challenge for achieving success. Design thinking offers an approach to align all the players while maintaining a discerning view toward various assumptions and goals.

      Projects fail because participants are self-serving, try to game the system for their own gain, are confused and inexperienced, and so on. While no system can completely stop this behavior, especially on large projects, design thinking at least makes a serious effort. In my experience, serious attempts to align participants will pay dividends.

      On the other hand, if no one involved in the project really cares about the outcome, then why bother to fix anything? In that case, the entire project becomes little more than a political shooting match where everyone is out for themselves. While it's easy to find examples of those projects, I am personally more interested in folks who are trying to do the right thing.

      Although you are correct in suggesting that design thinking is not a panacea to solve all problems, it does offer a genuine step in the right direction. Design thinking offers a worthwhile view that is highly consistent with my own perspective on IT success and failure. That's why I invited Chirag to write this post.
      mkrigsman@...
    • Project Failure is a Process Problem, not a People Problem

      @John238

      Possibly the most detrimental aspect of how we deal with project failure is the defensive proclivity of pointing fingers and assigning blame. There's usually plenty of blame to go around.

      Instead of trying to figure out who's at fault we would be better off figuring out WHAT went wrong and adapting our process as needed to try to do better the next time. Project failure is a Process problem. There are two logical possibilities:

      1) The process is incapable and therefore cannot result in project success.
      2) The process is capable but the participants are unable to effectively execute it (lack of training, capacity, timeline, etc., all ultimately process-related).

      The third possibility is sabotage, which is a totally different challenge.

      Unfortunately, the mechanism that would allow for proper analysis of the process is usually not given enough respect. This mechanism is the project post-mortem which, when properly executed closes the loop in the continuous process improvement cycle.

      Bill Monroe, Project Portfolio Excellence, Inc.
      wmmonroe@...
      • RE: Design thinking: A new approach to fight complexity and failure

        @wmmonroe@... Ah yes, our old friend sabotage. Don't you love it! The fact that it happens never ceases to amaze me.
        mkrigsman@...
      • RE: Design thinking: A new approach to fight complexity and failure

        @wmmonroe@...

        "Possibly the most detrimental aspect of how we deal with project failure is the defensive proclivity of pointing fingers and assigning blame." Well said, Bill.

        One of the things that design thinking has taught me and several other individuals is the humility. I have learned that failing is perfectly acceptable as long as you learn from it and do a better job next time. I have seen that primary reason behind assigning blame is that people are incapable of dealing with humility by recognizing a failure in public. This drives them to the defensive side. But, if your methodology is inherently designed based on "fail early and fail often" slowly and steadily the blame game goes away.

        Thanks,

        Chirag
        tochirag
    • RE: Design thinking: A new approach to fight complexity and failure

      @John238 Thanks for your comments. I really appreciate it.

      I typically see two views on any project: management-centric and team-centric. The management does want single person who is accountable for the failure since people do point fingers at each other. However, in most projects, team-centric view is completely missing. The individuals are made responsible for doing something but they're not necessarily accountable for the overall project since they are removed from the overall vision. I am suggesting to do both: have a person who is accountable for the project (which most projects do) as well as have people on the team responsible as well as accountable for the projects by making sure that they're grounded in the vision and they feel that whatever individual tasks they's performing are not just tasks but they have a broader meaning towards accomplishing the vision. In my experience, this is missing in many projects,.

      You're absolutely right. Any system is as good as the people working on it. Design thinking can't change that, but design thinking can help people who want to succeed and are open to a positive change. Organizational behavior is far more complex than any project management methodology out there.

      Thanks,

      Chirag
      tochirag
  • Interesting but I disagree with #2

    I generally agree with a lot of these approaches. But this one I don't agree with:

    2. Prepare for failure in the beginning. I recommend kicking off the project with a ???pre-mortem workshop.??? Visualize all the things that could go wrong by imagining that the project has failed.

    In my experience, what we visualize is much more likely to come into reality than what we don't. And by visualizing success - in addition to increasing your odds - you can accomplish the exact same goal of seeing your obstacles more clearly. Visualizing success in order to "see" the problems more clearly, however, requires that you visualize it truly - personally - even emotionally. When you can put yourself IN the situation of success and articulate what that really looks and feels like - as a group - everything out of alignment with that experience pops into immediate relief. This is a bit of an art, but it's not hard. Here's a more in depth guide for anyone interested: http://ht.ly/7MASt
    Dana Theus
    • RE: Design thinking: A new approach to fight complexity and failure

      @Dana Theus

      Yes, but the problem with what you are suggesting is that by "visualizing success" there is the danger of being overly optimistic about the vision, which can be counterproductive when that vision begins to unravel. (i.e., when Murphy's Law kicks in, which is it usually does at the most inconvenient of times).
      crystalsoldier
    • RE: Design thinking: A new approach to fight complexity and failure

      @Dana Theus

      Thanks Dana for the comment.

      I do both. Achieving success involves understanding and visualizing what success actually means. I do that by sharing and re-sharing the vision and keeping that vision persistent during the project by leaving the vision storyboard in a project room or in a hallway. Everyday, when people come to work, they see those artifacts and it reminds them of the success that they are trying accomplish. I mentioned in the post that a lot of people chase success without even knowing what it looks like.

      Visualizing failure does not make people fail but it makes them better prepared to anticipate the conditions that might result in a failure. This is to avoid a black swan effect. People are not good at reacting to conditions (leading to a failure) that they haven't encountered before. Visualizing failure also helps to organize a project to address those issues upfront such as missing training, scope concerns, lack of buy-in etc.

      Thanks,

      Chirag
      tochirag
      • RE: Design thinking: A new approach to fight complexity and failure

        @tochirag I must side with Chirag. While I don't discount 'visualizing success' as a motivator, what happens is that the people most motivated in this manner are the ones least equipped to deal with failure. And when i write 'deal eih failure' I don't eman accepting it, but ratehr doing something positive about it that could save the project. All to often the 'visualize success' people collapse into a cycle of recrimination and endless analysis of 'what went wrong', when 'what went on' was far too much rosy 'visualization' leading to unrealistic expectations and goal setting.
        Trevor Miles
  • This happens every few years.

    Someone comes out with a "new" idea on how to manage projects. It takes a year or two before they realise they need to go back to the tools that work.
    NoAxToGrind
    • RE: Design thinking: A new approach to fight complexity and failure

      @NoAxToGrind Tools that work? Given the high rates of IT failure globally, I would suggest we need basic changes to IT project management. In my opinion, traditional tools do not work, as demonstrated by failure statistics. If you disagree, please share your views!
      mkrigsman@...
  • RE: Design thinking: A new approach to fight complexity and failure

    Really well thought through article. Some thoughts...

    1. I agree that the same mistakes continue to be made in the same organization on successive projects. Somehow the "post"-discussions don't seem to have an impact. A "pre"-discussion definitely seems worth a try.
    2. Management by committee definitely has advantages since you get the right group of stakeholders having the appropriate level of communication going. It will work well if all is going well. However, if blockers, incompetence or sabotage makes and appearance, I am not sure how this methodology will react.
    3. Lack of KPIs in this methodology is definitely something that lends itself to an increase in risk for the "funding" party. Commitment and collaboration will make it work, but how do you defend against lack of either?

    Thanks,
    Aviral
    AviralSingh