This document provides guidelines for an Information Architecture Web Services Methodology called INSITE. It outlines a 4-stage methodology for defining, designing, developing, and deploying web services projects. Key aspects of the methodology include establishing goals and objectives, scoping the project, assembling a cross-functional team, involving clients, performing risk analysis, and creating deliverables like an Information Architecture Document and project plan. The methodology is intended to help teams successfully develop online services and applications in a rapidly changing environment.

1. Information Architecture Web
Services Methodology
Definition and guidelines document

2. Document Document name INSITE-SDLC
Author Andy Williamson,
Details Wairua Consulting
Revision 2.00
Legal Notice Copyright © Wairua Consulting 1999-2001. All rights
reserved.
This document and its associated components are provided
Wairua Consulting under license and remain the property of Wairua Consulting.
PO Box 60-517 Authorised users are granted a non-exclusive license to use
Titirangi the contents of this document and any associated
Waitakere City documentation and/or intellectual property. The conditions of
Aotearoa/New Zealand
this license mean that you must not copy, distribute, sub-
Telephone +64 (0)9 817 1133 license or resell this product. Wairua Consulting accepts no
Fax +64 (0)9 817 1103
responsibility for the direct or indirect consequences of using
Email info@wairua.com
www.wairua.com this material. E&OE.
Insite Information Architecture Web Services Methodology,
INSITE, Wairua Consulting and the Cabbage Tree logo are the
property of Wairua Consulting and are not to be used without
permission
CONFIDENTIAL
Revision 2.00 i

3. Contents
Document Details i
Legal Notice i
Introduction 1
Background.......................................................................................................................1
Principles for the New Economy .......................................................................................2
Information Architecture...................................................................................................5
How to use this Document ................................................................................................7
Methodology Overview 8
Scope.................................................................................................................................9
Exclusions ..........................................................................................................................9
Team Building.................................................................................................................11
Client Involvement ..........................................................................................................12
Steering group ..................................................................................................................................12
User and Customer involvement........................................................................................................12
Managing changes and feedback ......................................................................................................13
Stage 1 — Define 14
Clearly Defined Goal ......................................................................................................14
Define the Objectives......................................................................................................14
Ensure the Project is Scoped ...........................................................................................14
Define any Exclusions ........................................................................................................................14
Document all Assumptions ................................................................................................................14
Record Measurable Success Criteria...................................................................................................15
Perform Risk Analysis .....................................................................................................15
Generic Risk Checklist .......................................................................................................................15
Specific Project Risks..........................................................................................................................16
Create a Work Breakdown Structure ..............................................................................16
Tasks and Milestones.........................................................................................................................17
Skills/Resources.................................................................................................................................17
Document the Deliverables.............................................................................................17
Create a Project Plan ......................................................................................................17
Stage 2 — Design 18
Information Architecture Document ...............................................................................18
Goal and Objectives..........................................................................................................................19
Audience...........................................................................................................................................20
Use Case ..........................................................................................................................................23
Functional Requirements ...................................................................................................................24
Site Structure.....................................................................................................................................25
Architecture.......................................................................................................................................27
Client Interface .................................................................................................................................29
Project Structure..............................................................................................................31
Estimate ............................................................................................................................................31
Timeline............................................................................................................................................31
Resources..........................................................................................................................................32
Tools for Developing your IAD........................................................................................32
Workshops and Interviews .................................................................................................................32
Data Modelling .................................................................................................................................32
Workflow ..........................................................................................................................................33
External Specifications ....................................................................................................33
Stage 3 — Develop 34
Application Paradigm .....................................................................................................34
Selecting Development Tools..........................................................................................34
CONFIDENTIAL
Revision 2.00 ii

4. Version Control ...............................................................................................................34
Version Numbering ........................................................................................................35
Release Levels.................................................................................................................35
Architecture.....................................................................................................................36
Testing.............................................................................................................................36
User Acceptance Testing (UAT) ..........................................................................................................36
Test Scripts ........................................................................................................................................38
Error Tracking and Logging ...............................................................................................................39
Error Levels and Acceptable Rate .......................................................................................................39
Stage 4 — Deploy 40
Project Close-out .............................................................................................................40
Post-Implementation Review ..........................................................................................40
Financial Review................................................................................................................................40
Project Review ...................................................................................................................................40
Project Management 42
Cost/Benefit Model..........................................................................................................42
Project Reporting 43
Attention Reporting ........................................................................................................43
Project Documentation....................................................................................................44
Quality Assurance 45
Risk Management 46
Identify ............................................................................................................................46
Assess..............................................................................................................................46
Manage ...........................................................................................................................47
Product Evaluation ..........................................................................................................47
Change Management 48
Documentation................................................................................................................48
Document Management 49
Standard Documents.......................................................................................................49
Non-Standard Documents ..............................................................................................49
Terminology ....................................................................................................................49
Naming Conventions ......................................................................................................50
Project Charter 51
Project Scope ....................................................................................................................................51
Deliverables ......................................................................................................................................52
Milestones.........................................................................................................................................52
Reporting ..........................................................................................................................................52
Quality Assurance .............................................................................................................................52
Methodology .....................................................................................................................................52
External Influences ............................................................................................................................52
Roles and Responsibilities ..................................................................................................................52
Risk Management Approach ..............................................................................................................52
Appendices 53
Appendix A – Terminology..............................................................................................53
Appendix B – Test Script..................................................................................................54
Index 56
CONFIDENTIAL
Revision 2.00 iii

5. Table of Figures
Figure 1 - Four stages of INSITE..........................................................................................................................................8
Figure 2 - Cross-stage processes ........................................................................................................................................9
Figure 3 - INSITE Process Model .......................................................................................................................................10
Figure 4 - Roles and responsibilities..................................................................................................................................11
Figure 5 - Definition of roles .............................................................................................................................................12
Figure 6 - Generic risk Checklist .......................................................................................................................................16
Figure 7 - Specific project risk checklist outline..................................................................................................................16
Figure 8 - Audience map ..................................................................................................................................................21
Figure 9 - Relationship matrix ...........................................................................................................................................23
Figure 10 – Use case example ..........................................................................................................................................23
Figure 11 - Graphical site structure...................................................................................................................................26
Figure 12 - Functionality Matrix ........................................................................................................................................27
Figure 13 - Page layout grid .............................................................................................................................................30
Figure 14 – table of graphical elements ............................................................................................................................31
Figure 15 - Resource requirements ...................................................................................................................................32
Figure 16 - Test cycle........................................................................................................................................................37
Figure 17 - Error levels .....................................................................................................................................................39
Figure 18 - Cost/benefit analysis ......................................................................................................................................42
CONFIDENTIAL
Revision 2.00 iv

