Discuss: How to Plan Manpower on a Web Team
by Shane Diffily
- Editorial Comments
2 Untitled
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!
posted at 01:29 pm on June 20, 2006 by Michael Kamleitner
3 Nice
Good Conclusion:
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!
posted at 05:06 pm on June 20, 2006 by Raj Anand
4 Probably echoing other comments...
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.
posted at 05:26 pm on June 20, 2006 by Mark Reeves
5 Team numbers
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.
posted at 06:10 pm on June 20, 2006 by Shane Diffily
6 Tip of the Iceberg...
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.
posted at 02:52 am on June 21, 2006 by Rob Grady
7 Calculates to...?
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?
posted at 04:32 am on June 21, 2006 by Mike Hoefer
8 Interesting stuff.
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?
posted at 04:08 pm on June 21, 2006 by Ian Ferguson
9 Flipside
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.”
posted at 05:39 pm on June 21, 2006 by John Lascurettes
10 Good starting point for discussion...
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”.
posted at 06:53 pm on June 21, 2006 by Scott Maira
Discussion Closed
New comments are not being accepted, but you are welcome to explore what people said before we closed the door.
Got something to say?
Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.
Create a new account or sign in below if you’d like to leave a comment.
Subscribe to this article's comments: RSS (what’s this?)
1 Technology also matters
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.
posted at 11:45 am on June 20, 2006 by Andreas Berg