If you have read any of my recent articles you should be familiar by now with the concept of Website Scale.

Website Scale is a means for classifying sites of different types into groups based on shared underlying characteristics. These characteristics are:

  • Size
  • Engagement (i.e. traffic or online activity)
  • Complexity
An image of the concept of website scale

The usefulness of this concept is that it can predict similarities in Web Governance between sites that superficially seem to be quite distinct, but in fact have many features in common.

For example, consider two websites - one a cancer charity (e.g. macmillan.org.uk) and one a retailer (e.g. bhs.co.uk). You may think that they are so distinct that each requires quite a different solution in terms of Governance.

However, when examined more closely we find that they are both large in Size, they generate a lot of online Engagement and use highly Complex technology.

BHS and Macmillan regarding Website Scale

In a sense, it does not matter that these sites have different content & audiences, they are so similar in Size, Engagement & Complexity that they deal with essentially the same basic Governance problem.

In fact, there are enough similarities between sites of the same Scale to allow us sketch out Governance solutions that work across the board, including core skills, numbers of staff, team structures, etc.

For example, in my last article we explored a typical configuration of Governance as seen on many Mid-Large Scale government, corporate and non-profit sites in the UK.

The benefit of this commonality is that whenever you need to plan a new system of Governance for your own site (or update one already in place), you don't have to start from scratch. You can simply work out the Scale of your site and then build from examples that already exist.

But to do so we need to learn a bit more about the concept of Website Scale itself.

The heart of Web Governance

Website Scale lies at the heart of a model that describes everything needed to build a successful system of Web Governance. This model consists of:

  • 4 Primary Activities...
    These Activities describe everything you must do to manage a website effectively.
  • 4 Pillar Resources...
    These Resources describe everything you must have to support the above activities.
  • Website Scale...
    This determines how to configure the Activities & Resources into a workable system.
How website scale can be used to plan Web Governance

The good thing about this model is that it is applicable to any online venture, no matter what it is about or how big (or small) it is. The elements within the framework always remain the same. The only difference is that the granularity & sophistication by which the Activities and Resources are carried out varies as a factor of Scale.

For instance, consider the Web Governance needs of two businesses at the opposite ends of the online spectrum. Mom-n-Pop versus MegaCorp.

MegaCorp's online presence is huge. Mom-n-Pop's is tiny.

An image of contrasting website scales

Despite the enormous difference in Scale, both sites need to carry out the same basic Governance Activities (maintenance, development, etc.) and provide the same core Resources (people, tools, etc.) to make things happen.

While MegaCorp may have to configure a fulltime team and buy expensive software to expedite all their activity - Mom-n-Pop simply hire a student to update their site once a week using readily available Freeware tools.

So we see that while the core Activities and Resources on both sites are the same - the granularity and sophistication by which they are implemented differs hugely.

That is why Website Scale is such a powerful tool for Web Governance. It enables us to recognise and plan for these differences in a structured and predictable way.

Scale scaled up

To date most of my writing on Website Scale has been confined within The Website Manager's Handbook and on AListPart - and is admittedly somewhat dated.

In this article I want to share the revised metrics I use for assessing each of the parameters of Scale.

As you will see, these are based as much on experience as on sources of data, and are also non-linear in progression, i.e. they do not grow in a straight line. This is because of the often huge differences between sites of different Scale. For example, a busy site such as Vodafone.co.uk may attract orders of magnitude more traffic than a quiet site such as this one.

I also want to show that Scale can grow at varying rates along each parameter - i.e. growth in Size may not be matched by similar growth in Engagement or Complexity - and how this can impact on Governance planning.

Let's start by exploring what I believe is the hardest parameter of Scale to quantify, Website Size.

A. Website Size

In simple terms, the bigger a website is, the more of everything that happens and the more of everything that is needed to maintain it.

But how to measure the Size of a website? Is it a total of all the megabytes of data it contains? Or 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 or be host to thousands of pages, though each may contain only a few words.

An image of Size as a grade of website scale

The best way I have found to measure Size is to estimate the total effort (as recorded in Full Time Staff Equivalents) needed to expedite core site operations. This includes:

  • Planning, creating & publishing new content.
  • Designing, coding & testing new features.
  • Day-to-day supervision, QA, feedback, performance monitoring, etc.
  • General project management.

The benefit of this measure is that it does not bias towards a particular type of site.

For example, a site that produces low volumes of complex content (video, games) can be labelled 'Large in Size' in the same way as a site that creates high volumes of basic content (text, pdfs). This is because the total effort needed to expedite core tasks for each is the same.

The steps to create an estimate of total effort are:

  • Estimate the average time needed to expedite each maintenance & development task.
  • Apply those estimates to the volume of work being carried out by the Web Team.
  • The end result is measure of total effort.

Let's take a crude example to show how this works...

