The strategy used to develop the Web resource in an organization influences the role of the project team members and analysts. The meta-development
Figure 5.5 The travel.com.au Web site.
strategies are discussed next along with how the approaches affect the gathering of requirements.
Plan the Entire Site
One approach is to plan the entire site and then strictly regulate its distributed development. In this approach, significant effort is put into the planning of the site. However, the aim is to help (and regulate) the users in the development of the content. This strategy would be used where control of the Web content and design is important but where it would be too costly or too difficult because of a lack of specialist knowledge to pay a central team of developers to gather the requirements and build the site. The emphasis is on making sure that the content is appropriate and aligned to the Web strategy. The aim with the design is to present a uniform interface to the outside world.
The analysts involved in the project must make sure that the content and design guidelines are clearly communicated. This can be done through e-mail, Web pages, meetings, and paper-based reports. Training of users in Web page
Figure 5.6 Enhancing current sales with online selling.
design and development is required. There may be people at various levels of the organization who are responsible for overseeing the development of their business unit’s Web neighborhood. These people must meet periodically to discuss problems and swap ideas. The mechanism for evaluating Web page content and design has to be put into place. For instance, all pages may have to be evaluated by a central team before they can be added to the Web site.
Plan the Core of the Web Site
Another option is to plan the core of the Web site (using either outsourcing or in-house talent) and then make no further changes. This type of Web site is typically restricted in the number of pages and its functionality. Hence, only a central core of information is ever included in the Web site. The organization requires strict regulation over content and design. It is also usually trying to communicate a clear and simple message.
By not allowing the Web site to grow organically, the overhead involved in training people about Web site development is avoided as is the overhead involved in evaluating and monitoring Web site content and design. These sites are often developed (and sometimes maintained) by outside contractors.
If the site is developed by outside contractors, then designated staff within the client organization must develop a working relationship with them. The contractors will need to gather content, functionality, and requirements and get feedback on design issues. Of course, it is important to choose a suitable con- tractor for the development (see the section in this chapter on acquiring and working with contractors). The maintenance of the site needs to be resolved at the outset. If changes need to be made quickly and frequently, then it will probably be worthwhile to develop in-house expertise. The cost and time delays involved with contractors when making minor changes to the Web site can be a problem.
Plan and Centrally Develop the Core of the Web Site
Some companies plan and centrally develop the core of the Web site and then let user departments develop their own neighborhoods. The core of the site may include general-purpose information for customers or may try to project a key image or theme. The other business units, however, may have quite differ- ent objectives that they wish to implement. In this case, it might be better to let the business units develop their own portion of the Web site and provide links from the core pages.
The benefits of this approach are that the business units have the content knowledge and are accountable for what they produce. They would typically
be responsible for updating their own section. Letting the user departments go it alone will usually mean that the site as a whole will not have the same
“look and feel” about it. The central team should therefore assess how impor- tant this issue is before deciding on such a strategy. The team responsible for the overall project will need to give some initial guidance and training to the business units before they make a start on developing their own neighborhood.
A similar approach is to plan and develop the core of the Web site and then loosely regulate and manage the development of the business units’ efforts to complete the site. Regulation may involve providing general guidelines on appropriate content and flexible design guidelines to avoid the extremes of inappropriate content and poor design. The analyst must concentrate on gath- ering the requirements for the core of the site and provide support for the rest of the organization.
Allow Unregulated Development of the Entire Web Site
Allowing unregulated development of an entire Web site is an extreme approach that is considered undesirable in most cases. The approach could be adopted for a short period in the hope that some structure may organically emerge. Without some minimum guidelines this may not happen. If the Web site became unmanageable, the time and cost expended in the process would have to be written off. Inappropriate content and design that adversely affected the organization could become a real issue.
Although it is a high-risk approach, it could be used as an intranet devel- opment method where information is only accessed internally. The method could allow users to “adopt” the intranet as their own resource and could lead to innovative uses of the resource.
Plan the Entire Web Site, Develop the Core, and Then Incrementally Develop the Rest of the Site
Where control over content, functionality, and design is important but where resources are not available to complete the Web site over a short period then the site could be developed stage by stage by a central team. The analysts involved would need to decide the priorities attached to each section or component of the site and inform user departments and business units about these. Analysts should plan group requirements sessions with each business unit in advance, so each unit can release key people without difficulty.
Defining the Users
Many different groups of people interact with Web sites. Understanding their characteristics and the roles these groups play is helpful in defining the requirements for a Web application. The more detail that can be added to the development of user profiles, the more likely the completed system will be of use. For example, many different types of customers may interact with a business. Understanding how they differ should go a long way toward under- standing how their needs can be serviced.
1. Browser. The Web is an environment where lots of people will just stumble on a Web site without any intention of making a purchase.
They may be just browsing, which is similar to window shopping in a shopping mall or high street. This type of user will just pass through quickly if the site is not appealing or easy to navigate. If the site is memorable, this person may return at a later date to look again or even make a purchase.
2. Buyer. This type of person has come to the site to make a purchase.
They have some knowledge about the item required. A clear, well- designed system will help the customer complete the transaction.
3. Member and nonmember customers. In some organizations, customers must be members. This may give them special privileges or discounts that are not open to nonmembers. Nonmembers must complete an application form and apply for membership.
4. Dissatisfied customers. There should be some way for customers to make a complaint. This can be done by providing customer service contact details on the Web site.
5. Recipient. The person who buys the goods may not be the same as the person who receives the goods. This must be taken into account in the information system.
6. Suppliers. Suppliers may access an extranet to determine which prod- ucts require supplying.
7. Internal users. Many people within an organization interact with the Web site. There are systems developers such as the analysts who define the requirements of the system. Designers decide on the lay- out and design features of the system. There are content specialists who provide the text for the system. Then there are those who have the technical expertise to implement the system. If the system is
connected to corporate databases, then the database administrator will interact with the Web interface.
Customer service representatives will also interact with the Internet as well as marketing and sales staff. Senior management will be involved more in developing the Web site strategy. Of course, if there is an intranet available, then potentially anyone in the company may use the system.