I know I’m not alone here when I say that content management projects are HARD to do right. I’ve been doing a lot of thinking about this subject – particularly around the project management aspect of it. All is rosy at the beginning when you put together a master project plan, but it seems that within a very short time, you’re heading towards scope creep, over budget, way over schedule, and stress! There must be a better way.

Over the span of my career (the last 15 years or so), a project manager has become standard fare for any corporate IT project. As I’m sure many of you recall, however, there was a time when having a person dedicated as a “Project Manager” was seen as an unnecessary frill. Thankfully, that’s changed (in most places).

When you embark on something as complex as a major content management initiative, not only do you need a dedicated project manager, you need a highly skilled and experienced project manager. That’s another issue.

The good news is that organizations like the Project Management Institute (PMI) have their PMP certification, which I believe sets a really good foundation for project managers. But even PMP certified individuals who have managed other types of system implementations or software development projects may struggle with a content project.

So what’s different about content management projects?

Well, content management projects are particularly messy because of several factors:

  • The people involved are oftentimes cross-functional, requiring concensus building among several departments that don’t typically work together. This takes a lot of time and effort on the part of the PM. The proverbial “herding of cats.”
  • The content itself isn’t something that every project manager knows how to deal with. Content needs a lot more care and feeding than data does. It gets into the realm of graphic arts and marketing, and copywriting or technical writing, which is foreign to many IT and project management folks. If the PM doesn’t “get” content development, and how a CMS is used, they will have a tough time defining the proper tasks and milestones. For example, migration is a huge thing. Someone who has never done a CM project before might think it’s no big deal.
  • The technologies are also not a piece of cake to work with. Content management systems have come a long way, but it still astounds me how often technical glitches in the software suck up an unbelievable number of hours. It’s not unknown for it to take a week just to properly install the software.

So, while, there are a lot of differences between implementing a CMS and doing traditional software development, I think there are lots of similarities, too. We’re talking about gathering requirements, doing database modeling, designing business process (workflow), doing user interface design if we want to customize the UI, and there always seem to be custom components that need to be built to fit a specific business need.

Ok, now, if content management is similar enough to software development, there must be some things we can borrow from that world to make things easier. With all this in mind I decided to delve into the latest software development project management practices and came up with some interesting insights.

  • The waterfall method is passé
  • The new methodology is called “Agile”
  • Software development is like playing rugby – it involves a “Scrum!”

The ‘jist of this is that what is known as the “waterfall” project just hasn’t been working that well. This is the plan where you do all the requirements gathering and approvals up front, go into a big development phase, do testing at the end. Unfortunately, in an alarming number of projects, this method tends to make the project go over budget, over schedule, and often the end result doesn’t meet the users’ needs. How ’bout that!

The newer Agile software development process in a nutshell, involves breaking the project up into smaller components and completing each one in a more rapid cycle–requirements, build, test, refine, re-build, re-test, etc. I can definitely see how this could be better.

One of the inherent problems with this methodology, however, is that it allows you to *not* develop all the requirements up front, which makes it very difficult to scope your project. And without accurate scope, how to do get budget? And with no budget, you have no project. Hm….

The other new buzzword in software development is Scrum. Having played co-ed rugby in grad school for one hilarious season, I kinda knew what a “scrum” was. It’s like a team “huddle” every morning where the team lets everyone else know what they did, and what they’re going to do for that day. The team works in 30-day increments on discrete functionality per the Agile method above. These are called “sprints.”

I won’t go into the full detail on Scrum here, but, again, it seems like a good idea. The team has much more ownership over the solution and more accountability to each other for their deliverables. The Agile/Scrum model has you define a discrete set of functionality that has to be fully developed, tested, documented, and delivered in a 30-day period. When that’s done, you go on to the next set of functions.

Where I struggle is in figuring out how this Agile and Scrum stuff could be applied to a CMS implementation. Can you really break out project deliverables in a way that they can be delivered in chunks like this? I suppose so.

At any rate. I hope I get a chance to try it out on my next major project and find out. Wish me luck! Comments and shared war stories welcome.

Note: The book I read about these two methodologies is “Agile Project Management with Scrum.” And, another great resource to learn more is Rally Software where you can take a course to become a “ScrumMaster.” Now how cool is that!