Information Technology Reference
In-Depth Information
have an effect on the core of the development process. In addition to coordination,
the primary intent of an organizing design structure is to control the decision-making
process. It is logical then to conclude that we must consider the design implications
of the types of organizing structures in which we deploy the ICOV process to man-
age design practice. When flat organizing structures are adopted with design teams,
members must negotiate design decisions among themselves because a top-down
approach to decision making may not be available. Members of a software design
team negotiating decisions with one another during design projects is an obvious
practice. A common assumption seems to be that these decision-making negotiations
proceed in a reasonable manner—this being a basic premise of concurrent software
design (what do you mean? Concurrent design means that more than one member
of the design team is working on a different part of the design). Patterns and out-
comes of decision making are best explained as a dynamic behavior of the teams.
Even if two teams develop similar software using the same process, members of the
otherwise comparable design teams may have varying levels of influence as deci-
sions are made. The rank differences among members of a design team can play a
substantial role in team dynamics from the perspective of day-to-day decisions. It
is the responsibility of the Black Belt to balance such dynamics in his or her team.
As team leaders, Black Belts and Master Black Belts need to understand that de-
sign teams must make decisions, and invariably, some set of values must drive those
decisions.
Decision making and team structure in companies that use hierarchical structures
follow known patterns. Although day-to-day decision making is subject to team
dynamics, the milestone decisions are not. In the latter, decisions are made based
upon the formal rank. That is, decisions made by higher ranking individuals override
those made by lower ranking individuals. Such an authoritative decision-making
pattern makes sense as long as the ranks cope with expertise and appreciation to
company goals. This pattern also will ensure that those higher in rank can coordinate
and align the actions of others with the goals of the company. We adopted this model
for DFSS deployment in Chapter 9. Despite these clear benefits, several factors make
this traditional form of hierarchical structure less attractive, particularly in the context
of the design team. For example, risk caused by increased technological complexity
of the software being designed, market volatility, and others make it difficult to
create a decision-making structure for day-to-day design activities. To address this
problem, we suggest a flatter, looser structure that empowers team members, Black
Belts, and Master Black Belts to assert their own expertise when needed on day-to-
day activities. In our view, an ideal design team should consist of team members who
represent every phase of a software life cycle. This concurrent structure combined
with the road map will assure company consistency (i.e., minimal design process
variation and successful DFSS deployment). This approach allows information to
flow freely across the bounds of time and distance, in particular, for geographically
challenged companies. It also ensures that representatives of later stages of the life
cycle have a similar influence in making design decisions as do those representatives
of earlier stages (e.g., maintenance, vendors, aftermarket, etc.). Although obvious
benefits such as these can result from a flattened structure, it does not need to be
Search WWH ::
Custom Search