============================================================= ANGOTTI PRODUCT DEVELOPMENT E-MAIL NEWSLETTER Volume 1, No. 2 "Helping You Accelerate Your High-Tech Development Projects" ============================================================= Welcome to the ANGOTTI PRODUCT DEVELOPMENT email newsletter! The goal of this newsletter is to help you accelerate your development projects by sharing some of the many tips, techniques and strategies we've honed during our two decades of providing high-tech consulting services. This issue discusses a fundamental way that specifications and related documentation can assure that a high technology development project can complete in record time. ===================================================== 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-739-5046, and I can send you some useful templates or discuss your situation with you. ===================================================== This article is an expansion of the second of our "12 Best Strategies for Keeping Engineering Projects on Track". For more information on the "12 Best Strategies", visit www.angotti.com/12strat.html. ===================================================== THE NEXT NEWSLETTER ===================================================== The next newsletter in this series will cover the topic "Determine High Risk Areas Before Beginning Planning". This is the third of the "12 Best Strategies" article available at www.angotti.com/12strat.html. ========================================================= FEEL FREE TO FORWARD THIS NEWSLETTER TO YOUR ASSOCIATES ========================================================= If you think this information would be valuable to others, please feel free to forward this newsletter to your associates. I would appreciate it if you would not alter its contents. If you were forwarded this e-mail, and wish to subscribe, please send an e- mail to mailto:carl@angotti.com with SUBSCRIBE in the Subject Heading, and I will add you to the list of subscribers. ===================================================== MORE FREE MATERIAL ON PROJECT MANAGEMENT ===================================================== For more FREE Project Management tips, techniques and strategies, and to learn more about the services available to my clients, be sure to visit the ANGOTTI PRODUCT DEVELOPMENT website at www.angotti.com. ===================================================== TO REMOVE YOURSELF FROM THIS EMAIL LIST ===================================================== To REMOVE yourself from this email list, REPLY TO THIS E-MAIL with "REMOVE" in the subject or body of the message.