6. Introduction
INSITE is a web services methodology from Wairua Consulting that is based on
the principles of information architecture. INSITE introduces project managers,
web designers and software developers to a simple yet highly effective
methodology. By maintaining design integrity and INSITE helps to minimise
design flaws and human error during the specification, development and
deployment process of web-based services, ranging from simple web sites to
complex transactional platforms. INSITE addresses the often-overlooked issues
of re-usability and maintainability, aiming to introduce best practices to reduce
development cost and effort.
The philosophy behind INSITE is simple: do it quickly but get it right!
Information Architecture delivers real business advantage and improvement
through technology. It permits radical process change to occur accurately, safely
and quickly. It is not the aim of this methodology to tightly define exactly what
must be done, when, how and by whom. Rather, it is the role of the project team
members to work creatively and dynamically to deliver maximum value in the
shortest possible time. The methodology defines guidelines1, rather than
standards2 and remains neutral and unbiased towards specific operational
environments and development tools, since these are changing rapidly and
become quickly outdated. INSITE attempts to define a best practice model for
successful online, collaborative development.
Background
The impact of the Internet on information and communications technology (ICT),
not to mention the commercial world that ICT supports has been both dramatic
and revolutionary. In only a few short years, we have seen a radical change in the
way business and society operates and in the way software is developed. Perhaps
more radical still is the change in user expectations. This is a revolution that is
more than the sum of its technological parts. We stand today at a mid-point in
1 A guideline is a recommendation that indicates a best practice but adherence to this is suggested rather than enforced.
2 A standard is something that, unlike a guideline, you must do.
CONFIDENTIAL
Revision 2.00 1

7. the transition from the old-world supply-driven economy into the new world,
one which is customer-led and where “markets are conversations”3
The Internet has radically changed the way our society thinks, acts and functions;
it has changed the way people talk to people, businesses talk to each other and
the way citizens talk to government. The speed of change throughout this
revolution has been staggering. One only has to look at the banking industry to
see that the Internet is itself one of a number of catalysts for monumental changes
in business process and the environment in which organisations operate. Banks
entered the 1990s doing more or less what they had done for the last three
hundred years. They exited that decade coming to terms with pervasive
technologies that had eroded their traditional delivery channels and created new
ones, that had started the metamorphosis from a transaction based business into
one focused on customer service. Most importantly of all, banking was no longer
constrained in space and time but could happen anywhere and at any time4. It
isn’t over yet; with the onset of broadband data services, falling costs and
exploding technologies, the next ten years will see an even more dramatic
transformation in the way we use ICT. As Miller5 observed, “few dispute the
likelihood that within 20 years the Internet will become as generalised,
indispensable and taken for granted as today’s phone or electrical networks.”
INSITE does not directly address this revolution; rather it is concerned with
solving the problems that this has caused behind the scenes. To support these
new business modes, tools, applications and projects are transformed in this new
world.
Principles for the New Economy
The key to success in the new online world is the ability to adapt quickly.
Unfortunately, in terms of systems design, this has meant a return to anarchic
development, jettisoning traditional practices for the cut and thrust of a back-of-
a-beer mat specifications, where prototyping becomes little more than a
metaphor for “just do it”. As idyllic, exciting and fun as this might sound, the
Internet is not a giant playing field where anything goes and this approach is not
3 Siegel, D. (1999). Futurize your enterprise: Business strategy in the age of the e-customer. Danvers, MA: Wiley.
4 Darlington, L. (1998). Banking without boundaries: How the banking industry is transforming itself for the digital age. In D.
Tapscott, A. Lowy & D. Ticoll (Eds.), Blueprint to the digital economy . New York, NY: McGraw-Hill.
5 Miller, R. (1998). Cyberspace: The next frontier? In D. Tapscott, A. Lowy, & D. Ticoll (Eds.), Blueprint to the digital economy .
New York, NY: McGraw-Hill. pp.384
CONFIDENTIAL
Revision 2.00 2

8. a recipe for success. As a result we are seeing many projects delivering software
that is poorly designed, unreliable and inefficient. Ultimately it leaves businesses
with unforeseen expenses for maintenance and enhancements. Part of the
problem is that there has been a failure to develop, adapt and adopt
methodologies that work. Backtracking to the days of traditional development
methodologies is certainly not a realistic option; this would stifle creativity and
slow down the development and delivery cycle, gone are the days when the
technologists can huddle together for six months to develop a specification.
Development schedules today must talk in weeks and months, not months and
years. The second problem with traditional methodologies is that they are
technology-focused and we live in a different reality, one where the boundaries
between technologist, designer and marketer blur uneasily and then evaporate
altogether.
Our new reality is one where the only constant is rapid change and the road to
success is built on three principles:
Get close to your customer
Brand is everything
Technology is part of the problem
We no longer need ICT professionals with time-served apprenticeships in
specific languages and platforms, instead we need flexible, highly talented
individuals who can pick up the next hot tool and make it work. In the new,
networked economy the value proposition changes for both developers and
business, as speed to market becomes crucial and hesitation risks letting someone
else into a valuable market space. But remember that in this age your old
competitors might not be your biggest threat: start-up’s built from the ground up
to function in the new economy can come at established organisations
unexpectedly and the language of the new economy is one of cooperation,
integration and intermediation6.
The project deliverable must be what the customer wants, not what the business,
or worse still, the technologist, thinks the customer needs. Customers are people,
not demographics or abstract concepts. To deal with this, teams in the post-
revolutionary world must be cross functional and non-hierarchical, projects
6 Evans, P., & Wurster, T. (2000). Blown to bits: How the new economics of information transforms strategy. Boston, MA: Harvard
Business School.
CONFIDENTIAL
Revision 2.00 3

