Additional Blogs by SAP
Showing results for 
Search instead for 
Did you mean: 
Active Participant

SAP Co-Innovation lab Project Development Process and Design Thinking

The buzz of Design Thinking in business as a conceptual framework used by a firm to spur innovation has been top of mind for many for perhaps a bit longer than what some of the more recent articles on the topic would suggest. A quick Internet search yields links to numerous magazine articles and academic
essays; about a decade’s worth including the most recent discussions. There are a few books out there too, most notably The Design of Business by Roger Martin.  Of course you can always attend Stanford to really immerse yourself in the art at the Hasso Plattner Institute of Design. Being familiar with what they do at the d school from some past project work at SAP Labs, I encountered very bright minds there originating and collaborating on multiple dimensions of design like nowhere else where they must surely consume their fair share of the global supply of Post –its. (Check out the student photos on the d school home page to see for yourself.)   This essay was written in reaction to some of the more current discussions I’ve been following on the subject of Design Thinking as it has given me reason to identify some of the key aspects of it which are clearly present within the process the SAP Co-Innovation Lab (COIL) uses to approve and enable COIL projects.

I’ve had the recent good fortune to host some design thinking sessions conducted by various SAP and partner business teams at COIL in Palo Alto and I know many of my colleagues in our other locations like Tokyo, Sao Palo and our newest location in Shanghai are doing the same. COIL Tokyo for instance now offers complementary Design Thinking and LEAN services to partners. This is being offered as a way to engage even closer with innovative
customers and partners before they even begin to develop and use COIL-provisioned SAP landscapes. These sessions are implemented as half day
workshops covering:


DT BMC (Business Model Canvas)

DT-USM (User Story Mapping)

LEAN introduction

Design Thinking and Business Thinking Together

From my vantage point in COIL Palo Alto, I have seen enough Design Thinking sessions begin with introducing the concepts and methods to the
participants and rigorously tout its widespread applications. The lead design thinking expert in the room describes a “show, don’t tell” mindset where the focus is largely upon human values. I’ve heard more than one speaker proclaim that design thinking has a “bias towards action” but in all fairness one can likely find many business methodologies proclaim to be just as action-oriented. The participants hear about strong value capture, powers of ten and what lo-fi
prototyping is, why-how laddering and empathy mapping is and how all of it applies towards unleashing creativity and innovation.

In most sessions there is always a slide or two which compares design thinking with business thinking. Design thinking is all about experimentation,
novelty and finding better possibilities. It is more about the subjective and draws from emotional insight. This all is then placed into contrast to business thinking which is always objective and rational, based only upon logical deduction, numerical models and risk management. What I then expect to follow is a
discussion surrounding how both forms of thinking process are valuable and can perhaps provide render even more value to captuing innovation when used in unison. However, I’ve yet to hear someone go into this precise discussion and in fact what I more often observe is speaker leading such sessions imply that design thinking must somehow replace business thinking if a company is serious about getting a firm grip on driving real innovation. I’ve personally thought of this as being incomplete if not misleading and definitely short-sighted.

As someone interested to know if there are other facts or informed opinions supporting my own view, I quickly found that I did not have to look too hard. Peter Merholz wrote a piece for the Harvard Business Review back in 2009 entitled Why Design Thinking Won’t Save You. In this article he too did a bit of lamenting on this same critique of design thinking superiority over business thinking in reaction to an article on the same topic from BusinessWeek magazine. I laughed out loud as he described the idea that left-brained, MBA types who drive spreadsheets all day have exhausted their abilities to innovate and only the right-brained, turtleneck wearing creative can forge the new path forward to capture more innovation.

I laughed because I recall once comparing code writers in a similar way. Early in my own career, I spent a lot of time talking to all sorts of programmers in my own effort to learn to write code.  I soon began to think that the coder with long hair gathered in a pony-tail wearing a RUSH 2112 Tee-shirt and jeans seemed to have a greater knack for creative problem solving and could render a compelling new object-oriented application more easily then the short-haired, horn-rimmed glasses wearing coder with a pocket protector.  While this more laid back, long-haired coder was maybe more approachable or there was something about their free form style that screamed creativity to me, I equally discovered that the latter type of programmer could adeptly come in behind the pony-tailed engineer to clean up bugs and optimize the program faster than coding an array using bubble sort. While he or she may not have been as approachable or seem laid back enough to tolerate questions from a newbie, they most certainly tended to offer equally useful approachs to problem solving. I soon discovered that there were many different types of coders and problem solvers out there and that even these two stereotypical programmers types do in fact possess a wealth of real talent and experience.  Understanding this and learning how to work with such a wide range of problem solvers is what I've come to find increases the likelihood that we will derive optimal benefit in the ongoing pursuit of technology innovation. 

The same holds true for Design Thinking. We need to think more about how to bring design and business thinking together. As Merholz suggests, it’s foolish to accept a dichotomy between both ways of thinking. Zoom forward to 2012 and we find a more recent article from Jeffrey Tjendra who leads an article with the title “Why Design Thinking Will Fail”. He begins by casting Design Thinking as the latest over-hyped innovation process. He agrees with Merholz that there is true value in the creative problem solving approach. For many it seems logical that innovation stems from creativity and that imagination is at its root.

