web project management best practice guidelines

Web Project Management

The practices behind successful web projects

E-consultancy, May 2007

Lead author: Sonia KayContributing Editors: Craig Hanna and Chris Lake

Copyright © E-consultancy.com ltd 2006 1

Table of contents

1. Executive Summary............................................................................3

1.1. Research aims.....................................................................................31.2. Top 10 key findings and recomendations............................................3

2. Introduction................................................................................7

2.1. About this report.................................................................................72.2. Who is this report for?.........................................................................72.3. About E-consultancy............................................................................82.4. What is Web Project Management?.....................................................9

3. Research aim.............................................................................11

4. Methodology..............................................................................12

4.1. Sample..............................................................................................124.2. Questions..........................................................................................124.3. Analysis.............................................................................................14

5. Findings and Recommendations...............................................15

5.1. The differences between web projects and other projects.................155.2. Biggest challenges facing web project managers..............................165.3. Key drivers of success.......................................................................185.4. A few words about agencies and consultancies.................................275.5. Building the right environment for success.......................................315.6. Using the right methods and processes.............................................485.7. Small projects need structure too......................................................675.8. The essential project managers toolkit..............................................71

6. Helpful resources......................................................................72

7. References.................................................................................72

8. Appendix 1 - The state of the nation........................................73

8.1. Quantitative research highlights.......................................................738.2. Quantitative research results in full..................................................74

9. Appendix 2 – Interview Script...................................................81

10. Appendix 3 – Questions used in online survey.........................82

11. Appendix 4 – Example of in-house adaptation of Prince...................88


1. Executive Summary

1.1. Research aims

The purpose of this research is to fill the information gap around web project management by learning from the experiences of organisations who are already out there managing web projects.

We’ve put this report together on the back of a combination of in-depth interviews and quantitative research.

Specifically this research will…

Discover what makes some organisations and projects more successful at web projects than others;

Show what methodologies, tools and techniques are working, and which one’s aren’t;

Help you evaluate your own situation and work out the best approach to move forward.

1.2. Top 10 key findings and recomendations

1. Nearly half of all respondents do not have a structured approach to managing their web projects.

Nearly half of all respondents (45.5%) do not have a structured approach to managing their web projects. This rises to 67% in the retail industry. This can add up to bad news.

Companies without a structured approach are the least likely to achieve their project goals, least likely to deliver customer satisfaction, are least able to deal with change during the course of the project and are less likely to achieve deadlines, meet budgets and deliver positive ROI.

Lack of processes and skills can mean that…

Teams don’t have visibility of the progress of the project and its’ associated risks and issues;

There isn’t a consistent vision of what the team are trying to deliver;

Estimation of the resources and effort required for the project involved is either poor or non-existent;

Projects are planned in isolation from the rest of the business and are consequently poorly supported.


2. Budgets and deadlines are difficult to control

Nearly 58% of respondents say that their projects always achieve their goals, and yet only 21% of them say they always achieve deadlines.

Only 39% always achieve budget and a positive ROI.

In fact over 8% of respondents never meet their project deadlines and nearly 6% never deliver their projects within budget. Ouch.

3. Web projects are integrated with the rest of the business less than half of the time, and customer satisfaction is hard to achieve

Fewer than half (46%) of respondents work to an annual plan that is aligned with their overall business strategy and only 56% say that they share common goals with the rest of the business.

Whilst nearly 80% say they involve the end customer in gathering requirements for their projects, and 72% involve the customer in testing, only half consistently achieve customer satisfaction with their projects.

4. Teams know that their requirements will change during the course of the project but yet they struggle to deal with it when it actually happens

Nearly 88% of respondents say that they set their requirements knowing that they are flexible to change during the course of the project, yet half of organisations say that changing requirements during the course of their projects is one of the biggest challenges they face.

5. Excellent project management is considered crucial to project success, but project management methods are not valued, and many organisations don’t use qualified project managers.

Good communications and excellent project management are considered to be the two most important factors in determining the success of a web project.

However, 22% of projects are managed by members of the marketing or commercial team rather than a qualified project manager.

Knowledge of specific project management methods is considered to be the least important skill in managing web projects.


6. Web projects are different from other projects

E-consultancy’s research identifies that web projects are different from other projects because of their need to be responsive to…

changing customer requirements and market conditions, the breadth of people and skills involved, the raft of stakeholders, frequently tight or fixed deadlines, a degree of uncertainty, and the need for interaction with real customers.

Therefore web projects require a project management approach that helps with…

Evolving requirements; Putting focus on the end customer; Collaboration between different skill sets; Managing stakeholder expectations.

7. Successful organisations have a structured approach to projects, and know how to apply a range of project management methods which can be tailored to the circumstances

The most successful organisations are able to tailor their approach to the specific circumstances of the project and the organisation they are in, typically using a combination of agile and traditional project management methods.

8. Successful organisations think strategically but deliver tactically

Companies with a more evolved approach to e-commerce embrace flexibility and the ability to deliver iterative, tactical change, because they are operating in highly competitive environments (and as such they need to be able to respond to the rapidly-evolving needs of the customer).

Despite this flexible approach, every project is aligned with the strategy of the overall business, providing consistent direction.


9. In successful organisations collaboration is built into the process from the very top of the organisation down.

The culture and organisational structure of successful companies support effective collaboration between IT, E-commerce, Marketing and Management through;

Shared goals; Sponsorship for projects at a senior level of the organisation; Cross-functional steering groups who prioritise resource and provide

guidance.

10. Excellent project management is as much about managing the environment as it is about managing the process

Successful organisations recognise the importance of having a dedicated project manager. A good project manager brings excellent communication and people skills, managing the environment around the project rather than just following a set of text book processes.

1.3. Creating a model which is predictive of success

A maturity model has been defined to help organisations to benchmark their web project management prowess against other organisations.

It identifies three key groups…

1. Early experimenters – Web not part of business strategy, little/no project management structure or skills

2. Frustrated visionaries – Projects aligned to business strategy, project management style not suited to web

3. Slick professionals – Web projects supported fully by whole company, sophisticated project management

The model is based on a series of behaviours and practices that the research has shown to have the most significant impact on a company’s ability to deliver successful projects.


2. Introduction

2.1. About this report

This report describes the methodology and findings of a significant piece of research conducted into web project management. It makes a number of recommendations regarding web project management best practice on the basis of these findings, and the experiences of those who have kindly agreed to take part. It also draws on the writing of well respected authorities in the fields of project management, software development and web project management.

The research was carried out in two main phases:

Phase 1 focused on in-depth interviews to identify the characteristics and practices of successful web projects, and the main barriers to success.

Phase 2 was designed to validate the findings of the first phase of research and allow quantitative measurement of the typical success rate of web projects using an online questionnaire.

The interview discussion guide and a copy of the online survey are both published in full in the Appendices of this report.

2.2. Who is this report for?

This report is aimed at anyone involved in commissioning or delivering web projects within their organisation, or on the behalf of a client organisation.

The bulk of the report deals with the infrastructure, culture, practices and processes required to deliver medium to large web and e-commerce projects, although there are also specific findings and guidance relating to the delivery of smaller projects.

The aim of the report is to enable those involved with web projects to identify the challenges that are specific to them, and identify best practices and approaches that will help them overcome these challenges and improve their chances of success on future projects.

It is important to note that this report does not recommend a specific approach or set of processes as a ‘silver bullet’ to resolve all web project management challenges. Rather, our aim is to provide the reader with the framework and information to help them determine for themselves what their future practices should be.

We hope it proves useful to you. We love receiving feedback, comments and, all being well, your testimonials. Send word to [email protected].


mailto:[email protected]

2.3. About E-consultancy

E-consultancy is an award-winning UK-based publisher of best practice internet marketing reports, research and how-to guides, to help educate business people and marketers about the internet and e-commerce.

Founded in 1999, the company has grown to more than 52,000 registered users and operates a paid-subscription model. Subscribers pay from as a little as £149 per year to access exclusive and highly practical content.

E-consultancy also provides a range of public and in-house training programmes, such as seminars and workshops. It trained more than 3,000 internet professionals in 2006 and runs bespoke training programmes for well-known blue chips and SMEs.

More than 100 exclusive E-consultancy events are lined up for 2007, including roundtables and monthly Supplier Showcases, which remain highly popular.

Web Project ManagementBased on this research E-consultancy is running a programme of training seminars specific to Web Project Management.

Upcoming dates for these courses are…

Manchester 25th April, 2007Manchester 4th July, 2007London 10th July, 2007London 13th September, 2007Manchester 25th September 2007London 20th November, 2007Manchester 22nd November, 2007

If you are interested in attending any of these sessions please email [email protected], or see our website’s training channel for more detail.

E-consultancy also held a roundtable forum of E-commerce managers and project managers to discuss the findings of this research, the outputs of which can be found on our website.


http://www.e-consultancy.com/knowledge/training/



http://www.e-consultancy.com/knowledge/events/supplier-showcases.asp

http://www.e-consultancy.com/knowledge/events/

http://www.e-consultancy.com/knowledge/training/

http://www.e-consultancy.com/about/subscription-membership.asp

http://www.e-consultancy.com/publications

2.4. What is Web Project Management?

What is a project?

In ‘A Guide to the Project Management Body of Knowledge’ (PMBOK Guide) a project is defined as:

“A temporary endeavour undertaken to create a unique product, service or result”

What is significant about this definition is that it distinguishes projects from the everyday work of running of a business. Projects run alongside business as usual operations and typically deliver a change that needs to be integrated back into the business, at the completion of the project.

What is Project Management?

“Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements”

(PMBOK, 2005)

Sometimes carried out by a professional project manager, at other times project management is an activity carried out by another member of the project team. You don’t necessarily have to be a project manager to manage projects.

There are a few universal truths for any project which are reflected in every Project Management methodology:

1. There is always a customer, the project is always being delivered for someone;

2. There is always a project team, no matter how big or small;3. There should always be a goal, otherwise why are you doing the project?4. It ultimately comes down to managing the iron triangle…

The iron triangle represents the three key elements of a project: cost, quality and time. Altering one of these variables will impact the other two. For instance, if you need to reduce the time to complete a project you will either Copyright © E-consultancy.com ltd 2006

Cost

Time

Quality

9

have to risk reduced quality, or pay more money to ensure the same quality in less time.


Web Project Management

The fundamentals of project management are the same, whatever the project, but there are a number of challenges inherent to web projects which often prevent teams from delivering their projects on time, on budget and to the satisfaction of their internal and external customers. These challenges are outlined in more detail in section 5.1.

In the experience of the participants of this research there is no single approach that is a perfect fit for web projects.

Many organisations have embarked on journeys of experimentation and adaptation to arrive at processes that work for them. It is from documenting these experiences that we have been able to build a new body of knowledge that supports the notion of web project management as a separate activity.

At its most basic level Web Project Management is about creating the right environment for the delivery of web projects. One with the following characteristics:

Just enough structure to help rather than hinder progress; The flexibility to work with evolving requirements; Focus on and involvement of the end customer; Effective collaboration between different skill sets and departments; Manages the expectations of multiple stakeholders; Enables rapid deployment of priority features.


3. Research aim

E-consultancy felt that there was a big gap for this sort of research, and so we decided to do something about it. We are experienced in web project management, having created, launched and operated many websites for ourselves and for third parties. Indeed, a thorough revamp of the E-consultancy website has just begun, a project anticipated to take a year before it comes to fruition.

Moreover, this research was undertaken in response to a growing need for guidance on web project management best practice from people working at the sharp end of the internet industry.

As ever, our guidance is based on practical experience rather than theoretical knowledge of managing web projects. People say that this is where E-consultancy really stands out from the crowd, and we hope this guide will prove to be a valuable addition to the existing research available on at www.e-consultancy.com/research.

Specifically this research aims to…

Discover what makes some organisations and projects more successful at web projects than others;

Show what methodologies, tools and techniques are working, and which one’s aren’t;

Help subscribers evaluate their own situation and work out the best approach for them.

Our research is not intended as a training manual for any specific project management method or process, but we think it articulates the ideal environment for managing web projects.

It also provides an insight into some of the wide range of project management techniques available.


http://www.e-consultancy.com/research

http://www.e-consultancy.com/research

4. Methodology

4.1. Sample

Phase 1 of the research comprised of 18 depth interviews with representatives from different organisations, across a wide range of industries including travel, financial services, telecommunications, retail and agency. The respondents were chosen because they are responsible for either commissioning or managing web projects within their organisation.

The purpose of this first phase was to identify the characteristics and practices of successful web projects, and identify the main barriers to success.

Interviews were conducted with senior representatives from the respective internet teams at the likes of: MyTravel, Sony Ericsson, Sony Business Services, Axa-PPP, Alliance and Leicester, BSI, First Choice, Framfab, Henderson Global Investors, Lloyds, Code, O2, Opodo, P&O and Signet.

Phase 2 was designed to validate the findings of the first phase of research and allow quantitative measurement of the typical success rate of web projects, and the maturity of UK organisations in their approach to web projects. This phase was conducted via an online survey to the E-consultancy newsletter subscriber base. The survey was completed by 633 individuals (about 5% of our newsletter readers).

4.2. Questions

In order to satisfy the aims of the research it was necessary to evaluate what skills and resources are necessary to run web projects and also how projects are influenced by and interact with the wider organisation.

In order to do this we borrowed a strategic framework already seen in E-consultancy’s in-depth study: ‘Managing an E-commerce team: Integrating digital marketing into your organisation’.

The structure for his study was based on a strategic framework devised by McKinsey Consultants – The 7S strategic framework. In it each “S” represents a key issue that needs to be addressed. We have applied this framework equally effectively to the practice of managing Web projects, and it has been used in this research to highlight the key issues that need to be managed in order for a company to deliver its projects with a degree of success.