9. require input and skills from many areas, from pure technology through to
business analysis, process modelling and marketing. Teams are no longer tightly
bound units but flexible, adaptive and organic, they are made up of core skills
that can be supplemented by additional resources or specialists as required.
It is imperative that an Internet presence supports and accurately conveys the
organisations brand. This is of vital importance yet all to often website
development is left to ICT professionals who are unfamiliar with the issues
involved in delivering customer-facing applications. On the Internet your brand
is vital simply because of the vastness of cyberspace. It is very easy for your
brand to get lost in the enormity of the Internet and you need to ensure people
know you exist. Evidence is mounting that the best way to do this is actually
through off-web media and that online advertising and in particular banner
advertisements are not particular effective. Ironically, an increasing reliance on
traditional media to promote the online business channel increases the
importance of synergy between traditional and online branding.
The sheer pace of change can lead us to focus on technology but unfortunately
this means taking our eyes off the customer. We are here to solve business
problems and technology must remain an enabler in this process. When the
customer is ignored and technologists take over, technology can become part of
the problem. In all but exceptional circumstances, the customer does not care
about the technology you use, so long as it works and works in a way that works
for them. So, the angst in the backroom over a choice of Active Server Pages,
Cold Fusion or Java Server Pages is more often than not a waste of time and
energy. The real decision is on the overall platform that delivers the best solution
to the customer, and this includes seamless integration with internal legacy
systems and third parties. Trying to offer the latest technology just for the sake of
it is a recipe for failure.
The network is the business but there is more to delivering a service than the
network. An organisation needs to be fully cognisant of what technologies their
customers support and find acceptable, applicable and enjoyable. It is now
imperative that we understand the customer’s relationship with that network in
order to optimise the delivery of products and services.
CONFIDENTIAL
Revision 2.00 4

10. Information Architecture
A methodology derived from the principles of information architecture differs
fundamentally from traditional models of systems development; this is a
methodology focused on delivering what the customer wants. Traditional
development models focus on a lifecycle of months and years, where toolsets are
established and team members experienced. Traditional systems development
methodologies are about supporting business process. Information architecture
works well where project lifecycles are measured in weeks and months, where
toolsets are constantly changing and your most valuable staff will be the ones
who can adapt quickly. This is a world where systems development no longer
simply supports the business process but is an active ingredient in enabling
change. In a world filled with media, technologies and skills alien to traditional
ICT projects information architecture can provide an appropriate framework.
Whilst this approach has many similarities with prototyping methodologies,
information architecture goes beyond prototyping because of its focus on the
appropriate representation and management of information as well as the system
functionality associated with it.
Developing successful software applications for the Internet means developing
them quickly and deploying them fast. Fortunately, the environment that we
now work in allows us to achieve this by supporting rapid, dynamic projects
within an iterative development framework. Products are developed quickly and
delivered frequently and as a result the way business is transacted changes.
Product life expectancy is reduced as rapid development allows for incremental
releases and easy, centralised upgrade paths. And so it becomes an inherent
philosophy in the organisation that eighty percent of the business need must be
delivered with only twenty percent of the effort, in other words we are no longer
aiming for perfection but measured and measurable success.
Although we have now broken free of the logistical nightmares associated with
rolling out traditional distributed applications or mainframe systems, this has led
to a tendency amongst the developer community to mentally position Internet
development at the informal end of the methodology continuum. In many ways
this can be seen as a valid approach, since traditional methodologies add a level
of complexity and bureaucracy that is simply inappropriate and would stifle
creativity in the dynamic world of the Internet. However, this is a dangerous
approach, our Internet-based applications are often customer-facing, the first
CONFIDENTIAL
Revision 2.00 5

11. point of contact a potential customer might have with the business and,
increasingly, these systems are fully integrated into the corporate legacy
environment and running mission critical applications. There is simply no longer
any excuse for lax development attitudes in this field. What industry needs is
staff capable of delivering in this new, rapid fire, multidisciplinary environment,
of delivering excellence on a clear process that ensures quality is part of the
equation from day one. What we need are methodologies that are suitable for
delivering high-quality fast-turnaround Internet applications that perform.
It is imperative for designers and developers in the online world to remain
nimble-footed and reactive to customer wants, without being weighed down in a
torrent of formal specifications and change control processes. An approach to
Internet-based development based on information architecture, with its focus on
the user not the technology, offers an appropriate model for project managers,
web designers and software developers. It is an attempt to develop a simple yet
highly effective methodology where the project team is able to maintain design
integrity and hence minimises the flaws in the design process and human errors
during the specification, development and deployment processes. It also
attempts to address the often-overlooked issues of re-usability and
maintainability, aiming to introduce best practices that reduce development cost
and effort and recognising that a component-based architecture minimises
development cost and risk.
Information architecture, with its focus on how we organise, relate and represent
information is appropriate to the online medium and can be an important
building block in successful web site design. The starting point in an information
architecture-based design process is defining the audience (internal and external,
direct and indirect), what relationships exist and what it is this audience wishes
to do. It is the audience map and the user-scenarios that the architect creates that
will drive the development of the application, feeding into the definition of
functionality. Now that the project team understands who the customer is and
what it is they want to do, the architect can develop an organisational metaphor
that maps the virtual model to the physical organisation, and both functional and
visual metaphors to describe what the site will do and the look and feel and
branding needed to anchor the site appropriately online. Behind this front-facing
activity it is important to create good project processes and so a successful
Internet development methodology must also include project management, risk
management and quality assurance.
CONFIDENTIAL
Revision 2.00 6

12. In the online world, web developers must be user-focused to succeed the
customer-facing applications that we create must enhance existing branding to be
viable. The INSITE information architecture web services methodology from
Wairua Consulting allows organisations, project managers and web developers
to respond creatively, rapidly and with a deep understanding of who the
customer is, leading to the successful of online solutions. Because the Internet is
about delivering the information that your customer wants, when they want it
and how they want it, a flexible user-centric methodology such as INSITE
presents significant advantages over traditional developer-centric and
bureaucratic development methodologies.
How to use this Document
This document describes the full INSITE methodology, however it is not
anticipated that you will require the full methodology for all of your projects.
Ideally, a subset of the methodology can be used and this subset will be relative
to the size and complexity of the project and appropriate to your own toolsets
and organizational culture. Therefore, it is recommended that you use this
document as a detailed reference but not as an exhaustive guide to the exact
process to be followed.
CONFIDENTIAL
Revision 2.00 7

