Is your Web team big enough?

In the pioneer days of the Web, only the 'dot com' companies required a dedicated Web team. As for the rest of us, we could get by with a lone Webmaster. Likely the Webmaster role was just a part-time responsibility - someone who knew how to use Dreamweaver and could ftp the occasional photo or press release to the site.

Fast forward a dozen years and you probably have more folks publishing to the Web, but are you properly staffed to manage the site? Will your organization have the resources to execute your vision for the Web? How many people does it take to run a Web site these days?

We typically work with organizations that have large sites (by large I mean more than 500,000 files) and one thing they all have in common is a dire lack of dedicated Web personnel. Sure, they have lots of content contributors and even one or two folks who are full-time on Web production, but it's rare to find a true Web team. Why? Because in many organizations the Web program hasn't yet matured. Senior leadership hasn't quite accepted the Web as a formal business function to be managed. To them the Web is an ad hoc project or something that runs in the background. How it runs is taken for granted.

Here's an example. We were once working with a global organization with a Web presence that spanned more than 1,000 Web sites. Ownership of the Web fell to Communications and the senior VP of the group actually believed that the entire Web presence was run by one person from her desktop. What's more, he couldn't understand why she couldn't make a new design template automatically populate across all their sites. As unbelievable as that story may sound, I bet Web managers who are reading this are thinking, "that happened to me!"

As organizational expectations for the Web continue to grow, Web managers will increasingly find themselves having to make the case for additional staffing support. So, how much staff do you need and how do you convince the boss you need them? 

There is no proven formula to determine Web team headcount and there is very little benchmarking going on either. But in general, every Web team should account for four key functions:

1. Web Program Administration:
overall management of the Web program

2. Web Product Management:
designing and driving the Web presence

3. Web Infrastructure:
day-to-day Web production and operations

4. Managed Publishing:
training and support for content contributors

How these primary functions are fulfilled will vary by organization. There's no such thing as an industry standard for Web team headcount. You'll need to first evaluate how well your existing Web team provides the above functions then come up with a staffing plan to shore up any gaps. Here are three things you can do to help determine how to staff your Web team.

 1. Evaluate the Web team against stated business objectives.

Let's say you're an association and there is a new initiative to start continuing education courses online. Working backwards from that vision, you should think through all that will be required to meet the objective. Aside from content, you'll need to consider support for tools, infrastructure, training, R&D...etc. This approach will help you map resource requirements to targeted outcomes. It will also help with your business case because you're making staffing requests in the context of business goals specific to your organization rather than trying to argue a 'best practice' or industry standard.   

2. Understand the difference between project and program needs.

It's not uncommon for people to start evaluating their Web team during a major re-design effort. That's generally a time when the Web is high on the management radar and there's more opportunity to discuss funding for the Web program. The pitfal to avoid is thinking that the level of effort during a site transformation will be the norm. Migrating to a new look and feel or implementing a new technology platform requires a lot of heavy lifting. You will need a dedicated team to manage this process and execute the change, but the Web team requirements will likely shift once the implementation is complete. As you define your Web staffing needs, you will have better luck with management by showing them how you plan to ramp down on staffing once you reach the steady state. 

3. In-house, outsourced or hybrid?

One final consideration is to figure out what functions can be outsourced and what should be done by in-house staff. Some organizations still completely outsource the Web program. This model can work well if you have a good service level agreement and take advantage of tools like a Web content management system to support your in-house contributors. The challenge with an outsourced team is that you can't always guarantee you'll get the expected level of service and costs may vary with rate changes. 

At the other end of the spectrum is the full in-house team. The advantage here is all your Web resources are under one roof and dedicated to your Web presence. Depending on your Web needs, management will need to determine where the Web team sits (under Communications, IT, standalone?) and the number of FTEs may be significant.

In most cases, even if there is a dedicated Web team, it's likely there will be some outsourced support as well. This approach allows the Web manager to staff up as appropriate on special projects or fill the need for functions that don't quite require a full-time employee. A hybrid approach can be the best overall solution, but in general, you will want to make sure key functions such as program administration and Web product management are filled in-house.

Before you take on the next big Web project or seek funding for the Web program, take a moment to do an honest evaluation of your Web team. Are you properly staffed to fulfill basic functions? What are the liabilities to the organization if you're understaffed? What opportunities are you missing out on because you lack human resources? Going through this kind of assessment can help you as a Web manager to make smarter choices when it comes to staffing your Web program.