'If you work on a web team, you need this masterclass. Clarifying, affirming, practical!' Susanna Guzman, Web Director CFA

In the last article we explored the elements that underlie all systems of Web Governance. These are:

The 4 Primary Activities of Governance, which are supported by...

The 4 Pillar Resources of Governance, which are configured based on...

The Scale of the website in question.

Let's briefly recap how this works...

As we learned, the same Primary Activities happen on all sites no matter how big or small they are, and no matter what they are about. These Activities are:

Leadership

Development

Maintenance

Infrastructure

In addition, the Pillar Resources required to support these Activities are consistent across all sites:

People

Processes

Tools

Budget

Differences in how these Activities & Resources are applied in practice (i.e. how they are configured to produce a workable system of Web Governance) arise principally as a factor of Scale.

(Other factors such as local culture, politics, legacy, etc. also play a role.)

Website Scale

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

Engagement

Complexity

Size

The usefulness of this concept is that it exposes similarities between sites of different types and thus allows us to plan Governance for them in essentially the same way. For example...

If I am looking at a Large-Scale site (i.e. one that is very busy, very complex & very big) I know that its Primary Activities will be highly granular, which as a consequence requires that its Pillar Resources be configured in a very sophisticated way (i.e. with complex teams of highly skilled people using expensive tools following documented processes) and supported with a large budget.

This broad arrangement of Activities & Resources will be the same no matter what a site is about. If two sites are of a similar Scale (e.g. an online retailer or a government agency), they will share many of the same features of Web Governance.

So in a sense, knowing the Scale of a site is the first step for building a new Governance system - or for assessing the suitability of one already in place.

Let's start the Healthcheck...

The aim of a healthcheck is to assess whether the essential Activities of Governance are being carried out to the level of granularity & quality required for your site (based on its Scale), and whether these Activities are supported with the right level of resourcing.

In short, you are looking for gaps or deviations from the type of Governance system you would expect to see. To make this judgement you need to conduct your audit from 3 angles:

Establish the Scale of your Site

Audit your Governance Activities

Audit your Governance Resources

(It should be noted that these Activities occur to some extent concurrently, not in strict sequence.)

Step 1 - Establish the Scale of your Site

The first step for conducting a healthcheck is to establish the Scale of your site.

With this information you can arrive at immediate conclusions about the type of Governance it needs. Furthermore, if you know how its Scale is expected to evolve over time, you can predict how Governance needs to keep pace. For example...

If a Small-Scale site is growing fast (e.g. increasing its online audience, producing more content or utilising complex new technologies) investment in Governance will need to keep pace perhaps by acquiring new skills or building more complex teams.

As we have seen Scale is a measure of the Size, Complexity & Engagement on a site. By using Scale as a metric, we can classify the websites of many different organisations into groups based on shared underlying characteristics.

It does not matter what these sites are about. If they are of the same Scale, they will share the same basic Governance requirements.

In rough terms there are 3 levels of Website Scale: Large, Medium & Small. The detail is explained here, or else you can skip ahead to continue reading.

A. Large-Scale

Engagement

Engagement is a measure of the 'busy-ness' of a site, i.e. traffic, sales, conversions, etc. It is included as a measure of Scale because as a site grows in 'busy-ness' it inevitably has to deal with increasing volumes of customer queries, technical concerns & general issues of upkeep.

In this way it has a strong influence on the granularity of Governance Activities as well as on many support Resources, such as staffing & processes.

Complexity

Complexity of a measure of the sophistication of the content and hosting technology used to support a website. As a website grows in intricacy it typically requires larger numbers of personnel to look after it, who also need expensive tools & complex procedures to keep the show on the road.

For example, highly complex websites allow for online transactions, incorporate a lot of personalisation (login), use many content formats (flash, video, audio, RIA, forums, wikis), and additionally deploy large and highly robust infrastructures to support all of the above.

Size

In simple terms, the bigger a website is, the more of everything is needed to maintain it - people, processes, tools & budget. But, how to measure the size of a website? Is it a total of all the megabytes of data it contains? Or, perhaps a count of the number of pages online?

In fact, neither of these is satisfactory.

The best way to measure size is to estimate the total effort required to manage production/development activity, i.e. to create & publish content, as well as design & code new features. For example, a large website may require anything above 15 fulltime equivalents to expedite all such operations on an annual basis.

Note: this does not mean that the Web Team requires 15 people for production, but that it would take the time & effort of about 15 people working fulltime for everything to work. As we will see, a team may be smaller than this but hire additional staff on a contract basis to address short term needs.

B. Mid-Scale

Engagement

Complexity

Such a website typically allows some personalisation, including content dynamically generated from a database with server-side scripting - but does not allow for online transactions & has a relatively simple architecture.

