We’ve previously mentioned that the fear of being left behind often motivates web strategy, even though this just leads to mediocre web presence. Why does this happen? It’s because our heads are ruled by fear, as this Newsweek article points out. As a consequence we make poor choices, trying to come up with functionality-driven requirements rather than finding the problem we’re trying to solve.

A typical example is to implement folksonomies for relatively small websites. Folksonomy (or social tagging) works for large sites with an engaged readership. The sheer volume of tags and people tagging supports rather than counteracts other classification systems. But this simply won’t work if your editors are adding more content than your audience is actively classifying.

Similarly, you may look at other websites with rich media and think that’s what’s driving visitors to their site, when the opposite may be true. Just look at what happened when The Register introduced video reviews for an audience that browses the site while at work.

These kinds of implementations are often driven by the fear of being left behind, losing audience and revenue. Many organisations feel they should be on Web “version 2.0″ by now, irrespective of whether they can articulate what that functionality is or what purpose it will solve. So how do you fight the fear? You need to set out some clear business-driven objectives for the web.

These objectives are common across practically every organisation: increase market share, reduce costs, reinforce brand, improve communication with customers and so forth. Every system requirement that you specify will need to meet one of these objectives. If a requirement is completely off the wall, then it’s either not relevant for the organisation or the organisation needs to reassess its objectives. When you record your requirements, these should be mapped to an objective and validated by the body responsible for meeting the objective: the marketing team, customer relations, IT, etc.

Once you’ve recorded all your requirements, you can develop functional solutions for each one. Again, the relationships between requirement and functionality should be tracked, so when you come to decide about functionality that will be in project scope, you have a clear idea why you’re implementing any given feature. You’ll then be able to ensure that requirements are driving functionality, rather than the other way around.

Just as your organisational objectives will corroborate your organisational strategy, so the requirements you document will inform the technical strategy you adopt. Do your requirements suggest the need for a web content management system, or an enterprise version to manage documents, or federated search, or wiki tools? You should be able to design a technical strategy once you have an overview of the requirements. This strategy will also inform the functionality you specify to meet the requirements. If your strategy dictates project teams should collaborate using blogs, this should be consistent across your web presence; you shouldn’t end up with a mix of blogs, Word documents and forums. If you can achieve this level of consistency, your technical and organisational strategies will be appropriately aligned.

So stave off your fear of being left behind technologically. Being at the technological bleeding edge will bring you little reward, as Get Strategic points out. Focus instead about meeting your business goals and ensuring that your technology is being designed with these in mind. Didn’t you want business 2.0 rather than web 2.0?