Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Process for Product Problem Discovery Through Scenario Challenges

IP.com Disclosure Number: IPCOM000124923D
Original Publication Date: 2005-May-13
Included in the Prior Art Database: 2005-May-13
Document File: 2 page(s) / 158K

Publishing Venue



In large organizations developing multiple products that are meant to work together and integrate in meaningful ways, it is frequently difficult to have people who work on any one component have a good feel for how it will be used in an integrated whole. The typical solution is written documents about defined integration and specifications. The problem is that these documents are frequently more "theory" than practice and without the context of having attempted the specified integration it is difficult to assess whether any proposed specification is sufficient or practical. These documents are frequently reviewed by architecture boards etc... but the design ethic behind them and their goals are not easily pushed down to product developers who make many day-to-day compromises and triage decisions. This results in "misses" in integration or impractical integration that "looked good on paper" but didn't achieve the goal they were proposed for. There are many documented processes for especially "Software Engineering" that purport to solve this problem, but most of them fail due to assumptions about uniformity of process over large organizations, inability to scale to large decoupled efforts, or over-dependance on "everyone being really careful and following the process."

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Process for Product Problem Discovery Through Scenario Challenges

Main Idea

Disclosed is a process to engage a large organization in a learning experience that puts the product developers who create the products to be integrated into the position of the customer of those products and the position of the integrators of those products. Even though not everyone in the large organization can participate in the actual learning experiment, they can be engaged in the presentation and report of experiences and since each group will on average contribute a person or so to the learning experiment, they will benefit from that person's participation by embedding that knowledge in many teams.

The structure of the learning experiment is a competition to accomplish a "real world" integration effort using the diverse products produced by the company. The challenge has several teams and a time limit, the teams act as competing service companies attempting to solve a business problem for a customer.

The scenario for the challenge should be both realistic and achievable for the timeframe and should incorporate as much of the real context of such efforts as possible. As shown in figure 1, the organizers engage a group of scenario experts to ensure this is true. The scenario should also have some entertainment value or "humor" embedded in it, this isn't a trivial issue, it helps a great deal to draw observers and participants into the scenario and helps to encourage creativity and engagement by making the challenge a less formal and more "creative" in tone.