A few weeks ago we posted an illustration on Flickr called “The Problem With Your Website.” It describes an issue we’ve seen over the past few years with our own clients and throughout the industry.
In a nutshell, the problem is that organizations spend most of their resources on site development and then have little left over for support, maintenance and improvement over the total lifespan of their site. Here’s what the illustration itself means:
- The red line is all the resources you might spend on your site, including money, people and even intangible things like goodwill.
- The blue line is the effort it takes to manage the site, including keeping content up to date, dealing with technology, and dealing with governance issues (like policies, procedures, etc.)
- The “trough of despair” is where many organizations end up–having spent most of their resources on site development, they have little left to support and maintain the site. The trough of despair is where staff get burnt out, customers get frustrated, and opportunities are missed. This is where web teams face the frustration of high expectations and limited resources. (Where you’re in the middle of developing a site you call this “Phase 2”, that mythical place where you put all the interesting stuff you can’t tackle during site development.)
We’re not presenting this as a universal law of website development. But it does explain, in straightforward economic terms, a common problem that many large organizations face.
Why does this happen?
We’ve been talking about this problem within our team and with colleagues for a while now, and there are all sorts of reasons an organization might fall into the trough of despair. But the reasons that interest me the most are structural–they’re related to the structure of organizations themselves rather than external factors like the capabilities of their design consultants or the features in their content management system.
Here are few of those structural problems:
- Many organizations think of their websites as a technology product and give their IT departments a significant role in rolling out the site. So the website becomes a software acquisition, implementation and development project, because that’s what IT is really good at. As the content strategists have pointed out, if you have a website you’re in the publishing business.
- Many organizations aren’t good at measuring ongoing performance of their site. This is especially true for organizations whose websites primarily provide information or customer service. (Companies that generate leads and/or sales through their sites tend to be much more performance-oriented.) Without meaningful performance measures tied to business objectives, it’s difficult to make a case for change.
- Resource-rich IT departments lead site development and then hand-off the site to resource-poor Communications departments to manage.
- The website is treated like a project, with a fixed timespan and budget rather than a program, with ongoing resource requirements.
- In many organizations one-time funding is easier to access than ongoing operational funding (doubly true if you’re asking for headcount).
- Operations requires a different skillset than development. For example, understanding and using analytics tools effectively is an important operational skill. Using a content management system effectively is another key operational skill that rarely comes into play during development.
The thing about structural problems is that they’re difficult to change, and sometimes they’re even difficult to discuss. Many website post-mortems focus on aesthetic or functional problems–the design is dated, search doesn’t work, or content is hard to find. Fundamental questions, such as “did we have the right team in place, with the right resources for the duration of the site’s lifespan?”, come up much less frequently. And yet my experience has been that a great web team can turn around a poor site quickly, while a site that’s elegant on launch day will quickly falter without the right support.
I’m going to save my thoughts on escaping the trough of despair for another blog post. But in the meantime you might want look at Lou Rosenfeld’s presentation on Adaptive Information Architecture, where he covers some of the same ideas and offers some solutions of his own:
You might also be interested in the comments posted on Flickr where Peter Boersma asked several good questions