Technology Management: Product Life Cycle

Not too many years ago, trading your old car for a new one meant driving to the dealer, swapping personal items from one vehicle to another, and driving away — all you left behind was the old car. Today you may have to leave behind that address book of GPS locations that you built up because the design of on-board GPS systems may not have a facility for transferring that personal data to a portable memory chip that could be inserted into the new system.¹ Even if it did, the data formats may be incompatible unless automobile manufactures agree on a standard.

The issue of data preservation and transfer between systems isn’t limited to cars, cell phones,² and MP3 players,³ it also applies to the data systems you rely on to collect, analyze, and report instrument data. Any programmable microprocessor controlled device (microplate readers, automated pipette systems, etc.) could also be subject to the same constraint. Access to lab data and processes stored in intelligent devices will become a concern as systems are upgraded, changed, or mature as part of their life cycle. The matter is more pressing for computer controlled data acquisition/analysis systems, since they are not single products, but layered products each with its own separate life cycle plan.

This article’s emphasis is on external vendor products. However, if you substitute project for product, the same concepts apply to systems developed in your facility. Planning for change should be part of the initial project design.

Product Life Cycles

Products go though several phases in their development

Initial Concept: a need is recognized, product requirements are written, design and project management documents are drafted and reviewed, and decisions are made to proceed.
Development and Testing: the product goes through development, testing, quality assurance, and beta testing, and is then certified for release.
Marketing: during the development process, the product is marketed, leads are generated, sales are made, and the success of the product is evaluated along with competitive products. Depending on the success of the product in the marketplace, it may be dropped or future development and enhancements could be planned.
Product/Technology Reaches a Level of Maturity: at some point sales flatten due to a number of possible factors: lack of acceptance, strong competition, and newer technologies. If the product is viable, a new version will be created with added features and capabilities to make it more attractive and competitive. A decision may also be made to completely redesign the product if the underlying technology is dated or to take advantage of new options. The decision to terminate the product could be made if it is no longer marketable.

Due to the rapid changes in technology, product life cycle phases are occurring at an increasing pace. You may pass through several product life cycles and product changeovers during the useful life span of the data in your lab, which could be decades in biotech and pharmaceutical industries.

The possibilities of product termination or significant upgrades are a concern in technology management. Well-planned, well-designed systems can tolerate change; inadequate planning can put you up against a wall. The same issues can occur when an entirely new product or technology is introduced, replacing products already in service in your lab.

Planning against a vendor’s product life cycle is a matter of balancing the benefits of new product technologies against the potential for painting yourself into a corner. The choices you or your predecessors make can limit your future options.

Instrument-Computer Data Systems and Data Base Management Systems

The intelligent systems offered today are not always single element products; they are a composite of a measurement device and a computer system working together. Each element has its own, separate product life cycle (the operating system, OS for example, is independent; the layered application product may have upgrade versions keyed to OS upgrades). As often happens, upgrades and new versions of computer operating systems can occur more frequently than instruments and applications software.

This can result in your being faced with several situations and choices:

“If it ain’t broke, don’t fix it.” This is a reasonable point of view; the system is operating properly and has been validated. Should you change it if an upgrade to an underlying component (operating system, device handler, etc.) becomes available? No (in the author’s opinion), any significant change would require re-validation of the system. Beyond the fact that operating system changes can create problems with systems and impose additional hardware requirements (more memory, etc.), the instrument vendor’s software was designed and qualified for a specific version of the OS. Unless they have tested and certified it for use, changes should be avoided. The instrument software vendor may have to release a new version of their software to work with the upgraded operating system.
Note: the list of hardware and software requirements are often listed as “minimum requirements” and the operating system version identification is followed by “or later”; unless the vendor has specifically certified the software for use with a later version of the OS, “or later” should be viewed with caution.
The IT group is going to require it for support purposes. This can be a major policy issue. IT has to understand the magnitude of the potential problems and cost that this will generate, plus the potential for down-time in the labs operations. One method of handling the issue is to point to the vendor’s statements of requirements which will spell out the hardware and software environment expected and supported. Vendor support for the application is more critical to you than support for the OS.
When the software is certified for use on a new version of the operating system, you will then have to decide if the upgrade should be done.

-Does it provide any significant improvements or bug fixes that will benefit your lab?

-How long will the vendor continue to support the older version? If you choose to upgrade, the system should go through a re-certification to make sure it is operating properly before being put into service. This may mean running parallel systems. In addition, provision should be made for data backup and recovery — stuff happens.

Vendor-provided upgrades to their products create another set of issues. Their importance will vary depending on the experience of the vendor. Any system change is an opportunity for instability in a lab’s operations, and planning should be done to minimize any impact. That planning should include running the new system in parallel with existing equipment until you are certain everything is working properly and a changeover can be done successfully. Testing of systems doing data acquisition and analysis will have to be done outside normal business hours to avoid compromising routine work. Aside from normal validation and qualification issues, the planning should include:

Consideration for any programming changes made to the systems (customization, tailoring, working with user-defined fields). How will they be transferred to the new system? Are they compatible with the new software or will a redesign be needed? Do you have people and documentation available to do the assessment and re-implementation if needed?
How will any data stored on the system be treated? Will the new system automatically incorporate it? Is there a backup facility? How will you verify the integrity of the data?
What support will the vendor provide? Will you need support from your IT group?
Will the upgrade require additional hardware and software? The upgrade may be released in conjunction with the release of a new version of the operating system.
Do you want to be among the first to do the upgrade? One point to consider here is the level of support a vendor will give to old versions and for what period of time. There is a cost for support and a vendor will limit how much they can afford to provide.
Will lab personnel need additional training? If so, you may need to run a parallel system for training.

