E-Commerce

Project Management Process
of an E-Commerce Solution Provider

Justin M. Ha

A thesis submitted in partial fulfillment
of the requirements for the degree of

BACHELOR OF APPLIED SCIENCE

Supervisor: M.S. Fox

Department of Mechanical and Industrial Engineering

ABSTRACT
The main purpose of this research is to define a distinct project management process for an e-
commerce solutions provider engaging in a project to create and launch a new web site. There
are many generic project management models and system development life cycle models that
have been developed over the years. However, there are few available resources for managing
projects related to the e-commerce industry, and models designed specifically for e-commerce
solutions providers are essentially non-existent. Such models would greatly benefit e-commerce
solutions providers by offering a guideline relevant to the nature of their business, as well as the
basis in which further improvements can be made upon.

The project management process described in this thesis was initiated with the hopes of
understanding the requirements of building a web site for a client. After a preliminary high-level
outline of a project management process detailing the needs of an e-commerce solutions provider
was provided, knowledge gained from literature reviews as well as interviews with a CEO and
project managers involved in the industry was used to transform the outline into a complete
model of the project management process that could be followed.

The outcome of this research is a project management process model e-commerce solutions
providers can follow when a new web site is requested by a client. This model not only aims to
complete a successful project, but also aims to carry out the project in competitive fashion.
To ensure completion within the projected timeframe and within the proper scope, certain
conditions are established from the outset, and full understanding and involvement are expected
from the client through every step of the process. A period of sixteen weeks is given to complete
a project, starting from initiation of the project to planning, execution, and final launch of the
web site.

2

ACKNOWLEDGEMENTS
I would like to express my most sincere gratitude to all the people that have helped me through
this research. First and foremost, I would like to thank my supervisor Prof. Mark Fox, who gave
me an opportunity to work on this project with Novator Systems Ltd. and whose constructive
guidance and advice were crucial in completing this project. I would also like to thank the people
at Novator Systems Ltd., Carine Jamison, Rebecca Taylor, David Chiu, and Adrienne
MacWhirter, who generously gave up their time for me to gather the information required in
completing this project. I also owe special thanks to Peter Weiss at the engineering writing centre
at the University of Toronto for his help in reconstructing the outline of the project, giving me a
clearer view of this project‟s direction. Last, but not least, this project could have not been
completed without the continuous encouragement and support from my family and friends, to
whom I offer my sincere appreciation.

Thank you all!

University of Toronto, March 2008

Justin M. Ha

3

TABLE OF CONTENTS

1 Introduction ............................................................................................................................ 6
1.1 Background ................................................................................................................................. 6
1.2 Problem Area and Motivation ..................................................................................................... 9
1.3 Research Question .................................................................................................................... 10
1.4 Objectives .................................................................................................................................. 10
2 Literature Review .................................................................................................................. 11
2.1 Electronic Commerce (E-Commerce) ........................................................................................ 11
2.2 Project Management ................................................................................................................ 13
2.2.1 Guide to the Project Management Body of Knowledge (PMBOK® Guide) ........................ 13
2.2.2 Project Management Knowledge Areas ............................................................................ 16
2.2.3 Project Constraints ............................................................................................................. 20
2.3 System Development Life Cycle (SDLC) ..................................................................................... 21
2.3.1 Waterfall Model ................................................................................................................. 23
2.3.2 Spiral Model ....................................................................................................................... 24
2.4 Adaptive Project Framework .................................................................................................... 25
3 Methodology ........................................................................................................................ 28
3.1 Project Approach ...................................................................................................................... 28
3.2 Project Procedure ..................................................................................................................... 31
4 Novator Systems Ltd. - Introduction ....................................................................................... 34
4.1 Company Presentation .............................................................................................................. 34
4.2 Virtual Retailer (VR) ................................................................................................................... 35
5 Novator Systems Ltd. – New Model: Standard Web Site Creation Process ............................... 36
5.1 Project Overview ....................................................................................................................... 36
5.2 Standard Web Site Creation Process ........................................................................................ 36
5.2.1 Prerequisite Conditions ..................................................................................................... 38
5.2.2 Project Initiation (week 0-1) .............................................................................................. 43
5.2.3 Requirements Analysis (week 1-2) ..................................................................................... 52
5.2.4 Design & Solution Specification (week 3-4) ....................................................................... 56
5.2.5 Integration Rapid Prototyping (week 3-9) ......................................................................... 66
5.2.6 Personal Accounts & Static Pages Build, QA, and UAT (week 5-6) .................................... 71
5.2.7 Home Page & Catalog Build, QA, and UAT (week 7-9) ...................................................... 74
5.2.8 Check Out Build, QA, and UAT (week 10-12) ..................................................................... 75

4

5.2.9 Integration Testing, Performance Analysis, & UAT (week 13-16) ..................................... 76
6 Conclusion ............................................................................................................................ 80
6.1 Overall Conclusion .................................................................................................................... 80
6.2 Limitations ................................................................................................................................. 83
6.3 Suggestions for Future Research .............................................................................................. 84
List of References ..................................................................................................................... 85
Appendix A – Standard Fox Chart .............................................................................................. 87
Appendix B – Unofficial Virtual Retailer Features Checklist ........................................................ 89
Appendix C – Sample Test Case ................................................................................................. 93

LIST OF FIGURES
Figure 1. The Dimensions of Electronic Commerce ............................................................................. 12
Figure 2. PMBOK® Guide Project Management Process Model .......................................................... 14
Figure 3. PMBOK® Guide Project Management Knowledge Areas ..................................................... 17
Figure 4. Project Management Triangle .............................................................................................. 20
Figure 5. Waterfall Model .................................................................................................................... 23
Figure 6. Spiral Model .......................................................................................................................... 25
Figure 7. The Adaptive Project Framework ......................................................................................... 27
Figure 8. Standard Web Site Creation Process model......................................................................... 29
Figure 9. Initial Project Procedure ....................................................................................................... 32
Figure 10. Sample FDTs: content layout templates and widget ......................................................... 41
Figure 11. Sample Fox Chart ................................................................................................................ 46
Figure 12. Sample Standard Data Mapping Document....................................................................... 56
Figure 13. Sitemap ................................................................................................................................ 61
Figure 14. User Flowchart .................................................................................................................... 62
Figure 15. Sample Wireframe .............................................................................................................. 63
Figure 16. Entity Relationship Diagram ............................................................................................... 70

LIST OF TABLES
Table 1. Organization Types ................................................................................................................. 12
Table 2. PMI® Mapping of Process Groups to Knowledge Areas......................................................... 19
Table 3. Standard Web Site Creation Process – 1. Project Initiation.................................................. 52
Table 4. Standard Web Site Creation Process – 2. User Experience & VR Requirements Analysis ... 54
Table 5. Standard Web Site Creation Process – 3. Integration Requirements Analysis .................... 57
Table 6. Nielson’s General Usability Principles ................................................................................... 60
Table 7. Content Matrix Column Items ............................................................................................... 65
Table 8. Standard Web Site Creation Process – 4. Design & Solution Specifications ........................ 66
Table 9. Standard Web Site Creation Process – 5. Integration Rapid Prototyping ............................ 70
Table 10. Standard Web Site Creation Process – 6. Personal Accounts & Static Pages Build, QA, and UAT .... 74
Table 11. Standard Web Site Creation Process – 7. Home Page & Catalog Build, QA, and UAT ....... 75
Table 12. Standard Web Site Creation Process – 8. Check Out Build, QA, and UAT .......................... 76
Table 13. Standard Web Site Creation Process – 9. Performance Analysis, Integration Testing & UAT ........... 79

5

1. INTRODUCTION

In this chapter, the research topic covered by this thesis will be introduced. First, an overview of

the background and motivation for this research will be given, followed by the research question

and a brief discussion of research objectives. Finally, a summarized outline of this thesis will be

provided.

1.1 Background

The advancement of technology has transformed our society into a world where the World Wide

Web can be accessed essentially anywhere. Browsing the internet can be done in the palm of a

hand, and such devices are becoming increasingly common within society. Since the Internet

was opened to commercial use in 1991 [1], continuous rapid development of electronic

commerce (e-commerce) has turned e-commerce into a major sector of the economy. No longer a

new way of doing business, e-commerce is now a market which businesses cannot ignore. In a

global consumer report published by Nielsen in February 2008, “Trends in Online Shopping,” it

is stated that 85% of internet users (875 million) have made an online purchase, with more than

half making such purchases regularly [2].

When businesses decide to expand their markets to reach these potential customers, they find

themselves with three main options in launching their website. They can choose between setting-

up their own server, using simple web hosting services, or using specialized e-commerce

platform providers to meet their needs. In this project, the focus will be placed on the case of e-

commerce solution providers who offer expertise in building and managing online retail websites

6

to meet the needs and requirements of its clients.

A number of advantages to choosing the option of seeking e-commerce solution providers to

launch a website exist. For one, the e-commerce solution providers are able to give advice on the

key factors for structuring, operating, and managing an online retail website. They have years of

experience, giving them knowledge of strategies that work and those that do not, and are also

more likely to be up-to-date with new, relevant technology. In addition, they would be able to

customize the website to meet specific needs and requirements of their clients, and could offer

tools that a client may not have initially considered. While undoubtedly more costly, this route

involves much less time and effort invested by the client in understanding the factors involved in

launching and managing a successful online retail website.

For the e-commerce solution provider, having to fulfill all the needs and requirements of their

clients could mean large project sizes and dynamic conditions. With the seemingly inevitable

changes in the business environment that occur constantly and rapidly, it is crucial for an

organization to be aware of and continuously adapt to the changes that surround the industry.

Whether a shift in market conditions, development of new technology, or strategic elimination of

a competitor, how quickly the organization can respond appropriately is arguably one of the key

components in remaining competitive and succeeding in the industry. There is therefore a

growing need for businesses across industries to operate with a project approach. It is not a

surprise that project management is considered by many business leaders and experts as the wave

of the future [3].

7

As new industry sectors develop and existing industries change the way they do business,

questions about the concept and practices of project management arise. Many approaches to

managing a project exist, depending on its nature. Several international organizations are

currently attempting to standardize the notion of project management, such as Project

Management Institute (PMI® ) and International Project Management Association (IPMA).

Regardless, project development typically passes sequentially through major stages of initiation

(or defining), planning (or development), execution (or production), maintenance and controlling,

and closing [3]. In addition, applications of project management have expanded greatly, as

concepts and techniques of project management are being applied not only within businesses, but

also to many organizations [4]. Does this mean the notion of project management is generic

enough to be used throughout different industries, and can bring about significant results? Or

with the changing business environment, is there an emerging need for project management

process models to be industry-specific?

One study [4] examined the project management sector to determine its transferability across

different industries. This study compared construction, information systems, pharmaceuticals,

manufacturing, and utilities industries with respect to typical project size, project management

uncertainties, and qualifications of project managers. Results from the study found 80% of

project management tasks being general across the industries, while the remaining 20% of tasks

were industry-specific, supporting the notion of generic project management. Although the study

indicates that the test should only be treated as a pilot due to its limited sample size, it showed

that certain industries appeared to be more readily transferable to others, while some would

require more additional training or education to do so.

8

1.2 Problem Area and Motivation

This research intends to focus on the process model of project management and associated tasks

performed by the project managers through an analysis of the project management process in

creating and launching an e-retail website for new clients of Novator Systems Ltd., an e-

commerce solutions provider. E-retail simply refers to the business of selling goods online over

the internet.

The problem with project management processes that currently exist is that they are too generic.

Existing project management models can be used as a reference for carrying out a project,

meaning that it can provide a structure to be followed for essentially any project. However, it

only outlines the high-level phases that are required in managing a successful project and

demands very experienced project managers to bring in tools and related knowledge and skills

needed.

So what about new project managers with no experience? Would they need to go through

triumphs and tribulations on their own before establishing a firm grasp of managing projects in

their respective industries? It would not be necessary if a standard model was developed out of

knowledge gained from years of experience specific to the e-commerce and e-retail industry. All

the lessons learned from the successes and the failures could be of valuable information to be

incorporated into further improving a project management model, if such a process existed.

In the case of Novator, software systems are developed to offer e-commerce platforms to its

clients, along with other services such as managing and monitoring of online retail operations.

9

Therefore, Systems Development Life Cycle processes (SDLC) will also be incorporated in this

research. Two approaches of SDLC that were investigated are the traditional waterfall model,

that follows linear stages, and the spiral model, which takes more of an iterative approach.

1.3 Research Question

What project management process model does an e-commerce solutions provider have in

creating and launching an online retail website of its clients? How are they similar or different

from the concept of conventional SDLC methodologies, and would adopting some of the features

of SDLC methodologies help or hinder the success of an organization in the e-commerce world?

1.4 Objective

The main objective of this research is to analyze the current New Client Project Management

process of Novator Systems Ltd., used in launching an online retail website and managing the

operations of its clients. Then, a new Standard Web Site Creation Process will be developed to

provide a project management process model geared specifically towards Novator‟s management

methods. It is my hope that the outcome of this project would be specific, but also generic

enough for other e-commerce solutions providers to use as a process handbook.

10

2. LITERATURE REVIEW

This chapter is intended to present basic knowledge and theories related to this research. Review

of relevant literatures in the areas of electronic commerce, project management, and system

development life cycle will be provided with discussions where needed.

2.1 Electronic Commerce (E-Commerce)

As the technology developed over time to expand the capabilities of how information can be

transferred electronically, the definition of e-commerce has taken on new meanings along with it.

The notion of e-commerce initially emerged when Electronic Data Interchange (EDI) was first

developed in the late 1960s and the initial standardization of EDI data format called ASC X12

followed in 1984 [5]. EDI refers to the electronic transfer of business data between two

businesses, and standardizing the EDI data format enabled different businesses to process these

data universally [6]. From then, continuous development of software, applications, and

additional capabilities of the internet led to the formation of what e-commerce is today.

In the present time, e-commerce can be defined in simplest terms as “the process of buying,

selling, transferring, or exchanging products, services, and/or information via computer

networks” [7]. Even with this broad definition, how businesses operate in the means of e-

commerce can differ by the degree of digitalization. Three dimensions of e-commerce have been

developed by [8], and are shown in Figure 1. E-commerce is only considered pure if all three

dimensions of the product or service, the process of operations, and the delivery method are all

digitalized. Thus, it is important to note that an organization can choose to adopt all or partial

11

practices of e-commerce. An organization can be described in three generic types [7] as defined

in Table 1. It is becoming increasingly common to see brick-and-mortar businesses converting to

click-and-mortar ones, shown by many retailers making a move to penetrate the online market,

such as Walmart, Nike, and Best Buy.

Figure 1. The Dimensions of Electronic Commerce, Source: [8]

Table 1. Organization Types

12

When companies transition over to click-and-mortar from brick-and-mortar, e-commerce

solution providers such as Novator come into play. It is the e-commerce solution providers that

digitalize the dimension of process. The process of conducting business now moves on to the

World Wide Web, where the customer can go to the website and order the product online.

Degrees of product and delivery method can also be digitalized, depending on the type of

business the client conducts, but the role of the e-commerce solutions provider deals with

digitalizing part or entire business process by enabling e-retail operations.

2.2 Project Management

Project management is a method of applying the set of knowledge, skills, tools, and techniques

based on the accepted principles of management to project activities, in order to meet the

requirements on time, within budget, and according to specifications [9, 10]. Project

management process usually follows a series of similar steps, regardless of methodology. One of

the project management process standards, developed by Project Management Institute (PMI® )

will be briefly presented here, which covers the major steps and provides a good basis in

understanding a general approach to project management.

2.2.1 Guide to the Project Management Body of Knowledge (PMBOK® Guide)

PMBOK® Guide is a standard document published by PMI® , recognized as one of the standard

information and practices of project management by various organizations for standardization

[11]. PMBOK® Guide is organized into five high-level process groups (Figure 2) to describe

how project management processes commonly interact. The five process groups are described by

13

[12] as follows:

1. Initiating

In initiating processes, the project on hand is defined and authorized. Formal authorization is

facilitated to start and commit to a new project, and the project manager is chosen. The

business needs and the intentions of the project are documented, along with the outcome that

is expected to be delivered by the end of the project. The preliminary scope of the project is

set by defining boundaries, methods of acceptance, and high-level scope control.

Figure 2. PMBOK® Guide Project Management Process Model, Source: [11]

2. Planning

Planning processes involve defining and refining the objectives, thereby providing

alternatives to choose the best course of action. How the rest of the project tasks will be done

14

is planned in detail, while the preliminary scope determined in initiating processes is further

defined. Work Breakdown Structure (WBS) is created, which is a document that defines the

total scope of the project in an outcome-oriented manner [10]. It defines the required work

and deliverables related to the project more comprehensively, and breaks it down into more

manageable components.

Once specific activities are identified and sequence and dependencies among activities are

determined, a work schedule is developed. Resources and duration for all activities are

estimated in creating a project schedule. Cost is also estimated to establish a budget for the

project. Then, planning is done with respect to assigning responsibilities by staffing each

activity, as well as management of the project, managing communication, risk analysis and

management of risks, and quality management by determining quality standards.

The planning phase creates a roadmap on how the work is to be performed, as well as a

decision tool in a sense that many alternatives are produced and the best alternative can be

selected [9]. Throughout the planning phase, benefits of reducing uncertainty, increasing

understanding, and improving the efficiency of the project can be gained [9].

3. Executing

During the execution processes, the plan is launched. All the planning of the project is

carried out by coordinating people and other resources necessary. Quality assurance is

performed to ensure all processes are employed in the project, as well as recommending

corrective actions if needed. Project teams are acquired or developed to be assigned in

15

accomplishing the work. Any information or resources that need to be distributed is done

during this phase.

4. Controlling and Monitoring

Controlling and monitoring processes deals with measuring and monitoring progress

regularly. To ensure that the project stays on course and objectives are being met, necessary

corrective actions are taken when any inconsistencies are identified. Measures of

performance are collected and the information is shared among the relevant groups. Any

changes or alterations are controlled and implemented when approved. Risks identified

during planning phase, as well as any new risks that arise, are managed through systematic

approaches.

5. Closing

In the process of closing, formal completion of the project work is done and acceptance of

product, service, or result of the project is formalized. All the deliverables are installed or

submitted, while project documentations and post-implementation audits are completed [9].

The final project report is issued and the project is closed.

2.2.2 Project Management Knowledge Areas

In addition to the guide of project management processes, PMI® also defined nine PM

Knowledge Areas to describe project management knowledge and practice in terms of their

component processes [11]. A framework of project management is shown in Figure 3, which

includes nine knowledge areas, as well as stakeholders‟ needs and expectations, and project

16

management tools and techniques.

Stakeholders simply refer to “anyone who has an interest in the outcome of the project” [9].

They can be the people directly involved in a project, or ones that will be affected by the project

activities. Today, tools and techniques are usually in the form of software which assists project

managers and project teams in managing scope, scheduling, cost, risks, and many other aspects

of project management [10].

Figure 3. PMBOK® Guide Project Management Knowledge Areas, Source: [10]

Knowledge areas outline the key areas of expertise in which project managers should ideally be

proficient [10]. The knowledge area of project integration management is an overarching

function that integrates different components developed by the project teams with respect to all

other areas of knowledge [10, 13]. The other eight knowledge areas are divided into two types:

core functions and facilitating functions. Core functions lead to defining specific objectives of

the project, and include management knowledge areas of scope, time, cost, and quality.

Facilitating functions, on the other hand, are the means through which the project objectives are

achieved. It consists of human resources (HR), communications, risk, and procurement

17

management areas of knowledge. Brief descriptions of the eight knowledge areas are as follows

[10, 13]:

 Core knowledge areas:

 Scope Management: defining what work is to be completed and ensuring that the

focus does not drift away to perform any unnecessary work

 Time Management: estimating the duration for the work to be completed in order to

create a project schedule, while maintaining timely completion of the project

 Cost Management: planning, preparing, and controlling the budget for the project

 Quality Management: making sure the project satisfies the needs it originally

intended to meet, such as stakeholder expectations

 Facilitating knowledge areas:

 HR Management: effectively planning and managing people involved with the

project

 Communications Management: collecting and generating information to disseminate

appropriate communication to all parties involved

 Risk Management: managing uncertainties by identifying, analyzing, and

responding to risks related to the project

 Procurement Management: acquiring or procuring goods and services required for

the completion of the project from external sources

How PMBOK Guide‟s project management steps from previous section and the knowledge areas

18

are integrated is shown in table 2.

Table 2. PMI® Mapping of Process Groups to Knowledge Areas

19

2.2.3 Project Constraints

Traditionally, achieving or exceeding the expectations of the customer and/or upper management

determines the quality and the success of a project [3]. During the pursuit of such an

accomplishment, project management is also bounded by constraints like any other task or

problem to be solved. The most well known model that depicts the constraints involved in

project management is the project management triangle in Figure 4.

Figure 4. Project Management Triangle, Source: [3].

Each of the three corners of the triangle represents a constraint in project management, which are

the scope (performance), cost, and time. These three constraints affect the final outcome of the

project, influencing the quality of the resulting output. Each constraint can be referred to as [14]:

 Time constraint: amount of time available to complete a project

 Cost constraint: budgeted amount available for the project

 Scope constraint: what must be done to produce the project's end result

There is a trade-off between these three constraints. For example, sometimes scope must be

compromised to decrease the time and reduce the cost to complete the project. However,

20

relationships between these three constraints are not always correlated. The cost may be less to

decrease the span of the project and minimize the overhead costs, but it can also be reduced by

using less efficient and cheaper methods that may take longer to complete.

It is not a surprise that the four components of Figure 4 are the core functions of the nine

knowledge areas mentioned in the previous section. A good project management must control

these four areas to find the best balance among the constraints in achieving the best results.

2.3. System Development Life Cycle (SDLC)

In the context of information systems, project management can be further defined as the “process

of planning and controlling the development of a system within a specified time frame at a

minimum cost with the right functionality” [15]. As this research looks to focus on Novator

Systems Ltd.‟s services of providing an e-commerce solution involving software engineering,

SDLC models will be looked at for this project.

As the product life cycle of information technology industry, SDLC is the “process of

understanding how an information system can support business needs, designing the system,

building it, and delivering it to users” [15]. There are different methodologies of SDLC for

various project needs, but all have a similar set of four fundamental phases: planning, analysis,

design, and implementation. These four phases can be summarized as follows [15]:

 Planning Phase

The planning phase identifies the business value the system will have on the organization.

21

The system request is presented, which briefly outlines the business need, and how the

system that supports the need will create business value. A feasibility analysis is done to

examine critical aspects of the project. Once both the system request and feasibility analysis

are authorized by the approval committee, it enters the project management, where a project

plan is created. The project plan describes the steps that will be taken to develop the system.

 Analysis Phase

The question of who will use the system, what the system will do, and where and when it

will be used is answered in the analysis phase. Analysis strategy is developed to show the

state of the as-is system, while suggesting ways to design the to-be system. Requirements

gathering is done at this time and a system proposal is presented to the stakeholders to decide

whether the project should move forward.

 Design Phase

The design strategy is developed to decide how the system will be designed. Once it has

been determined, the designing of one or more of architecture, interface, database and file

specification, and program takes place. System specification is then handed to the

programming team for implementation.

 Implementation Phase

The actual system is built during implementation phase. The system is first constructed and

tested to ensure it performs as it was designed to do. Installation of the system follows where

transition happens from the old system to the new system. The training plan and support plan

22

are established to minimize any fallout from the transition.

Two models of SDLC will be presented in detail, which will also be used in comparing the

current processes of Novator.

2.3.1 Waterfall Model

The waterfall model is one of the traditional design methodologies still in use today [15]. The

development proceeds in a linear fashion from one phase to the next, as shown in Figure 5. Each

phase must be completed and approved before the next phase can begin, hence the dashed lines

