(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 ExamplesCost of Being Late
Market Factors:
Sales seasonality Once a year
  • Entertainment software sells at 2-3X the avg. rate during holiday season
  • Essentially all tax software sells between Jan 1 and Apr 15
May miss the bulk of sales for the product release
Competitive updatesEvery 6 to 18 months
  • Quicken updates annually
  • Web browsers update much more frequently
Risk unfavorable product comparisons with "new & improved" competitor
Comparative product reviewsOnce a year
  • PC Magazine's annual printer issue
  • Most magazines determine their editorial schedule a year in advance
Harder to get publicity for the product
"Environmental" Factors:
Release of an industry "standard" Varies
  • Modem protocols
.
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
  • DOS to Windows 3.0
  • Windows 3.0 to Win95
Lose market leading position to a faster competitor (WordPerfect was slow to move to Windows and Word for Windows killed them)
Revolution in distribution mediaSeveral years
  • CD-ROM supplants diskettes
New distribution media often enable entirely new classes of competitor who can take your market position
Revolution in distribution channelVaries
  • Computer super store supplants software only stores
  • Membership clubs begin to carry software
A new channel may be more or less difficult to enter, depending on the circumstances
Requirements for regulatory approvalCan take many years
  • FDA approval of a new drug
.
Financial Factors:
Life cycle of an existing product6 to 18 months
  • Revenues and profits from existing products don't last forever
Stock price could take a beating or company survival may be threatened
Duration of a financing round6 to 18 months
  • Seed financing might support a company for 6 months
  • A product development round might support a company for 12 months
Additional financing can be very expensive or it might not be available at all
Investment horizon of VCsSeveral 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).

The Sequential Development Model
TimeDevelopment Stage Responsibility
1
Concept development Marketing
2
Feasibility testing R&D Engineering
3
Product design R&D Engineering
4
Process design R&D Engineering
5
Pilot production Production Engineering
6
Final production Production Engineering
7
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.

The Parallel Development Model
TimeTechnical/Production Activities Marketing Activities
1
Preliminary technical assessment Preliminary market assessment
2
Concept generation Market testing, studies
3
Engineering design and prototypes Develop marketing plan
4
In-house prototype testing Test prototype with customers
5
Finalize design, trial production Finalize marketing plan, test market
6
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.

The Iterative Development Model
Time
An Interdisciplinary Team Has Responsibility Throughout the Project
1
.
.
Concept development
.
2
.
.
.
Feasibility testing
.
.
.
.
3
.
Product design
.
.
.
.
.
Process design
.
4
.
.
.
.
Pilot production
.
.
.
.
5
.
Final production
.
.
.
.
.
Product introduction
6
.
.
.
.

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 ObjectivesThese set the context in which the project exists.
Product Specific ObjectivesHigh-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:
  • Product description
  • Brief description of competition and the market opportunity
  • Overall design objectives
  • Minimum required features
  • "Nice to have" features
  • Performance requirements

Key technologies should be evaluated with real code on a real machine before a PRD is finalized.

Core Marketing StatementThe 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 SpecificationsThe 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