A life cycle perspective on EC is useful for two reasons. First, a client may have a problem or an opportunity that clearly falls at a specific life cycle stage. In this case its useful to go right to the resources that are useful at that stage. As an example:

Second, consultants often need to help clients think through all the implications of moving into an EC environment. Both in terms of finding resources and showing the client what is involved, the life cycle view can be invaluable.

See ECOTS for details about the supply chain integration project in which the utility of these stages was tested.

Below are the seven stages of the EC life cycle. Each is linked to resources that are useful in managing this stage.

• Awareness Training
• Business Analysis
• Requirements Analysis
• Design
• Implementation
• Integration and Validation
• Maintenance

(1) Awareness training is done to give key people in a company a basic understanding of what a technology is, what it can do for them, and where resources can be found (e.g. consultants, training) to make decisions about implementation. Working at this stage assumes that people know nothing or little about the technology and feel a need to know more. It provides people with a framework for intelligent discussion and planning about a particular form of EC.

(2) Business Analysis Once there is awareness it is all to easy to jump to the detailed planning of stage 3 - requirements analysis. But business analysis is critical if EC is to provide maximum value to an organization. The worst case is that without business analysis, EC will be counterproductive. The more likely possibility is that without deliberate business analysis EC will have some benefits, but with greater expense and less return than should be the case. The goal of business analysis is to move a company toward the best case, i.e. an EC environment that will make the company more efficient, more productive, and more competitive. One impetus for business analysis might involve technology, as in:

• "My customer told me to do EDI", or
• "I see my competitor using the Web and I think I better do something".

A second starting point may be a more general business need, into which EC can be factored as part of the solution, as in:

• I'm having trouble filling my orders because my suppliers don't deliver on time.
• We are running into trouble because its increasingly difficult for our sales staff does not fully understand the capabilities of the new, more complex, products that we are offering.

(3) Requirements Analysis is identification of the EC system that will meet the previously defined business needs. As an example a business need may be to keep customers informed of ever changing products availability, costs, and terms. The requirement to meet this need might be a Web based catalogue linked to a data base on prices and availability; and set in a new organization where a single group maintains a common data base for the Sales and Purchasing Departments. Requirements analysis can be seen as a "wish list", or as an envelope of EC system functioning within which solutions can meet business need. In the real world it is impractical to build systems that will meet all requirements. On the other hand it is impossible to build a system that will meet any requirements unless those requirements are clearly articulated.

(4) Design is an activity which sets out the specifics of system. Questions to be resolved at this stage include:

1. What will the system do?
2. What is the system's design?
3. Who are my potential vendors?
4. By when do I need different parts of the system up and running?
5. What tasks need to be done, and by when, to get the system implemented?
6. What will the system cost?
7. How will the system be integrated into other existing systems?
8. What people have to be involved in the process, and for how long a time?
9. What are the needs for training?
10. What teams need to be formed to implement the system?
11. What organizational changes are needed to take advantage of the system?

(5) Implementation The purpose of the implementation phase is to acquire and implement the system. This is the phase when new technology comes in the door, training is conducted, reporting relationships change, and new EC processes begin to function. Making this work involves careful management of activities and resources to move from the previously developed "paper-based" plans to the reality of implementing new systems in a company that at the same time is trying to satisfy its customers and respond to ever changing business conditions.

(6) Integration and Validation Testing makes sure that the system performs in accordance with its specifications. In other words, that it does what it is supposed to do and does not do what it is not supposed to do. First, individual modules are tested in isolation. Then integration testing begins as modules are hooked together. Finally the entire system is tested with the participation of the users. At this point the system may be put into service, but testing can be said to continue for a few months to assure that users are able to accept the system as a tool to assist in their routine work.

(7) Maintenance, the last phase of the project life cycle, is what happens to the system after it has become operational. It includes changes to the hardware, software, and procedures for using the system. This phase includes keeping the system going, adapting it to unforeseen circumstances, and planning for the evolution to new systems to meet changing business needs and the potential offered by new technology.