Over the years I have learned that it takes anything up to 6 man-hours* to create one newly written page of online content containing about 700 words. This includes research, writing a draft, sending for review/approval, incorporating changes & publishing online.

If you consider a site that publishes the equivalent of 250 new articles per year, that adds up to approximately 200 man-days of effort - or the guts of one Full Time Staff Equivalent (divided among writers, reviewers, designers, etc.)

Add to that the needs of other specialist developments, ongoing site maintenance, project management, etc. - you can see how total operational effort can ramp up quite quickly.

* This estimate may seem high, but most clients grossly underestimate the time needed for content production. Indeed, if content in formats other than text is required, it can take even longer, e.g. video, audio, flash. To help plan your content, download my 'Web Content Production Calculator' for free :)

Of course, obtaining accurate work estimates on a Web Team is not easy. Consequently, guesstimates based on samples of activity are often the order of the day. These guesstimates must then be tempered by further analysis and sanity checking with staff.

Despite such caveats, the output is generally worthwhile as it serves both as an indication of relative Size and as an exposé to (often startled) Senior Management about the staff & skills investment needed to keep the show on the road.

Based on my experience of UK and similar web operations, the Size metrics I use are as follows:

i. Small Size

A manpower requirement of 0.20 - 2 fulltime equivalents is needed to expedite core maintenance & development activity.
Example: Many, many sites operate perfectly well with 1 or 2 people at the helm (though these people do require a broad range of skills.)

ii. Mid-Size

A manpower requirement of 4 - 8 fulltime equivalents for maintenance & development.
Example: Macmillan.org.uk

iii. Large Size

A manpower requirement of 10+ fulltime equivalents* for maintenance & development.
Example: Vodafone.co.uk

* As in my previous article, this does not mean that a Web Team requires 10+ people for operations, but that it takes the equivalent time & effort of 10+ people working fulltime for everything to work. Some people may be hired on a part time or contractual basis.

B. Website Engagement

Website Engagement is a measure of activity on a site. Although it can be assessed in a variety of ways (Page Impressions, Visits, Conversions, Shares, etc.) the commonly accepted metric I use is that of Visitors, i.e. the number of unique or repeat browsers that come to a site.

Engagement is included as a parameter of Website Scale because as a site grows in 'busy-ness' it inevitably has to deal with increasing numbers of queries, problems and general issues of upkeep. This can have a considerable knock-on effect on the granularity of Governance Activity & Resourcing.

An image of Activity as a grade of website scale

For example, consider a busy news website with lots of content that invites interaction with its articles. As well as expediting standard maintenance tasks, the Web Team can expect to devote significant extra time to moderating comments, engaging with visitors, responding to issues, etc. This effort will only increase as the site gains in popularity.

Inevitably, it is quite difficult to obtain all the traffic statistics necessary to create a global spectrum of online engagement. Nevertheless, some indicative analytics is available (for example, here & here & here) and combining this with industry experience, a series of metrics can be suggested.

In the context of the UK market therefore, the brackets I use for delineating Website Engagement are as follows:

i. Low Engagement