This framework formed a backdrop for the first phase of qualitative research, which then defined the quantitative survey which was used in phase two. The interview discussion guide and a copy of the online survey are both published in full in the Appendices of this report.


Element of 7S model

Application to Web Project Management

Key issues

Strategy Annual planning approach, aligning projects with organisational and marketing strategy, gaining appropriate budget and resource, delivering value

Being part of organisation wide planning process

Effective prioritisation of web projects to align with business goals – roadmapping

Being part of a programme of work

In-built flexibility to adapt to fast moving environment

Digital strategy as collaboration between IT / Marketing / Digital / Commercial

Structure Modification of organisational structure to support digital projects

Cross-functional steering and cross-functional teams

Common goals and targets

Integration between IT / Marketing / Mgt

Where does project/programme mgt function sit?

Accountability

Systems Development of specific processes, procedures and information systems to support digital projects

Adoption of structured approach to PM.

Approach communicated and used by whole team/organisation

Approach is fit for purpose – speed, quality, flexibility, scale

Visibility of the project – timescales, issues, resource

Effective process for gathering and refining requirements

Role of customer / end user in the process

Choosing the right supporting software

Effective resource estimation and allocation

Staff Breakdown of staff in terms of background and characteristics, location, insource/outsource, part-time vs. dedicated

Senior level sponsorship

Diversity of backgrounds, skills and understanding of web technology

Dedicated PM function vs. managing projects as a part-time


task

IT Project Manager vs. Commercial Project manager

Style The way key managers behave in achieving the organisational goals, and the cultural style of the organisation as a whole

Shared ownership and decision making vs. working in competing silos

Organisational culture main driver of process/method

Techniques to nurture collaboration across functions

Co-location

Fear of permanent beta

Skills Distinctive capabilities of key staff Breadth of skills required across the project

Project management skills, training and experience

PM balance between technical, commercial and people skills

Experience of working in web projects

Availability of expert technical resource

Ability to evolve and embrace new technology

Super-ordinate goals

The guiding concepts of the organisation which are part of shared values and culture

Improving the effectiveness of cross-functional teams through education and involvement in the process. Give the organisation understanding so they can embrace the potential of the web channel

4.3. Analysis

The Clicktools analysis tool was used extensively in the quantitative phase of the research and enabled responses to be cross-tabulated and filtered. For example;

Cross referencing specific attributes and practices against their impact on success

Analysing the relationship between project management method ando Successo Cultureo Challengeso Practiceso Requirements gatheringo Nature of deadlines


Cross referencing culture against success Filtering to establish the impact on success of the predictive model Filtering the model behaviours to quantify the volume of respondents at

each stage of the model


5. Findings and Recommendations

5.1. The differences between web projects and other projects

The interviews conducted in the early stages of this research supported the view that web projects have challenges of their own which set them apart from other kinds of projects.

Web projects draw on a huge range of people and skills – Marketing, commercial, design, usability, accessibility, information architecture, programming, database development, application development, integration with legacy systems, back office support and fulfilment. It’s not enough for each area to own one chunk of the project and then put it into a black box for someone else to integrate. Multi-discipline teams need to work together to define whole solutions that maximise the technology’s’ potential to fulfil the customers’ needs.

Because of this diversity of interests, most web projects also tend to attract a huge array of stakeholders and hangers on. It’s also fair to say that in some organisations, web is still perceived as ‘quick and easy’ so project managers have to manage varied and unrealistic expectations.

Web development tends to be an iterative process. Enhancing functionality through smaller, more frequent releases is the most effective way to keep up with the fast pace of change in consumer habits and technology. Plus the volume of data available on how customers interact with your website makes it impossible these days not to find ways to continuously improve conversion or loyalty.

Hand in hand with a fast paced, competitive environment and demanding customers comes fixed deadlines, primarily driven by product launches and advertising campaigns.

Many projects are made more complicated by the need to integrate cutting edge applications with legacy systems, which typically means that there are lots of unknowns.

The requirements of a web project are often less defined at the outset, partly because it is difficult to second guess how the audience is going to interact with a three dimensional customer experience. It’s not uncommon for requirements to be refined as part of the design process, and prototyping is sometimes used to aid this.

The web channel represents your company’s window to the outside world, so if your projects go wrong the evidence is there for all your customers to see and experience in the form of poor usability, confusing navigation, frustratingly slow page downloads, underwhelming content, impossible to complete transactions and error messages.

Copyright © E-consultancy.com ltd 2006 17Key Finding

Take the time to ensure that you and other key stakeholders understand the unique challenges inherent with web projects. This will help manage unrealistic expectations from the business.

5.2. Biggest challenges facing web project managers

All our research participants were asked to identify the top three challenges they faced in delivering web projects. Their responses served to highlight the fact that a huge number of organisations are struggling with challenges that are inherent to the nature of web projects! Elements of their environment and / or processes are inadequate for the tasks they are being asked to carry out.

Resoundingly, the biggest challenge facing web project managers is changing requirements during the course of the project. This is a defining feature of web projects, and can’t be avoided unless organisations are prepared to go back to producing brochure-ware and stop striving for meaningful customer interaction.

Chart 1 – Biggest challenges in managing web projects

50

3331

27 27

23.5

1916 15 14

0

10

20

30

40

50

60

Chang

ing sc

ope

or re

quirm

ents

Unrea

listic

exp

ecta

tions

Busine

ss fa

ils to

inpu

t on

time

Develo

pers

und

eres

timat

e

Unable

to a

rticu

late

requ

irem

ents

Get/K

eep

reso

urce

Poor c

ollab

orat

ion

Poor u

ser i

nput

No cle

ar P

M p

roce

ss

Lack

of s

kills

Most frequent challenges

% o

f re

spo

nd

ents

(n=527)

Ironically most organisations, 87.67% according to our survey, set their requirements knowing that they need to be flexible to change. The fact that 50% still consider this to be one of the biggest challenges in their projects simply highlights the fact that they are unprepared for change when it needs to happen, or when it happens anyway.

All project management methodologies will state that they have a mechanism for dealing with change within the project. But organisations need to understand that there is a world of difference between managing change as an exception to the project, and embracing change as part of the process.


“Our problem was that the environment was constantly changing – you start off

in waterfall with a big scope and then during the journey there would be continuous re-scoping because of unforeseen changes. So by the time you

deliver it’s different to what you set off with and the business is disappointed”.

The next most significant challenges are the unrealistic expectations of the business and failure of the business to provide adequate input at the right time. Once again, this is probably symptomatic of one of the major challenges of web projects.

The fact that there are a myriad of stakeholders and skill sets involved in web projects, means that managing the appropriate level of involvement from all parties can be a phenomenal communications task.


Key Finding

The results from the questionnaire serve to reinforce the view that web projects require a project management approach that helps with:

Evolving requirements Putting focus on the end customer Collaboration between different skill sets Managing stakeholder expectations

5.3. Key drivers of success

During the interview stage of this research it became clear that organisations that are successful in delivering web projects share similar behaviours. We can see that success is not driven by the size of the organisation, which specific methodology they used or even the team structure.

Instead, the key to running successful web projects appears to be nothing more that a collaborative and communicative culture, supported by structured practices and processes that are appropriate to the individual project and the organisation.

The most successful organisations had these attributes in common:

Statements of a mature organisation Think strategically but deliver tactically Projects aligned with business strategy Sponsorship at senior level of the organisation Cross-functional steering to prioritise resource and provide guidance Collaboration between IT, Marketing and Management Shared goals Structured approach to projects, which is appropriate to the needs of

the business. This often means using different approaches for different kinds of projects.

Driven by business/customer needs Dedicated project management resource Flexibility to respond to change Focus on the requirements that deliver the greatest benefit

For the purposes of statistical analysis and producing a predictive model, these statements were translated into specific practices which were then incorporated into the quantitative study:

Flexibility in requirements Involvement of the end user in defining requirements Having a Project Manager Having a structured approach to managing web projects Highly collaborative culture Highly communicative culture An annual plan that is aligned with the overall business strategy Shared goals with the rest of the business A business wide approach to prioritising resource Cross-functional steering Senior sponsors for projects

A final influence, less easily quantified, was whether an organisation was able to demonstrate using different approaches for different kinds of projects.

Key Finding


Delivering a successful project is as much about managing the environment as it is about managing the process.

Most of us do some of the right things

The model will demonstrate that it is a combination of practices that drive significant improvements in the success rates of projects. But some behaviours are more important than others, and the good news is that UK businesses are already doing a lot of the right things.

The table below shows the percentage of respondents already demonstrating the behaviours and practices that are critical to success. The practices that have the most tangible impact on success are marked with stars.

Chart 2 – Percentage of respondents who demonstrate key success factors

100.0

75.2

66.2

55.5

54.5

54.2

49.8

46.6

38.4

38.4

34.9

28.9

17.1

0.0 20.0 40.0 60.0 80.0 100.0 120.0

Baseline

Flexible requirement

User drives requirements

Have a PM

High collaboration

Structured approach

Highly communicative

Shared goals

Align with business strategy

Snr Sponsors

Business wide prioritisation

Cross-functional steering

Multiple approaches

(n = 631)


Percentage of respondents

Key finding

Some factors have a larger, clearer influence on the likely success of a project. The top four factors are: creating a highly collaborative environment having a structured approach aligning projects with business strategy business wide prioritisation of resource.

A model for successful Web Project Management The quantitative study enabled data relating to over 600 companies to be mapped onto a maturity model, to establish whether these key behaviours were truly predictive of success.

Each success factor was input according to how widespread its’ practice is i.e. the most commonly followed behaviours first, with the least common and arguably more sophisticated practices at the end of the model, as illustrated in the table above.

Mature organisations are more successful

By looking at a combination of which key success factors had been adopted by a company, and the perception of success they had achieved against the following criteria, we were able to demonstrate a clear link between the adoption of best practice (via the critical success factors) and the increased success of a project.

How would you rate the success of your projects on the following criteria?

Never Sometimes Always

Achieves goals

Meets deadlines

Meets budget

Customer satisfaction

Involvement of the end user

Embraces flexibility during development

Delivers ROI

Without doubt some elements of the model are more significant than others in driving success, but no single attribute guarantees success on its own. The model represents, at a high level, an ideal blend of company culture, organisational structure, skills and practices.

The most successful organisations do all or many of these things. The following charts show how different facets of the model impact some of the success criteria.


Chart 3 - Companies further up the model = more likely to achieve their

goals.

2.4

2.45

2.5

2.55

2.6

2.65

2.7

2.75

2.8

2.85

2.9

Ba

selin

e

Fle

xib

le r

eq

uir

em

en

ts

Cu

sto

me

r a

tre

qu

ire

me

nts

ga

the

rin

g

Ha

ve a

PM

Co

llab

ora

tion

Str

uct

ure

d a

pp

roa

ch

Co

mm

un

ica

tive

Sh

are

d g

oa

ls

Alig

n w

ith b

us

stra

teg

y

Sn

r S

po

nso

rs

Bu

sin

ess

wid

ep

rio

ritis

atio

n

Cro

ss f

un

ctio

na

lst

ee

rin

g

Sc

ore

ou

t o

f 3

(n = 631)

Chart 4 - They are more likely to meet deadlines

1.9

2

2.1

2.2

2.3

2.4

2.5

2.6

Ba

selin

e

Fle

xible

re

qu

ire

men

ts

Cust

om

er

at

requ

ire

men

ts g

ath

eri

ng

Have

a P

M

Colla

bo

ratio

n

Str

uct

ure

d a

ppro

ach

Com

mu

nic

ativ

e

Sh

are

d g

oals

Alig

n w

ith b

us

stra

teg

y

Sn

r S

po

nso

rs

Bu

sin

ess

wid

ep

rio

ritis

atio

n

Cro

ss fu

nct

iona

lst

ee

ring

Sc

ore

ou

t o

f 3

(n = 631)


Adoption of Model

Adoption of Model

Chart 5 - They are better at staying within budget

2.15

2.2

2.25

2.3

2.35

2.4

2.45

2.5

2.55

2.6

2.65

2.7

Bas

elin

e

Fle

xibl

e re

quire

me

nts

Cus

tom

er a

tre

quire

men

ts g

athe

ring

Hav

e a

PM

Col

labo

ratio

n

Str

uctu

red

appr

oach

Com

mu

nica

tive

Sha

red

goal

s

Alig

n w

ith b

us s

trat

egy

Snr

Spo

nsor

s

Bus

ines

s w

ide

prio

ritis

atio

n

Cro

ss fu

nctio

nal

stee

ring

Sco

re o

ut

of

3

(n = 631)

Chart 6 - They are better at dealing with change in the project.

2.25

2.3

2.35

2.4

2.45

2.5

2.55

2.6

2.65

2.7

2.75

Ba

selin

e

Fle

xib

le r

eq

uir

em

en

ts

Cu

sto

me

r a

tre

qu

ire

me

nts

ga

the

rin

g

Ha

ve a

PM

Co

llab

ora

tion

Str

uct

ure

d a

pp

roa

ch

Co

mm

un

ica

tive

Sh

are

d g

oa

ls

Alig

n w

ith b

us

stra

teg

y

Sn

r S

po

nso

rs

Bu

sin

ess

wid

ep

rio

ritis

atio

n

Cro

ss f

un

ctio

na

lst

ee

rin

g

Sc

ore

ou

t o

f 3

(n = 631)

Key finding

It’s possible to apply a model that is predictive of success. Respondents at the top of the model scored themselves as 92.38% successful, versus the average which was 79.76%.


Adoption of Model

