Sato Partners Blog

This is first in a series of blogs on more successful alternatives to formalizing experience design, innovation and product development:
- processes
- standards
- metrics
- organizations

Situation
You’ve developed a standardized innovation, experience design or development process; yet they did not come. Policies your company implemented to enforce the use of the standardized processes have met with some success; though after trying it, practitioners experience it as “more overhead” than as an aid, so they try to find ways around it.

Next you turn your ethnography expertise internally to confirm the practitioner’s claims and find there is a mis-match between how they need to do things and your standardized process. At this point you realize the issue is an unsuitable design, not an organization transition issue. To further compound your challenge, you feel your team will be spending too much time revising and updating details of the process with every shift of the organization. So, what now?

One Size Fits All, Except…
Most often managers develop processes much like PERT (Project Evaluation and Review Technique) charts, around a sequence of activities to be carried out by designated individuals supported by certain frameworks, methods and tools. The weakness of this approach is the inflexibility of sequence of activities and who will carries them out. The process becomes outdated with every organization change or every alteration in your value delivery chain. So mangers spend inodrdinate time revising process standards or creating exceptions. Furthermore, the sequence of activities depends on the product or service being conceived, developed and produced; one group may outsource some of its development while another does not, requiring a different sequence of activities and roles. But in accomdating the variety of processes, the lowest common denominator brings you back to the obvious set of 3-7 process boxes!

Decision Flow, not Activity Flow
An alternative is to use a logical sequence of questions that need to be answered as a backbone for “standardizing a process”. I first learned about this approach from work MIT was doing to study how entities coordinate with one another. The researchers needed a way to compare apples to apples. For example, how does a school of fish coordinate on which direction to turn? How about a formation of fighter jets? This is an example of different approaches that answer the same question to produce the same results – turning in coordination. Often, to be successful, the questions need to be answered in a similar logical sequence.

Once we have the “question flow” established then we can answer each question through a combination of people, processes, roles, technologies and processes. For example, in customer-centered design the first logical question that needs to be answered is “who is your customer?” This question is followed by “what do they need (or desire)?”, then “why?” and so on. The second question “what do they need?” cannot accurately be answered without having an answer or speculation about the first question “who is your customer?” Note that in technology-driven design the sequence of questions is different – this reveals the competitive advantage that a customer-centered approach can provide a company yet also shows why customer-centered design is a bigger organization change challenge than most people realize). Fundamentally, your challenge is similar to the one the MIT researchers have – how can you successful support answering the same sequence of questions through different means?

Applying This Approach

• First, list in sequences, questions that need to be answered to conceive a concept, refine it or produce it with metrics for success (gating criteria) and gain alignment from stakeholders on it. There may be more than one sequence of questions that your organization uses to deliver concepts to market. Cocreating this sequence is a great way to get stakeholders on board early and often.
• Second, for each question, cite what expertises (design, marketing, R&D, production, etc.) are needed to best answer each question.
• Third, for each question, provide the best frameworks, methods or tools to most effectively answer the question.
• Fourth, create work session for the team of experts to figure out for themselves, then document and align on
  . the sequence of questions
  . roles for each question– who leads (typically whomever is accountable for the decision or their delegate), who supports (typically, experts)
  . measures to be used to determine the question has been successfully answered
  (the answer may be a hypothesis that will be validated later)
  . frameworks, methods and tools to support experts in succesfully answering the question
  This works session should be available for the team to make revisions if or when any of the items change
  and to reaffirm their agreement on the approach.
• Fifth, make the teams’ results available to other teams as templates – you’ll see patterns emerge over time.

By following this approach you will have provided teams the flexibly they need and gotten yourself out of the loop of revising multiple process standards. Instead, your efforts will be focused on heling teams define their process, finding and integrating the best frameworks, tools and methods available. In addition, it is scalable – in that it ought to work no matter the size of your organization.

Theory in Practice
We’ve used this approach to help the Chief Technology Office to standardize processes within a large multi-national IT hardware, software and services company. It was also used with success to help a division to integrate experience design and designers into a new product development approach; to figure out the roles and responsibilities, tools, methods and framewoks they would use going forward.

I’ve been told by consultants that I’m “giving away the store” sharing this kind of insight. Actually the framework and approach (the “theory”) is simple; though as you may discover implementing it for a given situation is the challenge. Experience helps with this.

Next time, I’ll blog on an alternative to standards that actually creates pull from practitioners.