© Copyright 2004 a.r.herrington
Innovation can be seen as a form of creative play by interested and excited people. In this article I make the argument that to induce innovation in a business in an efficient, focused manner a well defined and constrained 'sandbox' for innovative 'play' should be provided because justified, explained, rational limitations positively and actively stimulate innovation in motivated people. Naturally these limitations can be used to guide innovation toward the business's needs. The article - which is focused around new product development - rotates around the following concept:
"Necessity is the mother of invention; communication distils a Necessity Statement from the business's knowledge; effective communication techniques establish the same Necessity in all the minds in the team; The team's shared understanding of the Necessity then provides the basis for innovation that is focused upon the business's requirements, with all members of the team positioned to contribute pertinent knowledge."
I believe there are two types of creativity.
I think of the first as: "Open Space"- artistic; unconstrained; purely imagination and excitement driven; often solitary. Such creativity can be exemplified by the work of Einstein or Picasso. This kind of creativity is relevant to business infrequently but usually in a strikingly dramatic way - like Tim Berners-Lee's concept for the Internet.
The second type of creativity I think of as: "Necessity driven and Necessity enlivened" - flowing from the well known statement "necessity is the mother of invention". This is by far the most common type of creativity and is what is needed in business on a frequent, ongoing basis. It can be exemplified by teams and individuals meeting the real, year-in year-out, day-to-day needs for large and small innovations to continually deliver a products or services that are successful in the market, by fitting them within a business's constraints and the constraints of available knowledge or of new knowledge that can be generated within a short time by the business, perhaps 3-9 months.
This type of focused creativity can be promoted by unambiguously and completely defining 'the necessity' and then effectively communicating it to the people responsible for meeting its requirements. Effective bi-directional communication is needed because of the need for complete dialogue between diverse areas of knowledge contained in the minds of the two sets of people involved - the business's leaders and the product development team. The knowledge involved is:
This article discusses ways to ensure that 'the necessity' is first accurately and completely defined, and then delivered via effective communication by the team developing 'the necessity' to the team responsible for innovation.
Why should 'the necessity' be accurately and completely defined ? The purpose of accurate and complete definition is to ensure that the cost (time, dollars, risk exposure, opportunity) of developing solutions matching the necessity is minimized. Note that 'accurate and complete' implies that the 'necessity' is only precisely defined where precision is driven by justified customer requirements; otherwise the 'necessity' should include as much latitude as is consistent with customer needs, since this maximizes the 'sandboxes' envelope. My experience has been that, seemingly paradoxically, a tightly constrained 'necessity' can be more strongly creativity stimulating than one that is open ended and expansive - perhaps because the rewards of fitting within tight constraints seem more hard-won and hence more exciting and valuable to the spirit of the people involved. Perhaps this is a partial explanation for the success of start-up companies in creating new market opportunities when competing against the seemingly daunting advantages of large companies.
Necessity...
"You can't be creative just by trying to be creative. You need a deep understanding of the problems you are trying to solve." -- Steve McCallion, Director of Research and Design Planning at ZIBA
Design.
In most new product situations innovation is essential - simply because the easy, non-innovative products are already in the market. If 'it' (the product) seems easy 'it' is either not worth doing or there is a grave misunderstanding ! So the Necessity Statement must be designed and expressed as a message to stimulate focused excitement and challenge to the people who are to deliver the new, necessarily innovative, product.
The target audience of the Necessity Statement is the group of people charged with architecting the product. These are the people with sufficient knowledge of the available technology to be able to translate the necessity into an initial view of candidate solutions that meet the requirements of the Necessity Statement. These people must also be able to identify key technology-based reasons why the Necessity Statement cannot be met, should this prove to be the case, thereby starting a new cycle of Necessity Statement development.
The purpose of the Necessity Statement is to provide a carefully bounded 'sandbox' within which the product architects must work. The key to a successful Necessity statement is for it to give the product architects maximum freedom within which to work whilst describing to them only the essential limitations - carefully constrained freedom leads to focused invention and innovation. The Necessity Statement thoroughly defines the space within which the product has to be conceived and delivered.
The objective in writing the Necessity Statement is the production of a message that contains two major, linked, sets of information:
1) The customers needs for the product, in the customers terms (with a complete absence of information describing how the product is to achieve this).
2) The constraints imposed by the business - usually resource availability and schedule.
The key linkage between the two statements is the combination of the business's "Practical Vision Statement" and the "Business Plan objectives". As discussed elsewhere this linkage should already be well established in the minds of the architects because the business should be constantly refreshing all employees knowledge of the business's objectives.
The Necessity Statement should include (and be strictly limited to) the following:
General statement of customer needs and deliverables - from the customers viewpoint
Application data - knowledge of how the customer is expected to use the product
Performance statements - from the customers viewpoint
Competitive data - from the customers viewpoint
Quality needs - from the customers viewpoint
Cost objectives - driven by the business's margin objectives, linked to a selling price objective that is acceptable to the customer
resource availability - driven by the business
Risk acceptability statement - driven by the business
Schedule objectives - driven by the business
Statement of anticipated new, but as yet unavailable, knowledge that must be taken into account as the project proceeds
'From the customers viewpoint' means the value and utility delivered by the product or service to the customer as described by the customer in the customers language.
Before the Necessity Statement is written two key items should already be in place - the business's Practical Vision Statement and the Business Plan Objectives. Both are defined at the end of the article.
The Necessity Statement should be written by small team that includes representation of all the business's knowledge, with general context setting input from the business's leader figure or group - those individuals responsible for writing the business's Practical Vision Statement. Participants should be from every functional area within the business. The group could beneficially consult key individuals from the group responsible for architecting products, who should play an only advisory, passive role. The eventual product architects should not be involved, to prevent biases from entering the Necessity Statement. Taking this approach goes some way to ensuring that future business's needs are met whilst diminishing the impacts of irrelevant organizational history.
Classically it has been the case that knowledge of the customers needs has been the origin of similar documents to Necessity Statements (e.g. Requirement Specifications), as reflected in the statement "We are a market driven company", often limited to meaning "We are only a market driven company". Since Sales and Marketing departments are seen to 'own' customer knowledge they are often responsible for creating "Requirement Specifications". There is a fundamental problem with this approach, as illustrated in the following example:
Intel customers did not ask for the microprocessor - they asked for multiple different fixed-function calculating devices. Somebody - probably an engineer - in Intel saw that the best solution for Intel was a general purpose processor that could be programmed to deliver multiple different calculator functions for multiple customers with only the single design investment needed for one calculator - a technology opportunity driven solution. Thus Intel could meet make many volume deliveries quickly to many customers with a single design team - design teams (then as now) being a critical resource limitation of Intel.
A key aspect of this example is that Intel's customers had no understanding of Intel's technology, design methodologies or the directions that these were going to take in the future - hence they could not ask for a processor. This situation, in which key technology knowledge is not known to customers, is very common in high tech business's.
A wider justification for this position is that customers rarely ask specifically for the solutions that they eventually enthusiastically buy. The best suppliers recognize that customers can be provided with a solution that economically and functionally suits the supplier - because customers don't care how a solution is realized. Usually Sales and Marketing departments reflect accurately only what the customers are currently asking for - something that is inevitably limited to what current customers currently understand - whilst having only a limited understanding of future technology opportunities and future customer needs. This reinforces the argument that Sales and Marketing Groups should not be solely responsible for Necessity Statements, otherwise they will only reflect those groups short term priorities.
This further justifies a critical aspect of the Necessity Statement - that it must include only the utility the customer currently expects from the product (plus such speculative views of predicted changes in the customers utility that the business wants to risk as means of gaining competitive advantage) and that it should include nothing to do with how the product is implemented - further reinforcing the view that the Necessity Statement must be written by a group that is able to reflect all the business's knowledge using only the language of the customer.
Writing the Necessity Statement is a communication task for a "Led Team". Writing the statement has three functions:
1. Developing a description of what the business needs.
2. Obtaining, via "Vital Discussions:, the agreement, and committed participation of those business leaders responsible for all the business's
knowledge.
3. Communicating to all parts of the business that a key step in fulfilling the Business Vision and Business Objectives is starting, and that a key commitment of resources is underway.
An example outline Necessity Statement is: "The product should deliver all the functionality of our existing product (minus the following features), plus the additional functionality of
competitors one and two (minus the following features), plus have the following new features that we believe will gives us proprietary market advantages because.....Product life must be .. using the
following operating tests. Product software should be conform to the proposed new user interface style under exploration and capable of networking with ...The product cost must be minimized and be
less than x in volumes of bb, with a cumulative volume over life of cc using the new costing model, it is available for production start y months for manufacture preferably using only location dd
capital equipment plus no more than $k new investment or be capable of outsourcing under the following circumstances..., with only n engineers participating in the design process and that it is
painted customer y's shade of red. It must fit within a space no larger than zz, be capable of the following steps with the following precision using less than mm amount of energy. The business
justification for these statements is as follows:
Expected competitive developments, well informed customer Y's need are acceptable to all customers, customers are becoming more concerned about energy costs..."
In summary the Necessity Statement has the objective of describing what is needed without in any way defining what the end solutions implementations is. It describes with some precision the business's needs of the product and incorporates customer views of what is needed. It is written with the full participation of the business's knowledge holders whilst not specifying in any way how the product should be implemented.
Let us now assume that a Necessity Statement exists. This statement must now be communicated to those responsible for the architecture of the product, and the accuracy and completeness of the communication verified. This is a key communication step and the business should be prepared to make a significant investment in ensuring that this step is performed effectively. The objective is a complete transfer of knowledge, the transfer of which verified by the group that created the Necessity Statement. The Necessity Statement should be converted to an exciting and very complete presentation; the presentation meeting should allow essentially unlimited discussion and it should be possible for the entire architecting group to completely analyze the material and recycle the initial presentation meeting with the generators of the Necessity Statement until the architects feel they completely understand the statement and the business justifications behind it.
Commonly the best architectural solution is multi-disciplinary. The evolution of such a solution usually requires trade-off across the boundaries of all the technologies involved. These trade-off cannot occur if the people responsible for arriving at a solution do not fully understand the same 'necessity'. Moreover these trade-offs can resonate up and down the chain of knowledge's and technologies that comprise the product, so that a change made at one end of the knowledge chain can impact the other end of the chain. This type of situation requires long hours of conversation in which everybody involved in the products architecture continually explains the opportunities and limitations of the knowledge and technologies for which they are responsible in front of the entire architecting team. This highly intense communication occurs around the focus of the Necessity Statement and will often lead to the need to recycle the presentation of the Necessity Statement. It is during the recycling process that much bi-directional communication will occur. In particular technology driven market opportunities will be recognized by the two teams. These opportunities can be extremely valuable competitively because they can often be free of cost and risk.
This article has described an approach to developing the key statement that leads to the architecture of a new product. The approach seeks to maximize creative freedom within business defined limitations in order to stimulate an efficient search for an innovative architectural solution. Great emphasis is placed on creating a complete statement, communicating that statement, verifying that the statement has been completely communicated and then providing circumstances in which the architectural team can work to obtain a cross disciplinary understanding of what is needed prior to actually defining a set of initial architectural solutions. By providing a well defined, relevant and justified 'sandbox' there is created the hope that the Business Vision can be used as an effective stimulant to lead to the creation of relevant, focused innovation.
For teams to be successful they:
(a) need to understand what they have to achieve for the business - the teams objectives
and
(b) have to be able to successfully function as a group of people working synergistically.
The teams objectives for the business are described by a combination of "The Practical Business Vision", "The Business Plan", "The Necessity Statement", and "The Project Schedule". The latter is worked out by consultation with the team members at the projects start-up.
To make the team work successfully I believe in a concept I call "The Led Team".
Leadership:
Teams need leaders. To make the team work successfully I have successfully used an approach I think of as "The Led Team", which is based on using a Team Leader-Facilitator whose primary responsibility is facilitating the successful functioning of the team as a team - not the success of the project or the delivery of the product. Teams are taken gently, but firmly in the direction of the projects objectives. Maintaining focus on these objectives - particularly the schedule - is the Team leader-Facilitator's main discipline on the team. The Team Leader-Facilitators creates the communication circumstances - as described earlier in the article - whereby the team works as a focused, driven manner. The responsibility for achievement of objectives always stays with the team's members; team members must at all times feel this responsibility otherwise they will relax and simply 'follow the leader', thereby transforming the team into a group of isolated, controlled individuals - as in the old economy ! The Team Leader-Facilitator creates the circumstances for the Vital Discussions that create synergy amongst team members - the circumstances by which the team completes the project successfully.
The Team Leader-Facilitator has a delicate task in leading Vital Discussions. He has to get things done, decisions made, risks evaluated, schedules met, performance objectives reached - by the team. He must ensure that each of the team members maintain their focus on the objectives. He must continually ensure that team members retain ownership, authority and responsibility for their always unique 'knowledge-gives-responsibility' role in the team. If the project start-up was properly managed by the business's leaders team members will have a very good idea of the objectives and limitations because they will have participated in setting these objectives and agreed that their responsibilities in achieving them can reasonably be expected to be achievable, within an agreed and carefully discussed framework for acceptance of risks. They will also accept the role of the Team Leader-Facilitator in sewing together the fabric of individual team members deliverables to build the whole product.
Reporting:
A critical part of the Team Leader-Facilitators role in reporting is maintaining an ongoing judgment of the likelihood that the project will achieve its objectives. This is developed during regular meetings with the team to gather a team-agreed, team-shared, team-committed view of the status, the schedule and the probability of reaching objectives.
The Project Manager's role is confined to the capture and management of information describing the schedule status of the team's project. The Project Manager is responsible for developing and maintaining the schedule with the team members and with the Team Leader-Facilitator.
The Team Leader-Facilitator and the Project Manager jointly create a vital piece of ongoing business knowledge - the status of the project, reported to the business leaders as schedule status, achievement of objectives and probability of meeting the projects critical objectives.
(In this model the Project Managers responsibility is to bring generic skill and knowledge to setting up and maintaining schedules, using data provided by team members and a process developed by the business. The Project Managers responsibility is to the Project Office. The Project Office manages information describing utilization and co-ordination of the business's resources.)
The Team Leader-Facilitator delivers status reports to the business's leaders. For some team members this reporting responsibility confers on the Team Leader-Facilitator an important halo-effect reflecting the business's dependence upon them; this halo effect significantly strengthens the Team Leader-Facilitator in his critical role.
© Copyright 1999-2004 Andrew Herrington Pateo Consulting