27 Reader Comments

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.

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.”

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 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.

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!

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 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.

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.

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.

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. ;-)