launch
Mark A. Hart
Mark A. Hart, NPDP, Visions Launch Editor, Founder of OpLaunch
( mark_hart@oplaunch.com)
What do you do when your launch date is approaching and there are unexpected obstacles? What if you have options to enlist more
resources? This article explores the implications of adding resources and minimizing risks.
Alistair Cockburn states, “Software development is a series
of goal-directed, resource-limited, cooperative games of
invention and communication. The primary goal of each
game is the production and deployment of a software system;
the residue of the game is a
set of markers to assist the
players of the next game.”1
Cockburn (pronounced
Coburn) describes himself
as “project witchdoctor
and IT strategist.” He is
also a coauthor of the Agile
Development Manifesto.2
Cockburn’s insight ap-
plies to new product devel-
opment (NPD). It provides
an approach to develop products that are validated by abundant
sales at launch. It provides guidance on how to select the appropriate development resources. It embraces NPD concepts such
as Product Lifecycle Management and system-level training to
improve contributors’ skills for the next NPD effort. Brooks’ Law
provides another important insight.
“According to...Abdel-Hamid
and Madnick... the later in the
project that the additional resources are added, the higher
the potential for problems.”
Summary of Brooks’ Law
Frederick P. Brooks, Jr. is a software engineer, computer
scientist, and the author of the highly influential book, The
Mythical Man-Month, which was first published in 1975.3 An
oversimplified explanation of Brooks’ Law is “adding manpower
to a late software project makes it later.” Brooks’ Law provides
an appropriate warning for managers of software projects that
are behind schedule.
Brooks cites learning curve factors and communication factors
as the primary reasons for the additional strain on software projects
that are likely to cause them to fall further behind schedule. For
example, training engineers new to the project diverts resources
and diminishes the productivity of the established staff. Code
produced by engineers new to the project is more likely to require
rework because these engineers make errors consistent with their
neophyte status. Communication overhead increases as more
contributors are added to the project. According to the model developed by Abdel-Hamid and Madnick in the 1991 book Software
Project Dynamics: An Integrated Approach that is described by
Brooks, the later in the project that the additional resources are
added, the higher the potential for problems. 4
Sometimes, Brooks’ Law is cited inappropriately as an argument
for not adding resources to an understaffed project. In addition,
Brooks’ Law does not apply directly to contributors that perform
tasks that can be easily partitioned and isolated—those tasks
that do not have a significant learning curve and require minimal
communication.
Brooks’ Law and new product development
In NPD, an intrinsic aspect of preparing for product launch is
that resources are added late in development. Therefore, the impact
of Brooks’ Law may be amplified while preparing for launch.
Problems that can occur due to the late addition of resources or
limited communication include the following examples:
• Because of terminology differences, communication between
disparate disciplines (such as engineering and public relations) can be difficult.
• Because contributors are likely to be geographically dispersed,
there will be multiple channels of communication.
• Since team members do often not have the same managers,
there are additional learning curve and communication factors.
• Since the preparation for a successful new product launch
requires contributions from many disciplines, there are
additional learning curve factors—outside of traditional
production—required to harmonize launch goals. Common
conflicts include the sales organization requesting additional
product features while engineering considers eliminating
planned features in order to meet the launch deadlines.
Brooks’ Law impacts launch strategy decisions. For a given
obstacle, should resources be added? Or should the team make
other adjustments to overcome the problem? Using a concept from
martial arts can be helpful as a launch strategy is developed.
Shu, Ha, and Ri levels of mastery
Shuhari is a martial arts concept that Cockburn and others have
popularized to provide software development insights. When
differences in the level of mastery among team members are
considered, misunderstandings are minimized. Shuhari concepts
can be used in NPD to reveal insights about learning curves and
to facilitate communication. This applies to intradisciplinary and
interdisciplinary situations. It applies to both individual contributors and their managers, as seen in Exhibit 1.
From a discipline specific perspective, a Shu-level contributor
should be encouraged to follow templates and adopt a predefined