Roles allow you to use a computer science concept called 'indirection' to add flexibility to the way your staff are organised. They also allow you to define job descriptions clearly, and make sure that everyone in your organisation knows who does what and who is responsible for what.

When procedures are first introduced to an organisation, people often make the mistake of putting individuals' names into them: "Joe takes the timesheets, files them and gives the summary sheet to Jane". Of course, when Joe leaves the organisation, no-one knows who should file the timesheets.

Most organisations are organised around a series of job titles, and an organisation chart that shows who reports to who. This allows a certain amount of robustness in procedures: "The Team Coordinator takes the timesheets, files them and gives the summary sheet to the Team Manager".

Unfortunately, job titles change even more often than staff. So you're left with the job of trying to keep your procedures up to date during reorganisations, staff movements and job upgrades and mergers. In some organisations, this is worse than using people's names in the procedures!

A role is simply a set of actions and responsibilities that someone carries out. It normally represents a subset of one person's job, so that each person has more than one role.

For example, if you want all of the filing to be done by the Team Coordinator, you define a role called Filing. The job of Team Coordinator might include the following roles:

• Team Coordinator:

  • Employee

  • Timesheet processor

  • Receptionist

  • Postal collector

The procedure now looks like this: "The Timesheet processor takes the timesheets, files them and gives the summary sheet to the Timesheet authoriser".

The advantage of this comes when you decide to reorganise. The Team Coordinator job has grown too big, and needs to be split between two people. You create a new job title Assistant Team Coordinator, and split the roles between them:

• Team Coordinator:

  • Employee

  • Timesheet processor

  • Postal collector

• Assistant Team Coordinator:

  • Employee

  • Receptionist

You don't have to change any of the procedures to achieve this. Later, you realise that it makes sense for the person who sits on the reception desk (the Receptionist role) to do the post, so you change the roles to this:

• Team Coordinator:

  • Employee

  • Timesheet processor

• Assistant Team Coordinator:

  • Employee

  • Receptionist

  • Postal collector

... again, without changing the procedures.

Notice that both positions have the additional role of 'Employee'. This is a catch-all role which you can use to write procedures that cover everyone in the organisation.

Implementing roles

The key to using roles is to choose collections of tasks and responsibilities which are not too large, and not too small.

Make sure that everyone is aware of which roles they have (put a list of roles in their job descriptions ... in fact, they will often be the most important part of the job description).

Make sure that people can find all of the procedures that relate to each of their roles (have an index of procedures by role).

Roles are a simple idea which costs virtually nothing to implement. The advantage is that your policies and procedures won't fall apart the next time you change your organisation, and that might mean the difference between documentation that is useful and maintainable, and mere shelfware.