What follows is a post that was recently published on AIIM’s site as an “Expert Blogger”. (The original can be read here)
———————————————————————–
Different Systems and Different Silos – A Real-life Disaster
Discussions had been going on for months. Plans had been drawn up. Even though the main tasks had been itemized, there was agreement that these would still have to be refined further into the project.
Nothing had been done to assign owners to the tasks, but there was a mutual agreement that whoever could, would work on each task as they saw appropriate.
In any case, the goal, and the timeline, was clear. There was no disagreement there.
Over the weeks, considerable time and resources were committed to working through the various items that made up the project task list, and the necessary information was diligently recorded, and documented.
Progress was regularly reported to the various parties involved. This was done verbally. It involved the person who took ownership of the task describing what had been done, along with what else had to be done, and any impediments that they had encountered. If they felt it was necessary the task “owner” could describe a plan of action to overcome the impediment. The other parties involved could ask for more information, or give suggestions.
Communication was informal, but each party were confident that they were apprised of task activities, and that they knew the status of the project.
Then, one day, everyone involved, got together to “walk through” the progress of the project. This involved visiting the various locations where the tasks were done. It was, essentially, an internal, informal “audit”, and a complete day was scheduled. As is necessary for such an event, all “distractions” were removed. Everyone was asked to turn off their mobile phones, Blackberries, or similar handheld devices. An extended dinner was planned. Everyone had been working hard, and this would allow them to relax, and discuss the results of the audit, as well as talk about whether the project goal was still valid, or whether it needed to be modified.
The walk through of the first task went well. The recorded information was double-checked (obviously by someone other than the task “owner”). Everything looked good. Everyone was happy. The walk-through of the second task (identifying potential candidates for future sub-tasks) also went well.
But then, major issues were starting to appear. And these were not to do with the actual data, or even with the tasks themselves.
It turned out that each party had used their own system for recording information. This meant that the data, although present, was stored in two different systems. And in each case, the data had been recorded in a way that “suited” the person entering it. This meant that there was no “common” structure, and different metadata. And there was no way to simply “merge”, or import, the data from one to the other.
Further to this, because there was no real management of the tasks (as mentioned, it was a very informal process), it turned out that there was a duplication of activities. It appeared that some of the “unassigned” tasks, had been worked on by one party without knowing that others were also working on them. Result – a duplication of data. And, with the data recorded in two disparate systems.
To fix the “problem” would involve deciding which system would be the “master” system, and then manually entering all the data, from the unwanted system, into it. It was going to be a big job, and there was a lot of tension. The elaborate dinner that was planned was called off.
At this point, I turned to my wife, and suggested that the next time we were going to move house we need to make sure that we write everything down on the same notepad, instead of each of us having our own…
Based on true-life events.
Like this:
Like Loading...
