Hi Hurol

I’m not aware of any retail industry benchmarks or standards for this kind of thing – either process-wise or in terms of deliverables. I’ll ask around some of my retail specialist contacts.

However, I have been involved in similar work myself in the past, so can share some thoughts on that. What I talk about here, however, is perhaps more applicable to a single (larg-ish) retailer looking to manage their content more efficiently and holistically under a unified framework. It may not be relevant to your case, where the sites might be completely different? Anyway…

I guess you are talking broadly about content management. In my view this boils down to process + structure, where the structure is in the content to be managed and the processes are what define how the content is created, managed and published – usually via some kind of content management system (CMS). So for processes read things like workflow, archiving, publishing processes etc.

In the past I have tackled this kind of problem by splitting the work in ‘structure’ and ‘process’ workstreams. If I had my way I’d probably start with the content structure and layer the processes on afterwards but you can, to a degree, run the two streams concurrently for speed whereby the process work stream is about auditing current working practices (mapping work flows) and then optimising them (both generally and then specifically for internet publishing) and the ‘structure’ work stream is about building a content model (or ‘schema’ or ‘taxonomy’) which defines the structure, hierarchical relationships and data elements of the content, including metadata.

[NB for more on my interpretation of what a content model is, have a look at http://www.e-consultancy.com/forum/default.asp?v=1303 ]

The process that I’ve used for defining the ‘structure’ part (with the end deliverable being the content model) is, crudely, as follows:

1. Agree team to work on it – very important to have multi-disciplinary representation (technical, business/marketing, editorial, project management at least) as the end content model needs to embed the strategic, commercial and operational ‘DNA’ of the organisation + the technical guys need to understand how to translate the model into a database schema, with all the relevant inter-relationships etc.

2. Agree process and deliverable – a cunning way of getting round not having a process? Maybe… Or perhaps ‘iterative, collaborative development’? I would have the content model as the primary deliverable.

3. Audit of existing data structures – look at what content is to be managed to identify existing structural logic. There may be opportunities to map various elements into one common structure. Equally, in the case of retailers they’re likely to have a product catalogue or database with existing data fields, categories and so on.

4. Brainstorm content categories and sub-categories – nothing much more fancy than getting the right people in the room + flip-charts to define at least the top level categories and sub-categories.

5. Check output against business and user requirements. What you come out with from step 4 needs to be ratified and refined against business requirements (e.g. personalisation or cross-selling features may require certain categories or metadata to be present). I also think it is valid here to apply the same kind of techniques that are used by usability professionals when defining a site map to make sure it will work for users e.g. card sorting or task-based analysis. Get 5 end users (whether business users such as editorial staff or end site users) and see if the categories make sense to them – where would they find what they wanted? How would they better understand the categories, how they are named and so on.

6. Iterate and refine. Perhaps with the smaller core team only you will need to drill down into the details of the content model, including more detailed metadata, both ‘management’ data (what end users don’t see but the system needs) and ‘display’ data (what the users see on the screen, itself depending on their user status).

7. Specify / Document. Probably a content model is best done in XML. However, an indented list (to show hierarchy) with a naming key/convention (to keep the elements consistently referred to) is fine – could do it in Word or Excel quite happily - as long as the technical people are confident they can translate this into what they need.

That’s some thoughts on the ‘structure’ part – let me guess you wanted to know about the ‘process’ bit?

BTW, there's a thread that begins at http://www.e-consultancy.com/forum/default.asp?v=1259 on e-commerce product data population that might have some relevant information, or you could ask Sean about his experiences on the process side of things...

Thanks Ashley. These articles are definitely useful reads. We have been documenting our processes with the workflow approach outlined in Boiko's book. I am thinking about santising and posting the deliverables online once complete. I will let you know.

I am still looking for benchmark figures as we need to assure the management that we are not overstaffing the web management team.