that lead back to the preceding phase. Since the planning for the entire project is done at the

beginning, it must be done as completely and accurately as possible. Therefore, all the processes

throughout the project are under close watch to ensure all milestones are being reached on time,

documents are completed and signed-off by appropriate personnel, and any issues that may arise

are managed.

Figure 5. Waterfall Model, Source: [16]

23

2.3.2 Spiral Model

The spiral model takes on an incremental, rather than sequential, approach. A portion of a system

is built through a cycle of phases, and the cycle is repeated to add other parts of the system. As

shown in Figure 6, every cycle passes through the four quadrants where each quadrant represents

a phase. The first phase is determining objectives, alternatives, and constraints of the iteration.

The second phase consist of evaluating alternatives, as well as identifying and resolving risks,

and is followed by the third phase of developing and verifying deliverables from the iteration.

The last phase is planning for the next phase. Each cycle begins with identification of

stakeholders and their win condition, and ends with review and commitment [17].

A unique principle of spiral model is that it focuses on assessing risk to minimize the risk of the

overall project. A project is broken down into smaller subdivisions to evaluate and weigh the

associated risks of each piece, and the riskiest or most difficult segment with respect to the

success of completing the project is tackled first [16]. These smaller segments make the project

more flexible, allowing it to face any changes that may occur during the completion of the

project, as well as providing a chance to consider on whether or not further continuation of the

project seems feasible after each cycle [17].

24

Figure 6. Spiral Model, Source: [16]

2.4 Adaptive Project Framework (APF)

APF is a method presented by Wysocki in his book, Effective Project Management 3rd Edition.

As shown in Figure 7, APF is “an iterative and adaptive five-phase approach designed to deliver

maximum business values to clients within the limits of their time and cost constraints” [9].

Wysocki explains that treating scope as a variable is the fundamental concept underlying APF.

APF aims to maximize business value by adjusting the scope at each iteration within specific

25

time and cost constraints. Planning is done just-in-time with APF to eliminate all the non-value-

added work time that is wasted on planning activities that are never performed. As more

knowledge about the specific business situation is gained, APF continuously adapts to the new

conditions. It is client-focused and client-driven, and is grounded in a set of immutable core

values. The clients become the central figure during the each iteration, who decides on what is

valued the most and can choose to change the direction of the project based on new information

gained from the previous iterations. Change is embraced and not avoided to constantly correct

the course of the project.

