Web Development

A PM's lessons learned from delivering a CMS

A project manager shares his first-hand account of the challenges and the lessons learned from working on an enterprise level content management project.

Every once in a while, you get lucky as a project manager; I've just had one of those experiences. By pure good fortune, I got involved in a project that taught me a lot, expanded my horizons, and gave me exposure to a technology with which I had little experience. I also got to work with a tremendously talented and knowledgeable team, an obvious plus. Now that the stress has subsided, and the production system is rolled out, I've been pondering the outcome and the circumstances and thinking about my own lessons learned.

Project overview

For this project, my team helped a large life sciences company migrate from a business mostly based on catalog sales to an ecommerce model; we also moved them from an older Web platform to a new, "best-of-breed" architecture. The team spent almost two years patching together different elements, including a database, a content management system (CMS), an ecommerce engine, and lots of custom code and stored procedures, to create a customer storefront that displays highly complex and technical products in an intuitive and attractive manner. This was probably the most complicated software project I have ever engaged in and, although my participation was peripheral (I managed the customer relationship while the team managed the actual delivery), I saw firsthand the many challenges of delivering CMSs in an agile, distributed manner.

Content management basics

This was my first deep exposure to enterprise level content management, and I had to get up to speed quickly. 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 from involvement in this project is 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.

Conclusion

Whenever exposure to a new technology opens my eyes, educates me, and gets me fired up about new possibilities, there's only one thing I can say: I got lucky. I've gained a deeper understanding of the key role that CMSs play in delivering the photos, text, videos, .pdf files, and text that educate, entertain, and attract Web audiences.

In future articles, I'll discuss the changing landscape of content management and explore exciting new thresholds such as semantics.

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

About

Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

4 comments
donstrayer
donstrayer

Thanks for an insightful article, Rick. I'm reminded of a wise CIO for whom I once worked who insisted that there are no IT projects. There only business projects, some of which make use of information technology. Sharing your experience with this project should help others get the message.

GlobalPMO
GlobalPMO

Good article. We are going through this process of defining and adding content to our site so people "get it" on our new Augmented Reality (AR)mobile application offering. CMS adds new dimension to our product offering and market potential. John Choate PMO Point&Find/Nokia

erica.j.henson
erica.j.henson

"Content management is a process, not a technology" Absolutely the truth. The best solutions providers are definitely the ones who understand this commandment. :)