URL of this paper: http://website.lineone.net/~gill.clark/portfolio/writing/apma.htm
Return to Writing page.

Managing Commercial Web Site Projects

by Gill Clark

April 1998

Coursework for Advanced Project Management Unit: MSc Information Systems

Department of Information Systems, University of Portsmouth, Milton Campus,
Locksway Road, Southsea, PO4 8JF.

Abstract

This paper argues that project management principles can be usefully applied to the development of commercial Web sites, using an existing methodology (Boehm's Spiral). There is a brief introduction to project planning tools and an explanation of their role in managing projects. The importance of testing, risk management and security strategies is also briefly explained. The author argues that the evolutionary and incremental nature of Web site development makes the use of Boehm's Spiral model and evolutionary prototyping techniques appropriate choices. The phases of a project are listed and explained, each phase including guidelines for the developer and a list of those items (deliverables) which are the outcome of each phase. The importance of the analysis phase is emphasised due to its role in ensuring that the Web site meets the customer organisation's strategic business objectives.

Contents

  1. Aims and Objectives
  2. Introduction
  3. Why treat Web site development as a project?
  4. Project Management Principles
  5. A Web Project Methodology
  6. Project Development Phases
  7. Summary
  8. Bibliography

1 Aims and Objectives

The aim of this paper is to provide a methodology for commercial Web site development based upon project management principles. Each development phase is accompanied by a set of guidelines and proposed deliverables. The main emphasis is placed on the analysis phase, as this is the key to a successful Web site development project.

This methodology is suitable for the development of Internet, intranet or extranet solutions, provided certain considerations (indicated in the text) are taken into account. The methodology is most suitable for use by an organisation's Information Systems department, but could be adapted for use by Web site development consultancies.

2 Introduction

A project can be described as a unique endeavour undertaken to achieve some form of change which brings an organisation closer to a strategic objective. (See Figure 1, below) Research by the Forrester research group (Vernon, 1997) found that the average world-wide spend on a Web site was US$437,000, although in the European Union the figure is only $23,000. It is unclear whether these figures refer to development and/or maintenance costs, and whether they represent one-off or ongoing costs. However, the cost involved is undoubtedly high, so the decision to develop a Web site should be seen clearly to achieve progress towards some such strategic goal.

Figure 1: The role of projects in achieving business objectives
Figure 1: This diagram shows the role of projects in achieving some change which brings an organisation closer to one or more of its strategic objectives

Strategic business objectives may lead to the development of a Web site for Internet, intranet or extranet usage. These terms may require some explanation. An intranet is a company-specific network using the TCP/IP protocols, which allows disparate platforms to share the same information; in other words, a Web site for use only within an organisation. Similarly, an extranet is a private network (again using TCP/IP) which allows an organisation's customers, suppliers and trusted business partners limited access to its intranet in order to share and exchange relevant information.

3 Why treat Web site development as a project?

The adoption of the Internet for electronic commerce alone is expected to grow from the current 3% to 20% of sales by value of major UK companies by the year 2002, according to research by British Telecom (cited by Wilson, 1997). An IDC survey (cited by Stewart, 1997) showed that there were 8.9 million European home and business users of the Internet in December 1996, predicted to rise to 35 million by the year 2000. These figures indicate the huge marketing potential of the Internet, even without considering the opportunities offered by the imminent advent of interactive television in the UK, which will allow Internet access via the television screen.

Internet Web sites offer the unique potential of providing service on a one-to-one basis, by offering interaction and user-tailored content. Business-to-customer or business-to-business sites offer valuable potential for targeted marketing.

Despite having different purposes to Internet sites, Intranet and extranet sites also offer unique business advantages for business-to-business or inter-business communications. In addition, they can offer many features found in proprietary groupware solutions, without the disadvantages of being tied to one supplier. An additional advantage is that the technology is portable to the Internet, enabling seamless integration between intranet and Internet should the need arise. Extranets offer a offer a flexible way of linking remote sites, avoiding the need for expensive leased wide area data links (Dudman, 1998). For more information on the business case for intranets, see Business Case News [no date].

Without a formal, structured approach, there is a danger that Web site development will not play a part in the achievement of an organisation's objectives, thereby failing to take advantage of the potential benefits of Internet technology. The remainder of this paper goes on to demonstrate how the use of project management techniques can aid the realisation of such an aim.

4 Project Management Principles

4.1 Project Planning and Control

Projects are managed by using planning and control techniques. This paper's principal objective is to present a methodology for Web site development, so this section on Project Management Principles will provide only an introduction to some of the concepts involved.

4.1.1 Planning

Web site development enables the Project Manager to control the project in a structured and formal manner, in order to foresee possible setbacks and keep the project "on time, within budget and to specification" (J.R. Turner, cited by Wateridge, 1998).

The Project Log
In order to control the project and keep everything in one place, a Project Log may be kept. The Log can be kept in a book, folder or in electronic format, the idea being to keep everything readily accessible and in one place. By incorporating the following items, the Project Log can provide an audit trail for all project work, and a "one-stop" reference point for the Project Manager:

Work Breakdown Structure (WBS)
This section and the two subsequent sections are based upon material by Allan (1996).
The Work Breakdown Structure is used to identify individual tasks and to break them down into a hierarchy. The WBS does not show how many times a task may need to be repeated. The reason for breaking tasks down in this way is to produce a resource management plan for each level (phase, stage, activity, etc.).


Figure 2: Work Breakdown Structure
Figure 2: A generic example of the Work Breakdown Structure (WBS)


Figure 3: Worked example of Work Breakdown Structure
Figure 3: A worked example of the Work Breakdown Structure (WBS)

Precedence Planning
Also known as Critical Path Analysis, Precedence Planning is used to show which of the detailed tasks identified in the WBS are dependent on the completion of other tasks. The reason for doing this is to establish which tasks need to be carried out in advance of which other tasks, and to identify which tasks may be carried out in parallel: for example, much of the visual interface design can take place independently of the coding which provides the functionality behind it. The Critical Path of the project (which can be identified using this planning technique) is the chain of interdependent tasks which will take the longest time during the project, and hence is most likely to affect the deadline. The boxes in the diagram represent the lowest hierarchical level on the WBS (ie. individual tasks). Precedence Planning involves estimating the amount of time each task will take, and how many times it will be carried out. (Ie. the total time for that task during the project).


Figure 4: A Precedence Planner
Figure 4: The Precedence Planner (this much-simplified version does not show the Critical Path)

For further details on this and other project planning techniques, refer to McDermid.

Resource Scheduling
Once the Precedence Planner has been used to establish dependencies between tasks, and the amount of time for each task is known, the Project Manager can plan the available resources - principally time and manpower, though the Resource Scheduler could be used to plan other resources if deemed necessary. The Project Manager may make several versions of the Precedence Planner before he is satisfied that optimal use will be made of resources.
Figure 5: The Precedence Planner.
Note: The letters in the blocks correspond with the tasks shown on the Precedence Planner.
The area of the block and number on it represent the total time taken for the task. (Ie. Task F needs 3 staff for 6 units of time - days, weeks, etc.)

4.2 Testing Strategy

Unlike the development of large information systems, where full-scale testing may not be possible until software modules are fully assembled, web pages (apart from links) are not inter-dependent, and can be tested while they are being developed. For this reason, testing should be carried out throughout the development lifecycle, and not left until a late phase of development, when the time taken for testing may be unpredictable, and the tendency might be to skip or skimp on testing due to a shortage of time or the tedium of extended periods correcting programming errors! Internet web sites need to be tested on as many different hardware platforms as possible, and using a variety of different browsers (a decision must be taken early in development regarding which browsers the site is to be developed for.)

4.2.1 Quality assurance

It is suggested that as each Web page is finished, it should be signed-off in the Project Log by its creator/s as being error-free, and co-signed by a second member of the development team to assure the quality of the finished page.

4.3 Risk Management Strategy

By this we mean risk to the project, as opposed to risks in the Web site itself, such as security or legal liability risks. All projects have an element of risk: Boehm's Spiral Model takes this into account at every stage of the project. (See A Web Project Methodology.) As risks may occur or change throughout the project, they must be controlled and managed like other aspects of the project. Why take account of risks? Contingency plans can be made to eliminate or mitigate those risks which have been foreseen, with the aim of reducing their potential to negatively affect the project.

Aspects of project risk might include time, money, people, changing requirements, legal considerations… and other, unforeseen, risks.

Example: The Project Manager has allowed for staff holidays during the planning phase using Resource Scheduling, but was unable to foresee the absence of a key member of the project team at a critical time. Because he recognised that there was a risk of this happening, he mitigated its effect upon the project by contacting a contract staff agency in advance of the critical period to warn them of his potential needs. In this way he minimised the impact upon the project of the lost project member by using temporary staff. The point to emphasise here is that the Project Manager had a contingency plan in case the risk materialised.

4.4 Security Strategy

A security strategy is necessary for all Web sites, but the level of security adopted will depend upon whether the Web site is for use as an intranet or extranet, or for the Internet. If the necessary knowledge is unavailable in-house, it is recommended that a security expert should be consulted. A more detailed examination of the topic can be found in Ahuja (1996).

4.5 Cost Estimation

Although cost estimation is an important aspect of Project Management, an explanation of estimating techniques is outside the scope of this paper, but is widely covered in Project Management literature.

5 A Web Project Methodology

Boehm's Spiral model (described by Turner, 1993) was chosen as the basis for a new methodology for Web site development, because of the iterative and incremental nature of Web site development. The Internet changes constantly due to rapid technological advances: hardware and networking technology; the use of intelligent agents; changes in networking protocols, HTML and other Internet standards, and so on. "Growing" Web sites gradually allows an organisation to:
Figure 6: Boehm's Spiral model.
Explanation: the red line shows the first phase of the project. Each complete loop represents one phase of the project. The four quadrants shown are the stages making up each phase. (Although they are shown as equal divisions, this does not imply equal division of time for each stage.)

Boehm's spiral model (Figure 6) starts from the centre, with each loop in the spiral representing a development phase. Each phase has four distinct aspects, represented by splitting the loops (or development phases) into four quadrants:

  1. Objective setting. Constraints are identified and a management plan is drawn up.
  2. Identification and management of project risks. Each risk is analysed and steps taken to eliminate or control it. (See Risk Management Strategy)
  3. Choice and implementation of appropriate method to handle current development phase. For example, evolutionary prototyping might used because of the importance of the user interface to a successful Web site
  4. Planning. At the end of each phase, detailed plans are drawn up for the next phase (Plans drawn up during the initial project planning phase are not sufficiently detailed to be used throughout the project. These plans are essential to controlling the project, and are discussed in more detail in Project Planning and Control)

This model does not show how certain phases of the project can run in parallel with one another. It is the role of planning tools to show inter-relationships between the various development phases.

6 Project Development Phases

Although the Feasibility Study and Maintenance Phases are outside the project proper, they are included here as they are invaluable pre- and post-requisites to Web site development projects. They also put the project within a context, showing the lead-in and follow-up work required.


Figure 7: Web development phases
Figure 7: Phases of the development of a Web site (based on project management principles)

6.1 Feasibility Study

The Feasibility Study is not considered to be part of the Web development project: however, without a favourable Feasibility Study, the project cannot begin. (An article on the role and position of the Feasibility Study (Allen [no date]) is available online.) The Feasibility Study is a brief look at the economic, technical and organisational feasibility of the proposed Web site. It study should be undertaken by the organisation requiring the Web site, with advice from consultants if necessary.

Initially, a Statement of Scope and Objectives is drawn up. Its purpose is to:

The next task is to answer the following questions about the proposed Web site:

The Feasibility Study Report should look at the following aspects of the proposed Web site:

Deliverable:

A Feasibility Study Report, which should include a section on each of the following headings:

  • Statement of Scope and Objectives
  • Diagrams/description of present Web site (if applicable)
  • Diagrams/description of proposed Web site
  • Recommendation
  • Development Plan
  • Executive summary for strategic management (including Cost-Benefit Analysis)

After the Feasibility Study, a decision is taken whether or not to go ahead with the project . Where an organisation has an IS department, the decision may be taken to develop the site in-house. Alternatively, development may be outsourced due to:

If the project is undertaken in-house, a Project Manager should be appointed to oversee the work. (This can be combined with another job function for a small site.) It is strongly recommended that the Project Manager should not be the IS department manager, who will have too many other calls on his time to make a good job of managing a project of such strategic importance to the company. (However, this is not to say that he should be uninvolved in the project.)

6.2 Initial Study Phase

(NB. Hereinafter, "the Project Manager" refers to the person in charge of the Web site development, either in-house, or in a third-party development company. "The customer" refers to the organisation which derives benefit from the Web site)

Up to this point, a Project Manager has not been involved, although the person eventually appointed to that role may have had a part in undertaking the Feasibility Study (though this is usually undertaken by the customer or by a third party commissioned by them). It is not until this phase begins that Web site development needs to be controlled and managed as a project, so this phase is considered to be the start of the project proper.

As some time may have elapsed between the completion of the Feasibility Study and the start of the project, the Project Manager undertakes a re-appraisal of the Feasibility Study. The reason for so doing is to review the project's contribution towards achievement of the customer's business objectives, to check budgets and timescales, and to re-evaluate estimates of available project resources and skill bases.

6.3 Initial Planning Phase

The aim of planning is to control project resources: time, cost, staff, physical resources such as hardware, etc.. Without such planning, the project may become late or fail due to lack of resources at the appropriate time. Many project planning tools are available, from pen and paper to sophisticated computer software, the choice of which rests with the Project Manager. A range of plans is used to control various aspects of the project. (See Project Planning and Control for a more detailed explanation.)

The aim of this phase is to provide an overview of the project timescale and resourcing, which acts as a framework for the more detailed planning which precedes each phase (see A Web Project Methodology)

Initial Planning Phase Deliverables:

  • Work Breakdown Structure
  • Resource Scheduler
  • Precedence Planner

Note that these are initial plans, and so are likely to change during the course of the project.

6.4 Analysis phase

The aim of the analysis phase is to produce a logical plan of the proposed site. It should contain no details of the physical implementation of the site, to ensure concentration upon its purpose. The importance of the analysis phase cannot be over-stressed. McGurran (1997) suggests that lack of analysis leads to sites which remain static and lack strategic direction. A Web site failing to achieve progress towards specific business objective(s) will inevitably be seen as a failed project.

Another reason for concentrating effort on analysis is summed up by the words of one Web site developer, (The Net, 1998):

"One of the things that drives me particularly mad is when you're working on a brief for a client… and you're hitting all your targets and then… they change their minds … and want it done in a different way … or slightly different … or the whole thing needs to be different .. and you're three-quarters of the way down the production path... it can be very frustrating."

Not only is it frustrating for the developer, but it is costly - both in terms of time and money. Work has to be redone, which will lower morale in the project team, and lead to project delays. Time, hardware and people resources will be wasted. The developer or the customer will then have to pay for those resources.

Analysis leads to proper consideration of what is required, and documentation of those requirements. As these must be agreed between customer and developer before work is started on subsequent phases, there is less scope for introducing ill-considered changes on an ad-hoc basis. Having requirements committed to paper makes it easier to make the customer aware of the impact of changes upon project resources - extended deadlines, additional skills and a higher budget may be necessary.

Some guidelines follow for the analysis phase: most points are relevant to all types of site. Those points which are more relevant to intranets/extranets are indicated in the text.

Analysis Phase Deliverable:
  • A Site Requirements Report **, which should include a section under each of the following headings:
    • Site Objectives
    • Marketing
    • Web site/Business integration strategy *
    • Site Content
    • Site Features
    • Resource Requirements
    • Training Requirements
    • Budget

**A copy of this report, signed by both Project Manager and customer to show approval of the requirements, should be retained by both parties so there is documented evidence of exactly what has been agreed. This should help clarify who will pay for any changes which are made to the project after the analysis phase, preventing the ill-will engendered by "handshake" agreements where no formal requirements analysis has been performed.

* It is suggested that the Web site/Business integration strategy is dealt with in a separate report for intranet/extranet sites, and for Internet sites where the organisation exists solely online, because the success of these sites depends upon their successful integration into the organisation.

6.5 Design Phase

During this phase, the logical plan produced during the Analysis Phase is physically implemented. Guidelines for the Design Phase are presented below.

Design Phase Deliverables:
  • Site Structure Diagram(s), showing an outline of the content
  • Storyboardsto convey visual style / site architecture to the customer. These can take the form of screenshots or thumbnail sketches to show example screens from the site. They are intended to convey the overall intention of the site.
  • A Graphical Toolkit(see text, above)
  • An Update Interface (preferably graphical) for updating site content
  • A Site Update Procedures Document
  • If necessary, a Training Recommendations Update Report, detailing any changes to the training recommendations made in the Site Requirements Report (eg. training needed to use, update and/or maintain the Web site)

6.6 Evolutionary Prototype Phase

6.6.1 Why use prototyping?

Prototyping is particularly appropriate due to the "evolutionary" nature of Web site development. In the traditional software development paradigm, software modules are tested independently as they developed, with extended testing at the end of the coding phase to check that all modules interface correctly and give expected results. Web pages are "standalone": they can be developed and tested as discrete portions of code, while hypertext links are the "glue" which holds them together. Minimal functionality can be established using "bare bones" HTML to test information flow through the site. Further functionality can be added gradually: this may consist of visual elements, JavaScript and Java coding, database connectivity, etc., depending upon the functionality set out in the Site Requirements Report. Material is added to the prototype as it is developed, to demonstrate site functionality and usability (see next paragraph), and as an aid to debugging (correcting programming errors).

Another reason for using evolutionary prototyping is to establish usability of the site's features (ie. provide them with an optimum interface). Usability is a key issue for intranet and extranet sites, due to the amount of concentrated usage to which they are likely to be subjected. If usability is neglected, the end users may find the Web site difficult or dissatisfying to use, resulting in low morale amongst users, and possible reluctance to use the site. The end result for the Project Manager is likely to be no involvement with further development of the site. Involving end users of intranet and extranet sites in usability testing is straightforward, because they are easily identified. Users of Internet Web sites are not so readily identifiable or accessible! Using the graphical toolkit developed in the Design Phase, mock-ups of the Web site can be used to test user reaction to the interface even before functionality has been added by coding. This paper is not the place for a detailed examination of Usability Testing, but many texts are available on the subject: a valuable resource on the subject can be found online at http://www.uie.com External link (User Interface Engineering). [Accessed: 15 March 1998].

Alongside the testing of functionality and usability, the Web site is tested on the browsers identified as the desirable software platforms for the site, and on different hardware platforms, at differing screen resolutions, etc. Documents are also proof-read, and links checked.

An additional task at this stage is preparation of materials for promotion of the site to end users; online or paper documents, presentations, network notices, notice-boards, etc.

6.6.2 Site marketing material is prepared

Internet Web sites can only be properly marketed once they are online, so marketing material in this instance would consist of preparing press releases and traditional forms of advertising (adding the Web site URL to a television advert for example) ready for release when the site "goes live". Intranet and extranet sites can be promoted by presentations to end users and management at the customer organisation. This would probably take place near the end of this phase, before user training.

Evolutionary Prototype Phase Deliverables:

  • Prototype Web site(s) - as many as necessary, determined by user and management feedback, and according to the project's time constraints.
  • All files which make up the site (HTML, graphics, and other files) must be complete
  • Presentation/demonstration of the finished site to the customer
  • User guide/help (online/paper documents). Mostly applicable to intranet and extranet sites
  • Marketing/promotion material to raise awareness of the site within and outside the customer's organisation.

6.7 Installation Phase

Installation Phase Deliverables:
  • Promotion Activities Report: a short report containing hard copies of rankings of the Web site in all major search engine indexes, positive media reviews, press release(s), etc, as proof that promotion of the site has been carried out.
  • Training material (for intranet/extranet only: if required)
  • Fully functional Web site: Web server hardware/software with Web site files installed

6.8 Maintenance Phase(post-project)

After the project per se is complete, there is a certain amount of follow-up work to be carried out. As with the Feasibility Study, this is not part of the project proper, but is included in this paper to put the project into context, and answer the question, "What comes next?"

There are three aspects to the Maintenance Phase. One aspect is tasks related to maintenance of the Web site itself, such as updating of Web site content, upgrading of hardware and software. These tasks will be achieved as laid out in documents delivered at the end of the Design Phase.

Another task to be carried out soon after the Installation Phase (within say, two weeks) is a post-installation audit on site performance (and user reaction, in the case of intranet/extranets). Should the site be failing to meet any of its requirements from the analysis phase, it is the responsibility of the Web site development team to make any necessary changes.

Another important task during this phase is an analysis of the Web site to ensure it continues to meet the customer's evolving business objectives, as these will not remain static. Equally, the World Wide Web continues to evolve over time, so for Internet Web sites, the analysis may include a section on the current state of Web itself to see if the customer's site is maintaining its competitive advantage. This analysis enables the organisation to maintain a flexible but structured approach to its Web site strategy, allowing evolutionary planning and implementation, and results in a Site Evolution Plan (to be delivered to the customer). The analysis for this plan needs to take place within three to six months of the site's installation, and at regular intervals thereafter.

Maintenance Phase Deliverables:
  • Regular Web site updates/upgrades
  • Post-Installation Audit Report (and adjustments if necessary)
  • Site Development Plan (Web site analysis and recommendations for further development)

7 Summary

The aim of this paper has been to provide a methodology for commercial Web site development, and to introduce some of the key project management principles. These introduced project planning tools and their role in managing and controlling projects and their resources. The project management principles also emphasise the importance of testing, risk management and security strategies.

Boehm's spiral model was proposed as the approach most suited to the evolutionary nature of Web site development. This approach is then applied to each phase of the project. Each phase also includes guidelines on topics to consider and deliverables.

Project Phases:

(Note: Although the Feasibility Study and Maintenance Phases are outside the project proper, they are included in the paper because of their importance to the overall strategy for Web site development, and to set the project in context.)

Great emphasis is laid upon the importance of analysis. Indeed, the whole reason for choosing to write this paper is summed up by the words of McGurran (1997), a new media consultant and author of "Corporate Web Strategies in Europe":

"Without clear goals or a set of measurement criteria for success many sites remain static and lack strategic direction. The planning phase is of utmost importance as it sets the agenda and future direction of a company's activities in interactive communication."

Return to Writing page.

Bibliography

Ahuja, V., 1996. Network and Internet Security. London: Academic Press Ltd. Pp.11-25, 207-302.

Allan, G.W., 1996. Project Management and Control: a unit in MSc Information Systems, University of Portsmouth, UK.

Allan, G.W., [No date]. The Position of the Feasibility Study in Project Management. [Online]. Available from http://www.sis.port.ac.uk/~allangw/feasib98.htm. External link [Accessed: 30 April 1998].

Anon, [No date]. Business Case News. [Online]. Available from http://www.solutionmatrix.com/newsf.html. External link [Accessed: 30 April 1998.]

Dudman, J., 1998. The Virtues of Being Virtual. Network News. VNU Business Publications. 22 April 1998, Issue129, pp. 24-26.

McGurran, P., 1997. Web Europe. Internet Business. Brighton: Internet Business. May 1997, Issue 4. Pp.28-31.

McDermid, D., (date unknown). Software Engineering for Information Systems. Blackwell's Scientific Publications.

New Media Marketing Inc. [1997]. Steps to launching an effective online marketing presence. [Online]. Available from http://www.nmmktg.com/steps.html External link [Accessed: 15 March 1998].

The Net (television broadcast), 1998. 16th March 1998, BBC2. British Broadcasting Corporation.

Turner, R.J., 1993. The Handbook of Project Management. London: McGraw-Hill.

Smith, B., 1985. Project Concepts. Effective Project Administration. Institute of Mechanical Engineers.

Stewart, A., 1997. Net Statistics. Internet Business. Brighton: Internet Business. May 1997, Issue 4, pp. 38-41.

Vernon, M., 1997. Forrester Forum. Internet Business. Brighton: Internet Business. August 1997, Issue 7, pp. 34-35.

Ward, A., Lewis, M. & King, N., 1997. Site Reports: Web Site Management. Business Computer World. London: VNU Business Publications. pp. 68-71.

Wateridge, J., 1998. How can IS/IT projects be measured for success? International Journal of Project Management. Elsevier Science Ltd. 16(1), pp. 59-63.

Wilson, T., ed., 1997. BT sees e-commerce as key to future trading. Internet Business. Brighton: Internet Business. May 1997, Issue 4, p.12.

Return to Writing page.