Size

A mid-Scale website requires an average of 8 fulltime equivalents to expedite content production, design & coding on an annual basis.

C. Small-Scale

Anything below a Mid-Scale site may be defined as Small-Scale. Typically these have quite low traffic, use very simple technology (brochureware) and have a manpower equivalent of 1-2 people for just about everything.

(Of course, permutations of each of the above categories is possible, i.e. a highly complex website of low traffic and medium size.)

Once you know the Scale of your site you can begin to assess its Governance needs. For example...

If you find that you manage a Large-Scale site, it is inevitable that each of the Activities of Web Governance will be highly granular (i.e. each subtask will be very detailed) and demand significant investment in skilled people, sophisticated tools and complex teams for the site to be a success.

If that is not what you see, something is wrong. For example, if you notice that important Maintenance Activities (e.g. responding to feedback) are being delayed or forgotten, it is likely that the quality of the site is suffering as a result.

So, let's now look at all these Activities and explore the granularity you should expect for sites of different Scale.

The only difference is that the granularity of these Activities increases as Scale increases. That is, as a site grows the 4 Primary Activities become more detailed and sophisticated.

During this part of the Healthcheck you are seeking to establish if - based on the Scale of your site - the Governance
Activities you expect to see are being carried out to the level of granularity and quality required. For instance, if you manage a Large-Scale site, are all the Activities of Web Governance and their associated subtasks being completed to a high level of detail?

Let's use an example for illustration.

Consider the Activity of Maintenance. This Activity contains the subtask of Publishing.

On a Small-Scale site - such as that for a City Museum - nothing more sophisticated than a couple of articles and a few images may be published each week. At this Scale, one person working part-time with relatively simple web skills will be adequate for all Publishing.

In fact, this person may also be responsible for design, coding & other tasks which also happen on an ad-hoc basis. In this case, we can say that the granularity of Governance Activity is quite low.

In contrast, a Large-Scale site - such as that of a national retailer - likely contains huge volumes of content in many different formats (images, video, audio, flash, etc.) using sophisticated technology (personalisation, login, ecommerce, online forums, etc.) aimed at different, widely dispersed audiences.

At this Scale, the Activity of Publishing is highly detailed with many updates being implemented all the time. This inevitably requires a substantial team of experienced professionals (writers, video editors, etc.) who work continuously at developing & managing content using expensive tools and following a formal editorial procedure.

In this case, we can say that the granularity of Governance Activity is quite high, because many staff are deployed to work at individual parts of a single task.

So, as Scale increases you expect to see greater & greater granularity for each Activity of Governance.

How to check

The attached Healthcheck Cheatsheet is a useful tool for checking what to expect for a site of a given Scale. It lists all Governance Activities & their Subtasks.

To check if Activities are being completed to the level of detail required, simply fill in the name of the person(s) who implements each subtask. Then also take note of the following:

Are relevant processes defined?

What tools or technology are in use?

What to look for...

If you manage a Large-Scale site, you should expect to see every task being completed and these tasks to be divided among several people, who use expensive tools and follow formal procedures.

However, if you find tasks that are being overlooked, gaps where no-one is fully responsible or discover the same name appearing again and again for unconnected tasks - it implies that granularity is not sufficient to the Scale of your site. Any such findings can be used as initial recommendations for change.

Let's take another example to illustrate what I mean.

If you manage a Mid-Scale website, you may find that the task of Quality Assurance (e.g. checking for broken links, missing metadata, etc.) is a problem. For example:

It is frequently overlooked.

No-one is really responsible for it.

It does not follow a formal process.

It is not automated.

Your first recommendation should be to allocate QA to a staff member, state that it needs to be expedited at a particular frequency (e.g. daily), define a review process and invest in a new automated checking tool. The same applies for all other tasks.

Of course, all this may require a significant investment in new Resources. But what if such Resources are not available, or are inadequate to the job?

This brings us to the final part of our audit.

Step 3 - Audit your Pillar Governance Resources

Now that you have established if the necessary Activities of Governance are being carried out, you can investigate whether the supporting Resources are adequate to the job, given the Scale of your site.

You should recall that the 4 Pillar Resources of Governance are:

People

Processes

Tools

Budget

We have already gathered some preliminary information about how Resources are allocated among Governance Activities. This helped us to establish the following:

If each task is being completed.

Who (if anyone) is doing it.

What tools they are using.

Whether they follow a formal process.

We can now question in detail whether the Resources allocated to these Activities - and the way in which they are configured - are adequate to the Scale of the site, both now and in the future. That is, if your site is expected to grow, will resourcing keep pace (more staff, more tools, more budget)?

How to check

The following represent the type of questions you should explore for each Pillar Resource:

