Information Technology Reference
In-Depth Information
taken to the extreme. It is apparent that having no structure means the absence of a
sound decision-making process. Current practice indicates that a design project is far
from a rational process of simply identifying day-to-day activities and then assigning
the expertise required to handle them. Rather, the truly important design decisions
are more likely to be subjective decisions made based on judgments, incomplete
information, or personally biased values even though we strive to minimize these
gaps in voice of the customer (VOC) and technology road mapping. In milestones,
the final say over decisions in a flat design team remains with the champions or TG
approvers. It must not happen at random but rather in organized ways.
Our recommendation is twofold. First, a deployment company should adopt a
common design process that is customized with their design needs with flexibility to
adapt the DFSS process to obtain design consistency and to assure success. Second,
it should choose flatter, looser design team structures that empower team members
to assert their own expertise when needed. This practice is optimum in companies
servicing advanced development work in high-technology domains.
A cross-functional synergistic design team is one of the ultimate objectives of
any deployment effort. The Belt needs to be aware of the fact that full participation
in design is not guaranteed simply because members are assigned into a team. The
structural barriers and interests of others in the team are likely to be far too formidable
as the team travels down the ICOV DFSS process.
The success of software development activities depends on the performance of this
team that is fully integrated with representation from internal and external (suppliers
and customers) members. Special efforts may be necessary to create a multifunctional
DFSS team that collaborates to achieve a shared project vision. Roles, responsibilities,
membership, and resources are best defined up front, collaboratively, by the teams.
Once the team is established, however, it is just as important to maintain the team
to improve continuously its performance. This first step, therefore, is an ongoing
effort throughout the software DFSS ICOV cycle of planning, formulation, and
production.
The primary challenge for a design organization is to learn and to improve faster
than the competitor. Lagging competitors must go faster to catch up. Leading com-
petitors must go faster to stay in front. A software DFSS team should learn rapidly
not only about what needs to be done but about how to do it—how to implement
pervasively the DFSS process.
Learning without application is really just gathering information, not learning.
No company becomes premier by simply knowing what is required but rather by
practicing, by training day in and day out, and by using the best contemporary DFSS
methods. The team needs to monitor competitive performance using benchmarking
software and processes to help guide directions of change and employ lessons learned
to help identify areas for their improvement. In addition, they will benefit from
deploying program and risk-management practices throughout the project life cycle
(Figure 11.1). This activity is a key to achieving a winning rate of improvement by
avoiding the elimination of risks. The team is advised to practice continuously design
principles and systems thinking (i.e., thinking in terms of the total software profound
knowledge).
Search WWH ::
Custom Search