Such a site logs anything below about 50,000 unique visitors per month. Many, many organisations fit this category and some sites can record very low traffic, e.g. this one :(

ii. Mid Engagement

A site of this type records visitor numbers of approximately 75,000 to 750,000 per month. In my experience, a high percentage of corporates, nationwide charities and government sites fit this category, e.g. Macmillan.org.uk

iii. High Engagement

This may record anything above 1,000,000 unique visitors per month, e.g. Vodafone.co.uk (Of course, many sites far exceed these figures.)

Note: Please note that these figures are rule-of-thumb only. The aim is not to produce precise numbers (though that would be nice) but to guide deliberations about the type of Governance system that is needed to support a site.

C. Website Complexity

Perhaps the easiest of the three parameters of Website Scale to quantify is that of Complexity.

Complexity is a measure of the sophistication of the content and other technologies used on a website, including hosting.

An image of Complexity as a grade of website scale

Website Complexity affects Governance in the sense that as a site becomes more intricate, the more specialised become the skills that are needed to look after it.

For example, if we consider the basic Mom-n-Pop site again, its technical requirements are so simple that a 'Jack-of-all-trades' Webmaster with a low-level IT qualification could easily set up a webserver and manage content via FTP.

However, as the site becomes more complex it demands someone with application, data and security expertise. These specialist skills come at a premium and probably lie outside the ability of the original Webmaster. As such, new staff are needed.

In this way, Website Complexity may be separated into three levels as follows:

i. Basic Website

Often referred to as 'brochureware', such sites contain information in plain text with perhaps a few supporting images and downloads. No interactivity is included. Their uncomplicated nature also means they are relatively easy to maintain.

In many instances, this activity may be outsourced to a web host provider. Alternatively a part-time contractor with standard skills may be all that is required.

ii. Dynamic Website

On a Dynamic website content is stored in a database and published using server-side scripting, e.g. PHP, ASP, JSP. Such sites are used to publish large volumes of information in a standard format. A good example is my own website LikePlace.ie which contains thousands of 'pages' but where all content is based on a just a few HTML templates linked via server-side scripting to a database.

Although the user experience of a Dynamic website may be similar to that of a Basic Site, the technology that underlies it is much more involved. As above, a small & quiet site may be satisfied with a part-time contractor to look after things, though busier sites of this type may require 1 or 2 people with good technical skills.

iii. Transactional Website

A Transactional website is one that uses the internet for facilitating operations or generating revenue, e.g. Vodafone.co.uk. However, not all Transactional sites are monetary in nature. For example, many intranets can be considered Transactional because of the features they contain, e.g. timesheets, expenses submission, etc.

As with a Dynamic website, a Transactional site requires highly skilled staff. For example, a large & busy site could employ 2 or more people to perform all technical duties. The largest and busiest such sites frequently hire many, many more.

Putting it all together

It is tempting to imagine how all websites could be classified into 1 of 3 types:

  1. Small Scale  =  Small Size  +  Low Engagement  +  Low Complexity (Basic)
  2. Mid Scale  =  Mid Size  +  Mid Engagement  +  Mid Complexity (Dynamic)
  3. Large Scale  =  Large Size  +  High Engagement  +  High Complexity (Transactional)

And in fact, that is what we do see in many cases.

For example the sites below can (broadly) be defined as being Small Scale, Mid-Scale & Large Scale based on an analysis of their apparent Size, Engagement and Complexity.

What this means is that - without knowing anything else about these sites - we could begin to make recommendations for Web Governance that would work for each.

For example, in the last article we learned about common patterns of roles, responsibilities and team structure, and how these evolve as a site grows in Scale (reproduced below). We can apply those lessons here to suggest additional Governance solutions to sites of varying Scale.

Small Scale

An image of a small scale site

The Governance needs of Diffily.com are similar to many business websites. Such sites are of such a Small Scale that 1 person with low level skills, working part-time (1 day a week or a couple of hours a day) and using readily available Freeware tools can easily keep things ticking over. For organisations with a strategic focus on the web, 1 - 2 FTEs may be required.

An image of a small scale team

Mid Scale

An image of a mid scale site

There is quite a big step from a Small Scale to a Mid-Scale site. As explained in my last article a single 'Web Guy' simply does not have the time or skills to expedite all the tasks needed to manage a such a site. As such, more people must be hired and a formal Web Team created.

The structure of this team will follow the outline as shown previously, though with a smaller manpower requirement. Total effort could be estimated at 10 - 12 Full Time Equivalents.

An image of a mid scale team

Large Scale

An image of a large scale site

How high can you go?

My experience of UK and Irish sites tends to suggest that the Largest Web Teams weigh-in with a manpower of +/-20 Full Time Equivalents (although some sites are so Big, Busy & Complex that dozens of people organised in regional, national and global teams are required to keep the show on the road).

The Governance challenge on such large teams cannot be understated. Excellence in all aspects of the Primary Activities and Pillar Resources are required, including well defined roles, documented procedures, professional tools and excellent leadership.

An image of a large scale team

Mixing it up

While it is nice to think that all sites could fit into one of the above models, there is no law that says each parameter of Website Scale must grow at the same rate. As such it is very common to find sites of Mixed Scale, with a consequent knock-on on their required system of Governance.

For example, consider a site such as the Gàidhlig language version of the Scottish parliament website.

This site contains large volumes of content based on a complex architecture - but is low in visitor activity due to its restricted target audience. As a consequence the manpower needed to expedite maintenance is lower than for a similarly sized site with a larger reach, due to the fewer visitor interactions and other issues that arise.

An image of the scale of the Skyscanner

Similarly, consider the website, Skyscanner.net.

Skyscanner uses highly complex technology to deliver airline schedules to a very large audience in multiple languages and currencies. Yet, the amount of actual content created by Skyscanner itself appears to be very low. The vast majority of content is automatically generated using scripting.

What this suggests is that - although Skyscanner has a large manpower requirement for technical, coding & other services - it requires a different skills mix than seen on a typical Mid-Large scale site, especially for content production.

An image of the scale of the Gaelic language version of the Scottish parliament website An image of a large scale team

Conclusion

Website Scale is a tool to assist in the creation of a Web Governance system that works for you.

The main strength of the concept is that can clarify thinking about what is needed for a site of a certain Scale, as well as estimate some outline manpower and skills requirements.

However, it is not infallible. You must be remember that local factors (such as internal politics, budgets & organisational preferences) will play as big as a role as any fancy formulae of Website Scale.

As such, you should consider Website Scale as a useful means to an end, but not the end in itself.