Design Thinking and Emerging IT Roles


This is the third and final part in a multi-part post inspired by Robert Pirsig’s masterwork, Zen and the Art of Motorcycle Maintenance.  In Part 1 (titled “Reflections on ‘Zen and the Art of Motorcycle Maintenance’ 38 Years Later “) I discussed the implications for IT professionals of Pirsig’s musings on ‘classic’ versus ‘romantic’ worldviews, and his struggle to resolve these.

In Part 2, (titled “Zen, Motorcycle Maintenance, Design Thinking and Information Technology”) I teed up my observation that this classic-romantic balanced approach is embodied in the “design thinking” movement, popularized by Tim Brown and Ideo and exemplified by companies as diverse as Apple, Proctor & Gamble, Herman Miller and GE.  I discussed why Design Thinking is becoming increasingly important to the IT profession.  Among the reasons for the rising importance of Design Thinking in IT:

  1. Thanks to the likes of SAP, Oracle, et al, and the growing base of cloud-based ‘applications as a service,’ most of the opportunities to improve or automate transactional business processes have been exploited.  Today, businesses are increasingly searching for product, service and business model innovation.
  2. As we accelerate the move from custom development to personal apps, reuse, and “mash-ups,” much more emphasis is placed on synthesis rather than analysis – leveraging widgets and components rather than coding solutions from scratch.

I will pick up in this final part where I closed Part 2, with a discussion of three roles that are key to instilling Design Thinking in an IT organization.

Key Roles for Design Thinking in IT

Achieving the classic-romantic balance in discovery and solutioning involves many IT roles, but there are three roles that I believe are key:

Roles – Not Necessarily Jobs!

Before we examine these roles and how they work together, I want to emphasize I am talking about roles, as opposed to jobs.   The distinction is important in that the notion of organizing around roles imparts flexibility and variety for a workforce, whereas jobs tend to constrain people in boundaries defined in job descriptions.  An individual typically will hold only one job, but may fill multiple roles.  For example, my job is Principal in a consulting firm.  In some engagements, I am the Engagement Lead.  In others, I might be a Subject Matter Expert.  In still others, I am the Client Relationship Officer.  Beyond engagements, I might be a Research Program Leader or a Research Associate.

Also, these roles are typically instantiated with all sorts of labels – rarely the label I’m using here.  For example, I’ve worked with Business Relationship Managers (BRM’s) who were called Business Partner Director, Account Manager, Client Relationship Manager, IT Business Partner, Business IT Partner, IT Demand and Account Manager, Client Engagement Director, and so on!  And the specific missions, visions and implementations of the BRM role has been as varied as their titles!

Nevertheless, let’s drill into these roles and how they relate to each other and to moving IT to more of a Design Thinking philosophy.

Business Relationship Manager

I’ve posted extensively on this role in the past – it’s the role that sits between the IT organization and its business clients.  As such, it both represents the business clients to IT, and IT to the business clients.  This role has surfaced over the last 10 years or so.  I don’t know what percentage of IT organizations have this role today, but as an indication, LinkedIn hosts 2 groups dedicated to the role.  One group – IT Business Relationship Management – currently boasts over 1,800 members.  The other group, Professional Business Relationship Managers currently has over 2,600 members!  (In the interests of full disclosure, I co-manage the latter group.)

As the bridge between the business and the IT organization(s), the BRM plays a key role in moving above and beyond the traditional “requirements analysis” to an approach to discovery and solutioning that is more:

  • collaborative
  • abductive
  • experimental
  • integrative
  • outside-in
  • human-centric
  • innovation-biased approach

As such, the BRM has to understand Design Thinking, and ensure that the qualities listed above are brought to the table and play together effectively and efficiently.  The BRM herself does not have to be expert in these qualities, but must be an effective “broker” ensuring that people with the needed competencies and incentives are at the table.  These competencies will often be found in the other two emerging roles – those of Enterprise Architect and Product Manager.

Enterprise Architect