Adoption of Model

The model applied

Discussions with client and agency organisations suggested that there are three main categories to describe an organisations’ maturity in delivering web projects. The survey data enabled the size of these groups to be quantified.

Chart 7 – Shows where the biggest improvements in success occur and the location of the three main groupings in terms of their adoption of

the model

(n=631)

Although success rates consistently improve the further along the model you go, each of the markers on the diagram above serve to illustrate the point at which the most considerable improvements occur.

Key finding

Although some elements of the model are more significant than others in driving success no single attribute guarantees success on its own. Organisations should strive to adopt as many of the success criteria as possible in order to deliver value and ROI.


0.0

20.0

40.0

60.0

80.0

100.0

120.0

Baselin

e

Flexib

le re

qu irem

ent

User d

rives

requ

irem

ents

Have a

PM

High

colla

bora

tion

Struct

ured

appro

ach

Highly

com

munica

tive

Shared

goa

ls

Align w

ith b

usiness

stra

tegy

Snr Spon

sors

Business

wid

e prio

ritis

ation

Cross

-func

tional

ste

erin

g

Has m

ultiple

appr

oaches

Achieves goals

Meets deadlines

Meets Budgets


Involves end user

Flexibility in dev

Delivers ROI

Slick Professionals

2.8%

Frustrated Visionaries

14.2%

Early Experimenter

83%

0.0

20.0

40.0

60.0

80.0

100.0

120.0

Baselin

e

Flexib

le re

qu irem

ent

User d

rives

requ

irem

ents

Have a

PM

High

colla

bora

tion

Struct

ured

appro

ach

Highly

com

munica

tive

Shared

goa

ls

Align w

ith b

usiness

stra

tegy

Snr Spon

sors

Business

wid

e prio

ritis

ation

Cross

-func

tional

ste

erin

g

Has m

ultiple

appr

oaches

Achieves goals

Meets deadlines

Meets Budgets


Involves end user

Flexibility in dev

Delivers ROI

0.0

20.0

40.0

60.0

80.0

100.0

120.0

Baselin

e

Flexib

le re

qu irem

ent

User d

rives

requ

irem

ents

Have a

PM

High

colla

bora

tion

Struct

ured

appro

ach

Highly

com

munica

tive

Shared

goa

ls

Align w

ith b

usiness

stra

tegy

Snr Spon

sors

Business

wid

e prio

ritis

ation

Cross

-func

tional

ste

erin

g

Has m

ultiple

appr

oaches

Achieves goals

Meets deadlines

Meets Budgets


Involves end user

Flexibility in dev

Delivers ROI

Slick Professionals

2.8%


14.2%

Early Experimenter

83%

Adoption of model

% of respondents

Early Experimenters

Early experimenters tend to be relatively new to delivering web projects. The web channel is typically seen as a tactical tool rather than a channel that is integrated into the overall strategic plan of the business.

This can be problematic. It can mean that e-commerce initiatives operate in a vacuum and the opportunities and benefits are not fully realised by the wider organisation.

On the one hand this means that the project team will typically have a lot of empowerment (while things are going well), but at times the lack of support from a senior sponsor can be to the detriment of the project. A particular challenge can be getting and keeping the right resources for the job.

This mode is typified by a lack of formal process, or having to operate with processes that aren’t always suited to web projects. There will usually be some organisational tools such as work schedules, project updates and team meetings but these are often applied in an ad hoc manner. The knock-on ef-fects of a lack of structured approach are discussed more fully later in this document.

There is unlikely to be a full-time project manager in place, although IT pro-ject managers may get involved where there is integration with legacy sys-tems. Projects are completed purely as a result of the sheer determina-tion of the individuals within the project team. Nothing more.

Working in this mode can be maintained for a while, but typically issues can occur when:

projects increase in their size or complexity web gets a higher profile in the business more stakeholders come out of the woodwork there are more projects and/or fewer resources available key team members leave

Key Finding

Web projects need to be part of an overall business strategy. When this isn’t the case the project team operate in a vacuum without the appropriate tools and techniques to make their projects a success. The business case for appropriate resource is doomed to fail because the project is not contributing to the priority objectives of the business.



Frustrated Visionaries tend to deliver their projects against an annual plan and objectives which are aligned with the overall strategy of the busi-ness. They tend to have more formal structures and processes in place in-cluding cross-functional steering groups to prioritise projects and resources. In these circumstances web projects have visibility at a senior level in the company.

Although there is a defined process for delivering projects there are still some common complaints:

IT and marketing don’t collaborate enough Web projects sometimes disappear into an IT black-box and don’t al-

ways do what they’re supposed to when they come out the other side Projects take too long to deliver The business can’t be as responsive to customers and the competition

as it needs to be Projects get derailed by changing or misunderstood requirements

Legacy systems and laborious processes are perceived as the biggest bar-rier to achieving the organisations’ online vision. What these organisations lack is the flexibility to cope with the demands of the market and ambitions of the company. They usually manage to deliver one or two large web pro-jects a year, but want to be able to deliver enhancements in a more frequent and iterative way.

“We have two big problems. It’s too long from getting an idea to delivery and stemming from that is that the process involves far too many people, too many personalities”

Typically these companies will work within a Prince framework or a home grown waterfall process.

In their favour, the communicative and collaborative nature of the team means that they’re usually well aware of their problems and are trying to re-solve them. They actively research new methods and tools.

Key Finding

The vast majority of organisations that are struggling to deliver their web projects do so because they are persisting with a methodology that is inappropriate for their needs. A more flexible approach, using tools that are applicable to the task at hand, should be considered. This often means considering more agile project management methodologies.


Slick Professionals

Slick Professionals bring sophisticated expertise to managing web pro-jects, and are likely to have clear processes (usually multiple methods) for managing projects which are characteristically more collaborative, user fo-cused, iterative and flexible to change.

These organisations are typically in highly competitive industries where cus-tomer expectations are high. They will deploy multiple changes during the course of the year, which are largely driven by customer research and mar-keting deadlines. The IT department is perceived as (and perceives itself as) as a key service provider.

Agile methodologies are often adopted here because of: quick starts, ability to prioritise key requirements, quick delivery of tangible outputs, their ability to ensure participation of IT, commercial and market-

ing, the fact that risks and the impact of problems or mistakes are min-

imised.

More traditional approaches such as Waterfall are still used where appropri-ate e.g. where there is less uncertainty, requirements are fixed and the there is less need for innovation.

Key Finding

To be able to respond to a competitive market the most successful organisations adopt project methodologies that are appropriate to their environment; flexible, collaborative, with quick start ups and incremental delivery.


5.4. A few words about agencies and consultancies

Special consideration needs to be given to agencies and consultancies. Put simply, they are not in control of all the key success factors of their projects because their clients are responsible for the sophisticated behaviours at the top of the model;

Annual plan for web projects aligned with the overall business strategy Ensuring that there are senior sponsors for the project with decision

making authority Using cross-functional steering groups to ensure that the relevant areas

of the business have input and accept responsibility for the decisions made within the project

Anecdotally, it is in these areas where many agencies feel their projects can experience difficulty – getting the right person at the client to make decisions in a timely manner.

It therefore comes as a surprise to find out that in spite of this, agencies and consultancies are still more successful than other organisations in delivering their web projects. The diagram below illustrates how respondents from different industries rated the success of their projects against key criteria.

Chart 8 – Success rate of agencies and consultancies compared to other industries

0

0.5

1

1.5

2

2.5

3

Ach

ieve

s go

als

Mee

ts d

eadl

ines

Mee

ts b

udge

t

Cus

tom

er s

atis

fact

ion

Invo

lve

end

user

Fle

xibl

e in

deve

lop

men

t

Del

iver

s R

OI

Success criteria

Sco

re o

ut

of

3

Overall baseline

Agency/consultancy

Financial

Travel

Gambling

Retail

Not for profit

Business Services

Technology

Communications

Other

(n = 528)

Agencies and consultancies consistently outstrip other organisations, so what is it that makes them inherently better at delivering projects?


It’s easy to overlook the most obvious point. The biggest different between agencies and consultancies and other organisations is that their raison d’etre is projects. Their staff is just one resource to be called upon, and they don’t have to juggle projects with other business as usual activity.

However, there are important factors to their success that can also be explained by the attributes of the model…

Culture – Of all the industries agencies and consultancies are more likely to describe their organisational culture as highly innovative, collaborative and communicative.

Table 1 – Responses to question 4, description of company culture, filtered by industry

How would you describe your company culture (1 is least like, 5 is very like)Prepared to accept risk Innovative Empowering Collaborative Communicative

All 3.1 3.47 3.36 3.49 3.39All excluding agency 3.01 3.41 3.31 3.42 3.3Agency/Consultancy 3.33 3.66 3.49 3.66 3.63

(n = 624)

The research, both anecdotally and statistically, shows a direct link between the culture of an organisation and its ability to deliver web projects.

Customer champions – Agencies and consultancies are better at championing the customer in the project and are more likely to involve the end user across more stages of the project.

Table 2 – Responses to question 11, involvement of end user in project, filtered by industry

At which stage is the end user involved in your projects (% of respondents)Requirements gathering Solution design Front end design Prototyping Testing

All 79.81 41.33 58.48 47.43 72.57All excluding agency 76.41 37.27 54.69 45.04 70.24Agency/Consultancy 88.16 51.32 67.76 53.29 78.29

(n = 526)

The research data shows that involving the user at any stage of the project has a positive impact on success, but involving them during solution design has the most positive impact of all. Ironically this is the stage at which most companies are least likely to seek user input.

Adaptable approach – Agencies are more likely than other organisations to experiment with different approaches to work out the best way to deliver a project, and frequently bring their past experience to bear.

The only real differentiation between more and less successful agencies is the sophistication of their methods and processes, and their ability to manage the project and their clients within an appropriate structure and framework. To this end we have identified two broad categories to define the way agencies approach web projects – Tight teamworkers and Professionals with process.


Key Finding

Agencies and consultancies have a head start in delivering successful web projects. Their whole organisation is structured around delivering projects, and they are more likely to have a culture of collaboration, communication and innovation.

Agency types

The research isolated two main types of agency in terms of project management methodology and maturity. Both can deliver successful projects but this will depend on the type and size of the project and the demands/maturity of the client organisation.

A.Tight teamworkers

Tight teamworkers are loved by their clients because of their ‘can-do’ attitude. There is a natural tendency towards team work and collaboration, and individual team members will go the extra mile to get the job done. It’s a fun and vibrant environment when things are going well and a chaotic workhouse when things aren’t.

A lot of these organisations will have project managers, although it does not necessarily follow that there is a structured approach in place to manage projects, or at least not one that is visible to everyone else in the agency.

There will be processes for trafficking projects through the various departments, and for smaller projects this is often enough. The cracks are more likely to show during bigger, high profile projects that have outgrown the in-house processes, highlighting the need for new tools and techniques to help accurately assess the scale of work and respond in a more structured way.

The biggest unknown is the quality of client input, and it has the ability to derail a project. Projects work well when the client is happy to let the agency get on with the job, but can suffer when pressures at the client come to bear. Key issues can be; involvement late in the day from key stakeholders, delays in giving feedback and the client not providing assets on time.

Often reactive by nature, it is difficult for these agencies to protect the quality of their output. This can cause problems later down the line when on occasion the client fails to appreciate the trade off between, speed, cost and quality.

Many of these organisations would like to take time out to clarify their processes and educate their clients about the importance of their role in the project.

“Clients want agencies to be reactive but they should be responsive not reactive… it has a ripple effect on resourcing. If you’re caught out then you

have to scramble to find the right people. In the end it affects the quality of the project. You need to be able to get the right people to do the job.”


B.Professionals with process

Professionals with process are agencies and consultancies with a structure designed to foster innovation and collaboration.

They vary in size from 5 to 500 people, but when it comes to running projects they are all flexible enough to cope with change, and can turn their hand to a number of different approaches depending on what suits the circumstances. They are equally at home with Agile and traditional project management methodologies, and are likely to develop a ‘house’ style based on the best of both worlds.

For some of these organisations it’s important to have PRINCE2 as a string to their bow, in order to attract business from government organisations.

Processes are robust but not heavy handed, with emphasis on customer involvement, quality assurance and testing. Because there is a defined approach to each project it is easier for these organisations to educate the client on what the process is and ensure the right level of involvement at the right time.

Professionals with process are equally adept at managing large projects as well as smaller undertakings, and are confident in implementing and adapting new technologies.

These organisations use their resources efficiently with effective methods of prioritisation, and pride themselves on being responsive rather than reactive.

“ Most of the time we take the initiative in deciding a process. It’s surprising how little process is in place at some clients. Most of the time clients are happy

to go along with it”

Key Finding

The most successful agencies don’t shy away from introducing more structured methods of managing projects, and will apply either Agile or Traditional approaches to suit the project. Amongst other things, a more disciplined approach can help to engage the client more productively.


5.5. Building the right environment for success

The right culture

The results of the research show that an environment that is innovative, empowering, communicative and collaborative produces more successful web projects.

This is supported by evidence from a ‘reverse model’ of the research data which showed that the least successful organisations had little aptitude in these areas. Poor communication is a particular killer of projects.

For people working in a project team there are two cultures in play – the micro culture within the immediate team, and the macro culture of the wider organisation.

We spoke to a number of companies who had successfully introduced new methods of delivering web projects into their organisations. They all had one thing in common: the people responsible for driving the change were the IT directors, E-commerce directors and/or Marketing Directors of the organisation.

Changing the culture of the wider organisation is not usually within the gift of the project or programme manager, but understanding it is critical in ensuring that your projects get adequate support. However, the project manager does have influence over the culture of the project and its team.

