Thursday, July 06, 2006

How to Plan Manpower on a Web Team

How to Plan Manpower on a Web Team








How to Plan Manpower on a Web Team


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


Staffing depends on management buy-in




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.

No comments: