(BUS 13) Notes to Accompany Lecture, May 21, 1998
by Kenneth L. Hess
It is just as important to have an agreed upon method
for building a product as it is to select the correct product
to build. We will discuss three aspects of the development process:
Project Time Horizon
Every project has a time horizon by which time it "must
be done." Exceeding this time horizon inevitably results
in a costly penalty, for "time is money."
In a high technology business, it is generally difficult
to define a product more than 12 to 18 months into the future,
if that far. Beyond a 12 to 18 month time horizon, unpredictable
market and "environmental" changes will begin to accumulate,
changing the requirements for a successful product at the very
time the team is building it.
The table below describes some of the many factors
that might constrain the time horizon for a project:
Events or Requirements Impacting Project Time Horizon | Typical Frequency or Duration | Examples | Cost of Being Late |
Market Factors: | |||
Sales seasonality | Once a year |
| May miss the bulk of sales for the product release |
Competitive updates | Every 6 to 18 months |
| Risk unfavorable product comparisons with "new & improved" competitor |
Comparative product reviews | Once a year |
| Harder to get publicity for the product |
"Environmental" Factors: | |||
Release of an industry "standard" | Varies |
| . |
For software: Average frequency of platform changes OR updates of the operating system that are backward incompatible (new software won't run on old op sys) | 4 to 6 years |
| Lose market leading position to a faster competitor (WordPerfect was slow to move to Windows and Word for Windows killed them) |
Revolution in distribution media | Several years |
| New distribution media often enable entirely new classes of competitor who can take your market position |
Revolution in distribution channel | Varies |
| A new channel may be more or less difficult to enter, depending on the circumstances |
Requirements for regulatory approval | Can take many years |
| . |
Financial Factors: | |||
Life cycle of an existing product | 6 to 18 months |
| Stock price could take a beating or company survival may be threatened |
Duration of a financing round | 6 to 18 months |
| Additional financing can be very expensive or it might not be available at all |
Investment horizon of VCs | Several years | . | Company might enter what's known as "the living dead" where its hard to get additional funding and difficult to recruit talented employees |
If time is so important, then why are many projects late? In
my experience, there are four primary reasons:
To avoid these problems requires both experience and discipline
on the part of management.
Development Models
There are a variety of models for organizing a product
development effort ("who does what, when"). The traditional
product development model is the sequential model (also
know as the linear model, the "relay race" model, or
the "throw the blueprints over the wall" model). In
this model, each development stage is completed in isolation by
the responsible group in the company. When one group completes
a stage of the process, they pass the project on to the next group
in line. This model tends to be slow and unresponsive to changes
in market conditions. It is rarely successful in a high-tech
business with one exception (see below).
Time | Development Stage | Responsibility |
Concept development | Marketing | |
Feasibility testing | R&D Engineering | |
Product design | R&D Engineering | |
Process design | R&D Engineering | |
Pilot production | Production Engineering | |
Final production | Production Engineering | |
Product introduction | Marketing |
The parallel development model organizes technical and
marketing activities in a side-by-side scheme, with both groups
interacting as a team throughout the course of the project.
Time | Technical/Production Activities | Marketing Activities |
Preliminary technical assessment | Preliminary market assessment | |
Concept generation | Market testing, studies | |
Engineering design and prototypes | Develop marketing plan | |
In-house prototype testing | Test prototype with customers | |
Finalize design, trial production | Finalize marketing plan, test market | |
Full production | Product introduction |
The iterative development model (also known as the rugby
model or the heavy overlap model) uses a team concept, like the
parallel model. In this model the technical members of the team
might be doing preliminary design work while the marketing members
are still doing concept development. As the concept development
is finalized, the product design iterates, reflecting the latest
marketing input. Iteration of a design is quite natural (things
don't always work out the way a designer intended and must be redone OR additional research changes the marketing input which in turn requires a design change). So, this model
is a good fit with the way the design process actually works.
The overlapping of activities and iteration of the work continues
until the product ships. This model is known for its speed and
flexibility in the face of market changes. However, the team must not attempt too much iteration or the process can become counterproductive, slowing the project -- this model requires walking a fine line.
Time | |||||||
Most successful high-tech companies use some variation of the
parallel or the iterative development model. Note that a talented
engineering professional with good marketing skills can sometimes
"do it all," performing or supervising the tasks normally
performed by different individuals in marketing and engineering.
Although the diagram for such an organization might look like
the sequential model, the individual is probably operating with
an iterative process -- changing from one role to another in his
mind's eye.
Key Project Documents and Milestones
A well-disciplined development process requires written
documentation to enable effective communications among the team.
Even if the team is small (perhaps just one person), good documentation
insures that all the pieces fit together as intended. To build
something, you simply must have a plan.
Imagine trying to establish the schedule for a project
that has no written specification. Each team member might be
imagining a different product when looking at the schedule. Who
knows what actually might be produced! As obvious as this seems,
there is not a day that goes by without a project team somewhere
trying to cut corners -- it does not work.
The table below describes some common project documents
and milestones, listed in the order in which a team normally completes
them.
Document or Milestone | Description |
Company Objectives | These set the context in which the project exists. |
Product Specific Objectives | High-level objectives for the product the team is to build. |
Product Requirements Document (PRD) | The PRD puts the project objectives into a working format. It contains:
Key technologies should be evaluated with real code on a real machine before a PRD is finalized. |
Core Marketing Statement | The core marketing statement is not as common as the other documents in this list. It takes the form of a draft press release, advertisement, or direct response mailer. I personally found it to be a helpful cross-check on the PRD to verify whether the product "sizzles." Do all the features hang together in a form that you can sell? |
Product Specifications | The blueprints. Software specifications are often broken into the two pieces below: an external and an internal spec. |
For Software: External Product Spec (EPS) | A detailed description of how the product appears to the end user, typically containing many screen shots. Consultations with customers, mock-ups, prototypes, and actual code should be used as appropriate to verify key parts of a design as early in the process as possible. |
For Software: Internal Product Specification (IPS) | A detailed description of the overall product architecture and coding techniques to be applied for each feature. |
Master Schedule | . |
Project Budget | . |
Test Plan (including performance testing) | Must test all performance and capacity objectives in time for corrective action. |
Alpha Test (optional) | In-house testing of the product. |
Beta Test (optional) | Testing among prospective customers. |
Every feature specified in the Product Requirements Document has
a cost. It is very important for the author to work closely with
the engineering organization to insure that the requirements are
consistent with the project resources and time horizon.
Stn_Cls3.doc
5/13/98