How to Plan Manpower on a Web Team

This is a re-print. The original article is on AlistApart website. There's also a good discussion of the article in that site. I just wanted a copy in my blog so I can search for it easily when I need it. Yup, sometimes I'm not that good on bookmarks, coz there are billions of articles to read on.

************************************

It can be tricky to identify the right levels of manpower for a web team. Indeed, many organisations badly underestimate the amount of work required to keep their sites operating smoothly—they perhaps imagine that once a website is put live, it magically looks after itself. As a result, only the barest bones of proper staffing are put in place.

Fortunately, the problem of defining the number of people required on a web team is not insurmountable. A useful device for arriving at a good answer is the concept of “website scale.”

Step onto the scales


Website scale is a means of describing a site in terms of three parameters:

* size
* complexity
* level of activity

Almost any online venture can be represented in this way—from a small intranet to a massive e-commerce site. The reason website scale is so useful is that it provides a practical means for estimating the number of people needed to carry out the activities of site maintenance. This includes content publishing, feedback monitoring, technical maintenance and general quality assurance.

For example, consider the websites of the British Broadcasting Corporation and the Icelandic TV channel, Ríkisútvarpið RUV. Even a cursory review will show that the BBC site is far greater in scale than that of its Icelandic equivalent.

That is, www.bbc.co.uk has more pages, uses a wider variety of more complex technologies, and receives substantially more traffic than www.ruv.is. It can therefore be concluded that a greater number of people are required to support it. The actual amount can be gauged by examining each of the elements of website scale.

Why size matters

In simple terms, the bigger a website is, the more people are needed to maintain it.

Yet, how can the “size” of a site be measured? Is it simply a total of all the megabytes of data it contains? Or, perhaps a count of the number of pages it has online?

In fact, neither of these is satisfactory. A website could contain hundreds of megabytes in just a few video files. Another might host thousands of pages, but each might consist of only a few words.

As a consequence, the best way of calculating website size is the total number of man-hours required to produce and maintain all of that site’s content. This can then be used to estimate the number of people required for support, particularly in the areas of content publishing and quality assurance.

Calculating man-hours


For instance, it may take 3 hours to create and publish a 500 word feature for an intranet; information about medical benefits, for example. This content would then be scheduled for review every six months (to ensure it remains accurate), at a cost of 30 minutes per review. Therefore, an intranet of this type requires 3.5 man-hours to produce and maintain a 500-word article.

If 100 new features of this type are planned, 350 man-hours (eight and a half weeks) are needed for production and review. Given that the average number of man-hours available per person per year is about 1,750, we can now see how staffing is calculated.

For example, the content described above could be maintained by a single person over the course of a year, with plenty of time to spare: 1,750–350 = 1,400.

Although this math is fairly straightforward, recommending precise levels of employment is more complicated because of the ways in which websites differ from one another. For example, a site that contains a lot of video or highly technical content may need far more time for production than one that holds simple generic text.

The general rule is that any site containing a lot of frequently changing features will need far more staff than one with only a few, static pages. The following table shows indicative staffing levels for the three most common grades of website size.




























Figure 1. The three grades of website size
Website size Man-hours Staffing level
Small 1,500–4,000 About 1–2 people
Medium 4,000–10,000 About 2–4 people
Large 10,000+ From 5 people upwards


Complexity by progression

Differences in manpower can also arise as a result of the technology used to develop a site. This is because intricate websites usually require several people in the area of technical maintenance. In this way, we can say that there are three levels of site complexity.

Basic

Often referred to as “brochureware,” this is the most straightforward type of website. Such sites merely contain information in plain text (HTML/XHTML) hosted on a webserver, with perhaps a few supporting images and downloads. The uncomplicated nature of such sites means they are relatively easy to maintain. A single person with low-level skills may often be enough.

Dynamic

On a dynamic website, content is stored in a database and published according to the requirements of site visitors. Such sites are frequently used by businesses that publish large volumes of information in a standard way, e.g. news organisations. However, (within the terms of the definition used here) it should be noted that a Dynamic site does not allow transactions, i.e. there is no ability to “log on” or to “buy.”

Although the user experience of a dynamic website is similar to that of a Basic site, the technology that underlies it is much more involved. As such, a team of two or three people with good technical skills may be needed for a medium-sized entity of this type.

Transactional


A transactional website is one that uses the internet to host applications in support of business operations or revenue generation. Indeed, some of the world’s best known sites use this as a model for their operations, e.g. Dell.com.

Not all such sites are vehicles for the exchange of money. For example, many corporate intranets can be considered transactional because of the interactive features they contain: timesheets, expense submission, etc. The variety of technology used in transactional sites (application servers, security systems, etc.) means that a team of highly qualified staff is needed for support. Indeed, the largest and busiest sites often employ half a dozen or more people.




























Figure 2. The three levels of website complexity
Website type Complexity Staffing level
Basic Plain content (HTML/XHTML) About 1 person
Dynamic Dynamically generated from a database About 2–3 people (or more on a very large or busy site)
Transactional Fully-transactional content, e.g. e-commerce From 3 people upwards (many more on a large or busy site)


The impact of activity

Website activity is the last and possibly most important factor for planning manpower on a web team. Busy sites inevitably have to deal with mountains of feedback, customer problems, and general issues of upkeep. As a result, complexity has a very strong influence on staffing across all areas of maintenance. It can also have the effect of rapidly multiplying the manpower estimates recommended by website size or complexity.

Two common means for measuring online activity are page impressions and the number of visitors. As a general rule, a site must receive a minimum of 1,000,000 page impressions or 100,000 visitors per month to be considered busy (although many receive far more than that).

The result of such heavy activity means a site is unlikely to function properly without a full complement of maintenance personnel. Indeed, a busy site that is also large in size and transactional in nature may need dozens of staff to keep it up and running.























Figure 3. The three levels of website activity
Level of activity Page impressions
Quiet 0–50,000 a month
Intermediate 50,000–1,000,000 a month
Busy 1,000,000+ a month


Many managers simply don’t understand why some website require a substantial maintenance staff—and this can lead to chronic understaffing. Overcoming this attitude is among the greatest challenges to be faced by a web team; with luck, the principles outlined in this article will help.

Popular Posts