13. Methodology Overview
The INSITE Information Architecture Web Services Methodology is a four-stage
rapid application development (RAD) methodology for delivering internet-based
applications and services that is flexible, forward looking and cognisant of the
need to interface with legacy applications within an organisation.
The term “Internet-based” is used throughout this document to describe internal
(intranet) or external (Internet or extranet) applications and interfaces that use an
IP-based network as part of a delivery mechanism or channel. This includes web-
based applications, such as HTML, ASP, JSP or ColdFusion, thin client
applications, such as Java, and data-only interfaces and conduits, such as XML,
with third party applications (regardless of their nature of deployment).
Underpinning the success of this methodology are the principles of:
Customer Focus (user-centric model)
High-level specification and modelling
Iterative processes
Re-usability and emphasis on components
The four stages of the methodology are:
Figure 1 - Four stages of INSITE
CONFIDENTIAL
Revision 2.00 8

14. Five cross-cross stage processes, existing throughout the project life cycle,
support these stages:
Figure 2 - Cross-stage processes
Scope
INSITE is intended for use in planning, developing and implementing Internet-
based applications, their underlying architecture, platform and components,
interfaces (including middleware) between such applications and to/from legacy
or third party applications.
INSITE covers the development of static web-sites through to complex
transactional Internet applications with many interfaces to external and/or legacy
systems. However, to achieve this, the methodology is intended to be applied
with flexibility, using only the parts that are relevant to the current project and
environment.
Exclusions
The methodology does not define standards, guidelines or processes with regard
to the analysis, specification, development or modification of existing legacy or
third party applications, their architecture, platform and components. INSITE is
not toolset or platform specific and is designed to provide best-practice processes
regardless of the environment you choose.
CONFIDENTIAL
Revision 2.00 9

15. Define Design Develop Deploy
improve
Information
Post Implementation
Project Definition Architecture Development Testing ok Deploy
Review
Document
Goal Goals and Objectives System test Install
Objectives Functional Requirements Integration test Support
Scope Architecture User Acceptance test Maintain
feed into IAD
Exclusions Client Interface
Architecture Close-out
Risk
Procure
Alternatively (for larger Install
projects) Data Model Configure
Project Proposal Data definitions
Translations
Document Type Definition (DTD)
Project Charter
Workflow
Cross Stage
Project Management
Project Plan Project Plan Project Plan
(High Level) (Detailed) (Update against actual)
Change Management
Risk Management
Quality Assurance
Document Management
Copyright © 2000 Wairua Consulting.
Figure 3 - INSITE Process Model
CONFIDENTIAL
Revision 2.00 1
0

16. Team Building
The heart of any successful project is a team that is both motivated and resourced
to succeed. In the online world, two projects are seldom the same and the ideal
team is one that brings together the right skills at the right time and can learn
new skills together as they progress.
Roles and responsibilities will vary depending on the toolset and architecture
used, the size of the project and the culture of the organisation and INSITE makes
no attempt to prescribe an architecture or toolset to use but attempts to remain
flexible with the best of breed products for the environment that you are in.
There are a number of standard roles and responsibilities that will generally be
expected to exist within a project. This is not an exhaustive list, nor is it expected
that this list should be rigidly adhered to, since the aim of INSITE is to enhance a
team that is co-operative and focused on mutually agreed goals, rather than
prescribe what the team should look like. For example:
Figure 4 - Roles and responsibilities
CONFIDENTIAL
Revision 2.00 11

17. Where:
Key Role
A Project Management
B Business requirements
C Process modelling/workflow
D Information architecture
E Data modelling
F Development
G Testing
H Deployment
I Maintenance
Figure 5 - Definition of roles
Client Involvement
Without the client there’s no project and since eBusiness is about getting close to
the customer (which in this case is both your client and their client!) then it
makes sense that the relationship with your client and their staff is going to be
critical to the success of the project.
Client involvement can occur at many levels, including:
Steering group
This is usual the most senior committee within a project and will consist of
project sponsors within the client organization as well as the Project Manager
and other project staff as required. This should be the group of people that can
make decision, sign off on budgets, specifications and changes.
User and Customer involvement
Talking with the users and other related people within the client firm is
important for two reasons. Firstly, it will help you to understand the business
problems that you are there to solve and, secondly, as you get to know people
and discuss their work with them, you start to gain an understanding for the
culture, politics and nuances of that organization. When you’re working on
eBusiness solutions, it’s not enough to simply talk to your client’s staff, you also
need to go out and talk to existing or potential customers.
This process of discussing the requirements with the potential end customer can
be a scary one for your client, particularly if they don’t have a close relationship
CONFIDENTIAL
Revision 2.00 12

18. with their customers. However it is vital that you do this, after all who
understands your requirements best, you or your own suppliers?
Managing changes and feedback
One historical problem with any development approach that uses prototyping
and on lots of client involvement is that the client will invariably change their
mind, come up with new ideas and generally cause the project team major
headaches. This is normal and cannot be avoided, however it can be managed
and the reason changes and variations become a problem is because the project
isn’t structured to cope. If you have a clearly defined process of change
management and a clear specification, then it becomes a simple matter to decide
what changes are accepted and which are either postponed to “stage 2” or
rejected completely. One of the benefits of INSITE is that it provides a framework
for managing the team/customer interface and this issue will be addressed
throughout this document.
In the next four sections, each of the project stages is defined in detail and their
constituent parts explained.
CONFIDENTIAL
Revision 2.00 13

19. Stage 1 — Define
Phase one of the project is to define the project requirements and boundaries, in
terms of the business7. This is communicated through the Project Definition
document. Which will contain the following information:
Clearly Defined Goal
The project goal describes the overall project aim clearly and succinctly, such as
“to enable our customers to do business with us electronically so that it saves
them time and money.”
Define the Objectives
The project objectives describe in more detail what the desired project outcomes
are, in the context of the overall project goal. This is normally expressed in terms
of a deliverable, or deliverables, to the business or to the customer, for example:
To develop an internet-based interface for remote external users to submit
quotations.
Ensure the Project is Scoped
The scope clearly defines the project boundaries, in other words, what is
included within the context of this project. It is important that the scope is clearly
defined to ensure that a clear focus on a deliverable is achieved.
Define any Exclusions
Clearly define exclusions and other elements that are outside the scope of the
project.
Document all Assumptions
Document all the assumptions that have been made in producing the plan, this
document and in terms of the overall project.
7 This document should not address any technology issues except at a high level and then only where it is the technology that
is the business enabler.
CONFIDENTIAL
Revision 2.00 14