Organisational culture

Every authority on project management supports the notion that the project management approach needs to fit the context in which the project is operating. It is not a Trojan horse for organisational change.

Jim Highsmith (2002) references a study by Geoffrey Moore which explains that there are four basic organisational cultures:

Cultivation – Puts people first, but as individuals rather than as teams. People tend to gravitate towards work they find fulfilling, and are therefore highly original and creative. These organisations are brilliant at experimentation, but less effective in running projects in the mainstream.

Competence – Stresses individual responsibility and accountability. Driven by the need for achievement, they are “can do” organisations, who can be brilliant in a turbulent, changing market place, but may struggle when the market matures.

Collaboration – The emphasis is on cross-functional teams. They prioritise strong leadership based on a meritocracy of experience rather than job title. The leadership style is goal-oriented, encouraging interaction and a balance of delegation and decisiveness.


Control – Motivated by a need for power and security, these companies are less comfortable with experimentation and rapid change, but are efficient at optimising what they already do. There is a focus on strong management and processes.

Understanding where your company fits on this scale should be a key determining factor in tailoring your approach. A simple illustration of how this can be applied is contained in section 5.6 (’Are you using the right approach?’).

Some organisations have recognised that their prevailing company culture is not suited to e-commerce and have responded by setting up web operations as either a separate company or branch of the organisation. This can work well where all the necessary resources can be ring-fenced within e-commerce, but can present challenges if, as is so often the case, there is still a need for integration with the rest of the business. The outcome can be a clash of cultures, and either an e-commerce division that is under siege, or one that is perceived by the rest of the company as being too big for its’ boots.

Key Finding

Project management styles that are at odds with the prevailing organisational culture are unlikely to succeed. Such radical change only occurs when the new direction is instigated by senior management.


Team culture

The first step in developing an effective team culture is to get someone in place who will take responsibility for not just managing the process, but the environment the project is in. Ideally, an experienced project manager can bring the appropriate communication, leadership and team building skills to bear.

However, Rome wasn’t built in a day, and it’s not enough to simply decide that your team are going to be communicative and work together happily. Culture is determined by behaviour, which is in turn supported by good practices.

Some of the key practices for fostering a positive team culture are:

Defining clear roles and responsibilities Effective communications Proactive stakeholder management Using the right approach

Scott Berkun’s book ‘The Art of Project Management’ is full of excellent advice for project managers on these subjects, which goes into much more depth than is possible in this report. The following is my summary of some of Scott’s key points.

A. Ensure clearly defined roles

Defining roles is one of the keystones for effective collaboration. One of the most destructive influences on relationships can be when there is ambiguity about what the team can expect from each other.

Virtually all project management methods set out a framework for communicating the roles and responsibilities for the project, and it is one of the first things to be articulated, usually even before requirements are discussed.

It is not uncommon for confusion to surround the role of the project manager, teams make assumptions based on their previous experiences of what the project manager will and won’t do. It’s all easily resolved through discussion with each of the team members, working out what each person takes sole responsibility for and where responsibility is shared.

A Responsibility Assignment Matrix (RAM) is a tool often used for this purpose in traditional project methods.


B. Ensure effective communication

Effective communication is only achieved when both participants are able to digest and interpret the message within the communication correctly. It’s not about whether you’ve said something or even whether your message has been received. People are always leaving voicemails and emails to each other – but it doesn’t necessarily follow that this information has been understood and acted upon.

Common communications problems are:

Assumption – good communicators are always clarifying assumptions made at key points in discussions, such as when commitments are made, and confirm them again before the deadline.

Lack of clarity – The natural remedy is to step back, slow down and break down ideas into smaller pieces until clarity is reached and then slowly build up from it. Sometimes it helps to use analogy to give a rough framework.

Dictation – This is not an act of communication as no attempt is made to reach understanding. Giving orders should be the exception. Instead try to make decisions in an environment where people have the right to ask good questions and propose challenges to your logic.

Crossed wires – If neither party recognises that there are different issues being discussed, but being confused as the same issue then the discussion will just frustrate. Someone has to separate them out and work out what is really being talked about, by clarifying and asking questions.

Derision, ridicule and blame – If someone is consistently demeaned in the process of communicating important but difficult information they will stop doing it.

One interviewee explained how her project team had introduced monthly ‘Project Workouts’ as a way of getting the team to work through any issues they were having with the project or working with each other.

One day in the month they spend time out of the office together, focusing on the end goal of the project and working out how to overcome barriers. This regular forum for objective and honest communication helped bring the team together.


C. Manage stakeholders

Stakeholders link the project to the wider organisation. Proactive stakeholder management or ‘managing up’ will help ensure that the business gives effective support to the project, has appropriate input into the project and help manage any negative influences from the organisation on the project and its team.

At the outset of the project you need to evaluate the goals of the project, and determine what support will be needed. Is it money, decision making, influencing other people, expertise? You then need to identify who it is within the organisation that will give it to you.

However, one of the added complexities of web projects is the volume and diversity of stakeholders. It’s not just a case of choosing which stakeholder relationships you want. It’s also about managing the stakeholders you have.

Stakeholder mappingA helpful exercise for identifying where the important positive and negative influences are likely to come from is stakeholder mapping.

Taking a couple of hours out with key team members at the beginning of the project will help you identify which are the important relationships to nurture and allow you to put an appropriate strategy in place for doing this.

Sometimes winning over an important stakeholder is critical to effective collaboration and success. On the next page we’ll show you how to do this – it’s easy!


Making your Stakeholder MapPut your project at the centre of a diagram and plot individuals or departments on the diagram depending on their proximity to their project, people that are close to the project near the centre and people on the margins out towards the edges.

Ask yourself whether these people are influencers, do they have responsibilities to the project, are they accountable for its success, or are they just interested in what you’re doing? Are they important? If they are, make their spot on the diagram bigger.

What is their attitude to the project? Colour them in green if they’re positive, black if they’re neutral, red if they’re negative.

In this example John is responsible for the resource, but has a negative relationship with the project. The outcome is a remote and indifferent back-end development team.

Chart 9 – Example stakeholder mapping exercise.


Project X

Database integrationTeam

Responsible

John (IT Director)Responsible

Jane (E-commerce

Director)Accountable

Dan(Product

Marketing)Responsible

Project X

Database integrationTeam

Responsible

John (IT Director)Responsible

Jane (E-commerce

Director)Accountable

Dan(Product

Marketing)Responsible

D. Taking the right approach

Choosing the right project approach is both a factor of and an influence on the culture of the team. For instance some approaches have rigidly defined roles and responsibilities, with formal communications channels, whereas others are specifically designed to encourage collaboration and more frequent, less formal communication.

Chart 10 – Respondents were asked to score their company culture against a list of attributes where 1 was least like their company and 5 was most like their company. This data has been segmented by project

method.

0

0.5

1

1.5

2

2.5

3

3.5

4

risk

innova

tive

empo

wering

colla

bora

tive

com

municativ

e

Baseline

None

Scrum

Waterfall

Prince

XP

Agile

(n = 624)

As illustrated in the chart above, respondents who worked with ‘Agile’ methods, including Scrum and XP, were more likely to describe their culture as innovative, empowering, collaborative and communicative, than those who worked with traditional methods.

Key Finding

A good project manager will be a key influence in determining a successful, collaborative and communicative culture within the project team. They clarify roles, encourage better communication, gain the support of important stakeholders and introduce collaborative ways of working.


Organisational structure

E-consultancy’s ‘Managing an E-commerce Team’ study (2005) showed that most organisations locate their e-commerce function in one of four areas:

1. Main e-commerce function part of marketing2. Main e-commerce function as separate team3. Main e-commerce as part of operations4. Main e-commerce as part of IT

In the qualitative stage of this research all of the interviewees fell into one of the first two categories, where the strategic direction for e-commerce either came from an e-commerce team reporting into marketing or a dedicated e-commerce business unit.

However, the e-commerce team are not always responsible for delivering web projects. It depends on the size of the project, the level of complexity, and the degree to which the project requires integration with legacy systems. However, in virtually all cases e-commerce provides the direction and motivation for the projects and will manage small projects with low risk.

For larger projects it is common that e-commerce or marketing take primary responsibility for managing front end development, and IT undertake integration or back end development. Budgets are often aligned on this basis. On larger projects involving front and back end work this can mean shared responsibility across IT, E-commerce and Marketing, which is when steering groups become essential to discuss resources, give direction and ensure that the objectives of all areas are being met.

So in terms of where project management, as a function, is located within a business, the picture is quite confused. Project managers are located variously in:

1. Web or e-commerce team2. Project/Programme Management team3. IT department4. No PM, use marketing or commercial staff

It’s worth noting that where there is a dedicated project management team, it is quite common for that team to still have a reporting line into the Head of IT. However the project managers are still perceived by e-commerce as more ‘neutral’ than IT project managers.

Many of the organisations in the research have experimented with different reporting lines for project management, and there doesn’t appear to be one right answer. However, organisations which are more mature and therefore successful in their delivery of web projects are more likely to have dedicated project managers in the e-commerce team, or use project managers from a dedicated project or programme management team, as shown in the chart on the next page…


Chart 11 – Location of project management responsibility, mature organisations vs. all respondents

0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

70.00%P

roje

ct M

anag

er in

E-

com

mer

ce/W

eb

Pro

ject

Man

ager

fro

mIT

Pro

ject

Man

ager

fro

mP

M t

eam

Out

sour

ced

Pro

ject

Man

ager

Mem

ber

ofM

arke

ting/

Com

mer

cial

Tea

m

Location of project management responsibility

% o

f re

spo

nd

ents

All

Mature

(n = 521)

Where there is a high degree of back end work there is often an IT project manager as well as a project manager representing e-commerce.

The point has been made elsewhere in this report about the need for productive relationships between different functions, as the high degree of collaboration required on a project can rarely be avoided. A frequent comment from interviewees is that more could be done within their organisation to ensure that the different departments pull together.

“The ideal would be to align IT to the business so that they are encouraged to work in collaboration rather than conflict. Align bonuses across the area that people work on, across IT and the business, to get everyone in the

same boat so they can focus on getting things done.”

Having common goals is one critical factor, otherwise what incentive is there for heads of department to provide support to web projects. 56% of respondents to the survey said that this was already in place within their organisation. Another interviewee also suggested that bonuses should be linked to these common goals, to ensure the full engagement and motivation of the team involved in delivery.


Key Finding

It is rare that any one department or function owns all aspects of the delivery of web projects, making it crucial for the different departments to be aligned in their strategic vision, from the very top of the organisation.

Alignment with overall business strategy

38.4% of the organisations who participated in our research have an annual plan for e-commerce which is aligned with the overall strategy of the business. This means that over 60% of them don’t!

It’s not enough for your project to have objectives, they need to be the right ones. If your project is not delivering against the key priorities for your company then the harsh reality is that your bosses probably don’t care whether you succeed or fail. That is until they get the bill and wonder what on earth you’ve been spending their budget on.

Projects that originate from an overall business strategy don’t just leave people with a warm sense of achievement, they also have a healthier bottom line. They are more likely to be delivered on time, on budget and have a positive ROI.

This is because projects that are planned in conjunction with the rest of the business get better support from the business. It is easy to demonstrate what benefits they will bring, so they are not perceived as a ‘pet projects’ lacking merit. They are more likely to be given appropriate resource, because there is a pertinent business case for doing the work. The success of the project is likely to be crucial to the objectives of one or more senior sponsor and their department, who will be more pre-disposed to make timely decisions and provide you with effective guidance. People that share your goals, care about your goals.

It’s easy to see how this important practice is linked to other success factors. Without it it’s hard to imagine how you can have a business wide view on prioritising resource, get senior sponsorship and foster a genuine sense of teamwork and collaboration. Without it you will find yourself in competition with the rest of your colleagues, fighting a losing battle for scarce resource.

Successful organisations think strategically so that they can deliver tactically.

Key Finding

Projects need to make a direct contribution to the overall strategy of the business. It ensures that the whole business gets behind the project and gives it the resource and support it needs. Successful organisations think strategically and deliver tactically.


Business Wide prioritisation

Successful, fast-moving projects need to be able to get the right resources at the right time. In reality, there are rarely teams of excellent people waiting on the sidelines, on the off chance that you might need them.

Putting the right resources in place at the right time requires a business wide perspective – one that is sufficiently informed to pre-empt the needs of individual projects versus daily operations and be able to prioritise them according to the overall strategic direction of the business.

The majority of our research interviewees do this via a cross-departmental steering committee. This committee has representatives from each of the core areas of the business enabling them to take a holistic view on resource availability and the impact of cancelling or stalling a project. Around one third of survey respondents have such a process in place.

“There’s an organisational roadmap, which is the priority projects, so if you had a

conflict between one project that is and one that isn’t on the roadmap this decides it.”

The effectiveness of this process has a direct impact on the flexibility of the team to adapt to changing needs and respond to issues. Slow, onerous processes can mean that resource issues are already starting to bite long before a solution is in place. And if, as we’ve already mentioned, your project is not aligned to the core goals of the business, be prepared to go to the back of the queue.

“Sometimes there are conflicts with other departments when doing IT development.

This kind of prioritisation is slow. You put in a development request, explain why it’s needed, give it a business justification. It gets reviewed at a monthly

meeting.”

If such an infrastructure does not already exist within your organisation a programme or project board is sometimes the next best thing, providing it has the support and participation of knowledgeable and empowered senior managers. Although the meeting will be limited to discussing the resource requirements and conflicts of your own group of projects, having the right people in the room such as the IT director, your senior supplier, the main business sponsor etc, it should enable you to discuss your needs in the context of the other priorities in the business, as well as the context of your team.