As with BRM’s, Enterprise Architects (EA’s) come in all sorts of flavors with a variety of titles.  The major distinction I would make is with what are generally called IT Architects.  Enterprise Architects are clearly focused on the business, business models, major business processes, business-IT platforms and the ecosystem within which the business operates.  IT Architects, by contrast, are focused on the technologies, their standards and how they inter-operate.

Wikipedia defines Enterprise architecture (EA) as:

… the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.

Practitioners of EA call themselves enterprise architects. An enterprise architect is a person responsible for performing this complex analysis of business structure and processes and is often called upon to draw conclusions from the information collected. By producing this understanding, architects are attempting to address the goals of Enterprise Architecture: Effectiveness, Efficiency, Agility, and Durability.

As with BRM’s, the EA role has been growing in prominence over the last 10 years or so.  Typically, it is complementary to the more technical roles of IT Architect, Information Architect, and so on.  Also, as with BRM’s there is little that is ‘standardized’ about the EA role, and by many measures it is something of a stretch to use the term “profession” when talking about EA’s, in spite of the efforts of bodies such as The Open Group Architecture Framework (TOGAF®), and my old friend, John Zachman and his Zachman Framework for Enterprise Architectures.

Again, as with BRM’s, LinkedIn is home to an Enterprise Architecture Network, with an astounding 85,000+ members!  As an example of the passion exhibited by this group, a recent comment that stated, “EA is often left in IT because it can only handle tame problems” garnered 572 comments!

At its best, the EA helps bring to the business-IT discovery and solutioning table some of the competencies from my bulleted list above.

Product Manager

The third role in the triad that can help IT organizations introduce more Design Thinking into their activities is that of Product Manager.  This role is far more scarce in IT organizations than either BRM or EA.  It is, however, universal in product companies, including information technology product companies.  Wikipedia defines Product Management as:

…an organizational lifecycle function within a company dealing with the planning, forecasting, or marketing of a product or products at all stages of the product lifecycle.

The role consists of product development and product marketing, which are different (yet complementary) efforts, with the objective of maximizing sales revenues, market share, and profit margins. The product manager is often responsible for analyzing market conditions and defining features or functions of a product. The role of product management spans many activities from strategic to tactical and varies based on the organizational structure of the company.

While involved with the entire product lifecycle, the product management’s main focus is on driving new product development. According to the Product Development and Management Association (PDMA), superior and differentiated new products — ones that deliver unique benefits and superior value to the customer — is the number one driver of success and product profitability.

Of particular note, Wikipedia goes on to note that:

Product management often serves an inter-disciplinary role, bridging gaps within the company between teams of different expertise, most notably between engineering-oriented teams and commercially oriented teams. For example, product managers often translate business objectives set for a product by Marketing or Sales into engineering requirements. Conversely they may work to explain the capabilities and limitations of the finished product back to Marketing and Sales. (Emphasis added.)

The Design Thinking Triumvirate

So, the keys to getting more Design Thinking into Business-IT solutions lies in the triumvirate of Business Relationship Manager, Enterprise Architect and Product Manager, with the BRM as the broker and orchestrator of these roles.  There are, of course, other roles played – e.g., business analyst, project manager, program manager, and so on, but I wanted here to focus on those roles which are less common but in the ascendancy.

Graphic courtesy of Green Hat Group

Enhanced by Zemanta

Customer Experience, Taming the Remote Control Madness – And a Tale of Advances in End User Programming

I rarely get so excited about technology that I post about it – that’s not this blog’s raison d’être.  However, between being snowed in (a rare occurrence in Atlanta, GA!), being really delighted with a great product that really solves a familiar and widespread problem, and enjoying a very positive series of customer experiences with the product’s vendor, I thought I’d break ranks, as it were, and talk about a product – and how it manifests the evolution of end user programming and what used to be called “user friendliness.”

The Challenge of ‘Best of Breed

I think everyone in IT has at some point wrestled with the choice between ‘integrated’ solutions and ‘best in breed’.  The analogy of home entertainment plays out well to illustrate the pros and cons.  I won’t go into this well worn territory – suffice it to say that most of us end up with best of breed, and pay the price of a coffee table full of remote controls and the minor maintenance headaches they bring with them (how many different kinds of batteries can remote control manufacturers find to make our lives miserable?)