20. Record Measurable Success Criteria
Define specific, tangible factors that can be used to measure the success of the
project. Examples include:
Delivery
Performance and Reliability
Security
User Response and Uptake
Cost reduction
Perform Risk Analysis
Risk Management is not a static function, it flows through the entire project life
cycle as issues arise and problems occur. Further information on the approach to
Risk Management to be used the project should be provided in the Project
Charter.
Generic Risk Checklist
Use this generic model to give an overall picture of the project’s risk factors. It
can be used to compare the relative risks to an organisation of a number of
different projects.
Low (Yes) RISK (No) High
0 1 2 3 4 5 6 7 8 9
Inherent Risks
Project Objectives
Is the project small?
Is the project of minor importance to the
business?
Is the project functionally straightforward?
Are several parties able to define the
requirements?
Is the subject area well documented?
Are preceding projects well documented?
User Organisation
Does the project maintain existing user
procedures?
Is other organisational change unlikely during
the project?
Are the users grouped in one location?
Technology
Is tried hardware being used?
Is tried software being used?
CONFIDENTIAL
Revision 2.00 15

21. Low (Yes) RISK (No) High
0 1 2 3 4 5 6 7 8 9
Can custom programming being avoided?
Is the project technically straightforward?
Is the quality of existing data good?
Acquired Risks
Scope and Approach
Is the project scope well defined and agreed?
Is the project approach well defined and
agreed?
Project Organisation
Are people’s roles clearly defined?
Are users committed to the project?
Are staff able to commit sufficient time to the
project?
Are the required skills available?
Does backup exist for all members of the
project?
Are political and personal relationships good?
Is the project independent of third parties?
Can the design be achieved by a small group?
Can a “Big Bang” implementation be avoided?
Experience, Training and Support
Does the IT team know the technology?
Do the users know the technology?
Is the technology well supported?
Figure 6 - Generic risk Checklist
Specific Project Risks
Identify specific risks that have been identified with regard to this project in the
following format:
Issue Probability Impact Schedule8 Issue/Action
Direct
Indirect
Figure 7 - Specific project risk checklist outline
See Risk Management on page 46 for more details.
Create a Work Breakdown Structure
Include a work breakdown structure (WBS), preferably in a graphical format.
8 The potential impact on the project schedule.
CONFIDENTIAL
Revision 2.00 16

22. Tasks and Milestones
This tabular work breakdown structure should go to a deeper level and include
project milestones (show in italics) that were omitted from the graphical
representation. It should be supported by a Gantt Chart as an appendix.
Milestones will typically be points in the project that require sign-off to indicate
acceptance and before continuing to the next task, for example:
Definition Sign-off
Design sign-off
Testing Sign-off
Go Live
Full Launch
Skills/Resources
Identified skills and resources required for the project. Ensure that this definition
includes skills and experience levels, the duration and quantity required.
Document the Deliverables
Describe the project deliverables, including documentation and services, such as
training.
Create a Project Plan
Create a project plan showing the major deliverables, the resources required and
the time/cost estimates. This plan forms an appendix to the Project Definition and
will be expanded upon to include detailed tasks in Stage 2.
See Project Management on page 42 for more details.
CONFIDENTIAL
Revision 2.00 17

23. Stage 2 — Design
The design stage enables rapid development of internet-based applications by
clearly identifying the business issues and requirements and then documenting
the technology platform to be used. The aim of this stage is to produce a high
level understanding of the issues and then to develop a road map toward the
solution. Unlike traditional waterfall methodologies, it is not the intention to
produce a highly detailed specification, which is then strictly adhered to. Rather
development takes place iteratively using an evolving prototype where the end
users are as involved in the process as the designer. Having said this, it is
important that sufficient analysis has been undertaken to ensure that workflow,
data mapping requirements and table structures are identified.
Information Architecture Document
Information Architecture describes the business requirements and the business
process and technology changes that are required to achieve that outcome. This is
done by way of the Information Architecture Document (IAD).
The purpose of the IAD is to ensure that:
the business processes are fully defined
the scope of the project is clearly defined and any exclusions have been
documented
the technology/human boundaries are defined and understood
opportunities and threats are identified
Information Architecture brings together four key areas of a successful Internet
project: Internet; IT; user interface design; marketing. The Information
Architecture Document contains the following sections:
Introduction
Goals and Objectives
Goals
Objectives
Scope
Exclusions
CONFIDENTIAL
Revision 2.00 18

24. Audience
Audience
Scenarios
Relationship matrix
Use cases
Market environment
Functional Requirements
Organisational metaphors
Functional metaphors
Visual metaphors
Business process
Business rules
Functionality Matrix
Content
Architecture
Platforms
Interfaces
Application Development
Client Interface
Navigation
Visual Design
Not every section will be appropriate for every project and it might be necessary
to introduce new sections or sub-sections to meet specific requirements. This
document is intended as a road map, not a detailed and exhaustive specification.
These sections are explained below:
Goal and Objectives
This effectively summarise what is contained in either the Project Definition or
the Project Proposal, however, be aware that subtle (or even major) changes
could have occurred during the definition process. The goals and objectives
section lays out the fundamental requirements for the project under
development. It is important here to outline the key business drivers that support
the project in terms of:
CONFIDENTIAL
Revision 2.00 19

25. Goal
This is the project’s “mission statement” — a short paragraph that encapsulates
what the project is about. This might be: “To provide the widest range of New
Zealand literature online, at low cost to as wide an audience as possible”
Objectives
The objectives are usually a set of bullet points that expand on the goal. For
example:
To carry the widest range of NZ published books anywhere.
To increase the sales of NZ literature outside of New Zealand.
To support local writers and publishers.
To make buying easy.
To provide a range of flexible ordering options.
To build a community of interested people and become the meeting place for
that community.
Scope
Define the scope for the project so that it is unambiguous.
Exclusions
Clearly define any exclusions, such as changes to legacy systems.
Audience
Describe and group the target audience or audiences and any other relevant
demographics for this product. This information is vital since who your audience
is will strongly determine the structure, appearance and culture of your site.
Identify your audience in terms of a direct, indirect or remote relationship with
the product. You can also identify a wider societal audience who, whilst not
directly involved as primary or secondary users of the product, might have
issues or influence over it. For example, if you were designing a drive through
service for a restaurant, your audience might look like this:
Direct Counter sales persons
Driver
Indirect Car passengers
Kitchen staff
Remote Street cleaners
CONFIDENTIAL
Revision 2.00 20