Companies would find anything that can deliver creativity to be a very good thing. Tjendra cites some very good reasons (13 in all), why stand-alone Design Thinking will fail. One of these stood out big time to me where he describes the wrong implementation of Process. Design Thinking is offered as a process for delivering creativity to organizations where it becomes all too easy to believe this can be implemented like an operational process such as Six Sigma. In doing so, it can only dilute the creativity effort. Creativity is the output of divergent thinking. Implementing the great idea is convergent and this is where the heart of the innovation process lives. Tjendra concludes his article by predicting that the failure of Design Thinking will lead to its evolution of becoming integrated towards business that will then perhaps lead to turning new ideas into commercial success.  I’m interested in this view from my own
experience at COIL.

Blended Thinking

Both articles triggered a reaction from me to consider how design and business thinking occurs and influences co-innovation with partners. While COIL does not globally provide a formal program specific to design thinking, in an effort to assist COIL with being able to qualify and approve projects, its project approval process does contain several of the attributes found in both design and business thinking where deliberate effort is made to examine the intersects and how each interrelates and can influence the successful outcome for a co-innovation project. The COIL project request process illustrates a natural blending of some of the main elements found in both design and business thinking. In nearly all cases, The COIL project requestors we work with, go into the request process with both known and unknown gaps in the knowledge, skills and resources needed to pursue a project and to see it succeed.

While most of the project requestors do acknowledge that they are not always guaranteed an expected or desired result from a co-innovation project we are often impressed with what project teams put into the project effort right from the start. In nearly all cases, ideas comes from the entire project team and from both inside and outside of SAP. Time is allocated for experimenting, prototyping and all participants inject some degree of open-endedness useful to
problem solving. There is acceptance and encouragement among all for brain storming and creativity which then gets sufficiently framed by the COIL process to help the team act upon a good idea and to implement it.

It is this dimension of COIL project development that contains some of the fundamentals of Design Thinking and which strongly contributes to forming
up a successful co-innovation project. During the COIL project request process, it is quite common for COIL to bring stakeholders, project managers and subject matter experts together to first more broadly discuss project goals, business and market drivers and to explore how the various project work streams will be performed.  The COIL project process is not emphasizing creativity as a deliverable compared to design thinking as a process, but it absolutely acknowledges creativity as a cornerstone of co-innovation project development.

Similar to some design thinking workshops, these early meetings often consume copious amounts of whiteboard real estate and even colored post its and notebook pages as the participants work through tough project questions and work to refine what they want to do. While these COIL meetings are not as programmatically titled or facilitated like that of a discrete design thinking workshop, it is nonetheless a process which aids project teams to find the right balance between what is envisioned as the optimal future state and customer experience with what is still technically and economically feasible making project execution possible and prepared to deliver a positive result.

Business Thinking is an integral part of the same process too. The COIL project development process drives accurate articulation of the project’s primary business objectives and the intended use case(s) as both are crucial to the project timeline being met and for the expected result to be shared when
it is needed by the customer or intended to support an industry solution. The COIL project request process includes capturing what is objective and rational about the project and to make certain that the project cost recovery and project ROI is understood and agreed to by SAP and partner business managers and stakeholders prior to a project’s approval.  There is always an exercise in risk management ranging from correctly defining project scope to identifying if the project result will justify the time and resources required to obtain the result and what the impact will be if the project fails.

COIL Business and Project Development leads work with project requestors to understand the business challenges the project and its expected result is meant to address or contributes as a solution or new innovation for a given industry. There is an additional review to understand if the expected project result is or will be measurably known. We expect to learn if the COIL project result will contribute in some direct or indirect way to potential revenue impact for SAP and the partner(s). We then consider the project’s scope, timeline and estimate the number of COIL engineering days will be required to meet all project provisioning requirements. From the beginning when the projst propsoal is rist received, COIL project leads build a profile that can be compared to other project proposals in motion as well as those projects just started and to all active projects which helps to provide a way to quantitatively and qualitatively prioritize COIL resources for the projects of most value to SAP that lead to solutions comprised of SAP and partner-provided elements.


It is interesting to follow the ongoing debate over whether or not Design Thinking can deliver creativity as a process to a firm looking for a mechanism to drive innovation; which in today’s world is no longer really optional if longevity of business growth and profitability is to be expected. There seems to be enough understanding of the benefits and limitations of design thinking among many of the experts and critics to perhaps even negate Bruce Nussbaum’s recent claim that Design Thinking as a process to deliver the creativity needed to drive innovation is all but dead. Once a real advocate, he’s now on to what he calls Creative Intelligence (CQ) and he reminds us that he has a book on the subject published this year. Only time will tell if this takes the discourse over this topic in a new direction or becomes the evolution of design thinking integrated more deeply into business.

For the moment, my focus is simply to understand what works to make co-innovation successful. Experience has shown me that innovation is messy and co-innovation sometimes even more so where there is a constant dynamic of internal and external perceptions at play which can influence project outcome. What we witness through the COIL lens, particularly with projects where participant skills and experience vary widely, is that such project teams are comprised of versatile problem solvers who tend to have the right mix of both technical and business skill sets.

In other words, having the right composition of both left and right-brained project participants generally reflects a delight by the project team in wanting to turn over all the rocks and not just the ones they like or know best in trying to discover something new. This correct mix of leaders and experts, coupled to a  project process framework designed to acknowledge the necessity to bridge divergence and convergence stands as one example of how design and business thinking work together to best serve co-innovation.