An Early Solution

In 2006, my wife and I with our ’empty nest’ decided it was time to downsize our living situation and move into a town house in a community with shared common areas such as gym, swimming pool, tennis courts, and so on.  To be frank, I was not thrilled with the downsizing plan, but managed to blackmail myself with the idea that we’d get the basement of said town house finished and turned into a home theater and a nice home office (where I spend much of my time).  Strangely, the basement in our town house is where the second story of most homes would be (don’t ask!) so the office has windows with great views into the woods.

With money saved by the down sizing, I went for a pretty high end (for the day) home theater, with best of breed components.  Given the state of the technology in 2006 (HDMI was not very prevalent then), I opted to have a local company source the technology and install it for me.  I also opted for a single remote – the Philips Pronto – a jokingly called ‘programmable’ device.  I remember watching the installation team set up my system.  It took the best part of the day, and for most of that time, one of the install team sat on the floor with a laptop and the Pronto unit, programming and testing to accommodate my flat screen TV, surround sound, Tivo, DVD, etc.  Eventually, they got it all working and – voilà – a single remote controlled everything.  Sort of.  It never did work quite right, but was close enough for my wife and I to live with it.

Along Come the Upgrades…

Live with it, that was, until I needed to upgrade technology.  Add a Blue Ray player, for example, and that’s the end of single remote simplicity!  So, I decided to master programming of the Pronto device.  I was trained in IBM Assembler and Cobol early in my career, but never thought of myself as a programmer.  And programming the Pronto reinforced my “non-programmer” self-perception and my lack of  patience for the arcane or obscure.  I quickly gave up!  It was just too complex and time-consuming.  So I put up with 2 remotes – the Pronto plus Blue Ray player.  Then 3 remotes – the Pronto plus Blue Ray plus Roku.  By Christmas, we had decided to upgrade our flat panel TV with the latest 1080p Plasma.  Goodbye Pronto, hello 6 remotes!

Then Relief!

A little web research convinced me that the Logitech Harmony One was worth a try.  An Amazon ‘one-click’ and 48 hours later, and I was opening the box to my putative problem solver!  What a delight!  Everything from the easy-open, “green” packaging, to the instructions, to the slick look and feel of the device oozed ‘design thinking.’

Programming the device through a web interface (they must have a library of thousand of remotes and their code strings) was as simple as could be.  Once programmed, you have a touch screen device – select the activity you want (watch TV, watch Roku, listen to a CD, watch a DVD, etc.) and the right components are switched on in the right sequence and set to the right inputs and outputs.  If you need to, select the device you want, and the Harmony One remote behaves exactly like that device.  No more batteries – the Harmony One sits in a nice little charging cradle.

And a Reinforcing Customer Experience

Capping my delight, today I got an email from Glenn Rogers, Logitech‘s Director, Customer Experience, inviting me to provide feedback on “How are we doing?”  This was the most thorough and well-designed customer survey I have ever taken!  I’ve found some customer surveys actually frustrate me and lower my opinion of the company seeking input.  This was just the opposite.  They wanted to know about every aspect of how I researched, how I purchased, how I experience opening the package, installing the software, setting up the device, and so on.  I felt like they really cared about me as a customer and what they could do to improve my customer experience.

Not Perfect, But…

I don’t want to pretend that the Logitech Harmony One remote is perfect – there are some minor nits (fed back to them via their survey), but they really are minor.  This is a slick device in every respect and is a great example of how to make ‘programming’ not just user friendly, but actually user seductive!  Congratulations, Logitech!  Want to buy a bunch of old remotes, anyone?

Enhanced by Zemanta

You Know You’re Process Centric When…

As a management consultant, I’ve come to believe over many years of experience that poor process discipline is at the heart of many performance issues.  More to the point, I find an incredible amount of misunderstanding about the nature of process thinking and process management, and outright denial that process management is in any way lacking when it clearly is!

I’ve written before that listening to how clients talk about things can be illuminating, so allow me to share with you some of the things I hear people say about process discipline, what it reveals about their biases and how these misconceptions get in the way of good performance – and, more importantly – get in the way of performance improvement.

