Volume 1, No. 2 (Click Here for .pdf Version)
“Your Product Development Partner”
Welcome to the second in a series of articles from ANGOTTI PRODUCT DEVELOPMENT. The article aims to help you accelerate your development projects by sharing the many tips, techniques, and strategies we’ve honed during our two decades of high-tech consulting services.
This issue discusses the importance of a project to have at least a top-level schedule to set the overall focus of what the team will do during the project.
NO SPEC — NO PROJECT
Often projects “just start”, without going through an initial phase to define what is to be accomplished. What I have observed is that sometimes, this is done with a “bang”, and sometimes with a “whimper”. Managers and team members just “rush off” to begin the “real work”, or they just “wade into the project”.
As can happen, everyone on the team, and the management, assumes that they all collectively know what is to be accomplished without a formal focus on the project deliverables. Later, during design reviews, they discover that they were wrong, and have to repeat portions of the design. Its no wonder that projects can easily drift over time and end up over time and budget.
I have found a good way to remember to write a spec is to add, “No Spec, No Project” to the other old project management adages of “No Money, No Project” and “No People, No Project”.
KEEPING HIGH TECH PROJECTS “ON TRACK”
What seems to escape the team is that Specification documents formally define the real world deliverables for the project. They formally describe what the completed design will do, and, just as critically, what it will not be targeted to do at the time the spec is formalized.
Anything not specified here, is not a part of the project. Of course, as time goes on, the spec will change. I have found that it is critical to keep track of these changes to keep cost and schedule under control.
WHAT DOES A GOOD SPECIFICATION CONTAIN?
So, if the team doesn’t have a good spec outline, what might one contain? In the best scenario the spec describes the important system characteristics and is written down, and signed off by all of the critical team members.
The trick is to have it detailed, but not too detailed. This is where considerable experience with the systems design within the team is critical. It is most effective if all of the expertise in the team focuses on the Spec Generation, even if it initially written by one
person.
Once that management and a team decide to write a spec, a “Generic” spec outline is helpful. A good one might contain some of the following sections:
1. Cover And Signature Page
This makes the Spec stand out from other, less serious, documentation and allows a place for the Responsible persons to “Sign Off” that they agree to this set of deliverables. It should contain a date and Revision Number.
2. Summary of Specification Revisions
This is where any revisions are catalogued by the responsible person and by date. It also includes the purpose of change. This allows the tracking of changes to take place.
3. Misc. Material Used for a Large Specs
These sections become helpful for larger specifications that run into
many pages.
a) Table of Contents
b) List of Referenced Documents – Other documents relied upon in
the rest of the spec
c) A Very Brief Description of the Product Definition
4. A General Description of the Function of the System or Program
This section should contain a clear, short, description of the operation of the code or the system. Ideally it works in conjunction with the Block Diagrams and other support documentation.
5. Definition of Critical System Parameters
This can include such items as noise, bandwidth, accuracy, drift, etc for hardware. It can include such items as response time, code size limitations, special algorithms, languages used, etc for software. These often appear in tables or lists.
6. Definition of User Controls and/or User Interface
This is a description of how the user will interact with the program or system. It needs to be detailed enough to define scope, but need not be extensive. Lots of team judgement is often required here. In complex systems or programs, there may be a separate, more detailed, document to define this important function.
7. Mechanical Characteristics
This includes Size, Weight, Special Materials, etc. for hardware projects. A similar section for software projects might define specifics of the physical deliverables.
8. Operating and Other Design Environments
This section is common for hardware projects, but could be useful for software projects that have physical deliverables to the customer.
a) Operating Temperature
b) Storage Temperature
c) Shock and Vibration
d) Etc
9. Tests Used to Define System or Program Operation
This area defines how the unit will be tested to verify that it meets the specifications. This describes when the “deliverables” are declared completed.
10. Other Tests to Assure the Quality of the Design
This section can be critical for both hardware and software portions of projects. These tests will normally be performed by groups outside the design group.
a) Compliance Testing – UL, VDE, FCC, etc
b) Reliability Analysis and/or Testing
c) Temperature Testing
d) Bug checking for Firmware/Software Validation
d) Etc
HOW TO OBTAIN A SPECIFICATION TEMPLATE
For a more detailed outline of a specification, or help with creating your own, please contact me at mailto:carl@angotti.com or by telephone at (408) 462-2189, and I can send you some useful templates or discuss your situation with you.