Key Finding

Having a business wide approach to prioritisation can help put the right resource in the right place at the right time. If this process is too infrequent or ineffective then find other ways to engage with your stakeholders such as a project or programme board.


The Project Manager – practically perfect in every way

In his essay entitled ‘Pursuing the Perfect Project Manager’, Tom Peters gives a fantastic description of the ideal attributes of a project manager, calling them a set of paradoxes. The following is a summary of his list:

1. Total ego / no ego. Project managers have a passionate belief in the project and invest some of themselves in it, yet be able to put their ego to one side and allow others to invest the same energy and reap the same rewards.

2. Autocrat / delegator. When the chips are down, the project manager has got to issue the orders fast, and yet the rest of the time they need to empower the rest of the team to make decisions. The team should "own the problem" and take the initiative to deal with the situation without always deferring to the PM.

3. Leader / manager. Today's project managers, more so than in traditional settings, are only as good as their team mates' commitment, energy and diverse skills. So project managers must be leaders -- visionaries and invigorators. On the other hand, "management" means being expert at the mechanics. It’s about what you do and the way you do it.

4. Tolerate ambiguity / pursue perfection. All projects have an element of ambiguity and change, particularly web projects. A good project manager knows when to let creativity reign, when to button down the details, and how much energy to expend on pursuing the perfect solution.

5. Oral / written. Most people have either an oral or a "put it in writing" bias. Top project managers must have both. Effective meetings, brainstorms and one-to-ones are just as important as clear written reports and accurate documentation. The project manager needs to know which mode to use when.

6. Acknowledge complexity / champion simplicity. If a team gets bogged down in the complexity of a project the danger is that their solution will be equally complex to implement and run, perhaps unnecessarily so. The art of project management is to allow detailed analysis of the problem whilst keeping the team focussed on the big picture and providing the simplest possible solution.

7. Impatient / patient. Project managers must be "action fanatics": Get on with it; don't dwell on yesterday's issues. At the same time, they run a network with fragile egos, multiple cultures and complex relationships. Devoting lots of time to "relationship building" is as important as impatiently pushing for action.

This essay reflects the views of our research interviewees who described their ideal project manager as a reincarnation of Mary Poppins - firm and persistent


yet receptive and approachable. One interviewee described their ideal PM as “someone the team would like to follow into the next project”.


This emphasis on people skills over technical, commercial and even project management knowledge was also borne out in the quantitative research. Below is a chart showing how respondents rated the importance of each attribute out of a possible score of 5.

Table 3 – Responses to question 15, scoring the most important attributes of a web project manager out of 5, where 1 is least important

and 5 is most important.

Excellent communicator 4.44Focused on the end goal 4.37Good listener 4.17Motivates the team 4.14Leadership 4.1Persistence 4.08Flexibility 4.04Negotiator 3.93Commercial knowledge & skills 3.9Good at coaching others 3.75Technical knowledge & skills 3.65Knowledge of different project methods 3.23

(n = 510)

However, in spite of its relatively low score in the survey, technical knowledge of the subject matter was mentioned by nearly every research interviewee as essential in enabling the project manager to run the project effectively. They need to have an understanding of the work involved, bridge the communication gap between IT and the rest of the business, be able to gauge the quality of the proposed solution and have an informed view of work estimates. Or as one interviewee put it…

“They need to see through the rubbish and challenge timings”.

The degree to which project managers are expected to get involved in the commercial elements of the project varies between organisations, and depends on whether there is another role in the organisation which has ownership for this aspect.

For instance, in the agency environment the client services team may be expected to take more ownership for ensuring the commercial viability of the solution. However, no project manager can deliver successful projects if they are detached from the financial realities of the situation and fail to understand the commercial motivations for doing the project in the first place.

To some degree the skills bias of the project manager depends on which department they are located in within the company, and what kinds of web projects they specialise in.

Key Finding

Good Project Management is essential for delivering successful projects. Resources Copyright © E-consultancy.com ltd 2006 49

therefore must be allocated to get the right people with the right skills onboard. Using under-skilled resources / people greatly increases the chances of failure. Good project management is excellent people management and the processes surrounding them are just the tools of the trade.


Incorporating the user into the process

The research data shows that involving the user at any stage of the project has a positive impact on success, but involving them during solution design has the most positive impact of all. Ironically this is the stage at which most companies are least likely to seek user input.

These days very few people would argue against getting feedback from the customers, in fact 80% of respondents to our survey said that they involve the customer in gathering requirements, so why don’t more people involve the customer during design and build?

They think it will cause delays They think it will cost more money They struggle to justify spending time and money on it

In actual fact the companies that are best at delivering web projects, on time, on budget, on brief involve the customer more than anyone else.

Chart 12 – Involvement of the end customer at each project stage, mature companies vs. the average propensity.

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

Req

uire

men

tsga

ther

ing

Sol

utio

nde

sign

Fro

nt e

ndde

sign

Pro

toty

ping

Tes

ting

Methods of involving end user

% o

f re

spo

nd

ents

Baseline

Mature Companies

(n = 526)


Get users involved earlyCompanies that are the most effective at involving the customer, plan it into the process up front so that it doesn’t have a negative impact on costs and timings.

“Early prototyping has been key to ensuring usability and an intuitive experience.

We also do final testing with consumers as a belts and braces supplement to the rest of our Quality Assurance”

Customer feedback might mean rework, but why ask someone’s opinion if you’re not prepared to act on it? The earlier you get this feedback the less rework there will be. Isn’t it better to discover a problem before the site goes live rather than to see the project miss out on achieving its objectives?

“When you’re talking about user interfaces you are more likely to get it completely wrong if you just work from a design document. Early prototyping is

essential. Getting lots of customer involvement at all stages, design and testing, gives us a better idea of what the problems are early on.”

Key Finding

Planning customer feedback into the project gives you an early indication of the effectiveness of your solution, and actually has a positive impact on costs and timings by reducing the need for rework late in the day.


The X factor – flexibility

Projects are about introducing change, and without flexibility change is at best painful and at worst unachievable. In the online environment the ability to adapt and respond to the fast pace of technological and consumer change is what sets the most successful organisations apart from the rest.

Flexibility is the outcome of a number of practices and behaviours, some of which we have been able to identify in the process of conducting this research.

Just enough structure – In his book ‘The Art of Project Management’ (2005) Scott Berkun devotes a whole chapter to “How not to annoy people”. It supports the popular view that over-engineered processes are time consuming, stifling, controlling and make the team feel as if they are not being treated with the level of trust and respect appropriate to their experience.

On the other hand good processes: Accelerate progress Prevent problems Make important actions visible and measurable Are supported by the people impacted by them

Agile practitioners support the view of putting in place ‘A barely sufficient methodology’. Jim Highsmith explains that “streamlined methodologies concentrate on those activities that create value and ruthlessly eliminate non-value adding activities. Programming usually adds value; process management often adds overhead. Bare sufficiency means keeping the former and eliminating the latter” (Agile Software Development Ecosystems, 2002).

Multiple approaches

“If at first you don’t succeed try, try again. Then quit. There’s no point in being a damn fool about it.”

– WC Fields

What works for one project is not necessarily going to work for the next. Rather than persist with a sub-standard approach mature organisations will build a repertoire of different methods and techniques and use their experience to tailor their approach to each individual project. Building in frequent reviews of what’s working and what’s not allows teams to continuously improve the way they run their projects.

The right method – All project management methods are designed to manage change. The difference is that some quite literally assume that change is an exception rather than the rule e.g. Prince2, Waterfall; whilst others assume that change is a positive dynamic to be embraced as part of the process, as in the case of the Agile methodologies. The right method will give you the right degree of flexibility for your project.

Involve the customer - Inviting customer involvement and incorporating it into the process doesn’t give you more flexibility per se, but it is a common


practice of flexible teams. It allows them to exploit their flexibility as a competitive advantage, and design solutions that have a higher probability of being successful in the live environment.

Business Wide prioritisation - Maintaining a business wide view on resources ensures that priority projects receive the resource they need when they need it. This is typically done via a cross-departmental steering committee, who evaluates the needs of the individual projects in relation to their contribution to the overall strategy of the business. The effectiveness of this process has a direct impact on the ability of the team to adapt to changing needs and respond to issues. Engaged senior sponsors – Related to business wide prioritisation, having engaged senior sponsors who are empowered to make decisions about the direction and resourcing of the project is essential in allowing teams to respond quickly to change without causing delays. Your sponsor not only needs to support you in what you are doing, but the way in which you are doing it.

Culture – Flexible organisations are characterised by being communicative, collaborative, innovative and empowered. A common misconception is that these organisations accept more risk. If anything they believe that they have a more pragmatic approach to risk management. By recognising that there will be change, and subsequently planning and estimating work in smaller increments, they are reducing the uncertainty and risk in each module of work.

Expect requirements to change – By denying that change is going to happen, the team simply have a blind spot where their risk management strategy should be. A team that is expecting change can turn it to their advantage to deliver an even better solution and steal the march on the competition. After all, necessity is the mother of all invention…..

‘Permanent beta’ is not the bogey man – The trouble with the phrase ‘Permanent beta’ is that it has a confused reception. It is derived from the idea of beta testing, which is the final stage in software or hardware testing typically involving sending out a nearly finished product to a select group of users for live testing. For some people this association strikes fear into their hearts, conjuring up thoughts of sub-standard quality and hidden bugs in the system that the developer couldn’t be bothered to iron out.

‘Permanent beta’ on the other hand is a buzz word that has been used (perhaps over-used) to describe an approach to web development which acknowledges that a website is never in it’s final permanent state and will continue to be improved through a series of small and frequent iterations. It views the live website as one big consumer test, which the organisation will use to inform future changes.

At the end of the day, if you plan to continuously improve your website you’re in permanent beta. It’s a good thing! It allows you to rapidly deploy changes informed by data from your real-life customers.

Key Finding


Flexibility is the most powerful competitive advantage in the online environment today. It is driven by company culture from the top down and is embodied in team culture and practices. The most important aspect of flexibility is to embrace change instead of hoping it won’t happen.


5.6. Using the right methods and processes

Have a structured approach

45% of our survey respondents say that they do not have a structured method for managing web projects. This rises to 67% amongst retail organisations!

Finding and adopting a structured approach to delivering web projects is possibly the single most important thing an organisation can do to improve their working environment, the morale of the team and the success of their projects. If you haven’t yet put a method in place then do this one thing and according to our interviewees it will make your life much easier.

The data from the survey shows that organisations that don’t have defined approach to managing web projects are:

the least likely to achieve their project goals least likely to involve the end user least likely to deliver customer satisfaction the least able to cope with change during the course of the project less likely to achieve deadlines and meet budgets and deliver a positive

ROI

And for good reason too. A lack of a defined process tends to cause the following problems:

Lack of visibility of the progress of the project and its’ associated risks and issues – problems come as a surprise and either derail the project or impact subsequent projects by causing delays.

No shared vision of what is being delivered – the requirements and therefore design of the solution are open to interpretation so the end res-ults does not match expectations, or requires re-work.

Poor or even no estimation of the work involved in the project – means that resource requirements aren’t clearly stated, and the impact of reduced resource is not known (i.e. someone can steal your resource and you can’t defend it) expectations are unrealistic and unmet, budgets and deadlines are blown and there is a negative perception of the pro-ject.

Projects are planned in isolation from the overall objectives of the organisation which can mean; delivery of a project that doesn’t do any-thing for the business, the project doesn’t integrate with other business milestones e.g. marketing initiatives, there is little support of sponsorship from key stakeholders who don’t perceive the value of the project.

If you are working in an environment like this and have made the decision to outsource your projects to an agency, your projects will still suffer if they are not aligned to your business strategy and have the appropriate sponsorship from an empowered decision maker. Agencies identify this as


one of the key barriers to successful implementation of client projects. So put some kind of structure in place – it will be better than nothing.


Are you using the right approach?

Having any structured approach always gives your project a head start, but one of the most frequent complaints from e-commerce managers is that the approach they’re using is too onerous and complicated, and IT managers complain about poor input and changing requirements from the rest of the business.

Yes, any approach is better than nothing. But having the right approach is best of all.

Chart 13 – Methods of project management used by research respondents (%)

45%

23%

18%

12.50%

11%

10%

6%

5%

5%3.50%

No defined approach

Prince 2

In house process

Waterfall

Agile

Extreme Programming (XP)

Scrum

Rapid Application Development (RAD)

Rational Unified Process (RUP)

Dynamic Systems Development Method

(n = 628)

There are a whole raft of project management and software development methods available to choose from. A few of these are reviewed in more detail in the next section of this report. Meanwhile, the table above illustrates which methods are most popular amongst the respondents to the research questionnaire.

A characteristic of the most successful organisations is there ability to tailor their project approach to the needs of the web project and the characteristics of its environment.

Typically these organisations will be skilled in delivering both ‘traditional’ projects using and ‘agile’ projects which are (as you would expect) more nimble and collaborative.


Some 18% of organisations choose to develop their own project management approach (more about this later), but they usually still seek their inspiration from the recognised methods rather than start with a completely blank canvas.

It truly is horses for courses.


When you’re starting up your next project ask yourself the following questions:

Are requirements well known or unfixed? Will the project need to be delivered quickly? Is the project technically complex? Are there likely to be changes to the project as you go along? Is there a high degree of innovation in what you are doing?

The rule of thumb is that:

If your project has unfixed requirements, tight or immovable deadlines, innovation, new or complex technology, or a high likelihood of change then you should try an Agile approach (e.g. XP, Scrum, Crystal, DSDM).