26. Societal Neighbours
Local community
This can also be represented graphically, which has the advantage of allowing
you to define relationships between different audience groups:
Figure 8 - Audience map
When creating your audience list, brainstorm without analysing the list. Assign
categories and eliminate unnecessary detail later.
Scenarios
Scenarios describe realistic situations for a range of sample users (rather than
simply stating the requirements). Choose a range of sample users from the
audience groups defined above and describe the way you expect them to interact
with the product, what they are likely to be interested in, how they might expect
to find information/products/services and what would make them return.
Don’t just select direct audiences, try and create a broad range of scenarios. The
ultimate aim is to look at the product from the perspective of the end customer.
If you are unfamiliar with scenario development then these steps should assist
you (once you are familiar with the process, you will find that much of this
becomes automatic).
CONFIDENTIAL
Revision 2.00 21

27. Step 1 – Select role-play Be specific, such as “family ordering food for a picnic”.
Step 2 – Create a scenario Develop a complete scenario from beginning to end for
the selected role-play.
Step 3 – Context Decide on a context for the scenario, such as “one child
under 10 and one under 5” or “a hot, sunny afternoon”.
Step 4 – Create “what ifs” Create a list of possible situations that could arise in the
scenario, for example their first order preference is not
available or there is a wait on one of the orders.
Step 5 – Profile customer Determine what information you need to know about the
customer.
Step 6 – Condense Steps 1 through 5 can be done on a large piece of paper or
a whiteboard, once complete and you are satisfied with
them, condense the results down into a single paragraph
that captures the salient points. You might also like to add
a table showing the information to capture.
The initial output from this process tends to be a list, which, for the example
above, might look like this:
Vehicle Driver Does not want to leave the car.
Wants minimum disruption or distraction for children.
Wants to order, pay and collect in a single location.
Has no cash.
Wants food well wrapped so that it doesn’t spill or mark in the
car
In Step 6, you combine the key points from your list into a single scenario, which
takes the form a story:
Vehicle driver
Wants to be able to place an order, pay and collect in a single location, without leaving the
vehicle. They have no cash, so you (the vendor) must be able to accept Eftpos. Finally, the vehicle
driver does not want food and drinks spilt over their upholstery or greasy finger marks on the
trim.
Information required: order (items and quantity), payment method.
The story format is used because it lacks the implied priorities of a list and
because a story is a powerful way of conveying meaning. These stories can be the
combination of a number of scenarios of potential audience members. As you can
see from the example above, this process also allows you to determine what
information is required for this process to be carried out.
CONFIDENTIAL
Revision 2.00 22

28. Relationship Matrix
Now that you understand who your audience is, the next step is to map this
audience to the activities that they are likely to perform on the proposed site. The
purpose of this is to identify user intentionality: mapping business objectives to
the audience requirements and defining the path to best achieve this. This will
assist you in defining the functionality of the site and in understanding potential
options for site navigation.
AUDIENCE
ACTIVITY Visitor Customer
Gather information Product information
Whitepapers
Reviews
Search
Order product Availability Delivery status
Price Return purchase
Delivery
Support Service levels Existing products
Legacy
FAQ
Figure 9 - Relationship matrix
Use Case
Use Case diagrams9 are a simple and effective way to graphically describe the
boundaries and interactions for the scenarios that you have identified and can be
used to identify relationships between audience members. For example:
Drive-thru ordering
Place order
Pay for order
Driver Counter staff
Fulfil order
Deliver order
Figure 10 – Use case example
9 For information about Jacobson Use Cases, see Object-Oriented Software Engineering, by I. Jacobson (Reading, MA:
Addison-Wesley, 1992).
CONFIDENTIAL
Revision 2.00 23

29. Market Environment
Provide background information on the market conditions and competitive
issues that relate to this product. This section is generic to the marketplace.
Where there is a strong internal focus, describe the potential business
improvement and process improvement opportunities that can be achieved
through this product.
Competitive Analysis
Provide an analysis of a number of competitors in this market. Normally, this
would be competing online organisations but that is not always the case and this
could include competition in traditional “bricks and mortar” markets.
Competitive analysis is used to identify points of difference and opportunities, as
well as to support industry/market norms and expectations that have been
identified in the Market Environment section above. Highlight what works and
what does not work for a competitor and attempt to describe the culture.
Market Environment and Competitive Analysis are similar (although the latter is
more specific and detailed), because of this you might find that you only require one of
these two sections, depending on the nature of your project.
Functional Requirements
This section is used to define the functional requirements for the product. It is
not, however, a traditional Functional Specification since the level of detail
required for an IAD is far less, placing a much greater emphasis on prototyping
and evolutionary product development.
Organisational Metaphors
This is mapping the physical organisation to the virtual. However, avoid the
temptation to merely recreate the org chart online as this will often fail. It is
important to understand how the customer would expect to view the
organisation and represent this, not how the organisation views itself.
Functional Metaphors
The functional metaphor relates to what you actually intend to do. This could be
purchase a product, order catalogues or find product information sheets. It is
how you translate physical activities into online actions.
CONFIDENTIAL
Revision 2.00 24

30. Visual Metaphors
The visual metaphors are the underlying look and feel of your site; the images
used to brand the corporate image online, define product sets and provide
navigation. Good visual metaphors are simple and mean something to the
visitor.
Business Process
This section describes the business processes that relate to this product. Ensure
that you clearly establish whether the process is “as is” or “to be” — since
electronic commerce is about changing business process, it is unlikely that the
process will remain the same after implementation.
Ideally, the business process should be shown diagrammatically.
Business Rules
Clearly describe any business/processing rules that apply to the affected
processes. This section should also address any legislative regulations that might
affect the product, such as minimum age or tax regulations.
Site Structure
Developing a site structure listing invariably involves a brainstorming session
where team members can start to create the structure of the site. This might be on
a white board or by using PostIt™ notes (they have the advantage of being easily
movable!). The aim is to develop a directory and page structure that reflects the
organizational and functional metaphors with consideration to internal and
external links, usability and process flow.
A structural listing can be either textual:
Index page: www.house2home.com.au
Shop Floor
Decorating
Interiors
Garden
Timber
Trade
…
Shopping cart
Checkout
Order management
Services
CONFIDENTIAL
Revision 2.00 25