A Bias for Continuous Improvement

First, let me state my own biases.  I was trained as an electrical engineer, and started my career in computer hardware design.  A training in engineering disciplines forges a strong and deeply held worldview about the way things work.  On top of this, by the random chance of meeting and being influenced by certain people, I came to be a believer in the Total Quality movement, and in the teachings of Deming, Juran, Shewhart, et al.  For a period in my career I was a judge for a Malcolm Baldrige type quality award for the software industry.  So, I do see the world through a lens of process discipline and continuous improvement.

I later came to work with Professor Tom Davenport, a brilliant colleague who exposed me to the world of business process re-engineering.  This approach has brought enormous benefit to the world, but I do regret the fact that along the way, it somehow trumped the quality movement.  “Don’t improve it – blow it up!” became the mantra.  While in many cases, this was the right thing to do, unfortunately, the “Don’t improve it!” part rose to prominence.

“We Do Have Process Management – Our Process are Documented!”

This is one of the first clues to listen for as an indicator of process mis-perception.  There’s a couple of traps here:

  1. If we’ve documented the process we are using process management discipline.  Wrong!  The fact that it’s documented does not mean that it’s being followed!  That would be akin to claiming, “All our citizens follow the laws of the land because those laws are documented!”
  2. A central tenet of process management discipline is continuous (and, sometimes, discontinuous) process improvement.  Having a process documented does not mean it is continuously improved – and may in fact be an inhibitor to improvement!

“Process Creates Bureaucracy!”

Another clue to process cluelessness!  Yes, if the process management approach is disproportional to the nature of the work being performed (e.g., a highly detailed process model for an activity that is either trivially simple, or is essentially skill-based) then it does become bureaucratic and unhelpful at best, or even dangerous.  (Imagine someone who is not a brain surgeon being handed a process model for brain surgery and being expected to remove a small growth from their spouses brain!)

“We Want Our People to Be Creative, and Process Stifles Innovation!”

A couple of years I posted on the distinctions and interrelationships between Improvement and Innovation.  Process management, intelligently applied, as one of the core management disciplines is an enabler of innovation, not a stifler!  My former colleague Tom Davenport used to say, “Process sets you free!”  And he was right – and he had the right perspective within which to apply process thinking.

“We Are Masters of Escalation!”

Escalation – the final clue!  I find that organizations that don’t have good process management typically have great escalation capability!  They have to – in some respects, great escalation is almost a sign that process management is weak.

How about your organization – are you really good at process management?  Or are you simply good at process documentation and escalation?


Cartoon courtesy of Savage Chickens

Enhanced by Zemanta

Do You Approach Strategy Formulation as an Event or a Continuous Process?

I find that most strategy efforts aren’t very strategic.  Nor do they have much real impact, or lead to significant change.

The Problems with Traditional Strategy Formulation Approaches

I think the supporting evidence for my findings lies in the fact that most companies either:

  1. Don’t undertake strategy formulation initiatives unless they feel they have to (e.g., 5 or more years have passed since they last conducted a strategy session, or the current strategy is clearly not working!)
  2. Do undertake strategy formulation regularly and rigorously (typically annual), with a detailed process spanning many weeks and taking lots of time.  When they are through the effort, everyone breaths a big sigh of relief, and gets back to work – and to executing against the original strategy!

Those in camp 1 above often engage strategy consulting firms.  Nothing inherently wrong in that, except that it can be a high cost route that ends in a good strategy that either:

  • Does not fit the firm’s capabilities particularly well, or…
  • Does not get sufficient engagement with those in the firm who must understand, buy into and execute against the new strategy.

Those in camp 2 above usually have a full time strategy organization – a small, but expensive group of bright folk who need to justify their existence.  Nothing inherently wrong in that, either, except that:

  • The results are often less than inspiring.  They do a good job going through the motions, but the thinking isn’t really very strategic, nor the goals very ambitious.
  • The results typically do not get sufficient engagement with those in the firm who must understand, buy into and execute against the new strategy.

Strategy Formulation as a Continuous Process

