Week 2 - Deciding on a Content Management System Team

As stated in the previous post, we had to axe Astoria from implementing a new content management system for us for various reasons. We sat in limbo for weeks. Finally, an executive in our company said that his own IT team, running a Documentum software, could help in our search for a content management system. The Documentum platform is build by EMC. He also suggested that he knew of a solutions team that could pull everything together for us, as far as integrating the Documentum platform with our data inside an XMetal repository. That team was Flatirons.

Soon thereafter, had our fist meeting with Flatirons. The Flatirons team comprised a Senior Programmer/Developer, a Business Analyst, and a Product Manger. The entire team on our side was present as well (10 Writers, 2 Editors, a Support Specialist, and the Documentation Manager). We had scheduled a 4-hour meeting to hash our work flows, having a much better idea for our goals and requirements versus when we went through the initial steps with Astoria. Also, our roles were already well defined, based on our current responsibilities in our daily routine; although, we were open for any augmentation of roles that the new content management system might require.

The meeting took a total of 8 hours, eating up the rest of our day, and we had to do another full day to further solidify the workflows. In other words, it was no easy task trying to define and then visualize the workflows. Several debates (some heated) took place over what types and how many workflows we needed in the first place, what kinds of documents fit in which workflows, the steps of the workflows, and how the system would operate in each stage of the workflows, and what was to be the outcome of each workflow.

Thus, we first had to separate all the different types of deliverables we currently create. That translated into 4 different workflows: (1) a new, regular document, (2) update of a single or multiple sections of a pre-existing document, (3) a field letter, and finally (4) our online help system. Then, each workflow required it's own steps and stages to be defined. Those steps included, how often the content needed to be reviewed and who would review it; where the content would go after being reviewed; how each version would be saved after the content had been updated with suggested edits by the reviewers, as they were marked on an editable PDF; how the system would denote the different versions in the user interface (Webtop), who would have what types of rights to the content (i.e., write versus read-only); and how and at what point would the final deliverables be created. All of these steps and stages engendered several different decisions. And each one required discussion. Seems like a lot? It was. That’s why it took two days.

Moreover, an overriding pressure loomed beyond just time and money that these two days cost. Based on our decisions in those meetings, we laid the ground work for how the content management system would forever operate after Flatirons had long since implemented the system. Our main concern was that if we made a mistake in deciding on the workflows and their subsequent steps and stages, we would be forever in trouble, having to come up with whatever inadequate workaround we could muster. In this sense, the business analyst was critical in translating our current processes to the programmer, who would then counter with either a “that’s possible” or “no, we can’t do that.” The meetings were of course tedious and exhausting, but ultimately necessary to ensure we did not get an out-of-the-box content management system that was substandard for our needs.


Return to HOME page or leave comment below.