If your project has known requirements, flexible deadlines, well known technology, lower complexity, change unlikely then you may be better off using a more traditional project management approach (e.g. PMBOK, Prince, Waterfall, Props).

The important thing is to question the approach up front rather than waiting to find out that it doesn’t give you the flexibility you need.

The best starting point for any project is the lessons learned from the last one. It will give you the best indication of how to improve your approach next time round. Bring together people who worked on your most recent project and have an open and honest discussion about what’s worked well, what’s been less fantastic and what are the things that you should have done more of. It doesn’t have to be a formal affair, but do make sure you get lots of different perspectives. It will give you a good steer on whether you need more or less process and documentation, whether you need to work together better as a team, or whether you’ve got it exactly right.

Just remember, there’s not a method in the world that’s suddenly going to make all your problems go away. And no process should ever become more important than the project itself.

Key Finding

Tailor your approach to the needs of the project and the culture around you, and don’t ever let process take over.


Agile

Agile is not a specific project management methodology, it‘s an umbrella term to describe a collection of software development approaches which share common principles documented in ‘The Manifesto for Agile Software Development” (2001).

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

In his book ‘Agile Software Development Ecosystems’, Jim Highsmith is keen to clarify that Agile approaches aren’t dismissive of processes and tools, comprehensive documentation, contract negotiation and following a plan. However the Manifesto places less importance on these things than its core principles.

In practice this translates into software and project management approaches which tend towards the following characteristics:

Collaborative and communicative working style Delivering prioritised features first Close team relationships Close working environments Frequent releases of working code Multiple iterations of relatively short ‘time-boxes’ Testing and correction as part of the ongoing process Individuals taking ownership for estimating and delivering their own work Continuous involvement of the customer or end user in the development

process Documentation only when necessary Project Manager manages an environment not a process

The purpose of agile methods is to be lean and flexible, implementing ‘barely sufficient methodology’ to navigate the chaos within a business. However, Agile should not be mistaken for being just a reactive philosophy, it is about embracing change as an opportunity to get ahead of the competition.

“We often use agile when the client isn’t able to provide requirements, we need to drive the requirements out and need to discover what we’re building really

quickly. You need to consider what teams you’re working with agile gives you a lot of client contact, they are part of the team not just signing off and reviewing

information.”


PMBOK

What is it?The Project Management Body of Knowledge (PMOK) is “the sum of knowledge within the profession of project management.” and forms the basis of the Project Management Institute (PMI) accreditation.

It is not a methodology, but a continually growing resource of project management best practice and forms the definitive guide to the specific skills and techniques required of a project manager. The PMBOK Guide provides detailed information on key processes, techniques and tools for managing projects, covering nine knowledge areas;

Project Integration Management Scope Management Time Management Cost Management Quality Management Human Resource Management Communications Management Risk Management Procurement Management

All of these knowledge areas can be universally applied alongside any other project management methodology. The processes, on the other hand need to be tailored to suit the individual requirements of the project.


Scrum

What is it?Scrum is an Agile methodology, developed by Ken Schwaber and Jeff Sutherland in the late 1990s. It was a deliberate push back against projects “overburdened with phases, steps, tasks and activities (with documents to support each).” and project managers who are forced “to pretend that they can, plan, predict and deliver”.

Scrum works on the assumption that unpredictable things will happen, and that the development process needs to be flexible to respond to the changes. It’s regarded as one of the more project management oriented methods, as opposed to XP which has more focus on software programming practices.

A Product Backlog is created which highlights all the features and requirements for the product. The Product Owner prioritises the Product Backlog, and selects which items should be in the next product release. At the Pre-Sprint planning meeting the Product Owner identifies which features should be included in the next 30-day Sprint, and the development team works out what tasks are required to deliver those features. It is then up to the development team to calculate how much of this can be accomplished within the Sprint given the available resources and negotiate the final features of the sprint with the Product Owner. Each Sprint is given a defined business objective to enable the team to stay focussed on what the sprint is trying to achieve rather than getting lost in the detail.

Once the Sprint Backlog is agreed there are no changes during those 30 days, except for in exceptional circumstances.

At the commencement of a sprint team members sign up for tasks, and they all work towards the Sprint Goal. Progress is monitored in a 15 to 30 minute daily Scrum meeting of all the team members and managers, which has the simple agenda of;

1. What was achieved yesterday?2. What will be achieved today?3. What is blocking progress?

This enables the Scrum Master to monitor the progress of the Sprint and address any issues that are preventing progress.

At the end of the 30-day Sprint there is a post-sprint meeting to demonstrate features to the customer, review progress of the project and decide which features will be progressed to live. Then it starts all over again with planning for the next Sprint.

Roles and responsibilities


Scrum Master – Most akin to a Project Manager, their primary responsibility is to ensure the productivity of the Scrum Team and remove any obstacles to progress. Product Owner – Officially responsible for the project, controlling the Product Backlog and prioritising the features for development.

Scrum Team – This project team organises itself in whatever way necessary to accomplish the goals of the Sprint. Each member of the team is responsible for creating the Sprint Backlog, estimating and delivering tasks and highlighting barriers to success.

Customer – Participates in determining the product backlog and reviewing the outputs of the sprint at the Post-Sprint meeting.

Management – Participates in setting goals and requirements, making decisions at the Post-Sprint meeting and monitoring the Product Backlog.

Who’s using it?Organisations working in highly competitive, consumer driven industries. E.g. Technology, Communications, Financial Services. It’s also being adopted by Agencies and Consultancies.

Scrum is ideally suited to organisations that support collaborative and communicative ways of working, and to projects where there is a high probability of changing priorities and requirements, probably driven by aggressive competition and savvy, demanding customers.

What have people said about it?

“It minimises risk to the project because there is no attempt to make unreliable predictions about costs, resource, risks and schedules outside of the

predictable timescale of the 30 day Sprint.”

“The Business feels more in control of the project as they determine which features to prioritise for each Sprint backlog, and progress is communicated on

a daily basis.”

“The process encourages a positive bond between Marketing, IT and the developers. It’s collaborative and enjoyable.”

“Have to find the right developers and the right sponsors. Each person is responsible for their own output, so there’s a big cultural change. Much more

accountability.”

“Scrum is an intense way of working. For people inside the team, working in the Scrum is all absorbing and they struggle to manage business as usual

alongside involvement in a Scrum project. Scrum needs a dedicated project team.”


“3 week promises are easier to keep so expectations are handled in a more convenient way. Of course mistakes are made, but they are smaller. People over and under estimate their tasks but it goes both ways and equals out. If

tasks aren’t longer than 16 hours then this is easier to estimate. We work with factors e.g. if someone is estimating 16 hours and there’s high uncertainty such

as a new technology, then we add a factor so there’s no underestimation.”

“The team are able to work without moving goalposts for the 30-day sprint, but the business has the flexibility to change priorities in the next sprint. If an

important feature needs to be developed it’s only ever the next sprint away, rather than months away in a typical development cycle.”

“Particularly in the early days it is easy to get drawn back into a traditional way of working, and it requires discipline to stick with it.”

“Agile approaches have less risk. Waterfall is based on pure guesstimates, so there’s more risk to manage. Agile is more fixed in timeline and budget, so all

you have to manage is what you want in it. You can’t overspend or miss deadlines. The business controls what’s being delivered.”

“Developers can sometimes be over-optimistic in their estimates – it takes practice to estimate the Sprint Backlog accurately, and in the early Sprints

features often have to be dropped back to the next Sprint to accommodate this learning curve.”

“There were problems in the first spring because the business changed the scope every week, so nothing could get developed. The trick is to really button down requirements up front… now expectations are really well managed and if they [the business] aren’t sure about what they want they take something out

of the sprint. It puts pressure on the business to deliver solid demands.”

“There is a problem with the way scrum is supposed to be implemented, architecture design doesn’t fit within sprint development. What we do is get a big team round the table and get a design down in x days. So in sprint 1 we do the easy things, or sometimes the complex stuff and then start design and IA in

the next sprint. Translations and copy approval doesn’t really fit into the normal agile way of working, so we do this in sprint zero [a pre-sprint planning

stage]. Within sprint 4 we are ready to deploy, do UAT and go live.”


PRINCE2

What is it?

PRINCE stands for Projects IN Controlled Environments and was first established in 1989 by the Central Computer and Telecommunications Agency. PRINCE2 was launched in 1996 and was intended to provide guidance on all kinds of projects, not just IT projects.

The PRINCE 2 manual describes a PRINCE2 project as having the following characteristics: A finite and defined lifecycle Defined and measurable business products (requirements) A corresponding set of activities to achieve the business products A defined amount of resources An organisation structure, with defined responsibilities, to manage the

product

PRINCE2 is a framework for projects, articulating the ideal project and organisational structure to satisfy the minimum requirements of the project, and doesn’t offer guidance on specific project management skills and techniques. PRINCE2 comprises of eight processes and eight components which should be tailored to suit the circumstances of each individual project. PRINCE2 is widely known for its’ emphasis on upfront planning and documentation. At project initiation it is expected that there is a clear business case, a detailed solution, budget, schedule and process. Deviations from this are managed as exceptions.

To that end PRINCE2 is suited to projects that are well defined and have a low likelihood for uncertainty and change, and are less suited to projects where exploration and innovation are required.

The focus throughout the project is on the initial business case, and ensuring that the solution will realise the benefits articulated in the business case. The project is managed as a series of stages, often in a sequential waterfall way, and there are controls at the beginning and end of each stage. There is an emphasis on detailed documentation of all stages of the project as well as the solution itself, to the extent where there is a specific role with the sole responsibility of managing changes to all the documentation, the Configuration Librarian.

Who’s using it?PRINCE2 is the project management standard for government organisations, so it is the prevalent method amongst organisations working with the public sector. Its use is also widespread within financial services and not-for profits. It is the most frequently used formal methodology for managing web projects.



”I like the formality of Prince. It identifies clear deliverables. The culture of our organisation means that we would never use an agile approach, we’re too risk averse. We use Prince for our other development projects and we’ve never had

any problems.”

“The structure is ideal for projects of a large scale the requirements and responsibilities are pinned down up front. But it can tie you down too much.”

“You have to be careful that the process doesn’t come before the project.”

“Prince2 is good at identifying the stakeholders up front and getting sign offs on business requirements and scope. It’s less useful when you get into the

project, the documentation becomes too heavy.”

“Prince2 doesn’t deal well with curve balls. The projects are a bit like tankers, you need very strong conviction about requirements up front as the projects are inflexible once they are underway. And integrating with legacy systems

does cause issues.”

“Projects tend to be long. As requirements get de-scoped they get put on the back burner, so they can end up taking a long time to come to fruition.”

“Specification documentation is an issue. It can take so long to get ready and is too detailed for new people to get their heads around the project.”

“We originally used Prince2 because it’s an industry standard, and because a lot of our 3rd party suppliers worked in Prince2 it was easier. We’ve since

adapted it to a Lite version, so that projects take 3 months not 3 years, which gives us more balance and control.”

“Prince needs to be tailored to the situation.”

“Prince is ideal for large projects but overkill for small projects. A light touch suits 70% of what we do.”


Waterfall

What is it?

Waterfall is a software development process where each stage flows sequentially into the next. For instance, only when requirements are absolutely defined and approved does the design stage begin. The key stages are:

Requirements specification Design Construction Integration Testing and debugging Installation Maintenance

Organisations that use waterfall value the fact that ambiguities and defects are ironed out early on before any construction takes place. Fixing a problem when it is still an idea on paper is much less expensive than encountering issues whilst code is being written. This works well when it’s possible to set requirements and design in stone at an early stage.

Waterfall also puts a greater emphasis on documentation as a universal reference point for the solution; in theory anyone should be able to pick up a document and understand how the system works. It also means that if the project is put on hold, it can be resurrected at a later date.

However, the changeable nature of web projects means that it’s rare for a web project team to work with such certainty. Detailed requirements and solution design are frequently elaborated through iteration and prototyping, and working with new applications or technologies mean that there are frequently unknowns that can only be resolved through trialling solutions. Because of this, few organisations now run all their web projects in a purely waterfall way, and will introduce iteration at some stage of the process.

Who’s using it?

Waterfall is by 12% of respondents who represent a mix of industries.


“Waterfall works well if the scope is well defined, people in your surroundings and the delivery team have a full understanding of everything you do and there is little change and low uncertainty. It’s a solid approach – business analysis,

requirements, feasibility…”

“Waterfall often has a solid timeplan based on vague estimates, so when you come to later stages and start development then you have underestimated

timescales. Usually the testing period gets eaten into, which means you end up with poor quality in the delivery.”


“Waterfall works well for discrete pieces of functionality with a defined input and output which doesn’t require user interaction.”

“From a web perspective this isn’t iterative enough for successful projects. It doesn’t encourage collaboration in fleshing out the options and overcoming

challenges. Iterations give you checkpoints to help the business work out what they want. You don’t need to deliver 100% of requirements, just deliver what’s

most important first.”

“Waterfall process gave clear documentation and process in reaction to a lack of formality in the past.”

“The high level plan at the start gets the business thinking properly about their contribution. They know what workstreams they have to prepare. It helps to

get confirmed timings from everyone and sometimes triggers when they need to find out more information about something. However we still suffer with the

business failing to deliver on its commitments.”


XP – Extreme Programming

What is it?

Extreme Programming has been around since 2000 and is the brainchild of Kent Beck. It is best described as a software development philosophy, with associated values, principles and practices.

These are some of its defining practices;

Stories – Instead of requirements planning is done by describing units of functionality from the customer perspective e.g. “store the customer’s credit card details for next time they purchase”. These stories are estimated early on so the team understands the cost of each feature and can adapt or prioritise stories accordingly. Stories can be grouped into ‘themes’ of related functionality.