I believe much better results can be achieved if strategy formulation becomes:

  1. A continuous process.
  2. A firmwide capability – a strength, even!
  3. A collaborative process.

We are living in unprecedented times.  Uncertainty and change are everywhere.  Market conditions can change overnight.  The globally interconnectedness of everything creates a complex environment that behaves in unpredictable ways.

New Possibilities Enable Continuous Strategy

At the same time complexity has increased and predictability decreased, information technologies create new possibilities for a very different approach to strategy formulation:

  • From an event to a continuous process enabled by the Internet
  • From a “canned” exercise for the select few to a “social” exercise for the many – employees, customers, suppliers, partners
  • From lengthy “big bets” with high uncertainty to rapid “business experiments” with low risk
  • From a dearth of data to help evaluate strategic options to a plethora of powerful business analytics, predictive modeling and simulation tools to help bring strategy formulation and execution together into a rapid learning model

Some of today’s fastest growing companies have figured this out and are quietly, but aggressively honing their continuous strategic capabilities.  Meanwhile, the large majority of companies are stuck in the old paradigm – afraid to open up the strategy process – just when the need for a shot of innovation and fresh thinking are matters of survival!

What do you think?  Are you in a company that is successfully moving to a more continuous approach to strategy?  Should your company be doing more to make strategy continuous?  How can you help achieve this?

Enhanced by Zemanta

Business-IT Alignment – The Relationship Dimension

Much has been written about “Business-IT Alignment” over the years.  Alignment can refer to Strategy – the degree to which IT strategy and business strategy are aligned.  (This, of course, is both ‘old news’ and yet often not the case in practice.  And there’s one school of thought that says there’s no such thing as IT strategy – it’s only business strategy with IT implications.)

Alignment can also refer to Structure – IT capabilities are structured to align with business structures and needs.  But there’s a crucial ‘third leg’ to the business-IT alignment stool, and that is the alignment of relationships that sit between business units and IT capabilities.

The Crucial Relationship Manager Role

Many IT organizations have created a role that bridges the business and IT.  Rarely actually called “Relationship Managers”, this role represents IT to the business and the business to IT. I’ve posted on this role before – see, for example The IT Relationship Manager’s Role in Expanding Business-IT Capability,  and From Supply-Constrained to Value-Constrained IT Business Model, and IT Maturity and the Role of the Relationship Management.  Sometimes called an IT Account Manager, or Business-IT Director, or some-such, the role is primarily responsible for ‘demand shaping‘ – stimulating an appetite for high value demand, and suppressing appetites for low value demand.  Sometimes, people in this Relationship Manager Role are effectively mini-CIO’s or Business Unit CIO’s – leveraging shared IT infrastructure (and often leveraging common applications and enterprise systems) but taking care of business unit-specific IT needs.

Relationship Alignment

There are at least three dimensions along which Relationship Managers can align with their business partners.  The first two dimensions are pretty obvious and generally handled well, but the third dimension is trickier and often not well addressed.  The dimensions are:

  1. Domain Expertise – the Relationship Manager (or whatever title this role operates under) needs to really understand the business domain for which they are responsible.  Be it marketing, supply chain, human resources, and so on, they need to have deep domain knowledge in order to bring real value to their business partners and have the credibility to have impact.
  2. Geography – as the real estate cliché goes, ‘location, location, location!’ so goes Relationship Management.  At its best, the Relationship Manager should be co-located with the senior managers of the business unit with which they are aligned.  At the very least, they need easy access.  The occasional ‘fly in’ to meet with their business partners typically doesn’t do it in terms of creating a productive business-IT partnership.
  3. Maturity – this is the tricky dimension, and one that is typically not well addressed.  Skilled Relationship Managers are a rare resource.  You want your most effective and creative Relationship Managers aligned with those business units and executives with the highest demand maturity – i.e., with the best  capacity to recognize and leverage high value IT-enabled opportunities.  Innovative, ‘change agent’ types of Relationship Managers will quickly become frustrated facing off against executives who are technologically in the dark ages, or who cherish the status quo.  Similarly, progressive, innovative business leaders will become quickly frustrated working with a Relationship Manager who lacks drive, a sense of urgency, the creativity to generate valuable ideas about IT possibilities, and the wherewithal to bring them to fruition.