People

Are enough staff on your team to cover each Governance Activity?

Do staff have enough time to complete each of their individual tasks?

Do staff have the necessary skills & training to do the job?

Are roles & responsibilities sensibly delineated and defined in terms of scope?

Are staff structured into appropriate teams with clear reporting & control structures?

Tools

Do staff have access to the tools, technology and other supports required to do the job?

Processes

Are procedures and other internal standards by which Governance Activity is expedited properly documented and updated in a controlled manner?

Budget

Is adequate budget available to cover the main costs of Governance (i.e. staff & tools) as well as online development ambitions?

Among the things to look for in your findings is any evidence that implies lack of time, money or attention to the needs of Web Governance. For example:

Do web staff have to manually complete tasks that could readily be automated at low cost, e.g. with a QA or CMS tool?

Are procedures for important actions undocumented, e.g. data backups. If not, it implies an uncertainty that could lead to serious complications in the event of a problem.

In particular we are looking for evidence of unreasonable pressure on staff.

The Importance of People

People are the #1 most important Pillar Resource on any web team.

Hire good people and they will find innovative ways to stretch your budget & use technology to get the maximum bang for buck.

Yet, there is only so much they can do. Too many web teams are run on wishful thinking. Indeed, the only thing that often keeps the show on the road is the flexibility & adaptability of staff who work quietly (too quietly) to keep things going.

The problem with this is that when things go wrong, they can go badly wrong.

If a key staff member goes on long term sick leave or some online initiative demands excessive staff attention; no redundancy is available and important tasks are overlooked. A team that has been stretched to the limit suddenly snaps - everything falls apart.

With this in mind, the following are some examples of what to look for during your audit of People:

After adding all the time needed to complete the Primary Activities of Governance, are there enough people on the team (with the right skills) to do all tasks?

Does site quality suffer due to inadequate staffing, e.g. overlooked tasks.

Does the team have to rely on expensive contracted labour to help complete developments?

Such investigations - although time consuming - are often quite straightforward. You are simply assessing the Resource 'balance sheet'.

If you find that essential manpower or skills are missing for a site of your Scale, you should submit a recommendation for investment (and inform senior management that site quality will suffer if it is not forthcoming).

However, it is when your audit delves into aspects of roles, responsibilities & teams, that a range of subjective factors can complicate decision making.

The Problems of People

Take the situation where a Web Team has grown from a 1-man operation into a multifunctional team.

While uncontentious mismatches of responsibilities can easily be put right (e.g. a coder who has traditionally managed analytics but wants rid of it), you may also encounter arrangements where changes to longstanding roles are vigorously resisted, e.g. a content producer who retains control of look-n-feel rather that surrendering it to a new designer.

This type of situation often arises where senior management has displayed little interest in the web. As a consequence, roles have remained poorly defined and responsibilities have not been updated to keep pace with changes in Scale.

One day - perhaps as the result of some minor incident - people fall out and the web team stops working. Someone like me is then hired to try to patch things up.

It is an invidious position to be put in.

While the emphasis in such cases is on designing a Governance system that works, magic wands do not exist. Sudden, enforced changes to roles & responsibilities on a web team are as disruptive as in any other part of a business. Good people who have worked hard over many years may find themselves side-lined or edged out. The trauma is always the same and the prescription generally painful.

It is my belief that we are currently working through a period of heightened conflict, as the legacy of historic mismanagement is finally exposed and put right.

On the bright side this means that disruptive change is likely to become less common in future as web management increases in professionalism. So, if you find yourself in a webteam-cum-warzone at the moment, don't be too down hearted.

Conclusion

While the Healthcheck above cannot expose every issue of Governance, it will help you to set a baseline for making things better.

For example, if you find that the Resources allocated to support the Activities of Governance on your site are inadequate to its current (or future) Scale, then you should at least be able to explain why to senior management. If management accept these conclusions, they have 2 choices.

Invest in Governance to match the Scale of the site.

Reduce the Scale of the site to match available levels of Governance investment.

If management refuse to invest; size, complexity or engagement on the site MUST be downsized. There is simply no other way. Governance tasks can only be completed to the quality desired when appropriate Resources are available.

As regards the issues of roles, responsibility and teams; these require a different tack. Such issues expose inappropriate control & communication structures. These may be tolerated for a short period, but as we have seen, can lead to disaster in the long term.

For obvious reasons, much of the debate about Web Governance focusses on this topic. Happily this has led to many practitioners sharing ideas about configurations of teams and roles/responsibility that have worked for them.

Adding this to the shared experience of 20 years of web management, it means that common solutions to the problem of Governance configuration are emerging.

In the next article I will look at some of these solutions, in particular team structures.