Sit together – XP advocates having the team working together in a single location to foster greater collaboration, communication and consultation.

Weekly and Quarterly cycles – Work is planned a week at a time, with a meeting at the beginning of each weekly cycle. The purpose of the meeting is to review progress, get the customers to pick a week’s worth of stories and sign the team members up for the associated tasks. Each quarter the team should reflect on the project and its alignment with larger goals, and identify the themes (groups of stories) for the next quarter.

Continuous integration – Changes are integrated and tested after no more than a couple of hours, on the basis that the longer you wait, the longer it will take to integrate and the more unpredictable it will become. (In the case of web, deploying to a test environment)

Test first programming – This means that the development team write the test for the feature they are designing before they write the code i.e. work out what the code will need to be able to do to deliver the requirement rather than write a test that they think their code will pass. The idea behind this is to prevent ‘extra features’ from being thrown into the code, and ensure that the code is evaluated completely objectively.

Pair programming - One of the more widely known and contentious practices, two people sitting at one machine, analysing, designing and testing code together. The idea being that it is better to innovate and improve ideas when not working in isolation.

Incremental Design – rather than do all the design first and then code, design the system every day against the needs of that day, knowing the outline of what is required for the future.

40-hour week – The philosophy of Extreme Programming is adamantly for work/life balance on the basis that an overworked team will produce code of a deteriorating quality.


Onsite customer – The customer is always accessible to the team in an XP project and is actively involved in the transition from story to code.

Who’s using it?

Organisations running web projects with a high degree technical complexity or innovation, typically those working in agencies or consultancies, and technology companies.


“High degree of customer acceptance because of the level of involvement of the customer”

“Ideal for managing change requests and frequent iterations.”

“Prototyping using XP stories works well to get complete understanding and buy in to what needs to be delivered”

“More biased towards software development than managing web projects per se.”

“The business culture affecting the development unit is a focal issue in XP. Any resistance against XP practices and principles on behalf of project members,

management or customer may be enough to fail the process.”


RUP (Rational Unified Process)

What is it?

Rational Unified Process (RUP) is an iterative approach which implements use cases and modelling to define requirements and lay down the architecture for the solution. There are six key practices articulated by Philippe Krutchen (2000), one of RUPs founders;

1. Develop software iteratively – Software is developed in small increments to allow risks and issues to be identified and responded to early on

2. Manage requirements – Identify changing requirements and highlighting those that have the greatest impact on the objectives of the project is a continuous process. Requirements are continuously prioritised, filtered and tracked.

3. Use component-based architecture – Components allow more flexible architecture and can allow the most changeable parts of the system to be isolated and more easily managed. Also, reusable components can save time for future development

4. Visually model software – Using a common visualisation method (UML is favoured in RUP) the system architecture and design can be captured unambiguously and communicated to everyone involved in the project

5. Verify software quality – Testing occurs at every iteration so defects can be identified early in the development cycle, greatly reducing the cost of fixing them

6. Control changes to software – Changes to requirements must be managed and their effect on the software must be traceable

RUP projects are divided into four phases; Inception, Elaboration, Construction, Transition. Inception establishes the scope, requirements and acceptance criteria of the project and identifies key use cases so that an outline solution can be devised. Elaboration is where the project plan and solution are articulated in detail and the stability of the proposed solution is assessed. Resources are fully estimated. During Construction phase all the components and features are developed, integrated and tested. The emphasis is on managing resources and costs, and building as rapidly as possible whilst still maintaining acceptable quality. The final Transition phase sees the release of the product to the user community who will provide feedback so that corrections can be made before subsequent releases. Any postponed features are also picked up again at this stage. Several iterations are often made, between beta testing, piloting and general release.

Who’s using it?Although not widely used by participants in this research the companies that have used it tend to be from the business services, financial services, technology or consultancy industries.


DSDM (Dynamic Systems Development Method)

What is it?

Dynamic Systems Development Method (or sometimes Dynamic Solutions Development Model) was developed in the UK in the mid 1990s and was originally based around Rapid Application Development (RAD). It recommends an iterative approach with an emphasis on being responsive to changing requirements and delivering maximum business benefit.

There are nine DSDM principles;

1. Active user involvement is imperative2. DSDM teams must be empowered to make decisions3. The focus is on frequent delivery of products4. Fitness for purpose is the essential criterion for acceptance of

deliverables5. Iterative and incremental development is necessary to converge on an

accurate business solution6. All changes during development are reversible7. Requirements are baselined at a high level8. Testing is integrated throughout the life cycle9. A collaborative and co-operative approach between all stakeholders is

essential

There are three phases in a DSDM project – pre-project phase, project lifecycle phase and post project phase. From the outset the project works from a list of high level requirements that have been prioritised by the business.

To promote collaboration and face to face communication the project lifecycle phase of DSDM uses prototypes rather than documentation to capture information about the solution. Once feasibility is established there are three main stages in the project lifecycle.

Functional Model iteration – Requirements are prototyped and the detailed requirements are fleshed outDesign and Build iteration – Prototypes are refined to meet all requirements and the code that will deliver them is written.Implementation – The code is deployed into the live environment

There is frequently overlap between functional model iteration and design and build. A time-box is set to constrain the length of time before benefit is delivered to the business, but functionality and resources are allowed to vary. The most important functions are prioritised over those that deliver less benefit.

One of DSDMs’ defining features is the emphasis on the project manager to establish the right environment for the project. It signifies a move away from the traditional climate where the project manager is effectively contracted to deliver a specific set of requirements against a plan that is defined up front, to a situation where the project manager agrees a process for refining and


delivering a set of high level requirements in the knowledge that priorities will change during the course of the project.

Who’s using it?Online betting, Travel and communications companies are more likely to use DSDM than other organisations. DSDM is less suited to projects which carry risk to personal safety e.g. healthcare because in DSDM the emphasis is on speed of deployment over extensive testing.


“(Used in conjunction with Prince) One of the problems has been giving too small timescales to things and sacrificing a lot of quality.”

“You need to really empower the key members of your team and let them know where to get decisions. You can’t punish people for taking things on their own

shoulders.”

“The most challenging thing about making the change was keeping the right people and not letting them revert to type. Also it’s difficult to abandon

waterfall altogether, not everything can be done in parallel.”

“Starting off with a new approach can be perceived to be risky but you de-risk it by not using new teams and new technology. Use people that have done it before, and bring in external consultants if necessary. They know where it’s going to go wrong ahead of time and they know how long things will take.”

“Sometimes the fact that we show our (internal) customers output from the project so quickly can be a problem. It’s about managing stakeholder

expectations – they can be a bit critical of the looks if it’s a bit rough and ready and don’t always have enough focus on what’s underneath.”


RAD (Rapid Application Development)

What is it?

Rapid Application Development (RAD) was developed to allow new applications to be built and deployed quickly, sometimes at the expense of features and quality assurance (although increased user involvement is intended to counterbalance this claim that quality is compromised). Consequently this approach is not ideally suited to projects where quality or safety is a chief concern.

What makes RAD fast compared to other methods is its’ use of three key management techniques;

Prototyping – allows results to be demonstrated early on and encourages collaboration and feedback from the end usersIteration – the solution is developed in increments based on refining the prototypeTimeboxing – focuses attention on delivery over all other considerations. Scope and functionality can change but the delivery date can’t.

The ideal project for RAD is one where business objectives are well defined and the team are experienced using the technologies involved. The ideal team is small, preferably six people or less who can perform multiple roles, and have the necessary authority to make decisions.

RAD projects consist of eight stages; Project Planning, Project Activation, Control Project, Requirements Planning, User Design, Rapid Construction, Transition and End Project, and typically last 60-90 days.

Whereas XP is focused on software development, RAD has an emphasis on data modelling making it better suited to back end data capture or integration projects rather than front end development.

Who’s using it?

RAD is more likely to be used by those working in financial services and technology companies.


“RAD can work for smaller projects but I’m nervous of a more iterative approach. I understand that it’s difficult to tie-in with user centric design.

Maybe it’s too technically focussed.”

The homegrown approach


In the experience of most of the participants of this research there is no single approach that is a perfect fit for all web projects. Many organisations have embarked on journeys of experimentation and adaptation to arrive at processes that work for them.

In some cases the ideal formula uses Agile techniques for the design and production stages of the project, but wraps it up within a more traditional framework. One of our interviewees works with a combination of DSDM (Dynamic Systems Development Method) and Prince. Here’s his description of how it works.

“We produce a business definition and solution document up front then go into a series of 15-20 day time-boxed cycles. These small cycles comprise of

prioritised requirements. There is an evolving document of the project which we produce using a tool called Select. Prince language is used to report back to

stakeholders but we don’t use it in the team on a day to day level.”

Other organisations, typically those working within a Prince2 IT environment, have developed a Lite version. Appendix 3 shows a detailed process flow provided by one of the research participants.

“The project mandate and project board have been kept but we have lost a lot of the documentation. Also we don’t do stage planning in the way that Prince

does. We have a project board for the whole programme and a project mandate goes to them for approval. The board acts as steering and exception

management. It includes the director of e-commerce, each function of e-commerce, sales and technology.”

Of course many organisations, particularly agencies, have used a framework based on the principles outlined in Ashley Friedlein’s book “Web Project Management: Delivering successful commercial websites” (2001). The diagram below illustrates the four key phases and eight work stages contained within a typical web project

Phase 1 Phase 2 Phase 3 Phase 4

Pre-production Production Maintenance

Evaluation

Project clarificati

on

Solution definitio

n

Project specificati

on

Content

Design and

construction

Testing, launch

and handove

r

Maintenance Review and evaluation

Key Finding

Few project management methods are a perfect fit. Many organisations find the ideal approach is to blend a combination of techniques and processes.Copyright © E-consultancy.com ltd 2006 76

5.7. Small projects need structure too

Generally speaking, organisations that deliver successful medium sized and large web projects have the right attitudes and culture in place to be good at delivering small projects too; communication, collaboration, effective prioritisation of resource etc.

The only real differences are the specific processes and tools required to see a small project through. Clearly invoking a full-blown methodology is far too heavy handed for something that only requires a couple of days work. However, if your organisation takes small web projects for granted and assume that they’ll just magic themselves onto the live server without a hiccup, you could be storing up problems for yourself in the guise of;

Lots and lots of reworking because people can’t be bothered to explain properly up front what needs to be done

Inflated costs (because of lots and lots of reworking) Changes that take 2 weeks instead of 2 days because everyone assumed

someone else was doing it A nasty little problem in the call centre /IT / operations – because nobody

had checked if there were any impacts for doing the change Annoyed stakeholders who can’t understand why something so small has

taken so long and cost so much money

In fact 7% of respondents don’t use any processes at all to manage their small projects! Essential tools listed by the rest of our research respondents are:

Steering committee – A regular meeting of those responsible for allocating resource to prioritise which projects should go ahead and in what timeframe

Impact assessment – Usually done in response to a change request, an impact assessment is where key departments review the proposed change to evaluate whether there will be an impact on their systems, people or processes. Risks and issues are highlighted up front and managed appropriately

Release schedule – A schedule of when changes are planned to be released to the website, ensures priorities are met and that the appropriate test environments are available at the right time

Resource plan – typically a GANNT chart, used to ensure that appropriate resource is available to implement the project

Change request – Usually a brief document outlining the objective and requirements of the change, which is then circulated to the project team to respond with the proposed solution, cost, timings and impacts

Timing plan – a proposed timescale for the project

Testing – Depth of testing depends on the extent of the change, usually a minimum of user acceptability testing


Requirements document – Sometimes called statement of work, this details the objectives and requirements of the project

The chart below illustrates how frequently these tools are used. The trick is not to overdo it and end up needing a process to manage the process.

Chart 14 – Tools used to manage small projects, by percentage of respondents

0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

70.00%N

one

Ste

ering

com

mitte

e

Impact

assessm

ent

Rele

ase

schedule

Resourc

e

pla

n

Change

Request

Tim

ing p

lan

Testing

Requirem

ents

docum

ent

Tools for managing small projects

% o

f re

sp

on

den

ts

(n = 471)

Each of these tools does serves a different purpose, but the two processes that seem to have the greatest positive influence on the success of the project are doing an impact assessment at the commencement of the project, and testing before going live, as illustrated by the series of charts below.

Conversely, not using any tools for managing projects seems to have a negative impact on success in most instances, particularly on customer satisfaction as shown in Chart 17 below.


Chart 15 – Impact of tools on ability to maintain integrity of systems

3.55

3.6

3.65

3.7

3.75

3.8

3.85

3.9

3.95

4

Baseli

neNon

e

Chang

e Req

uest

Requir

emen

ts do

c

Impa

ct as

sess

men

t

Testin

g

Timing

plan

Releas

e sc

hedu

le

Resou

rce

plan

Steer

ing co

mm

ittee


Su

cces

s sc

ore

ou

t o

f 5

Maintains integrity of systems

(n=471)

Chart 16 – Impact of management tools on ability to meet deadlines

3.45

3.5

3.55

3.6

3.65

3.7

3.75

3.8

3.85

3.9

3.95

4

Baseli

neNon

e

Chang

e Req

uest

Requir

emen

ts do

c

Impa

ct as

sess

men

t

Testin

g

Timing

plan

Releas

e sc

hedu

le

Resou

rce

plan

Steer

ing co

mm

ittee


Su

cces

s sc

ore

ou

t o

f 5

Meets deadlines

(n=471)


Chart 17 – Impact of management tools on customer satisfaction

3.7

3.8

3.9

4

4.1

4.2

4.3

Baseli

neNon

e

Chang

e Req

uest

Requir