31. House2Home Professionals
Architects
Builders
Etc…
Or graphical:
House2Home
www.house2home.co.nz
www.house2home.com.au
Shop floor Services Information About Contact
Product
catalogue and
online sales
Decorating H2H Professionals Newsletters History
Architects
Interiors Information sheets People
Interior designers
Landscapers Q&A Branches
Outdoor
Builders
Garden Plumbers
Glazier
Timber
H2H Packages
Trade
Trade
Home handyman
MyHouse Projects
Shopping cart
Checkout
Order
Figure 11 - Graphical site structure
Content Definition
Having defined the structure of the site, start to place more detail on each of the
sections. Define what each section will include, how it is to be maintained, who
has access and how often it will change. For example, here is an extract from an
IAD discussing the requirement for updated news content on the site:
News Stories
To make the site interesting and encourage return visits, the site must be kept up to date
with relevant news stories. The level of information published needs to enhance the visitor
experience and encourage them at the time or in the future to visit other parts of the site. It is
recommended that [company] publish information that is in the public domain or about to
become public and that enhances the reputation of [the company] in terms of implying a
level of expertise in that area.
The News section will contain main headlines (last 30 days) and an archive of previously
published stories. The main section should automatically display the latest headlines and
provide access to an archive page and search facility. A priority in the site design will be
CONFIDENTIAL
Revision 2.00 26

32. ensuring that stories can be added quickly without the need for HTML coding or site
uploading and that existing stories can be edited. It will also be a requirement to upload and
accurately place graphics with articles.
Functionality Matrix
This visually represents the relationship between audience activity and the
functional areas you defined above. The table below is used to indicate the
closeness of the relationship: a value of 1 means that the user must be able to
directly access this functional area when performing the said activity, 2 means
indirectly and 0 means there is no requirement.
FUNCTIONAL AREA
ACTIVITY Products Publications Ordering Support Search
Product 1 2 1 1 2
information
Whitepapers 2 1 2 2 2
Ordering 2 3 1 2 2
Support 2 2 2 1 2
Search 1 1 1 1 1
Figure 12 - Functionality Matrix
The above table shows that when a visitor is in the “Products” area, they must be
able to immediately access product information and that more detailed
information such as a whitepaper or ordering the product must be only a single
click away.
Architecture
Up until this point, the IAD has a strong business focus. From this point forward,
the focus shifts to defining the technology and the environment. For a large
project, this could involve creating two documents, however, ideally a single
document is retained for to present a complete picture to all parties.
Where the previous sections defined the reasoning behind the site and the
appearance of it, this section defines the physical site structure and the
technology required to support the site.
Include a systems architecture diagram here.
Platform
Describe the platform or platforms identified in the system architecture diagram
above. These could include:
CONFIDENTIAL
Revision 2.00 27

33. Application Server
Client (such as minimum browser feature set etc)
Database Server
Legacy Systems
Mail server
Middleware
Web server (including clustering, load balancing, redundancy etc)
Legacy Systems
Modification of legacy systems is usually outside the scope of an INSITE project,
however, the native environment should be described here for completeness.
Platform 1:n
Provide the following information (as appropriate and relevant) for each
platform shown in the architecture diagram:
Availability and Reliability
Connectivity
Extensibility and Flexibility
Maintainability
Performance
Scalability
Security
Systems Management
Network
Describe the network components identified on the System Architecture Diagram
above:
Standards and Protocols
Equipment (such as firewalls, routers etc)
Interfaces
Define all of the system interfaces10 that exist and for each describe:
The interfaces between specific systems.
10 This could include manual interfaces if appropriate.
CONFIDENTIAL
Revision 2.00 28

34. The interfacing standard and protocols to be used.
Interfaces that exist could include:
Application Server to Client
Application Server to Database Server
Legacy Systems to Middleware
Middleware to Application Server
Application Development
Define the environment(s) for application development. This should include one
section for each environment and should link this environment to platform(s)
and/or interface(s). Examples of application development environments could
include:
Page design tools
Integrated Development Environments (IDE’s)
Databases
AppDev Environment 1:n
For each environment, describe:
Platform(s)
Tools
Components
Standards
Client Interface
This section defines the boundaries, visual design and workflow and the image
sets that are to be used for the client-side of the project.
Navigation
Site Navigation
This describes navigation within the site as a whole and includes off-site linking.
This section needs to consider entry points, framing, top level menus, sub-section
navigation and site maps.
CONFIDENTIAL
Revision 2.00 29

35. Local Navigation
Local navigation describes how a user might navigate within a single section,
page or multi-part document. This might include page forward/back control,
internal hyperlinks and menus and returning to the top of a document.
Visual Design
The Visual Design structure defines the interface rules. This section should define
the standard typefaces, styles, sizes and colours. It also defines basic page and
graphics colours and styles.
Layout Grid
This section should include a layout grid demonstrating the graphical and textual
elements of all standard pages (if there are multiple page styles, develop one
layout grid per style).
Figure 13 - Page layout grid
Formatting Rules
Define any specific formatting rules for text and graphical elements, for example
Tables use <P> text, always align top/left, 0 Border.
CONFIDENTIAL
Revision 2.00 30

36. Graphics 0 Border , alt tag must be defined for all elements except spacers.
Graphical Elements
Define a list of all standard images that are to be used describing what they mean
and when they are to be used:
Usage Front page logo; all
documentation (including
rate charts and statements).
Hyperlink /index.html
image/logo_lg.jpg (300 x 80)
Usage Page heading on all pages.
Hyperlink /index.html
image/logo_sml.jpg (175 x 35)
Usage Navigate back to previous
page.
image/nav_back.jpg (30 x 30) Hyperlink javascript:history.back()
Figure 14 – table of graphical elements
Project Structure
Include in your IAD a definition of the project boundaries, timeframe and
resource requirements, including:
Estimate
Define the time and cost estimate. It can be useful to show this as a high, low and
mean by tasks, grouped according to functional areas, although this could
depend on the project and the client’s expectations/practices.
Timeline
Define start, milestones and finish dates, based on the elements in the project
time and cost estimate. Once a baseline has been established progress and
variations should be managed against this.
This should take the high level project plan developed in stage 1 and refine it, adding
more detail and reducing contingency.
CONFIDENTIAL
Revision 2.00 31

