So you’re working on a big new website development, overhauling all the functionality and delivering a better user experience to your site visitors. Naturally you’re using an agile development methodology. It’s going to rock.
In this scenario, it’s very easy to think of the CMS as merely a component of your solution. Probably there’s a little box for it on your high-level architecture diagram.
But really, the CMS is a distinct product (in the agile sense). It has a different set of customers, ie. the staff who will be updating the site content. They have different goals from your site visitors.
That means the CMS needs its own agile track in your development process. Most importantly, CMS development (or, more likely, customisation) must have its own customer representative, who represents the product stakeholders (the staff), and who drives development priorities.
If you treat it just as a component, then chances are your developers will implicitly be taking this role on themselves. They will be setting priorities and making decisions on behalf of stakeholders who they simply don’t represent and quite possibly haven’t even spoken to. This is a recipe for bad product.
How will you know if you’ve succeeded? Again, you should apply many of those same techniques that you’d use to optimise your site to ensuring that your CMS is also great. A/B testing might be tricky given the likely small size of the customer base. But you should definitely have a clear idea about success metrics and how to measure against them. Whatever methods you’re using to evaluate the site, it’s worth thinking about whether and how they can apply to the CMS.
It’s puzzling to me that there are some developers who seem to think that this is a waste of time. I bumped into one on Twitter recently. But over the last decade in particular, developers have benefited enormously from better tools and processes, making them way more productive and happier with their work [yeah, “citation needed”, but I believe it’s true]. Why would you expect that you can dump crappy tools on other staff and still expect them to do the best possible job?
This post based on a true story.
Filed under: Development, agile, cms
CMSish 
Isn’t this what personas are used for (http://zenagile.wordpress.com/2009/08/14/personas-in-agile/)? You may have the advantage with internal staff that the persona is a real person, but I don’t know if a class of internal user should be treated differently to that of external users.
I think Jeremy has it right. If the persona is appropriately represented, then we can make sure that we don’t forget the needs of the CMS users.
Ha, good try. But no. Personas are a bit rubbish really. Let’s face it, they’re more a rhetorical technique than anything else, a way of putting a veneer of user focus over your decisions without actually bothering to involve real people. They might have some utility on a consumer product where it could be difficult to corner live users; but on a CMS implementation you will generally have people in the house who are not merely representatives of the genus but are the actual users themselves. Why wouldn’t you engage with them?
Great points. The CMS itself definitely has its own set of stakeholders, and the CMS is going to be customized so it needs to be managed as a product to avoid becoming Frankenstein’s monster. This related post may be of interest: http://hobbsontech.com/content/web-product-management-cms-vs-website-product-management
Good post, David, thanks for the link