How Healthy Are Your Business-IT Relationships?

Clearly, the CIO is in many ways the ‘über-Relationship Manager’, setting the tone for demand shaping and the strategic context for IT, and typically ‘owning’ the business-IT relationships with the most senior executive team.  But no CIO has the bandwidth or domain expertise to handle all the relationships at all the management levels needed to surface and steer the best opportunities to create business value from IT.  So, how healthy and productive are your key relationships between business and IT? Do you even know what would be considered ‘key relationships’?  How would you know the degree to which they are fully delivering value against their potential?

Let me know your thoughts and experiences around Relationship Management effectiveness.

Reblog this post [with Zemanta]

Innovation and Web 2.0 – A Compelling Relationship?

I had a very interesting and exciting week!  I was a speaker at an nGenera Senior Executive Summit, which drew about 60 top executives from mostly large companies – CEO’s, CIO’s, CFO’s, HR and shared service heads, and even a couple of Lawyers and Platform/Brand managers.  It was an auspicious group – both in terms of participants and presenters/session leaders, which included Jim Collins, Michael Treacy, Don Tapscott, Tammy Erickson and Dartmouth’s Tuck School Professor, Chris Trimble.

I introduced my ideas about leveraging Web 2.0 (broadly defined) to significantly drive up the value of business innovation – specifically by following the principles and processes of Design Thinking.  I’ve been getting to this point in my last series of posts (Part 1, Part 2 and Part 3.)  In fact, those posts were largely written as I was developing my session materials.

Does ‘Design Thinking’ Have Legs?

Part of my thesis built upon the success of the Design Thinking movement that has gelled over the last 5 years.  I have found the success stories compelling, and the underlying principles resonate with my own experiences and values over the last 30 years in trying to leverage IT for increased innovation.  However, I was troubled by the recognition and acceptability of the term ‘Design Thinking’ – especially in the US.  The text of a 2007 speech by BusinessWeek‘s Bruce Nussbaum given in London tipped me off that there might be a problem here.

Nussbaum’s Banana…

In his 2007 speech to the Royal College of Art, Nussbaum noted:

In the US, CEOs and top managers hate the word “design.” Just believe me. No matter what they tell you, they believe that “design” only has something to do with curtains, wallpaper and maybe their suits. These guys, and they’re still mostly guys, prefer the term “innovation” because it has a masculine, military, engineering, tone to it. Think Six Sigma and you want to salute, right? I’ve tried and tried to explain that design goes way beyond aesthetics. It can have process, metrics all the good hard stuff managers love. But no, I can’t budge this bunch. So I have given up. Innovation, design, technology—I just call it all a banana. Peel that banana back and you find great design. Yummy design. . The kind of design that can change business culture and all of our civil society as well.”

One of the first to make the Web 2.0 connection, Nussbaum went on to say:

Innovation is no longer just about new technology per se. It is about new models of organization. Design is no longer just about form anymore but is a method of thinking that can let you to see around corners. And the high tech breakthroughs that do count today are not about speed and performance but about collaboration, conversation and co-creation. That’s what Web 2.0 is all about.”

I tested the waters of my Summit attendees, first by asking how many in the room had some familiarity with the term ‘Design Thinking’?   Three hands shot up, and a couple sort of hovered around shoulder level (presumably meaning, “I’ve heard of it, but please don’t call on me to talk about it!”).  Of the three hands, two were from companies for whom I had Design Thinking case studies about and who were listed in my very first slide (I had not at this point turned on the projector.)  The third hand was from a senior executive at a major Industrial Supply company that I had not expected to be particularly Design Thinking literate.  So, test 1 indicated that the term is not widely known.  Of course, this does not necessarily mean that Design Thinking is not widely practiced – perhaps all 60 companies in the room do in fact excel at Design Thinking, but refer to what they do as some variation of Nussbaum’s ‘banana’?  However, I truly doubt this.  In fact, the many one-on-one conversations that I had with the executives at this summit during the reception and dinner following my presentation supported my sense that explicit efforts to drive up the value of business innovation are relatively few and far between.