The APF core values are as follows [9]:

 Client-Focused

 Client Driven

 Incremental Results Early and Often

 Continuous Questioning and Introspection

 Change Is Progress to a Better Solution

 Don`t Speculate on the Future

26

Figure 7. The Adaptive Project Framework, Source: [9]

27

3 METHODOLOGY

The opportunity and the motivation behind the research approach and the procedure used for this

research will be described in this chapter. Research process and its intended strategy will be

explained, as well as tools that were used.

3.1 Project Approach

This project was suggested by Professor Mark Fox, who is the Chairman and CEO of Novator

Systems Ltd. He proposed an idea of conducting a case study type of project to come up with a

project management process model that would fit Novator and could be feasibly and realistically

implemented. A generic structure of a project management process that captured Professor Fox‟s

ideal model for Novator was given (Figure 8), and my goal was to transform the generic

structure into an explicit and complete process model that was specifically geared towards

Novator and other e-commerce solution providers alike. Detailed procedures are outlined in the

next section.

28

Figure 8. Standard Web Site Creation Process model

Contacts to various people at Novator were provided by Professor Fox as an additional source of

information other than himself. They included two project managers, Carine Jamison and

Rebecca Taylor, David Chiu, who is a product manager, and a web analyst, Adrienne

MacWhirter. They were mainly consulted to understand the current situation at Novator, as well

as to learn of any changes that were deemed necessary through their experience. Information

29

gained through them and the general concepts learned through literature review were then to be

utilized in developing the detailed and specific model designed for e-commerce solution

providers.

The nature of this research determined the project to take on a case study type of research

method. A case study is one of the five methodologies in conducting a qualitative study

classified by John W. Creswell in his book published in 1998, Qualitative Inquiry and Research

Design: choosing among five traditions. This project is considered as a qualitative study that is

often used for projects with research question beginning with what or how, rather than why [18].

This study does not have any major quantitative analysis, which aims to perform comparisons or

find correlations among set of data in determining either a cause and effect or relationship

between the variables [18].

Although there are certain data that may be used in defining the characteristics of a project, such

as project duration time and cost measures, this project is not data driven, in that it does not

intend to reduce duration and cost of the project specifically. This project is geared toward

managing successful projects, which is to complete and meet the customer‟s requirements on

time. As e-commerce is often driven by the target customers of the client, projects vary in respect

to size and scope depending on the client‟s needs and requests. Therefore, predetermined

conditions will be set out in an attempt to not limit, but control the flexibility in adapting to each

client‟s unique business. This project hopes to provide a basis that can apply to all cases with

predetermined conditions to reduce the variability in scope and size of the projects and ensure

the project stays within scope. As a result, any measures of previously completed projects were

30

seem to have insignificant value in comparing with what the new model is to achieve, other than

that this will ensure the goal of launching the web site initially will require much less time and

less resources to complete.

3.2 Project Procedure

This project was initially to be done in a seven step process, as outlined in Figure 9. The topic of

research was determined during initial meetings with Professor Fox. With the topic confirmed, a

more specific objective and the scope of the project were developed, as well as the expected

outcome. Once the outline of the project was formalized, literature reviews were completed to

understand the two most important aspect of this project: electronic commerce, and project

management. The knowledge and information obtained through literature reviews provided the

fundamental basis in understanding the topics surrounding this project and were applied both

directly and indirectly to this project.

It was originally planned to model the current „New Client Project Management‟ at Novator to

analyze and identify the key components in improving the current model. However, as the

outline of the new process, „Standard Web Site Creation Process‟, was given, it was found, and

agreed by Professor Fox, that it would not be useful in spending time to document the current

process. Having the outline of the new model allowed me to go straight into completing the new

model, directly applying the information as they were gathered and analyzed.

The main method of obtaining information was by setting up meetings with the project managers.

Meetings were not scheduled regularly, but by the availabilities of the two project managers.

31

Meetings usually lasted from half an hour to an hour and an informal list of questions was

prepared for every visit. Conference calls and e-mails were also used when scheduling a meeting

was not possible.

Figure 9. Initial Project Procedure

32

Many sample documentations, charts, presentation slides, and other resources were also studied

to obtain information. Sample documentations, figures, wireframes, mockups, and other visuals

were very useful in gaining better understanding of how they were prepared and what they are

used for. A number of presentation slides and tables were also provided, with detailed step-by-

step instructions on preparing some of the documents, charts, and reports.

The very first task was to find out what needed to be done in each of the nine activities in the

Standard Web Site Creation Process (Figure 8). For example, key information and personnel

must be brought together during the Project Initiation, to start the project on a sound basis.

Knowing the exact requirements of the activities, the tasks and tools that could be used to

successfully complete each of the activities were recommended.

33

4. NOVATOR SYSTEMS LTD. - INTRODUCTION

This chapter includes a brief introduction of Novator Systems Ltd. and the e-commerce platform

Virtual Retailer that Novator uses.

4.1 Company Presentation

Novator is one of the leading e-commerce solutions providers in the industry. Not only does it

provide a highly specialized e-commerce platform with a wide range of software and technology,

but also offer strategic retailing services of proven success. These attributes are ideal for those

businesses seeking services in both technology and online retailing expertise. Novator is built on

continuous improvement and expertise gained through years of experience since 1994. Novator

values the growth of its clients to maintain long-term relationship and success of both parties.

On the technical aspect, Novator creates an online e-retail website for its clients. With the team

of experts in web design and software developers, Novator is capable of uniquely customizing

both the interface and functionality of a web site to fit the needs and wants of each client.

Novator boldly recognizes and understands the need of continuous improvement for the web site

to be successful. Consequently, Novator is dedicated to maintain long-term partnerships with its

clients to continuously go through post-launch process of adapting to the market that constantly

changes over time.

34

4.2 Virtual Retailer (VR)

Virtual Retailer (VR) is an e-commerce platform developed upon the knowledge and experience

gained over thirteen years by leading retailers, marketers, merchandisers, and e-commerce

specialists. Many of the features embedded in the platform allow for high degrees of

customization so that each client can create and operate their e-Retail web site in a unique way

that distinguishes them from anyone else.

Some of the key features of VR are listed below [19]:

Microsites – Create Retail Data Model entities, microsites, data and design
inheritance, and internationalization.
Design and Content Management – Set up an asset library, page content management and
scheduling.
Search and Merchandising – Manage searches, guided navigation, search merchandising,
cross-sell, up sell, kits and bundles.
Product Management – Manage categories, images and inventory, create products, and
define shipping and taxation rules.
Personalization – Create microsites, targeted segments, profiles and business rule triggers.
Loyalty – Manage customer accounts, address books, gifting, contests, tell a friend, loyalty
points accumulation and redemption, gift cards, and customer reviews.
Email Marketing, SEO and SEM – Create segmented and targeted email campaigns,
organic search optimization, shopping comparison and marketplace data feeds.
Customer Care – Use the CSR module to create and manage customers and their orders.
Shop Cart and Order Management – Manage shopping carts, promotions, fraud, split
shipping, multiple payment options, multi currency, multi language, order cancellation,
fulfillment management, refunds and returns.
Reporting and Analytics – Create ad hoc reports and analyze website traffic.
B2B – Define various pricing options, order quantity restrictions, bulk add to cart and order
processing, invoicing, and fulfillment routing.

35

5. NOVATOR SYSTEMS LTD. – NEW MODEL: STANDARD WEB SITE CREATION PROCESS

In this chapter, a new project management model called Standard Web Site Creation Process

will be presented. This process model is to be followed when creating and launching a new web

site for the client. Standard Web Site Creation Process will be described in detail with in depth

explanations and reasoning behind the proposed steps.

5.1 Project Management Overview

The project enters project management when it is approved. In other words, the Statement of

Work, equivalent to a document that is commonly referred to as a project proposal, and the

contract are signed by the client. Therefore, it is assumed that the requirements of the client were

received prior to executing this project management process and the client has agreed to the four

preconditions that will be outlined. A Fox Chart that outlines a high-level schedule of milestones

and launch dates is set up, which will be discussed in detail later on, along with an annual

schedule that identifies the major events to be performed for or by the client during a 12-month

period. These can include marketing campaigns, micro-site launches, hardware maintenance, and

web site performance analyses.

5.2 Standard Web Site Creation Process

The Standard Web Site Creation Process is designed to provide the project manager with a

project management process model that can be followed when a new e-retail website is to be

created and launched for a new client. Unlike the generic project management and Systems

36

Development Life Cycle models that exist in the business, the Standard Web Site Creation

Process model is developed and geared specifically towards Novator Systems Ltd. and the

businesses alike. The tools and techniques mentioned here are more specific and familiar to

Novator, and they may be substituted with ones that serve the same purpose and are more

preferred by the company.

The objective of the Standard Web Site Creation Process is to serve as a guideline in executing

and completing a successful project of launching new e-retail websites. Having a project that

goes exactly as initially planned are extremely rare. There are always unknowns and

uncertainties that add on to the risk of the project, and the future simply is not always going to be

the way it is envisioned at the outset. Particularly when dealing with projects that aim to meet a

client‟s demands and requests, the client‟s inexperience and lack of knowledge may change the

envisioned finished product as they see the website gradually near completion. Thus, adhering

to the preset temporal outline can ensure the project stays on course towards achieving its goals.

Standard Web Site Creation Process aims to complete the project in four months. It is highly

schedule-intensive, as similar projects previously took eight to twelve months to complete. It

uses years of previous experience and knowledge gained by the CEO and project managers in the

industry to provide a structure and guidelines to the project management process. Methodology

to be used is given instead of having to assess the nature of the project and conditions to select

the appropriate development methodology, as many generic models suggest. The project

managers can have a clearer definition of what is expected throughout the project and can better

guide the project to completion.

37

Standard Web Site Creation Process follows the model outlined in Figure 8 in section 3.1. A

number of conditions that had must be met with the Standard Web Site Creation Process will be

briefly explained here, and detailed descriptions for each of the activities from the model will

then follow in the order of their occurrence. The three activities regarding hosting and

monitoring, however, are not included in the scope of this thesis project and are mentioned in the

suggestions for future research section. The three activities are hosting & monitoring

requirements analysis, hosting & monitoring build, and hosting & monitoring failover testing.

5.2.1 Prerequisite Conditions

The following preconditions are necessary to ensure that the project can be completed within

budget and on time, as well as control the scope of the project:

a. Client web site is to only use the features available in the current version of Virtual

Retailer (VR). This condition is to be agreed on in the contract that would already be

signed prior to entering project management process. Any ideas or requests of new

features of the web site that arise during the course of the project are to be noted and

negotiated after the launch of the web site. The advantage of the not allowing any

customization during this project is to eliminate the time needed for feasibility analysis

of technical and economic aspects, as well as the risk of uncertainties that come with it.

Technical feasibility plainly refers to whether the system can be built or not with the

resources and tools available to Novator. Economic feasibility deals with whether

Novator will profit or lose money in building the customized system for the client.

38

Negotiation of price for customization work will need to take place, which can also

prolong the project. Adding to the delay is the fact that the client may have to carry out

feasibility testing of their own, in terms of organizational aspects. They may want to

examine whether the customized feature they are asking for will be used to the extent

that it will add value to their business.

One major drawback is if the requested idea or feature is strongly envisioned by the

client to be an essential part of their core business practice. The client may not want to

add on a special feature after initially launching the web site. It can be argued that the

time between the launch and implementation of customization work could be of lost

benefit. The customized work being sought out by the client might even be the key

component in establishing a business partnership. Therefore, with the reminder that the

contract has already been signed at this point, the new feature must have been negotiated

during contract signing or the client must follow the standard VR features. If

customization work was to be considered, technical, economic, and organizational

feasibility analysis would need to be conducted and agreed upon prior to the start of the

project management process. The project scope, cost and timeline must then be

reassessed accordingly to reflect the new condition, extending the project period if

needed. It is important to communicate with the client to inform them of possible risks

that may delay and increase the cost of the project.

b. Client data format and communication protocols must conform to VR standards.

This implies that the client will be able to provide data formats that are compatible with

39

VR standards. If the client is not able to fulfill this condition or does not wish to, this

condition puts the responsibility on the client to build the custom code or data converters

themselves. If the client is not capable of doing so, then it must be done by Novator,

resulting in additional costs for the extra work, resources and time required.

One way to achieve this condition is to have a standard data format document for each of

the required areas in data feed. For example, there is a standard data structure for feeding

data into the catalog that is different from loading data into the static pages. Therefore,

all the different areas where the client is required to upload data should have its own

specific standard mapping document prepared in advance. The standard data format

documents must consist of a clear definition of data format and structure, leaving no

ambiguity. It is to outline what is expected from the client, leaving no room for any other

options. Hence, the mapping document places the onus on the client to ensure that their

data format meets the VR standard.

c. High percentage of Filling Description Templates (FDT) are reused.

i. 90% reuse of personal accounts FDTs and actions

ii. 70% reuse of catalog FDTs and actions

iii. 90% reuse of check out FDTs and actions

FDTs, such as that shown in Figure 10, divide the web page into sections, and are the

graphical representations of what you see on the web page. The main FDT is called a

content layout template that sets out the structure of a web page. For each of the sections

in content layout templates, a number of widgets are also to be chosen. The client is free

40

to use each of the sections in the FDTs however they would like. Each of the sections

can be used for navigation bars, banners, product displays, or any other visual and/or

textual content. However, they will not be able to request new templates and must

choose an existing FDT that would best suit their envisioned website.

Figure 10. Sample FDTs: content layout templates and widget

41

By using FDTs that are already created, the software developers do not have to spend

time coding new templates for each client. They may only need to perform minor

adjustments to the existing templates and quickly complete the web pages with the

content specified by the client. The customers must understand prior to the project that

they are only restricted to the spacing and structuring of the web site layouts, and can

absolutely customize the visual appearance and theme of the web page to appear unique

from any other site. Indicated by the percentages, some room for creating new FDTs are

allowed.

The percentages given above are not meant to be measured precisely, but to express the

idea of how much FDTs should be aimed to be reused. Catalog has lesser percentage

than other components because catalog is directly related to marketing and

merchandizing, which may need specialized design to represent the uniqueness of the

client‟s business.

d. Quality Assurance (QA) is to be automated. Currently Novator performs QA testing

manually, where the QA tester actually needs to go through each of the test cases step by

step. Depending on the size of the project, the number of steps that must be tested can

range easily to the hundreds.

The time needed to run through all the test cases is unavoidable. What the QA

automation software does is record how a user travels through the web site, being able to

mimic the sequence of user interaction with the site. However, in order to do so, QA

42

must still be done manually the first time. Where automated QA holds a great advantage

is when the software or the system is modified. After any changes are made to the web

site, QA testing must be conducted again, including the test cases that have already

passed. This is to ensure that any codes that were working properly were not affected

during the process of fixing bugs and errors. Since the QA will be able to be rerun as

often as is required, much time is saved from having to go through the test cases over and

over again each time new code is created or existing codes are modified.

There are two options in automating the QA testing. The company can either build in-

house QA testing software, or such software can be purchased. It would be more

favourable to purchase software, as costs associated with expending time, staff, and

resources to build in-house automated QA testing software would be significantly higher.

Considering the time and resources required to build in-house QA software, building

automated QA software alone may be a project on its own, resulting in further increases

in cost.

5.2.2 Project Initiation (week 0-1)

The Project Initiation brings key information and personnel together to start the project on a

thoroughly established basis. Project initiation consists of activities that must be done from the

time contracts are signed to the kick-off meeting. Since the project negotiations in terms of

business partnership have been completed and the contract is signed, this initiation phase would

only require one or two days. However, project initiation can take more than a few days

depending on the schedule of the initial kick-off meeting. There are four tasks to be completed

43

during the project initiation: create a Client Binder, prepare a Fox Chart, staff the project, and

hold a kick-off meeting. The kick-off meeting is the task that may delay the project initiation

because of the geographic location of the client and the schedules of both Novator employees

and its client. Availabilities of both parties may not allow their respective teams to meet right

away, and therefore, the kick-off meeting is to mark the first day of the project.

 Create Client Binder. The Client Binder physically stores all documentation related to

the client. It serves as a single location where all current and future documentation,

including any sign off sheets for client projects, can be found. These documents include

contracts, amendments, status reports, Fox Charts, client signature pages,

configuration/requirement documents, technical specifications, and change orders.

The Client Binder is prepared once the contracts have been signed by the client and a

business partnership has been established. It is to be in place before the kick-off meeting

takes place, so that any additional documents from the meeting can be stored in the Client

Binder immediately. Client binders are to be stored with the client team and must not be

removed from Novator. A separate binder is to be created for each year so that Client

Binders are organized by client name and year.

For accessibility and control of security of the Client Binder, a company may consider an

internal directory where scanned documents are to be uploaded. By uploading or scanning

only the documents that need to be shared by multiple personnel or teams, the amount of

information accessible by these individuals can be controlled. As a result, all of the

required documents can be easily accessible by those who need them, and the security of

44

the documents can be monitored.

 Prepare Fox Chart. A Fox Chart (Figure 11) is a table that is used to track all the project

milestones and events. It serves as a visual representation of when certain tasks and

events are to occur or be delivered, allowing the project to move on successively. The

Fox Chart is to be prepared prior to the kick-off meeting, so it may be discussed and

communicated with the client and other stakeholders. A Fox Chart can easily be laid out

on Microsoft Excel or similar spreadsheet software, so long as the client is able to view

and edit the file as well. Project managers can use the Fox Chart as a Milestone Report,

sharing and updating the client and other stakeholders on the status of a project and any

changes.

All the milestones and key events are filled along the first column and the time measures

for scheduling are filled across the rest of the columns. Key events include the tasks that

directly affect the project schedule from its delays or failures of completion. A standard

Fox Chart that is to be used can be found in Appendix A, which is to be used to ensure all

the required milestones and events are covered, and strict deadlines that must be followed

have been delegated to each stage of the project. For Standard Web Site Creation Process,

the time measure for scheduling is divided into weeks, and the date of the first day for

each week must be filled in. The first week usually is the week after the contract is signed,

but may be pushed back if the kick-off meeting cannot be held the following week. Then,

projected deadlines for each milestones and events must be replaced by specific dates. For

example, if the projected deadline was “end of week 2”, the actual date of the Friday of

45

Figure 11. Sample Fox Chart, Source: [20]

the second week would need to be filled in.

As not all projects are the same, additional milestones and events may be identified. In the

case of additional items that are more unique to a particular project, appropriate schedule

dates that do not affect the release date of the web site are filled in. It should be kept in

mind, however, that any changes to the standard Fox Chart should be kept to minimum.

All the milestones and events are distinguished by the responsible organization. They are

colour-coded to differentiate the various tasks for which each person is responsible, with

46

each individual assigned a specific colour. A different colour background is also used on

the column for the current week to indicate which week the project is on. The chart is

constantly updated as the project moves on, tracking the status of milestones and events.

For example, if a certain milestone was scheduled to be done during the third week, it is

marked “complete” under week 3 if it was done as scheduled. However, if it was not

completed as scheduled, a new due date is recorded under the week it was supposed to be

completed and an explanation for the reason for delay is to be added. This explanation is

noted in the missed milestone table that is located below the first table with milestones and

events. The explanation for the delay is linked by using a superscript number beside the

new date that corresponds to the note number in the missed milestone table.

When the Fox Chart is sent to the client and other stakeholders, it may be useful to add a

summary page that outlines the status of the upcoming releases and currently ongoing

projects, as well as information of critical issues that must be addressed immediately.

Detailed information on the above areas can be added on the Fox Chart file itself, but it

may be helpful to include a brief summary into the body of the e-mail, as some individuals

may not even open the report.

 Staff Project. The project team must be assembled before the kick-off meeting, so that

the team members who attend the kick-off meeting are the members who will actually be

working on the project. This project requires one project manager, two software

developers, two interface designers, and one quality assurance analyst. Even though this

project may appear schedule intensive, adding additional personnel in order to speed up

47

the process should be avoided. In system development, adding more personnel can

potentially lengthen the project duration as the need for coordination increases

exponentially [15], implying that developers and designers will spend less time actually

working on the project.

 Hold Kick-off Meeting. The first two days of the project should be spent meeting with

the client‟s team of representatives (i.e. VP, PM) and implementers (i.e. marketing, IT).

This is a great way to build a relationship with the clients and review all relevant

information regarding the project. Risks surrounding the project are identified and shared

from the beginning, and a communication network is to be established to ensure that the

appropriate personnel from each party are in contact with each other.

Novator is to provide a list of what is required by the client at this time, clearly explaining

why each item is required. They include a list of requirements for the design of the web

site (i.e. logo, colour scheme, etc.), any text or messages (company information, error

messages, navigation tabs, etc), data feeds (catalog, product images, SKU information,

etc.), and what type of reporting they would like to be able to see. This is to ensure that

the client is aware of all the items that must be provided along the course of the project,

and prepares them with a general timeline in hope of preventing any unnecessary delays.

A checklist can be used to speed up the process, as the client is not likely to have any

initial idea on the details of what they would like on the web site. For example, it would

be better to provide a list of error situations a customer would commonly face, and a list

of error messages that corresponding to the situation could be attached for the client to

48

choose from. In the case of data feeds, the client would not know what kind of data they

are required to send, and how the data should be formatted. The type of reporting that the

client can choose from is a similar case, as it is highly likely that the client could request

a type of report that does not exist at all in VR. Deadlines must be given to ensure that the

client is aware of and is able to provide all the necessary information and requirements by

the dates specified to avoid delaying the project.

The checklist of VR features reflecting what the client has requested prior to the contract

signing is prepared. A sample checklist that captures the concept of the VR feature

checklist but not the official list of features can be found in Appendix B. In addition to

features that were requested by the client, those which may be of interest to the client or

partially reflect their desires are run through with the client. Each feature is to be

explained in detail to make sure that the client understands the function of each feature.

Features on the checklist that clients may not have considered are also briefly mentioned,

as the clients are open to choosing new features. Some features that they may not have

originally considered may appeal to the client. If new features are chosen, however, extra

costs would be incurred. Clients are given a target date within the first week to inform

Novator of which features they want and how they want their web site to work. Any

possible customization work can also be requested, but will only be logged at the time of

VR feature selection and be considered during post-launch stage.

It is equally important for technical personnel from both sides to discuss and understand

the necessary technical requirements. Briefly talking about the current system network

49

structure and the software applications being used by the respective organizations can

give a general indication of what would be needed in integrating the data between the two

parties.

There are also two techniques that can be used to keep the project team on track, the daily

scrums and the ticketing system.

 Establish Daily Scrums. The standard web site creation process must follow a very strict

timeline, meaning that the progress must be made quickly. Thus, daily scrums can be

used to coordinate and keep the team on track on a daily basis. The project manager is to

act as a scrum master, who conducts the scrum meetings.

A daily scrum is a meeting that is held each day, where all team members are required to

attend. It is best to keep a sense of consistency with respect to the time and location of the

meeting. Preferably, these meetings should be held in the morning, as it can set the

framework of the day‟s work [21]. Other personnel around the company, such as a team

member of another project or a VP, may attend the meeting, but would only be able to

listen, as the daily scrum is not meant to be a status report given to the boss [21].

Every member who attends is given the opportunity to answer three questions: what they

have done since the last scrum, what impediments they may have faced, and what they

will do by the time of the next scrum [22]. This is an exceptional method for bringing any

issues that are currently being faced or are foreseen for the future out into the open. Any

50

problems that are brought up are taken offline and dealt by the relevant sub-group after

the scrum, so that daily scrums are not used for problem resolution [21]. Rather, it is for

people to give an update and make a commitment to each other of what work will be

completed by the following day [21].

 Utilize Task Ticketing System. Whether it is an internal database with simple interface

or an online software, a task ticketing system needs to be set up to delegate project tasks

to the team members. Access should be given to all the project members to be able to

view all the tickets created for the project. Each entry in the project should have the

following basic attributes:
- entry ID#
- name of the task
- description of the task
- person responsible for the task
- date of when the ticket was opened
- due date of the task
- status of the task (ie. started, in progress, completed)
- notes (where any of the team members can comment on)
This allows all team members to be aware of what is being done and which individual is

working on them. Also, any tasks that are not being handled or are being delayed can be

easily identified and addressed immediately. E-mail notifications can also be triggered to

the team member when a ticket is created for them, or when any updates were made to

their assigned tickets.

51

Table 3. Standard Web Site Creation Process – 1. Project Initiation

1. Project Initiation (week 0-1)

Time
Task Description
Line
Create Client Binder Prepared  Storage place for all client related documentation is
prior to the created. Documents include contracts, amendments,
kick-off
meeting status reports, Fox Charts, client signature pages,
configuration/requirement documents, technical
specifications, and change orders.
Create Fox Chart Prepared  Status of the project is visually represented. Tracks the
prior to the progress of all the milestones and key events, indicating
kick-off
meetings completions and delays, as well as upcoming deadlines.
Staff Project Prepared  This project is to have the following standard number of
prior to the people involved:
kick-off
meeting  1 Project Manager
 2 Software Developers
 2 Interface Designers
 1 Quality Assurance Analyst
 These roles must be filled before the kick-off meeting.
Hold Kick-off Meeting First 1 – 2  Initiate the project, coming to a mutual understanding of
days of the what is expected through the project. All the key
project
stakeholders of the project are acquainted and
communication network is established. Any risks are
identified to ensure they are handled appropriately
upfront.
Establish Daily Scrums Prepared  Set a time and location of where the scrums will take
at the start place daily.
of the
project
Utilize Task Ticketing Prepared  All team members are set up on a task ticketing system
System at the start and notified to check the system frequently.
of the
project

5.2.3 Requirements Analysis (week 1 - 2)

The fundamental procedure of understanding what the system will do and how it will be built is

done during the requirements analysis phase. The requirements analysis phase is to be completed

within two weeks from the time of the start of the project. As the kick-off meeting marks the first

day of the project, a requirements analysis must be completed over the rest of the week and the

52

week following the kick-off meeting. It is essential that Novator and the client gain complete

understanding and share common expectations of the web site during this phase.

The three activities that are to be completed during this phase are User Experience & VR

Requirements Analysis, Integration Requirements Analysis, and Hosting and Monitoring

Requirements Analysis. All the functionalities and the design of the web site requested by the

client are finalized during user experience & VR requirements analysis, while technical

requirements are communicated to the client during integration requirements analysis. As

mentioned earlier, hosting and monitoring requirements analysis will not be covered in this

report. All three activities are done simultaneously and must be done within, or even prior to the

first two weeks of the project.

All the necessary features are expected to have been introduced to the client during the kick-off

meeting, with greater emphasis given to those pertaining to the client‟s needs and interests.

Ideally, sufficient information should have been exchanged during the kick-off meeting for the

client to be able to conceptualize how their web site is to function and appear within the

boundaries of what Novator is prepared to offer. If many uncertainties remain or unexplained

features were left from the kick-off meeting, it would be beneficial to arrange another meeting to

meet in person with the clients. The majority of the requirements from the client and the features

VR offer should be clearly understood by both parties, leaving minimal ambiguity and

uncertainty before communication is shifted to e-mails and phone calls. Minor details or issues

that could be addressed quickly should be left to communication through e-mails or conference

calls.

53

Details of the user experience & VR requirements analysis is as follows:

 Determine Features/Functionalities. Clients were introduced to the features of VR

during the kickoff meeting in project initiation. The feature determination process deals

with deciding upon the intended functionalities of the web site. It begins with the client

notifying Novator of which features they wish to have on their web site. The key during

the user experience & VR requirements analysis is to minimize or even eliminate any

assumptions by coming to a complete understanding with the client on how the web site

is going to work. By knowing exactly how the web site is expected to function, any risks

in creating the wrong or incomplete components of the web site will be greatly reduced.

Going through the features one by one, the key question to ask the client in eliminating

assumptions is how they envision and expect a particular feature to work. This requires

the client to explain how they foresee the function of various features, so that any

misunderstanding with respect to certain aspects of the web site may be corrected. Other

capabilities may also be discussed so as to achieve the intended function of the web site.

Client should be prompted to imagine how their user may use the feature on the web site

to discuss its effectiveness, and assess whether other choices may be better suited to their

needs.
Table 4. Standard Web Site Creation Process – 2. User Experience & VR Requirements Analysis

2. User Experience & VR Requirements Analysis (week 1-2)

Time
Task Description
Line
Determine Features / Completed  Intended functionalities of the web site are determined.
Functionalities by end of Novator and the client must share common vision of how
nd
2 week of
the project the web site is going to look and function.

54

The outcome of user experience & VR requirements analysis should be the complete checklist of

VR list with appropriate explanations on requests from the client if needed. This is fed into the

Design & Solution Specifications phase. This checklist represents the overall requirements for

the client project, indicating the features and functionalities that a customer can expect to see on

the client‟s web site. This checklist must be completed and signed off before moving into the

design & solution specifications phase. By signing off the final checklist, the client‟s acceptance

and approval of the features of their web site is given. It also can be used to prevent the client

from requesting the addition of new features. Customers should be aware that any new changes

to the site‟s functionalities are not allowed and are to be discussed after the initial launch of the

web site. This is to avoid any scope creep, which refers to a situation when a new feature is

added to the project after system design is finalized [23]. It can be expensive to incorporate the

change, and reworking is often very costly and time consuming.

While the marketing team presents how they want their site to operate, technical people are to

drive how the site is going to work. As stated in one of the preconditions, the client is obligated

to ensure that their data format and communication protocols meet the VR standards. Therefore,

only thing that must be done during integration requirements analysis is to work with the client

on identifying the differences between the data feeds used in both parties. Standard mapping

documents described in the prerequisite conditions section is provided to the client and run

through to make certain that the client is able to conform to what is expected. The onus is placed

on the client to convert their data format if needed, and creating custom code for the client

should be the last option considered. Extra costs must be negotiated if any custom code is to be

built, and it must start as soon as possible.

55

Details of the integration requirements analysis is as follows:

 Educate Client on VR Standards. Communication with the client‟s technical personnel

is facilitated at an early stage of the project to ensure the client would be able to submit

the data when needed. Integration requirement analysis occurs concurrently with respect

to user experience & VR requirements analysis. As the requirements of the website are

being determined, which application protocol interfaces (API) and data fields will be

used are identified. Technical personnel from the client‟s team will then receive the

standard mapping documents for the corresponding data types. An example of

standardized data mapping document is shown in Figure 12. The clients should be

encouraged to ask questions if any instructions are unclear or whether they foresee

difficulties in conforming to the expected communication protocols or data formats.

Figure 12. Sample Standard Data Mapping Document, Source: [24]

56

Table 5. Standard Web Site Creation Process – 3. Integration Requirements Analysis

3. Integration Requirements Analysis (week 1-2)

Time
Task Description
Line
Educate Client on VR Completed
 Ensure the client understands the certain ways the data
Standards by end of
nd
2 week of are expected. There are various data formats and
the project
communication protocols required throughout the course
of the project, and the client must be able to meet all the
requirements.

At the end of the integration requirements analysis, feasibility in terms of capabilities and

compatibility of respective systems must be outlined to ensure the software can be implemented

and any data transfers between the two systems will be possible.

5.2.4 Design & Solution Specifications (week 3 - 4)

After all the requirements have been gathered and defined, the project enters the phase of Design

and Solution Specifications. This is when the transition from requirements to design happens. All

items discussed during the requirements gathering are documented and visualized, creating a

blueprint for the new web site. This is captured in a document called the user interface

specifications document, also referred to as the UI Specifications document. Mockups and

content matrices are also developed during this phase.

A large part of design and solution specifications is designing the user interface. Interface design

aims to create the “top layer” of the web site, one that is visually pleasant and easy to use. It also

must be realized that the layout and appearance of the web site is more than just cosmetics and

57

aesthetics. Interface design is closely linked to the functionality of the web site, determining the

position and space of the contents, as well as the navigational style of the web site. Therefore,

interface design cannot be done without cooperation from the client.

With the requirements of the web site determined, Novator must provide early notices to the

client on when certain responses or contents are needed as the UI Specifications document and

the mockups are created. For example, issues such as knowing the client will need a homepage,

deadline to choose the FDT for the home page and submit all the contents (such as banners and

navigation tab images) should be communicated to the client as soon as possible. In turn, quick

responses from the client in providing approvals, revisions, or submission of required images and

texts ensure that the job can stay on track. The client can have internal graphic designers or use

external creative agencies to create all graphics and images required. If an external agency is

used, they must also understand the need for prompt responses and submissions to stay on course

with the release date for the web site.

All three deliverables of this phase, the UI Specifications document, mock-ups, and the content

matrix, must be signed off by the client before the project moves on. Complete approval is

required to ensure that the web site to be built matches the one client envisions. It may be

acceptable to drag this week, in order maximize clarity and minimize the amount of assumptions

in building the web site. This additional step is not meant to further push back the launch date,

but instead allows developers to being creating portions of the website that have already been

approved. Having more ambiguity and assumptions increases the risk of potentially pushing back

project deadlines. The developers may be forced to stop the progress due to incomplete

information, or may have to rework the site. It is better to fix the outline of the web site before

58

coding begins, as rework tends take longer than coding from scratch. Also, the client should be

reminded that no changes are permitted once the UI Specifications document and the mockups

are signed and construction of the web site begins.

Details of the four tasks involved in design and solutions specifications are as follows:

 Educate Client on Design Guidelines. The spaces provided by the FDTs are freely used

by the client. They can utilize the space to create the look and feel they want to convey to

the users on the web site. However, it may be necessary to educate the client on methods

of interface design that are effective and easy to use. The client may be so focused on

aesthetics that their designs may hinder or conflict with the usefulness and the value of

the web site. One general usability principle identified by Nielson is shown in Table 6.

This, or any other list of guidelines or principles that serve the same purpose, can be used

to provide information and direction to the client during the content design process.

Although not all may be actually applied in their portion of the interface design, having

the client understand the guidelines Novator uses can help them to see and appreciate the

value in the interface designs Novator creates as well.

Another aspect to look at when designing interfaces is the search engine optimization

(SEO). SEO refers to the “process of improving the quantity and quality of visitors to a

site from organic search engine results for targeted keywords” [26]. In other words, the

web site is edited to appear as high on the list of search results as possible. This is

generally achieved by designing the content and HTML coding in a way that increases

the relevancy in keywords, and removing barriers to indexing activities of search engines

[27]. It would be ideal for an e-commerce solution provider to be equipped with

59

knowledge in SEO, so the client does not have to engage other external consultants who

provide SEO services.

Table 6. Nielson’s General Usability Principles, Source: [25]

60

 Create User Interface Specifications Document. The UI Specifications document

defines those features of the web site previously determined through requirements

analysis. It provides page-by-page illustrations of the web site from an external user‟s

point of view and consists of three main sections [28]. The first section consists of either

one or both of the sitemap and content matrix that lay out the total page scope and the

hierarchy of the web site to be built. Sitemap is any form of visual representation of the

web site architecture, and content matrix simply refers to a list of all the contents on the

web site [29, 30]. Example of a sitemap is shown in Figure 13, and content matrix is

discussed in more detail in the next section.

Figure 13. Sitemap

61

Next, common interactions and navigation routes a user may take through the web site is

described through the user flowcharts and associated usage scenarios. User flowcharts

graphically represent the process a user goes through, using “suitably annotated

geometric figures connected by flowlines for the purpose of designing or documenting a

process or program” [25]. Figure 14 shows an example of a user flowchart. Usage

scenarios are simply a step-by-step description of events or actions that occur while a user

interacts with a system [26].

Figure 14. User Flowchart

Lastly, a set of wireframes are included to depict each page or screen described in the user

flowchart. Wireframes are precise behaviors of every functional element and are defined

by standard set of descriptions that is included along with the wireframes [28]. When

creating the wireframes, the interface designers must remember to reuse as much FDTs as

they can, to minimize the extra work for the software developers when they actually build

the web site. Example of what a wireframe may look like is shown in Figure 15.

62

Figure 15. Sample Wireframe, Source: [28]

63

It is ideal for UI Specifications document to be completed and signed off by the client by

the end of the fourth week. However, it may be necessary to complete the document in

portions to allow the web site creation to stay on course of being completed in sixteen

weeks. The portions are to follow the sequence of all personal account and static pages

being completed first, followed by the home page and the catalog, and lastly the check

out pages. This is done to allow the commencement of mockup creations that need to be

prepared prior to the web site construction. The mockups can only be created when the

portions of UI Specifications document are signed off by the client and associated

contents are received. The ordering lets the software developers start building the

personal account and static pages at the beginning of week five as scheduled. Once all the

portions of the UI Specifications document are completed, a final document is compiled

and signed off by the client.

Only the functional representations of the elements on each page are contained in the UI

Specifications document [28]. The appearance of the web pages or technical

implementation procedure is not included in the document. It does, however, include

specifications required for development of technical schemes, code, and visual design for

the web site [28]. Therefore, the client is able to gain the full knowledge of all the

contents to be added with respect to both technical and creative development.

 Create Content Matrix. A content matrix is created only if the client requests it. It

outlines all the content to be on the web site, including texts, button names, and product

details. This document can be used to specify the merchandizing information for the web

64

E-Commerce

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie E-Commerce

Ähnlich wie E-Commerce (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

E-Commerce