emen

ts do

c

Impa

ct as

sess

men

t

Testin

g

Timing

plan

Releas

e sc

hedu

le

Resou

rce

plan

Steer

ing co

mm

ittee


Su

cces

s sc

ore

ou

t o

f 5


(n=471)

Chart 18 – Impact of management tools on effective use of resources

3.45

3.5

3.55

3.6

3.65

3.7

3.75

Baseli

neNon

e

Chang

e Req

uest

Requir

emen

ts do

c

Impa

ct as

sess

men

t

Testin

g

Timing

plan

Releas

e sc

hedu

le

Resou

rce

plan

Steer

ing co

mm

ittee


Su

cces

s sc

ore

ou

t o

f 5

Uses resource effectively

(n=471)


5.8. The essential project managers toolkit

Communication is the key to effective project management, and in the view of many of the research respondents, the simplest tools are often the best ones to facilitate this; phone, email, whiteboards, wallcharts, flipcharts etc. The most important thing is that the progress of the project is clearly represented in a way that is unambiguous and easy for team members and stakeholders to access.

Several software tools were mentioned by research participants, but only a handful are in wide use, namely MS Excel (93%) and MS Project (80%), and even these received a mixed response. 25% and 18.5% respectively see Excel and Project as essential to running their projects, whilst some commented that they found these software packages too inflexible to give them exactly what they need. A particular criticism of MS Project was that it only allows you to manage resource within a specific project, rather than have a programme wide view, and that users frequently had to export the Gannt charts into Excel so that it could be read by other users. Excel seems to be the universal tool of choice.

Basecamp, an online collaboration tool, was the next most popular piece of software, although it was only used regularly by around 7% of respondents. What Basecamp has in its’ favour is that it’s accessible online to all team members via a log-in, so there’s no need to pay for additional licences or download software. Its main features are a simple scheduling tool with email reminders, task lists, a shared document storage facility and an editable writeboard which can be used to collaboratively write documents involving contributions from the whole team.

Other tools listed by participants were; Primavera, Planview, Twiddlebit, Synergist, Studiometry, Prosight, Mindmanager, activCollab, Hydra, ACE, Nicu, Select, Rally, Hot Project and Project Kick Start.

It seems that although there is a wealth of software out there, project managers are yet to be seduced by them.

Key Finding

The project manager’s tools of choice are email, phone, wall charts and Excel spreadsheets. MS Project is in wide use, but not broadly acclaimed. Basecamp is the most popular tool for online collaboration, and it is cheap - $24 per month for 15 projects.


http://basecamphq.com/?referrer=586

http://basecamphq.com/?referrer=586

6. Helpful resourceswww.e-consultancy.com/topic/project-management/www.agilealliance.orgwww.gantthead.comwww.ogc.gov.uk/methods_prince_2__overview.asp

7. References

BooksBeck, Kent and Andres, Cynthia (2004), Extreme Programming Explained, Embrace Change, Addison Wesley

Highsmith, Jim (2002), Agile Software Development Ecosystems, Addison Wesley

Friedlein, Ashley (2001), Web Project Management, Delivering Successful Commercial Web Sites, Morgan Kaufmann Publishers

Berkun, Scott (2005), The Art of Project Management, O’Reilly Media Inc.

A guide to the project management body of knowledge: PMBOK Guide – 3rd ed. (2004), Project Management Institute, Inc

Managing Successful Projects with PRINCE2, 2005 Edition, (2005) The Stationery Office

ArticlesPekka Abrahamasson, Outi Salo, Jussi Ronkainen, Juhani Warsta (2002), Agile software development methods, Review and Analysis, VTT

Weinstein, Bob (2006), The Change Game, gantthead.com

De Carlo, Doug (November 24 2005), How Extreme Project Management is Different

De Carlo, Doug (November 2005), The Extreme Project Manager’s Leadership Role

Augustine, Sanjiv (2006), Getting Started with Agile Delivery

Ghosh, Gautam (2004), Agile, Multidisciplinary Teamwork

Peters, Tom (1991), Pursuing the Perfect Project Manager, TPG Communications


http://www.ogc.gov.uk/methods_prince_2__overview.asp

http://www.gantthead.com/

http://www.agilealliance.org/

http://www.e-consultancy.com/topic/project-management/

8. Appendix 1 - The state of the nation

8.1. Quantitative research highlights

Nearly half of all respondents (45.5%) do not have a structured approach to managing their web projects. This rises to 67% in the retail industry.

Nearly 58% of respondents say that their projects always achieve their goals, and yet only 21% of them say they always achieve deadlines and only 39% always achieve budget and a positive ROI. In fact over 8% of respondents never meet their project deadlines and nearly 6% never deliver their projects within budget.

Less than half (46%) work to an annual plan that is aligned with their overall business strategy and only 56% say that they share common goals with the rest of the business.

Nearly 80% say they involve the end customer in gathering requirements for their projects, and 72% involve the customer in testing, yet only half consistently achieve customer satisfaction with their projects.

Nearly 88% of respondents say that they set their requirements knowing that they are flexible to change during the course of the project and yet half of organisations say that changing requirements during the course of their projects is one of the biggest challenges they face.

Delivering projects quickly is important to 52% of respondents, but 75% say that their deadlines are flexible and will move during the course of the project.

Over 21% of respondents describe their projects as complex, with lots of new applications and technologies.

Respondents believe that communication is the most important factor in delivering successful projects, and that the most important skill of a project manager is to be an excellent communicator. People skills are considered more of a priority than technical skills.

Knowledge of different project management methods was considered by respondents to be the least important skill for someone managing web projects, which is supported by the fact that 22% of projects are managed by members of the marketing or commercial team rather than a qualified project manager.

Over 7% of people apply no processes or structure at all to managing smaller web projects and only 65% document their requirements up front. Those who follow no processes in managing smaller projects are consistently less successful than people who do.

Microsoft Excel and Project are used frequently by around half of all research respondents


8.2. Quantitative research results in full


9. Appendix 2 – Interview Script

Qualitative Questionnaire Discussion Guide

Section 1 - Your Web project team

1. Please tell us something about who manages your web projects:a. Do you have a specific resource for web project management? b. Do they have formal project management training? c. Which department/area do they report into? d. Who are they co-located with?

2. What do you think are the ideal attributes of a web project manager?

Section 2 - Web projects in your organisation

3. What do you think are the main differences between managing web pro-jects and other projects?

4. What processes do you use to prioritise project resource?5. What’s the approval process for your web projects?6. Who controls the budget for web projects?

Section 3 - Your Project Management approach

7. Do you use a specific methodology for managing web projects?a. How does this vary between projects of different sizes?b. What elements of this approach are successful?c. What elements of this approach have been problematic?d. What influences have led you to take this approach?

8. What tools do you use to manage web projects?a. How does this vary between projects of different sizes?b. What elements of this approach are successful?c. What elements of this approach have been problematic?

9. How do you ensure your projects deliver a quality product?10. What are the main challenges you face in delivering your web pro-

jects?

11. What tips would you give for running a successful web project?

Section 4 - The Future

12. What do you see as the main opportunities to improve the success of web projects within your organisation?


10. Appendix 3 – Questions used in online survey

Web Project Management Research

Phase 2 – Quantitative study

August 2006

The purpose of this questionnaire is to understand more about different approaches to web projects. The first section deals mainly with large web projects. e.g. more than 10 days of resource. There are some questions at the end of this survey which ask for more information about how you manage smaller projects.

About you.

1. Which industry sector do you work in?a. Financial servicesb. Travelc. Gamblingd. Retaile. Gamingf. Not for profitg. Business servicesh. Technologyi. Communicationsj. Agency/Consultancyk. Other (please state)

Managing significant web projects

2. What methodologies does your company use to manage web projects? Please tick all that are applicable

a. Noneb. Scrumc. Waterfall d. DSDMe. Princef. XPg. RUPh. RADi. EssUPj. Other (please state)


Please feel free to add further comments on this3. What informed your decision to take this approach?

a. organisation wide policyb. to integrate processes with IT / third party suppliersc. through researching or experimenting with different approachesd. experience from previous rolese. because changing it would be too difficultf. other companies use this approachg. initiative from Head of ITh. other (please explain)

Please feel free to add further comments on this

4. How would you describe the culture of your organisation? Please score your company against the following attributes with 1 as the least like your organisation and 5 as the most like your organisation.

a. Prepared to accept riskb. Innovativec. Empoweringd. Collaborativee. Communicativef. Other (please explain)


5. On a typical web project how do you manager requirements setting?a. Fixed from the start with changes difficult to implementb. Set at the start but flexible to change as we requirec. We do not work with any fixed requirements (please explain)


6. On a typical web project how do you manage deadlines?a. We have set deadlines which are not easily changedb. Deadlines are set at the start but flexible to change as we requirec. We do not work to deadlines

Please feel free to add further comments on this.

7. How important is it to deliver your projects quickly?a. Very importantb. It’s not the main priorityc. Not important at all


8. How technically complex are your projects?a. Most projects are not complexb. Some projects offer a degree of complexity and innovationc. Most projects are complex with lots of new technologies and

applicationsCopyright © E-consultancy.com ltd 2006 95


9. How would you rate the success of your projects on the following criteria? (Rank on a scale of 1 to 3, where 1 is never and 3 is always)

a. achieves goalsb. meets deadlinesc. meets budgetd. customer satisfactione. involvement of the end userf. embraces flexibility during developmentg. delivers ROI


10. To what extent are your web projects integrated into the overall business? Do you have the following….

a. An annual plan aligned with the overall business strategyb. senior sponsorshipc. cross-functional steering groupd. common goals with the rest of the businesse. programme managementf. business wide approach to prioritising resourceg. other (please explain)


11. At which stage is the end customer involved in your project. Please tick all that are applicable

a. requirements gatheringb. solution designc. front end designd. prototypinge. testingf. other (please explain)


12. What are the biggest challenges you face in delivering successful web projects – please choose the three most important ones.

a. unrealistic expectations from the business/stakeholdersb. lack of senior sponsorshipc. no clear project management processd. obtaining resource and keeping hold of ite. business unable to articulate requirementsf. changing scope or requirementsg. lack of project specific skills or competenceh. poor user inputi. business fails to give input or provide content on schedulej. poor collaboration between the business and ITk. Development team underestimate scale of work


l. Other (please state)


13. How important are the following in delivering a successful web project (score 1 to 5)

a. Having a defined processb. Small and frequent iterations of workc. Tailoring the approach to the circumstancesd. Following process in a disciplined waye. Involving the end customerf. Communicationg. Prototypingh. Staying focussed on objectivesi. Deliver priority requirements firstj. Excellent project managementk. Co-location of project teaml. Flexibilitym. Other (please state)



14. Who manages your web projects?

a. Project Manager in E-commerce/ web teamb. Project manager from Project Management teamc. Project Manager from the IT teamd. Outsourced Project Managere. Member of the marketing/commercial teamf. Other (please explain)


15. How important are these attributes in a successful Web Project Manager. Please rank them on a scale of 1 to 5 with 1 being the least important.

a. Technical knowledge and skillsb. Commercial knowledge and skillsc. Persistenced. Excellent communicatore. Good listenerf. Negotiatorg. Focussed on the end goalh. Good at coaching othersi. Motivates the teamj. Flexibilityk. Leadershipl. Knowledge of different project methodologiesm. Other (please state)


16. What tools do you use to help you manage projects. (score on the following scale; never used, use rarely, use occasionally, use often, this tool is essential)

a. MS Excelb. MS Projectc. Basecampd. Hydrae. ACEf. Nicu g. Selecth. Rallyi. Hot Projectj. Project kick startk. Other (please tell us what it is and how you rate it)


Managing smaller web projects

17. What tools / processes do you use to manage small projects e.g less than 10 man days. Please tick all that are applicable.

a. noneb. change request form


c. requirements documentd. impact assessmente. testingf. timing plang. release scheduleh. resource plani. steering committeej. Other (please state)


18. How would you rate the success of your small projects on the following criteria (score 1 to 5)

a. achieves goalsb. meets deadlinesc. meets budgetd. customer satisfactione. speed to deliverf. uses resource effectivelyg. maintains integrity of web systems and architecture


Contact Details

Providing your details is optional, however, if you do give us your name and e-mail address we will forward you a free copy of the Web Project Management Survey results as soon as they are published.

19. Name

20. Your job title

21. Company Name

22. Size of organisation?a. 1-9b. 10-24c. 25-49d. 50-199e. 199-500f. 500+

23. Email address

Thank you for your time.


11. Appendix 4 – Example of in-house adaptation of Prince


Have an idea for a project

Complete Project Mandate

Scope what is required with the

BA

Make Live

Test

Get it approved

Project closure

Deliver the project

Gain sign off from sponsor

Complete the Initiate Project

documents

10 Steps for Project

Management

Formulate the idea and collate the information required for the project mandateDiscuss with the project sponsor

Send Project Mandate to Programme Manager Project Mandate discussed at following weeks steeringDecision sent to Programme Manager

Work out business requirementsWork out solutionWork out benefits and costs

Complete the PIDComplete the Business CaseComplete the Project Plan

Produce Work PackagesRaise Change requests for work packagesMonitor ProgressUpdate the Project PlanMonitor and act on Issues

Update Project Plan and create Test PlanProduce Work PackagesRaise Change Requests for Work PackagesMonitor progressMonitor and act on Issues

Confirm project closureEnsure BAU handover completeArrange Project Closure MeetingProgramme Manager produce End Project Report

Produce weekly Highlight Reports




web project management best practice guidelines

Documents

web project managers

project deadlines

project goals

small projects

nonexistent projects

quantitative research

structured approach

key findings