Are Design Thinkers Web 2.0 Enabled?

To the larger part of my thesis, there was little evidence at this Summit that any form of Web 2.0 was being explicitly leverage to support Design Thinking (or innovation, or the banana!)  There were a few ‘accidental experiments’ and emergent social networks – both internal and external – but nothing claimed as part of a deliberate, holistic effort to increase innovation through Web 2.0 technologies.  This for me was the big surprise.  The Senior Vice President of Strategy from one of the Design Thinking literate companies told me at the reception, “When you first connected Design Thinking and Web 2.0 in your presentation, I thought you’d completely lost it!  But as you gave examples, the light bulbs began to turn on – I think you are onto something!”  This was gratifying indeed – well worth the price of admission!

Graphic courtesy of RI Nexus

Reblog this post [with Zemanta]

Design Thinking 2.0: Enabling Innovation with Web 2.0 – Part 3

In the first part of this series I examined the case for, and some of the key aspects of Design Thinking.   In Part 2 of this series, I distinguished between “Core” and “Edge” Capabilities and made the point that Design Thinking typically is heavy on Edge capabilities, whereas most businesses, and certainly, most corporate IT organizations are highly biased towards Core capabilities.  Now let’s drill into the Web 2.0 implications of Design Thinking.

The easiest way to do this for IT people is to think in terms of a process, the steps in that process, and how information technology might enable those steps.

Tim Brown‘s “Three Spaces of Innovation”

A good place to explore the Design Thinking process is in IDEO CEO, Tim Brown’s excellent HBR article from June 2008.  In that paper, Tim presents a model of how Design Thinking happens.  Tim’s model describes “Three Spaces of Innovation” – Inspiration, Ideation and Implementation.  What I like about this picture is that it’s not a simple linear process – it is somewhat chaotic, full of little feedback loops and more concerned with how things connect and flow that with a rigid process.

How Web 2.0 Might Enable Innovation Activities

In the figure below I have added simplistic examples of how different types of Web 2.0 capabilities might play into the major activities contained in Tim Brown’s model.  Consider this a simple illustration – there are a zillion possible variations on this theme!

Move Edge Activities to the Cloud

I believe that Cloud Computing in its various forms presents a relatively attractive way to quickly develop Edge capabilities.  Given that Design Thinking requires that we become more comfortable with experimentation, at the very least we should be experimenting with the Cloud, and Edge capabilities present an ideal case for cloud experiments.  We can keep them relatively isolated, implement them very quickly with little to no capital outlay, and everything we do in the cloud is inherently collaborative (e.g., think Google Docs, Google Wave, Mindmeister, etc.) just as just about everything we need to be doing around Design Thinking is inherently collaborative.

A More Traditional Process View

For those that prefer to take a more traditional process view, Wikipedia suggests a simple 7-Step Design Thinking process, rendered as a loop below.  Note, please don’t take this process too literally.  Design Thinking is more about ‘iterate and converge’ than the more typical IT process.  These steps are rarely going to be linear and sequential.

Collaborative Intents for Each Step

A couple of years ago, working on a multi-company research project with my colleague Tammy Erickson at nGenera, we identified 10 distinct types of ‘Collaborative Intents’ to be considered when planning any type of collaboration initiative.  For each collaborative intent, we can be quite explicit about the business outcomes to be achieved.  So, for example, in the Design Thinking step “Define” we are interested in ‘connecting ideas’ that might not typically be connected in order to amplify knowledge and identify innovation opportunities.

Web 2.0 Technologies for Each Step

We can map the types of Collaborative Intent to each step in the Design Thinking process.  In the table above, as an illustration, for each type of Collaborative Intent, I have identified the types of technology that might be useful to enable that intent, and provided some examples of actual technologies in each space.  Please note, mention or lack thereof for any specific technology does not imply any endorsement (or lack thereof!)

Does this make sense to you?  Do you have experience in applying Web 2.0 to Design Thinking?  Please weigh in – let’s generate some dialog on these ideas and their reality in practice.

Image courtesy of Red Jotter

Reblog this post [with Zemanta]