One thing has become clear over the last decade – large web projects inevitably run over budget, move slowly and often fail to deliver. Fortunately new approaches are emerging that buck this trend.
Fruugo spent €40 Million on their site and generated only €100k. Birmingham City Council spent an unprecedented £2.5 million on its website, running more than £2 million over budget. The UK Trade and Industry website cost a staggering £11.78 per visit, while Boo.com spent $135 million of venture capital in just 18 months.
There are no shortage of failures like these, from Myspace to the UK Business Link website. However, lessons have been learnt and large web projects are now handled in a different way. It is this new approach that is being adopted by Headscape and the University of Strathclyde in the work we are doing together. An approach given new prominence by GOV.UK and now being emulated around the world.
In this post I want to explore how this approach works within Strathclyde and the benefits it brings.
Let’s start with the concept of work packages.
One of the major reasons large web projects fail is because they become too unwieldy to define in detail. The normal specification process fails when faced with such complexity and so many stakeholders.
The way we have avoided this problem is not looking at the University of Strathclyde as a single project. Instead it consists of a number of work packages that seek to meet different business objectives. For example one business objective for the University is to highlight its research expertise. This objective has become the basis for our first work package.
Instead of trying to consult with every stakeholder about every aspect of the Strathclyde website, and specify how the entire website will work, we focus on defining just one package. We talk to just those stakeholders interested in research and focus just on meeting the needs of users interested in research. Only once that is done will we move on to the next work package.
We define these packages not by writing long specifications, but with user cards.
A user card is a statement of what a user wants to do on a site. They consist of three parts:
- Who the user is.
- What they want to do.
- Why they want to do it.
For example a user card might be:
- I am a prospective postgraduate student interested in nanotechnology.
- I am interested in viewing what postgraduate courses Strathclyde teach in this area.
- So that I can compare Strathclyde to other universities before making a decision about where I wish to attend.
Each work package is made up of a prioritised list of user cards that the development team systematically work through.
Of course, these user cards do not include enough detail to define the work to be done. That is why the development team and key stakeholders work together to define acceptance criteria for each card. In other words, we define the criteria by which the card can be judged complete.
In the example above the acceptance criteria would define the exact information our postgraduate student is interested in, and how that information needs to be accessed.
Only when all of the information is available and it can be easily found will the card be considered complete.
With our lightweight specification in hand, defining everything that needs building for the first work package, we can now begin work. This is done in a series of sprints.
A sprint is a small package of well defined work that will be completed over a short time period. In our case most sprints last a week.
Large projects with deadlines in the far future tend to slip, because the amount of work is too large and the deadline too far away for people to have any sense of perspective. By breaking the work into small chunks it helps focus the team as they push towards a single short-term aim.
For example, one of our first sprints was to complete half a dozen user cards relating to research. This involved building key pages scattered across the site as well as the core of a research section.
Where possible the entire team sits together in a room working on the sprint. The group constantly collaborate and feedback to one another, so preventing delays as one team member finds themselves waiting for a response from another. At the end of each day the team meets for 15 minutes to report back on what they did that day, what they intend to do tomorrow and any barriers they have encountered. This ensures the entire team is working unimpeded.
This team is not just made up of those building the site. It also includes stakeholders and business specialists who have knowledge for the current work package. Of course getting these people into a room for a week can be tricky so some forward planning is required.
While the majority of the development team is working on the same sprint, one or two individuals are looking ahead at upcoming ones.
Somebody needs to schedule in the stakeholder participation we need, and that means looking beyond the current sprint. It is their job to research into what will be coming up on the horizon and make sure we have all the people we need.
There is also a need to identify any dependancies we may encounter further down the line. These typically constitute content that needs collecting or access to systems with which we will need to integrate.
Finally, we have found it useful to have somebody considering the upcoming UX challenges. By doing at least some user interface thinking up front, it means that we can move much quicker when a sprint begins. Otherwise developers can be left waiting for the designer to finish.
Although no approach is ever perfect, the results have been encouraging and the experience inline with that of the Government Digital Service.
We have found the team works more efficiently, momentum is maintained and rapid progress is achieved.
What is more we have achieved a feedback loop that ensures the quality of what we are outputting remains high, but more on that in my next post.
“Gantt Chart With Hand Holding Pen” image courtesy of Bigstock.com