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#section2
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#section3
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#section4
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.
| 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#section5
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#section6
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#section7
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#section8
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.
| 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#section9
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.
| 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#section10
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.
The technology behind the website also matters. As it was said in the article in general a database based website needs a higher staffing than a static one. But it can be vice versa as well, if a big website is build with static pages you will not be able to make changes to the structure without touching each single page. So complex technology can also descrease the maintenance. The important thing is that you have to design the infrastructure as you design the layout or as you have a design phase doing software development.
considering the usage of the term ‘web team’: does this only include editorial stuff, i.e. folks who are writing and reviewing content, or does it include technical staff (sysadmins…) too ?
I tried to apply the articles’ rule of thumb to my largest project to date (http://play.fm, an audio archive), and the numbers look plausible…
interesting read!
Good Conclusion:
bq. 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..
I believe this article is a good starting point for entrepreneurs/web developers. But I’m not to sure about the _estimates_ made in the article. Overall a Nice Article!
The first consideration should really be the roles required before looking at manhours. Based on my background, I’m thinking of developers here, and even then it could be broken down into specialized db, backend and front-end developers, or maybe it’s just a team of UI developers doing integration, etc etc.
Thanks for the positive comments. Ref team numbers, I admit that they are somewhat subjective (reflecting the difficult nature of manpower planning!) The numbers noted were arrived at from discussions with other website managers. Many of these mentioned how under resourced they were. As such, a bias in favour of larger teams may be built-in. In that sense, it is possible for a team to operate successfully with lower numbers.
Great article. It really touches on a huge gap in the fundamental understanding of websites as projects vs. products. Projects have a distinct beginning and end. Products have more defined business objectives, lifecycles, roadmaps and projects that fold into it. Even after educating customers/mgmt on the value of web specific roles (IA, SEM, etc), it’s still a challenge to educate on the ongoing operational management and change the “˜fire and forget’ mentality.
Love the constructs of the article and it will be helpful for me in 2007 planning (VP of Marketing just asked me how we can accelerate our progress on web projects.) I admit I was expecting some sort of summary that would tie your premise together e.g Small x Med Complexity x Low activity = X people. Do you have any thoughts there?
According to the estimates in this article, I’m doing four people’s jobs, which feels about right 🙁
What would be great is some kind of advice as to helping non-techie managerial types understand this reasoning. I am the sole web person in our theatrical company, and handle the online marketing, sales and development; 40% of our sales are made through the website. As a comparison, about twenty five people are employed in our box office, along with their managerial structure and technical team.
This seems extremely disproportionate to me but it’s very difficult to impress on long-standing, traditional managers that web business is as important as offline business. Any advice?
In an organization that has no budget (or will) to hire more staffers this “manpower estimation” can be worked in reverse. That is to say something like, “based on how much you’re willing to budget, here’s the type and size of Web site you can have.”
I would love for someone to publish a follow up article to the tune of “How to get the necessary manpower to round out your web team”.
Some of us are wearing so many hats these days that it’s hard to focus on any one area anymore. As they say “Jack of all trades, master of none”.
Ian,Scott – obtaining adequate manpower involves a lot of managerial education. Experience suggests that a large number of website managers simply have no idea of the tasks involved in site maintenance or development. In this sense, it is our task to advise them, so that they can build accurate budget submissions for their managers (and so on up the line). I am releasing a book in July that explores many of these issues in more detail. This includes an overview of all the skills, technology, processes and precedures involved in site management. Visit my site http://www.diffily.com for more about this.
Mike – as regards overall team staffing, the formula is exactly as you suggest. I have done some work on this, though it can be dangerous to suggest ‘exact’ numbers (because of business idiosyncracies) – so I have deliberately steered away from it. I suggest you use the numbers from this article as a baseline but modify them with reference to your own circumstances.
What about self employed front end/backend designers/developers. i would love to tell my clients they need to cough up more money so i can bring on an extra guy to do their site and im not cheap relatively speaking so i dont think im watering down the field where price is concerned, but its really hard for guys like me not to be a jack of all trades.
good article though, will keep this under the belt for business growth. thought i have to agree with others in the case that making a site dynamic (using backend database to supply content) has been a god send for me in content and site management, i really would not have been able to make it on a couple sites i maintain without that knowledge and set up.
This article accurately states the problem of articulating web staffing needs to management. Anyone who’s been doing this work for a few years probably started out producing static sites of a few dozen pages that evolved into dynamic sites containing hundreds to thousands of pages. But as long as you, the webmaster, keep things humming along, there is no perception that staffing levels are no longer adequate to meet the needs of maintenance and development of new web applications. Letting things fall apart is obvioulsy a poor strategy for convincing your management that more staff are needed, so an approach like the one Shane offers is probably the only safe bet. While I’m not sure that I agree with the accuracy of all of the meausrements suggested, I think they’re a good starting point.
This article is great for small to medium sized businesses. My problem is that I work for a university that has over academic 144 departments, multiple webservers and more than 3,000,000 page views and about 550,000 unique visitors a month (just on the main web server). Each college has it’s own support staff for their site and content is centralized within each department. I’m actually part of the group that manages the CMS which the campus is slowly migrating to.
So.. seriously… how do we determine our staff needs on this scale? Currently our centralized team can generate about 340 man-hours of work each week and we’re still feel like we are behind in some areas given the volume of work that is needed.
This article make sense. It’s right that start from small.
David, I think you are on the track to an answer yourself. You seem to have calculated your man-hour requirements – from that you can arrive at a figure for staffing.
But, I know that things in big companies aren’t always so simple! I suspect your situation reflects what many web managers have to cope with. A large fragmented organisation with multiple departments controlling different aspects of site support. If I am right, you probably have no central team charged with overall site governance (or if there is, it is somewhat toothless).
Loose management structures make manpower planning more difficult, because cumulative activity is harder to measure. For example, if 10 different teams are doing similar work at various levels of intensity, overall effort is likely to be under- or over-stated.
My ‘idealistic’ reaction is to review & consolidate management structures first and then set about planning manpower. Only when definite management systems are in place can staffing be planned properly.
My ‘pragmatic’ reaction is to establish if all the activities of site management/maintenance are being effectively carried out, as things stand. If so, staffing is adequate. If not, more are needed. Just how many more depends on how much time (manpower) it would take to get things right.
This is good article with some high-level information about staffing a web team. Does anyone know of any more good information out there with more specifics?
For example, I am the the sole Internet/Java developer for an insurance company of about 50 employees. This website was originally created by consulting company that specializes in Oracle/Java. The website uses the entire OracleAS 10g suite of tools (Portal, SSO, AppServer, Database, etc) for a rather complex dynamic-transactional website.
This insurcance company has hired me to basically “take over” the day-to-day programming and maintenence of this website, since the consultants are charging them an arm and a leg, and I’m finding I am in over my head!
I basically need to find more documentation that will back me up that we need to hire a couple more people before they turn this monster loose!
Any ideas and thoughts would be appreciated.
Jerrware
Jerald, I suggest you make a list of the activities involved in site maintenance and tick off all the items that you can cover, based on your skills and time availability. Any gaps may mean more staff are required**. An outline of the main tasks of site maintenance are available on http://www.diffily.com – though this does not cover everything involved in site ‘management’, which is a much broader area. (I am releasing a book later this month that addresses many of these extra activities).
** – One thing we should all note, additional staff may not always be needed. For example, improvements in existing processes or the purchase of new technology (e.g. WCM) could be enough to fill in any gaps.
bq. 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.
The estimates are definately off and those reading the article should be given a disclaimer first 🙂 Many administrators often understimate the amount of time required to produce articles. As the manager of a web team for a few years, I’ve found that feature articles can take a week or more to produce, including interviews, photo shoots, etc.
Something as complex as information about medical benefits could take far longer than 3 hours, and the periodic review will likely happen by a few people in an organization, adding to the time.
The concept of the article is solid — just be careful and be realistic about time needed to produce new content. Sticking said content on the website, whether using a CMS or static HTML, is usually far less time consuming than producing the content, thus MY team is growing by adding content producers.
Mike, you are right. The figure of 3 hours was just an example may well be different in real life.
This was an interesting article but in my experience teams are a thing of the past and most websites are made by one person maybe two tops,unless your working for a big time organization CNN ESPN etc.And if your reading articles online on how to effectivly organize a team then your probably not going to get the job in the first placea nd more than likely all spots have already been filled at all the top organizations already.
Umm…, this smacks of not taking into account the lessons of “The Mythical Man Month”: As you add people to a project the complexity of completing that project, no matter how simple, increases exponentially (my exteremely quick summary of one of the main lessons of the book). I agree that the basic math works out, but there is always a lot more to getting something done by division of labor amoungst other human beings which always manages to make things much more complicated than they need to be.
I think many web developers have struggle with manpower planning, especially for large projects.
I often forget that the busier the website – the more time it takes to maintain. You brought up some good points to keep in mind when planning web development projects.
Thanks!
Good article! Resourcing has always been the bane of any system development. As someone who’s been in IT development for 33 years (yes I really am 38!), this whole question is not new and nobody has ever come up with an ‘A x B x C = D people’ answer. Major consultancies still get it wrong so it’s no surprise smaller WebCo’s find it perplexing. I’ve worked on projects from > 300 people down to my current team of 5. Shane’s figures seem to fit our company as we’re involved in heavyweight, transactional J2EE Web systems — but then we have our own product for doing the development work which has taken 6 years to build and cuts our timescales and costs right back. Without it, I’d be looking at a team of probably 12 – 15 just to cope with current workloads, let alone other projects. I think anyone contemplating major transactional, high performance, high hit-rate Web systems should err on the high numbers side from personal experience. But then don’t ignore the increased management effect that higher staffing will require.
Great article, but I wonder if you’re aware how alienating the language is?
I’ve worked in a web-related job for over ten years now; for the first six I wasn’t part of a team at all – one of the reasons I was interested in the content of your article. In common with other public services, many of the people I work with either as editors or page authors are female. It might seem like a small point, but while the subject matter should be of interest to anyone on a web team, I didn’t feel you were really talking to me.
It’s 2006 – surely we’ve moved on a bit?
I calculate the necessary mandays the following way: ask a developer of your team. Multiply his estimation with the number of years he is away from 5 years work experience. Triple the result and that’s a good start. 😉
Great article, although a few years old, still relevant!
Does anyone have a useful web based tool for resource management, I literally cannot find a thing. We use Basecamp for pm stuff, but would love a resource hook in.
cheers
Ian