When managing an intranet the team often has things it does again and again. Repeated tasks (e.g. a request for administrating permissions on a page, production and publication of a global news item, taking care of a bug in the WCMS) are actually the core of the maintenance work.
Repeated tasks should be performed in the same way every time, no matter who does it. A unique person in the team might normally be the primary provider of the task, but people get sick and need vacation. So you need to have stand-ins, and preferably they should do the task the same way.
Therefore it is a good thing to document how repeated tasks are done. If you have the actions concerning a task properly described the intranet team leader can distribute and redistribute tasks within the team. It’s also easy to hire temporary workers.
I’m of course talking about processes and process modelling. Depending on your organisation’s maturity in this field you might already have all the important processes decided on and described. But in my experience many organisations, especially municipalities and other public operations, need to work more with this. A quick indication of the maturity can be to look for a central function/unit taking care of the processes ”ecosystem”. If this function doesn’t exist, the organisation will most likely be bad at processes.
This should not prevent you as a an intranet leader. Every leader taking care of a product should document the work.
Describing a task could be done as a bullet list of the actions on a post-it note or in a document. It could also be described as the process it is with proper business modelling technique. Below is an example of what the development process for an intranet could look like.
This particular process is built in the BPMN ”language” plus “swim lanes”, one for each role. There are several other modelling techniques. My point is not that you should use BPMN, but to document what you do in some way.
There are more benefits of documenting the team processes than just being able to take some leave during summer. For example, in the process diagram above anyone can understad
- that the flow goes from left to right (circles represent starting point and end point),
- that different actors (Y axis) are responsible for different actions,
- that the task of developing something actually has a lot of actions before any result can be delivered.
Processes diagrams give you a tangible way to speak about what needs to be done, in what order and by whom. Often the intranet owner, top management, key managers and other stakeholders find it difficult to understand what the team does every day and why ”so many” need to be in the team. Documenting the processes often gives the intranet work a more real, ”official” look and feel and makes it easier to send the signal that intranet management is a real job best done by a professional intranet team.