Content Workflow, How to implement it? (and trust stakeholders)best practice
A good content workflow is based on the people who compose it and not on the tools that are only there to "inform" stakeholders. Things change over time and human beings' adaptability is more powerful than that of machines.
A workflow is here (do you want it or not) as soon as two people work together on the same object
From the moment an "object" is produced with several hands it is de facto placed in a "production line" or workflow.
Several people can intervene to imagine, design, manufacture, validate, revalidate, improve and, finally, distribute it. Making this "object" to circulate through these hands quickly becomes a major challenge in an environment that demands efficiency and quality.
Content is no exception. Especially at a time when regulatory constraints can be extremely strong and the demand is constantly increasing.
It is necessary to identify the stakeholders: who will be involved? What will its mission be?
Be careful, identifying does not only mean designating but also convincing. Does the person agree with his or her place in the process? Does she find it useful? Does it have the real means to accomplish the mission entrusted to it (time, skills, legitimacy)?
Identifying the participants in a process is an extremely important phase, guaranteeing its sustainability. Because, in the end it will be the people involved who will bring this scheme to life and help it evolve.
Carefully design "states" or workflow steps
A workflow is a series of sequential steps through which the content will have to pass. At each step the content will be in a specific "state". The number of steps is extremely important.
Too high and it becomes unreadable, we do not know how to read it, statutes are too close to each other to be chosen simply and surely by team members.
Too limited and it is the opposite effect, the stakeholders do not have the necessary states to designate the state of the content and we end up with "catch-all" statuses.
Each worklfow status must be correctly thought out beforehand to correctly designate the state of its production without this giving any doubt to a person who has just arrived on the project.
On Pilot, on average, teams design 5 workflow states. Never more than 10. Never less than 3.
Dissociate "status" from content and "tasks" to be performed.
For a long time we have linked, in the same functionality, states and tasks on Pilot. But this caused a lot of confusion because they are two very different "messages".
First of all, a content is in a particular "state" at a given moment in its production. It is a unique and clear message that must be distributed to the entire team.
From this information we decide what needs to be done (the tasks that need to be performed on this content).
"To be validated by the legal department" is a task. "Validated" is a state. And we have chosen to clearly distinguish this in the Pilot interface.
Having the "To be validated" and "Validated" states coexist brings confusion when reading a workflow. And above all, a lack of flexibility.
This is the other advantage allowed by the dissociation of tasks and states. The team may have to perform several tasks to move from one state to another, and these tasks may vary from one content to another. This need for flexibility must be guaranteed and supported. However, we cannot change too often the sequence of states of a workflow which remains the backbone of the production chain.
Content workflow: A complex process that is more human than mechanical
A good content workflow is a complex thing to set up. It must be both directive (to prevent cacophony) but also permissive, to admit that processes change, temporarily or not, that humans are not constant machines.
A workflow that is too rigid, that does not accept change, is doomed to failure. Designing a "blocking" step in a process and assigning it only to one person is an announced failure. One day this person will be absent, the process will be blocked, and the team will find a way to get around the problem by creating an informal workflow that will become the norm (for better or for worse).
A workflow cannot, must not, be based solely on a tool. It is based on the people who make it up. The tool is only there to record information for use by stakeholders.
How to design a flexible process ?
By first trusting the people who make it up. Assuming that they will adapt to reduce the friction due to change by leaving them the means and the freedom* to adapt to change.
A solid workflow is also a workflow restricted to a few people, for a few states. A process involving 50 people and 60 states must be redesigned in sub-processes.
Photo : Daria Nepriakhina
Do you want to discover Pilot ?
30 days free - no credit card required