Introducing Digital Triage

With most web teams under-resourced and at the whims of management, it is time to introduce a triage system.

It is rare for me to encounter a web team within an organisation that has the people to do the work asked of them. Instead there is a backlog of projects that they need to complete. That and unhappy internal clients each shouting for their project to be at the top of the list.

The result is that projects which you prioritise are those belonging to colleagues with the loudest voice. There is no sense that projects completed are those that best meet user needs or organisational objectives. This has to change.

Expanding the size of the web team to accommodate demand would seem like the obvious answer. But what is obvious is rarely what happens in many organisations. The next best solution is digital triage.

What is digital triage?

If you have ever watched an episode of M.A.S.H. or documentary set in a emergency room you’re already aware of triage. As patients come in doctors assess their injuries. The more serious the injury the faster they receive care. When it comes to life and death a first-come first-serve approach is not always the best.

One thing they teach doctors arriving on the scene of the disaster is not to prioritise patients who were screaming for help. If they are capable of doing that then they do not need immediate attention.

There is a lot we can learn from this approach to prioritisation.

For a start we should not be dealing with incoming projects on a first-come first-served basis. We should be prioritising the “critical projects”. The ones that are life-and-death for the organisation.

Second, we cannot presume that critical projects are those backed by the most vocal colleagues. Just because they shout does not mean they are urgent.

Like a doctor we need a more objective way of prioritising our patients as they come to us.

Prioritising with digital triage

How then do we prioritise where a project sits within our backlog? I recommend we use three criteria.

How business critical is it?

Every web team should have a prioritised list of organisational objectives. Every project that team undertakes should fulfil at least one of those organisational objectives. The higher the organisational goal the more business critical the project is and the higher it should be in our backlog.

How important is the audience it serves?

As well as having a prioritised list of organisational objectives we should also have a prioritised list of users. A project should meet the need of at least one of our user groups. The more important the user group the higher priority the project will receive in the backlog.

The one caveat to this is you also need to assess how important the task is to the user. You should not prioritise a project that serves an important audience, but provides little value to them.

How easy is it to build?

If somebody comes to the team with a request that is easy to build and won’t have an impact on other projects you can prioritise it. Even if it does not serve a particularly important goal or user need.

Of course this is all well and good in principle, but what about when people complain.

Objection handling

Few people will object to a fair and open system. The problem comes when people do not perceive the system as fair and open. If they think a colleague is getting preferential treatment they will be quick to complain.

The secret here is to clearly document how you go about assessing where a project fits in the backlog. As soon as somebody contacts you, you need to be able to show them the criteria by which you are assessing projects.

You need to be able to show them the prioritised lists of user groups and objectives. You also need to be able to justify how you have prioritised those lists. Getting executive approval for these lists will help.

I would also recommend having your backlog online somewhere for your colleagues to see. Update this often so that people can see their position in the queue and get a sense of progress as you complete projects.

Projects in the queue should also show:

  • Which audience they serve.
  • Which business goal they meet.
  • An estimate of how long the project will take.

Your contributions

It is important to stress that your colleagues do not have a monopoly on introducing new projects. I see many web teams frustrated that they don't have the time to address important projects because they have no 'client'. For example many web teams feel they never have an opportunity to think strategically.

Using this digital triage model there is no reason why you cannot introduce your own projects to the backlog. Just make sure you assess and prioritise them like any other project.

This approach is not perfect but then no approach is. What it will give you is a way of dealing with complaints and prioritising work that is important. It also puts you in control of the process because you are the one who assesses projects. You are also the one who created the criteria for this assessment. That should at least help you manage projects more sensibly.

  • I think triage is an excellent term to capture how teams can elevate above the first-come, first-served approach. That said, ideally teams get out of emergency mode, and part of that is clearly optimizing: some things should happen quickly and others should be more considered (or not happen at all). One way to do this is to get out of project-by-project mode, and move to a routine (say quarterly) review-implement cycle.