Insight of a content Management system

I learned the basics from the Content Management Bible and from a great Content Management guide by the American Productivity & Quality Center (available in full from Google Books, for readers who need a foundation tutorial). Some of the key ideas I absorbed include the following:

Content is data with meaning: Computers are called data processing machines for a reason; computers deal with data, individual bits of information that have no inherent meaning until put into context. Users, however, need content in the form of a presentation, a report, a video, an audio file, a product description, or a Web tutorial; information that, based on its presentation, context, and format, has explicit meaning.

Content management is a process, not a technology: After viewing lists of software products called up by a Google search and reading lots of product literature, one could get the idea that content management is a problem that can be solved with software. The reality I learned that, like many business problems, the challenge is distributed and complex, and, for the most part, human. It’s people who consume content, who create it for specific business purposes, who determine how it all fits together, and who has the right to edit, manipulate, and publish it. From the moment a firm determines that there is a business reason to capture, sort, categorize, and publish content, to the moment its content goes online and is available to an audience, the huge technical challenges are minor compared to the questions of content ownership, workflow, and maintenance.

It’s all about the data: While I’ve pointed out the distinction between data and content, in the end, the system’s capabilities are contingent upon the quality of the data architecture, the metadata that surrounds it, and the foresight of the designers. Every Web development program is a work in progress; with any valuable Web property, the revisions and updates never end because the client’s requirements, the marketplace, and the technology constantly evolve. Now that the first version of the production system is live, we’re already having client conversations about extensions and new capabilities. If the delivery team had only thought of the current revision or had used brute force methods to implement under pressure, the extended functionality under discussion would be difficult to impossible. Happily, the data architects, through experience and foresight, created a data and metadata schema that will support the client’s expectations for an extensible application.

Agile and traditional project management methods can be mixed and balanced: While this insight is not specific to content management, it was proven by fire in this project. The client has a very structured SDLC and a PMO intent on ensuring that proper processes and procedures are followed, and that the project be auditable after delivery. The timeline, budget, and the development team, however, cried out for an agile approach. By placing the team together in a “war room” setting, by holding daily progress and issues sessions, by integrating testing and quality control into the development process from the beginning (rather than as an after-the-fact add-on), the team achieved an agility and productivity level that was extraordinary. At the same time, by reporting progress with traditional project artifacts, like a project plan and a Gantt chart, and by involving the business and IT management in weekly PMO sessions, the team was able to retain their trust and sponsorship. While we did have to go back and recreate some project events to keep the SDLC documentation auditable, this was a small price to pay for the productivity achieved.

Distributed agility is possible: The team that delivered this project was all over the map, literally: the database expert lives in Boston, the project managers are in Kansas and San Francisco, the data architects are in Chicago and Berkeley, and the development teams are in India, Berkeley, and Silicon Valley. Through close communication, the creation of a strong esprit de corps, and extensive use of all sorts of collaboration technology (including email, IM, WebEx, and Skype), the distributed team was able to work as one and deliver outstanding results and a delighted customer. I observed the group bonding that occurred during times of pressure and tension, and now, after the fact, I’m also observing lasting relationships that were cemented by successfully delivering in a demanding environment.