Most of my experience has been like the school year - some ups and downs, but otherwise a combination of people, software and/or hardware coming to successful completion without too much excitement or too many bumps in the road. I have chosen a few of the more exciting or unusual summer vacation class of projects to include.
I started from ground zero at RIPS [Raster Image Processing Systems, a start-up] and setup component suppliers, performed board layout, arranged prototype fabrication, and test for the RISC based single board computer while keeping all of the vendors happy and the component orders in sync. This allowed software development to progress while I completed the Laser Engine Adapter board and firmware amidst other activities. We began with 3 people in the Spring and by Fall had built a small team that delivered the world's first demonstration of a PostScript compatible printer printing at 20 PPM. Starting a hardware/software program like this when absolutely nothing was in place and delivering a successful product demonstration in 8 months was definitely a challenging and rewarding adventure.
The Laser Engine Adapter board [at RIPS] was designed to connect to any laser printer engine by making a custom cable and changing some jumpers or, in the worst case, making a firmware change. One of my hats was the responsibility for the fabrication and firmware for this board. When contacted by potential customers for evaluation units, we would ask them to schedule a visit to our facility, ship us the interface specification and a laser printer sans controller. The printer usually arrived at the same time as the customer. An adapter cable was fabricated and the LEA board tweaked per specifications in advance of the customer arrival. The commitment to the customer was to demonstrate the controller on a similar laser printer and deliver a working configuration in 2 weeks. During the customer pitch meeting, the printer was usually working within 45 minutes. When the customer saw the demo running on their own printer and outperforming the Apple LaserWriter, their expectations were exceeded and their confidence in RIPS to execute was greatly increased. The technical expertise, concept, and planning transformed a typically boring event into a marketing advantage. And to the casual observer - "that was no big deal, it only took 45 minutes".
I volunteered to take over a seriously mismanaged project that was in a ditch. The project centerpiece was hardware and software to be delivered by a third party [TP] to TI - _and_ TI was committed to deliver the product to a major customer. A site visit revealed that the TP was marginally qualified to do the design and totally unqualified to deliver prototype or production parts. I remained on site for over a week developing a basic project plan and training someone to a minimum level to establish consistent communication terms and report back on project status. During this time our logic guru was factoring the FPGA logic so that it would fit. Upon receipt of working prototypes, I successfully pitched the idea to purchase the manufacturing rights from the TP. This allowed us to circumvent their inability to manufacture the product and select a contract manufacturer to build a quality product.
TI decided to promote a new flagship C6000 DSP and get it into more hands by selling a single board computer that could be used as a plugin PCI card or standalone board for software development. A JTAG controller that connected to the debug software via the PCI bus was included in the board logic. The overall project goal was to deliver hardware that could be plugged into the PCI bus and software that could be installed to create an instant DSP development environment. We were fortunate to have selected a competent third party developer to handle most of the hardware and software design. We were able to work as a team, working through issues on both sides, like requirement details and scope changes, calibration issues due to different development practices, and component delivery issues. After the completion of a rigorous Test and Acceptance Plan, the product was released and shipped to customers.
The product seemed destined for great success until the problem reports started coming in. Periodically installation problems would be reported and the support staff, who had not previously supported PCI-based products, was ill equipped to deal with the variety of things that could go wrong. In house testing had only identified user problems during installation - no other type of problems were able to be created. Investigation of the problems identified non-TI drivers were the primary culprit. Some vendors had released PCI drivers that could not share interrupts (this does not meet PCI specs) but did not experience problems due to the small number of PCI cards installed (no interrupt sharing needed). In some cases it was very difficult to convince a customer whose PC had been running flawlessly for a year that the new equipment failure was due to old software on their machine. Changes were made to the installation software and documentation, tech bulletins and training supplied to support personnel, and a troubleshooting guide was created to deal with problems if they occurred. The problem was the number of evaluation kits in the pipeline and the self installation nature of the product. With no corporate web support in place at the time, I joined and became an active participant of the Yahoo C6x group. This had two main effects - I could address user issues in the short run and obtain direct user feedback. Since obtaining useful user feedback on a product distributed through multiple channels is difficult, this proved very useful on future products - even though I initially bypassed the existing corporate system.
TI wanted to encourage third parties (TPs) to create and manufacture their own JTAG debug hardware. To do this the TPs needed two things - some DSP specific JTAG knowledge and a current licensed version of the source code based Debug Porting Kit. These constraints limited the potential number of JTAG debug hardware suppliers. I championed and managed the release of a redesigned "Sourceless" Porting Kit that eliminated the requirement of DSP specific JTAG knowledge and the original source code license. The released product went for over three with only a single software update.
There was a company with a very successful product line. Their string of products had progressed in a classical evolutionary manner. They decided to create a totally new product - new hardware, portrait mode display, Ethernet, UNIX OS port, WYSIWG editor, spreadsheet, graphics package, equation editor, and a relational database. A large program that was delayed beyond the original ship date when I was hired with full knowledge that the program was in serious trouble. The initial assessment was basically what was expected - all of the obvious and fun major technical issues were addressed, but the detailed requirements and final product details were lacking. The basic model was a Desktop Publishing System with a Xerox Star-like UI. The decision was made to contact and interview some existing Star users to determine the customer expectations. Wow! Here we were in the middle of the river with something like 100 man years invested and the requirements had not yet been nailed! The interview information and data from the Seybold Report were used to create new and refine existing user requirements. With everything split across two Project Managers, the rescheduled program was finally on the right track. The completion of the requirements and attentive beta testing were key to delivering a product with acclaimed Desktop Publishing functionality.
I was asked to visit a customer site in Burbank, California to assess and remedy a mystery problem with their embedded communication controller. The customer began experiencing fatal communication errors once or twice per day and it was causing a high degree of frustration. Service reps had replaced every component and power supply in the controller and it made no difference. Monitoring of the AC power showed no inconsistencies or disruptions. The controller would display inconsistent and unique error codes at the time of each failure. Manual intervention and restarting the job was always successful. My assignment was to 'visit the site and not come back until the problem was resolved or defined'.
After verifying that the controller was in proper working order, I began interviewing the operator and other folks in the immediate area. The only information that I got was 'everything was normal and it just quit' until I got to Dianne. As I was about to ask her a question, she said "You had better get back over to your machine. It is getting ready to break!" In the ensuing conversation, Dianne revealed that ever since they installed that new press on the other end of the second floor a failure would occur when they ran it. Aha, a clue, a clue!
The operation of the large press would vibrate the power relay just enough to cause a logic voltage glitch, but not long enough to detect a power failure.
The Lesson Learned - never underestimate the value of user [or observer] input.
- - - - - - - - - - - - - -
Process Improvement Specialist - Project Manager - Program Manager
Position to unleash my 25+ years of high technology experienceto make a difference in a growing organizationfor the next 10 years.
Attended Texas A&I University - Kingsville, Texas