37. Resources
Identify resources required in terms of numbers, skill set and timeframes.
Role Timeframe Number Skills
Information Architect 1 month from start 1 INSITE, RUP
HTML developer 4 months 2 HTML layout and design
Macromedia Dreamweaver
Macromedia Fireworks
Graphic artist 2 months 1 Macromedia Fireworks
Adobe Photoshop
ASP developer 2 months 1 Significant ASP experience
Macromedia Drumbeat 2000
Junior ASP 4 months 1 Some ASP knowledge
Developer
Figure 15 - Resource requirements
Tools for Developing your IAD
For the following tools and techniques can be useful when you are developing
and IAD:
Workshops and Interviews
Where your customer base is diverse, it can be useful to conduct review sessions
or one-on-one interviews with a range of users. Before carrying out such sessions,
it is important that you clearly understand the objectives and have sufficient
information to present to the participants to stimulate discussion. Since, a key
objective of these workshops is to understand what the customer wants, an
appropriate use of the results is the generation of scenarios.
Data Modelling
Modelling structures for database, XML and other interface formats can take the
form of:
Data definition
Document Type Definition
Translation
The resultant Data Model should be included as an appendix in the IAD.
CONFIDENTIAL
Revision 2.00 32

38. Workflow
Workflow can be described either diagrammatically (with use case or swim lane
diagrams) or textually in the form of a table.
The resultant Workflow should be included as an appendix in the IAD.
External Specifications
An external specification is any specification that defines changes that are
required to an application or platform that is outside the scope of this
methodology.
For example, changes to legacy system functionality could be required as part of
the greater scope of a specific phase or project, however, such changes must
follow their own methodology and process, not this one.
Where such specifications do exist, they should be included as an appendix in the
IAD to ensure that there is sufficient visibility of the wider context.
CONFIDENTIAL
Revision 2.00 33

39. Stage 3 — Develop
Development takes an iterative, prototype approach, where the application is
developed based on the high level definition contained in the IAD and is
regularly reviewed by the target users to assess fit to requirements.
Application Paradigm
Such as:
Thin client application
Web browser
Thick client
Data conduit
Selecting Development Tools
An appropriate business case should be created for each product required. The
choice of development tools will be based on the following selection criteria:
Fit to existing/proposed architecture
Best of breed product
Team experience with product/availability of training
Cost
Version Control
The purpose of version control at the development level is to ensure that:
Development is taking place from a known and controlled starting point.
That starting point can be returned to or compared against.
Copies of the system in testing can be identified and errors attributed to a
particular version.
There is a clear and concise record of what changes have been made, by
whom and when they were released.
CONFIDENTIAL
Revision 2.00 34

40. Version control will be dependent on the platform and tools selected.
Version Numbering
All system versions will use a three part version numbering convention:
major.minor.maintenance (n.nn.nn)
For example,
Version 1.02.01
The three parts of the version number are defined as follows:
Major Means a significant upgrade to the application where
functionality has been significantly altered. Prior to full release
(see definition below), the major version of the system will be 011,
when it is first released, the application will be version 1.00.00.
Note that when a major release is issued the minor and
maintenance release numbers are reset to 0, for example Version
1.04.01 becomes Version 2.00.00.
Minor When modifications are made to existing functionality and new
minor functionality is added, the minor release number changes
and the maintenance release number is reset to 0. For example
from 1.00.02 to 1.01.00.
Maintenance The final number in the version series indicates a maintenance
release only.
Release Levels
There are three release levels for applications, indicating the state of
completeness and potential audience:
Alpha Effectively pre-release, this is the earliest version of the
application and likely to be used for prototyping purposes only.
Alpha software is not complete, not tested and unsuitable for
unsupervised use.
Beta This is the controlled release phase where development is
fundamentally complete and some system testing has been
carried out. The beta version will be provided to selected users
for the purposes of User Acceptance Testing (UAT) (see page 36).
It is important to clearly identify whether it is appropriate for a
11 Version 0.xx.yy is effectively used to indicate alpha or beta release status.
CONFIDENTIAL
Revision 2.00 35

41. beta application to be used in a live environment, operated in
parallel or used solely in a user testing environment.
Full Release Full release means the application has been released into a live
production environment and changes are now treated as
maintenance (see Maintenance Releases on page 40).
Architecture
The systems architecture should be defined in a separate Systems Architecture
document. The systems architecture should be developed to conform with:
Existing organisational standards
Overall strategic direction for IT within the organisation
Organisational standards for eCommerce
Industry best practice and best of breed
A business case should be prepared for all hardware and software expenditure as
per organisational procedure. The detail of this will depend on the strategic
nature (or variance from agreed strategy) and cost of the equipment.
Testing
There are three types of testing that must be carried out:
Unit Testing Forms a part of the development process and is inherent in the
role of the developer.
System Testing Is carried out internally within the project team to ensure that the
system is stable and operates correctly within the team’s context
of the requirement.
User Acceptance Testing Is where the application is formerly tested by the end user in a
realistic work setting. The purpose of UAT is to ensure that the
business functionality is correct.
User Acceptance Testing (UAT)
UAT puts the developed application through rigorous procedures designed to
replicate the live operation of the system and to verify that all components
accurately perform the required business and control functions. All conditions
and exceptions should be defined and tested for all known operating
environments, including the simulation of any manual procedures.
CONFIDENTIAL
Revision 2.00 36

42. Prior to commencing UAT, it is important to formally define:
What testing is to be carried out
The environment under which testing is to be carried out
What constitutes acceptance of the application for release
The resources (people and equipment) required
Secondly, a Test Package is created that contains:
A definition of all the tests to be carried out, describing the functional and
technical operation of the application.
Test Cycle
As Test Scripts are executed, errors and exceptions can be recorded on the form.
All errors are then entered into the Fault Tracking System (see Error Tracking and
Logging on Page 39).
Figure 16 - Test cycle
Review Mechanism
The results of UAT Test Scripts should be reviewed on a regular basis. This
review will determine the frequency and nature of errors being logged. Where
testing errors are found and the developer fails to rectify satisfactorily, these
should be referred to the Project Manager for review.
CONFIDENTIAL
Revision 2.00 37