A risk framework for web-based application development

July 2011

Here are the primary risks drawn from the 120 item framework developed as part of my MSc in Software Development, see summary here. I was interested in whether web project managers in digital agencies should manage risk 'just like IT projects', for which documented models exist, or take a differing approach. This table shows the highest-rated risks from the framework I developed

The main risks identified fell within the following five areas:  

  1. Team or agency (company) issue
  2. Issue with the client
  3. Requirement and specification issues
  4. Technical issues
  5. Issues with project timing 

This is summarised below. The average column refers to the rating scale used (1 = highest risk, 5 = lowest), therefore the lower the score the higher the risk.

                   
ID Risk itemsAverage
Team / agency
1.1There is a lack of internal team communication between individual team members2.21
1.2The project requires new or unfamiliar ways of working2.25
1.3There is little or no culture of disciplines / departments being held accountable for project problems2.43
1.4The agency is over committing2.71
1.5The agency / disciplines have previously been able to get away with doing things badly / slowly2.83
1.6This type of project has not been done before by the agency3
Client
2.1The client regularly pushes for new functionality and changes2.25
2.2Unrealistic up-front estimates have previously been given to the client2.33
2.3The client does not understand the technical implications of their project requirements2.71
2.4The project is high-profile or politically sensitive within the organisation2.74
2.5The client lacks experience in web projects2.92
2.6There are frequent scope changes2.79
2.7The client lacks technical knowledge3
Scope and Requirements
3.1There are many unknowns2.38
3.2There is insufficient initial budget to deliver what the client wants2.5
3.3The technical scope is too ambitious / optimistic2.73
3.4There is confusion over scope or deliverables2.74
Technical
4.1There are strict client technical policies2.43
4.2There is poor technical support of the infrastructure2.48
4.3There are many organisational policies in force (i.e. data, legal etc)2.74
4.4There is political interference in technical decision making2.78
4.5Integration is required between many different technologies2.91
4.6The team is using unfamiliar tools / technologies / platforms2.91
4.7There are internal network or development platform issues3
Timing
5.1The agreed launch date is unrealistic2.74
5.2Key tasks on the timeline are allocated too little time2.96

For an overview see the study summary here

| Home |