Programmable Laboratory Hardware

Lab instrumentation and programmable equipment also go through product life cycles. They may not be as frequent as software systems, but they do occur in the form of firmware upgrades and new technologies. Products may also be retired due to market forces and the need to introduce new generations of equipment. Many of the same points noted above apply to these programmable devices.

The fact that they are programmable and may be controlled by an external computer adds another layer of complication to upgrades or replacements. Unless directed otherwise, programmers writing code to control a specific device will write software for that specific device and its characteristics (command set, etc.). Firmware upgrades may require some adjustment to that programming, but the real issue comes to the forefront when a device is replaced either due to retirement or to take advantage of newer technology: the device-specific programming may not work.

If you are using the same vendor and the devices are part of a product family, there can be compatible command sets and changes can be minor. New products from different vendors will require you to redo much or all of your programming (the overall logic of the program may work, but device-specific elements will change). This situation is similar to the early days of PC graphics programming when programs were written for specific graphics hardware. The solution is the same; generalize the program's logic, and keep device-specific elements in “device handlers” or scripts so that new equipment can be easily integrated with changes localized to the device handler/scripts.

Product Retirement

Products can be retired for a number of reasons: lack of market acceptance, inability to compete with newer products from other vendors, being superseded by a new generation of products from the same vendor, or the vendor was purchased by another company and they are cleaning out older, possibly duplicate product offerings. In any case, if a product you depend upon is being retired, you have issues, some of which may have been anticipated in the purchase agreement.

Points that need to be asked are:

· How long will the existing product be supported?

· If it is a hardware product, where can I get spare parts? Ordering quantities of vendor-specific consumables and difficult-to-replace parts is a good defensive measure. The vendor may be able to recommend third-party support for software and components.

· If the product is critical to your lab’s operations, can you get design and engineering data, software source code, etc. that will allow you to operate until a changeover can be made? It may take a long time — years in some cases — to research, purchase, make any needed adaptations, validate and qualify, train people, and then put replacement products into service.

· If the product stores data, can you extract it and work with it externally to the vendor’s product? This will require the vendor to disclose the file formats used for storage and the details of any proprietary algorithms used for analysis. This could be a difficult legal issue particularly if patents are involved. In addition, comparisons between the current and replacement products' analysis results will have to be made to ensure continuity of operations and to build confidence in the replacement’s results. Protecting access to your lab data is essential.

If the product is widely used, a user group may exist. The group may be able to pool resources and mitigate the loss of the vendor’s support. In the long run, this is a stop-gap measure and may just buy time until a changeover can be made.

Unless a vendor is going out of business (which could be precipitated by sudden unexpected events), they should give reasonable notice of a product's termination so that you have time to take action; if they are staying in business they will want to preserve your good will and potential for future business.

Not all product upgrades or retirements are planned or due to market forces. Sometimes things break. Disks crash and so do computers. Instruments fail and so do components on robots. If that happens and replacement parts aren’t available, the new system may be an upgraded replacement or something entirely new. In June, Microsoft is going to remove Windows XP⁴ from store shelves and new systems will ship with Vista. If the Windows XP computer with your critical application crashes and is replaced with a machine running Vista, will your application work?

Planning Mitigates Stress

As noted earlier, products come and go and the rapid pace of technology development is bringing new products to market that replace those you may have in your lab. Both the desire to take advantage of new technologies and the challenges of having to replace current products can be made easier by effective technology management. Not every potential issue can be avoided, but sound planning can minimize adverse impacts on your lab’s operations.

Avoid doing things that limit flexibility. Programming that is hard-coded to a specific device should be replaced with methods that provide flexibility. This applies to instrument control and data base management systems. Extensive programming changes to a LIMS are a lock-in; replacing or upgrading that system is going to require redevelopment of that programming. Is it really key to the lab’s successful operation? If the answer is “yes” then protect yourself by obtaining source code access and having in-house people trained.

Develop policies and programming standards — lab or organization-wide — that specify how programs should be developed and documented to make them easier to support and provide flexibility; not only do products change but people retire and their understanding walks out the door with them.

The laboratory’s data and its ability to work with it are a fundamental aspect of its operation. The ability to maintain that data in a workable and accessible format is central to meeting the lab's responsibilities. Having data locked in a system on outdated hardware and software is a losing proposition; eventually that system will fail. Not only should the lab's data be backed up, but it should be exported in a workable standardized format that preserves the lab's and the company’s ability to use it, independent of vendor constraints. The ability to do this should be part of purchase agreements.

Identify critical technologies and products and then meet regularly with the vendors to understand their plans and how they can affect your lab. User-groups are excellent sources of information about products and companies; what is critical to you may also be to them, and getting involved with such groups can expand the resources available to you when needs arise. At the same time, be aware of competitive products in case replacement strategies are needed.

Finally, make sure your company’s IT group is aware of your plans and the constraints you operate under, particularly in regulated environments. IT’s corporate responsibilities require them to keep aware of changes in vendor plans and product directions, and that information can help you adjust your planning and anticipate changes.

Product Life Cycle Planning is just one necessary aspect of technology management.

1. According to local Ford, Mazda, and GM dealerships

2. Software packages are available to make the transfer, but there is no cell-to-cell mechanism

3. You’ll need software to extract the music files and you may have to reformat each file if you are changing MP3 player vendors

4. Windows XP and Windows Vista are trademarks of Microsoft Corporation