I thought it was time to show you another real-life example of facilitation of a small process.
What was the situation?
All units had to deliver a certain report at the end of the reporting period, before consolidation in their business. It turned out that the units reported different things and delivered their reports at different times.
Of course this was not the way to go, so someone made an overview of the different scenarios that were in use, and from that (and with many discussions with everyone involved) they created the desired process that all units would have to follow for consistent reporting and consolidation.
The process described all actions that had to be completed at certain days around the end of the period. Every unit had to mark the action as completed on the day specified.
What was the solution?
The next step was to think of a place where every unit could monitor their progress. We expected to be many items (x actions * y units), and the items would be edited regularly by many different persons, which might lead to messing up each other’s data, so we first thought we would create a list per unit. That would also make it easy for people to find their own dataset.
However, that would make it harder to see if everyone was on the right track, and it would mean we would have to make changes to many lists if there ever would be a change in the setup.
We decided to go for one central list. A custom list, of course! I would add some safety measures to prevents accidental deletion or editing of other people’s items. (Few Datasheet views, a custom set of permissions and targeting – see also Dangers of the Datasheet)
Every unit had their own identical set of actions. Next to the actions, there were fields for unit, the responsible, the number of days before or after the end of the period that every step had to be taken (from -3 to +15), a free text box for comments and of course a Yes/No box to note if the action had been completed.
I then created one Datasheet view (Update View) with as few columns as possible to make it easy for all participants to update the list. I created a number of Standard Views for the process owners to keep an eye on general progress.
I also created a SharePoint group for each unit. Every group got a set of custom permissions: “Contribute without Delete”. This was one of the measures to avoid accidents that may occur when a big list is frequently edited by many people.
For each unit I created a page, and added the list webpart on it with the Update View. I filtered for the unit, sorted by day, and then targeted the webpart to the SharePoint user group of that unit. That way we made it easier for people to see and update their own actions only – if they accidentally clicked on the wrong page, they would see a blank page.
After each period had been reported in the correct fashion, the site owner made an export of the list into an Excel file for archiving, set the Completed fields to “No”, and the system was ready for a new reporting cycle. When “action time” neared, she would add an announcement on the Homepage that the new cycle was ready to start.
What was the result?
After a trial run in a few units, it turned out that this worked well. The pages per unit and the Excel-type update made it easy for people to find and update their own items. It was also easy for management to track progress – the Progress View (showing only items where “Completed is not equal to Yes”) showed if every unit was on track.
From now on, reporting was done in a uniform fashion and consolidation of the reports was a lot easier than it had been. After some months, another business asked me for a copy of the setup. So I guess it was a success :-).
Image courtesy of Stuart Miles at FreeDigitalPhotos.net