Serio Blog

Friday, 06 Jul 2007

In my previous post, I talked about issues relating to document design for knowledge base content.

In this post I’m going to talk about optimising your document for indexing. Whilst what I’m writing applies directly to Serio users, my guess is this holds true for most content-retrieval systems.

The most import thing in a knowledge base is the content – as I’ve written before. To have something that works well (particularly with enterprise content) you don’t always need a retrieval system – for example, you could simply set-up a few web-pages that organise your content in a directory form.

However, as the number of document grows, the need for a search mechanism increases. This search mechanism often takes the form of keyword of phrase searching – pretty much like internet search engines do – returning results based on relevance.

For example, Serio uses Microsoft Indexing Service, which is a standard part of the Windows family of operating systems. When you create content, and place it into the Catalog directory you’ve created, Indexing Service ‘behind the scenes’ reads the document and indexes it. When you search for something, it uses the indices it has created to produce your list of results.

When you create your content, you can give clues to the Indexing Service as to what the document is about – not all words on the page are treated equally. The following should help the Indexing Service to return the best documents to your consumers – but you need to have an idea of keywords. By keywords, I mean the phrases or words your knowledge base consumers might use to locate your document.

  • Title. Don’t use a standard title, create documents that have an expressive, relevant titles that contain some of the keywords you think searchers will use.
  • Bolding. Bolding of certain words seems to be a factor in assigning importance to some words to over others. Use bolding intelligently by bolding key words and phrases.
  • Location of words. Keywords near the top of the document again can help some documents rank over others for certain phrases.

Wednesday, 04 Jul 2007

I recently contacted a customer – an Incident Manager – whom I'd spent some time helping with his Incident Management procedures. He told me that things were going fine, but that some staff were not calling customers back within the 1 hour target of logging Incidents set down in the SLA (or not recording they had done so), and so he'd needed to sent a couple of emails.

I was strangely pleased to hear this, as it meant he was acting as an Incident Manager should – using the weekly checklist we'd drawn up to monitor that procedures are followed and following up where they aren't.

In an earlier post my colleague George asked "So What do Incident Managers do all day?".

An Incident Manager must ensure that the Incident Management process is documented, so that service delivery staff know what it is. They must also take charge of making sure that staff are aware of these procedures for example, through training, workshops, role plays, meetings, and so forth.

But all of this effort is pointless if no-one is actually following the procedures, so as Incident Manager you need to be checking that they are.

Following a weekly Incident Manager's checklist is a simple way of ensuring that such checks are systematic and regular. In addition, checklists provide important evidence that your Incident Management processes are working. In other words, they can be a Key Performance Indicator (KPI), with which you can supplement management reports to back up your recommendations for changes. (See "Some Service Level Management (SLM) Key Performance Indicators (KPI)").

So what sort of things would you include in an Incident Manager's Weekly Checklist? To be fair, you obviously must base your checklist on the documented Incident Management procedures you are providing to your staff (for example, your Operations Manual). After all, how can you expect people to follow a procedure you've never written down?

Clearly, procedures will vary from one company to another, but the following checks are typical from my experience, and will get you started with your own list. (Tip: For the benefit of yourself and other readers, I'd recommend you format your own list as a checklist, with tick boxes and spaces for your comments):

1. Take a sample of Incidents logged by different agents during the last week. Check the quality of the Incident details logged:

  • Have all the details listed on your call logging script been captured?
  • Has the correct priority been assigned?
  • Has the correct Configuration Item (CI) been recorded?
  • Is the description of good quality? (You need to break this down further by looking at whether standard questions were asked – version number? error message? - if appropriate description templates were used, if multiple Incidents are being described in one Incident, etc.)
  • Was the Incident correctly assigned?

2. Take a sample of Incidents logged within the last week and assigned to different agents. Check that your procedures have been followed with regard to responding promptly to Incidents logged:

  • Did the assigned agent respond to the customer within the target response time set out in your SLA?
  • Did they make the response in the correct manner (for example, if you have specified that agents should try phoning the customer before sending emails, have they done this?)

3. Take a sample of Incidents resolved by different agents within the last week.

  • Is there evidence that the agent has contacted the customer to notify them of the resolution?
  • Was a good quality resolution description provided, explaining clearly how the issue was solved (not 'done' or 'I fixed it').
  • Has the correct Cause code been attributed to the Incident?

4. Look at all Incidents during the last week where the resolution target was missed. In each case, try to determine the reason and note this against the Incident.

And so forth. Your own checklist might continue with checks on whether correct escalation procedure had been followed, a review of how any Major Incidents or Complaints were handled, etc.

Monday, 02 Jul 2007

This is a follow-on from my earlier Knowledge base Structure post, where I defined something called enterprise content, looked at describing your consumers, creating Catalogs, and creating some example documents that will ‘set the style’ for the content you are going to create.

This post is all about the enterprise content documents themselves – what I think works best, and some pitfalls to avoid.

Short Documents are Best

My own preference is for concise, single topic documents. In other words, don’t create documents that address a range of issues or subjects – it’s preferable to have a document that tells you how to fix a single 'something', or do something of value to the enterprise.

Sometimes content authors sit down to write content, and end up with a longer, more comprehensive document – maybe that covers a number of errors or problems, and shows you how to resolve each.

I tend not to favour this approach, and here’s why. Content consumers will be searching – either by entering a search term, or by browsing to the document from an intranet page. The consumer will want to make a quick decision about ‘Is this document right for me?’. The longer and broader your document is, the harder that decision making becomes, and the greater likelihood that your consumer will miss the solution you’ve taken time to create.

People can also be lazy. If their search yields a number of documents, the consumer may not ‘scroll down’ and instead only read the part of the document that displays ‘naturally’. This phenomenon has been known to search marketers for years, with content you have to scroll down to being referred to as ‘below the fold’ and generally regarded as much less visited.

Think About Your Format

Word, HTML, PDF – or something else? For each Catalog try to stick to a particular format. Remember Word is not the best format if your consumers are Internet visitors.

How will Documents be Linked?

Sometimes you’ll need one knowledgebase article to reference another, maybe to supply supplemental information to the consumer. If you are using HTML as your primary format, it seems natural to create a hyperlink between the two.

This seems fine – on the face of it. However, in creating that link you’ve just increased your support burden and created a dependence between the two documents. If you move the relative locations of the two documents, or rename the linked-to document, then your link no longer works.

A better approach might be as follows. Give each document an alpha-numeric reference number that appears in the title, and tell searchers to see ‘document …. for more information’. In other words, they have to re-search for the document using the reference you’ve given them. Although it is not quite so convenient for consumers, it does mean that you are free to re-organise your content from time to time without developing broken links within your content. Any changes you make will be handled by your indexing system.

Friday, 29 Jun 2007

Tracey Caldwell asks if the time has finally come for videoconferencing in business, at least in Australia and New Zealand.

Now that we are all Green and just as importantly have to be seen to be Green, the days of executives making long journeys in fuel hungry cars or worse still aeroplanes to attend meetings should be disappearing, replaced by virtual meetings.

Videoconferencing suffered from a bad press for years. It was complex to set up and use and rarely replicated a true meeting experience with jerky images and delayed voice. The video conferencing vendors would have us believe that with today’s software and broadband speeds, all that is a thing of the past. So why is it not used very much?

Or should that be why is it not used much in business? Anyone under 16 videoconferences routinely. Of course the videoconferencing offered by MSN and Bebo is one on one. Desktop and boardroom videoconferencing are two different animals and the real challenge is replicating a meeting among several people, being able to view all or one of them, handling interruptions, being able to kick Maria from accounts under the table before she falls asleep.

In South East Asia, Australia and New Zealand, where distances between business centres dwarf those in the UK or Europe, analysts found the uptake of videoconferencing increased significantly in the last year, partly due to the falling costs of equipment. Lots of new vendors especially telephony vendors and software vendors augur well for the growth of this market, they say.

The buzz for this year Down Under is around telepresence, expensive systems which aim to give workers that in the room meeting experience, all bar the biscuits. Unified communication, linking video and audio conferencing with web conferencing and instant messaging are also high on the agenda.

China is leading the market, according to Raidah and Frost & Sullivan, accounting for 44.5 per cent of total Asia-Pacific videoconferencing revenues. The ability to link several provinces across the country has taken this market by storm according to the analysts with players like Huawei and ZTE aiming to move into other Asian countries.

Vodafone, along with other comms companies, knows it should be taking a lead on greener meetings. It has announced it now requires that the alternative of using videoconferencing is considered before travel is approved. There were “air hostesses” at the recent launch of its videoconferencing initiative and a number of posters suggesting “Spend more time with your family”, presumably what cabin crew will be doing once the corporate muscle of Vodafone is flexed.

Google has caught the wave, buying up the flagship software product of video-conferencing start-up Marratech, leading people to believe that conferencing software may become the next addition to Google's office suite.

Google says it is excited about acquiring Marratech’s video conferencing software, which it says “will enable from-the-desktop participation for Googlers in video conference meetings wherever there’s an Internet connection”. I am loving the calendar, not so keen on the spreadsheet. It will be interesting to see what Google makes of videoconferencing as a desktop app.

A report from Cisco, vendor of the £150,000 plus per site Telepresence videoconferencing kit points out that the uptake of videoconferencing is not all about the technology.

Cisco-commissioned report “The Psychology of Effective Business Communications in Geographically Dispersed Teams”, points out that although richer media such as video conferencing helps build teams, it still takes two weeks longer building relationships through videoconferencing than through F2F (face to face, great acronym).

The report recommends using videoconferencing at the beginning of a project, reverting to instant messaging when everyone knows each other. With videoconferencing sounding a bit like a very expensive curry night it is hard to believe that the time is very ripe for this technology. Please see the attached Cisco-comissioned report.

Thursday, 28 Jun 2007

In this post, I’m going to continue talking about Knowledge base content – I started this thread here, and added a diversion thread here.

I’m going to write about content you write or create yourself, which is about many of the specific things you have to do, and some of the issues that arise when trying to create content of this kind. I’ll refer to this as enterprise content – as it’s (usually) unique to a given company or organisation.

Getting Started

The first thing you need to do is decide who the consumers of your enterprise content are, because this will influence the nature of the content, it’s presentation, and it’s availability. I usually ask clients I’m working with to write down a single paragraph about each type of consumer, covering the expected level of expertise, and examples of the information they may be looking for. This then goes on to become part of the editor’s brief (more of which in later posts).

Grouping the content

Next what you should do is to stream or classify the content you wish to create. Unless you plan on having just a handful of documents, it is worth avoiding a ‘skip’ or ‘dumpster’ mentality where lots of unrelated content is thrown in together. Organising your content correctly at the start means your knowledge base can ‘scale’ correctly over time.

There are lots of ways to do this.

By document type. Examples might be:

  • Fault resolution: Documents that tell people how to resolve common faults.
  • How-to documents: These tell people how to perform common tasks that are not faults per-se, such as how to apply a service pack, deploy a ghosted workstation, order a new computer.
  • Bugs: A place where bugs or known errors and workarounds are listed

By subject matter. Examples might be:

  • Documents relating to operating system software
  • Documents relating to desktop software
  • Documents relating to hardware configuration

Which works best for you will depend on what type of company you are. If you make and sell specific hardware or software product, it might make sense to organise your content by product. If you are involved is more general IT support, it might make more sense to group by content type. Make sure the grouping will be understood easily by your consumers.

Serio refers to groupings of content like this as a Catalog. Unless you plan to have many thousands of documents, keep the number of Catalogs to as small a number as possible, particularly at the start. Too many does not help consumers, it confuses them.

Design Some Example Content

So far, we’ve got a picture of our consumer, and we’ve applied a simple organisation to our content. Now you need to write some example documents – not many, 3 or 4 in each Catalog should be fine. Here you’ll define the layout and, by example, the tone and style of the documents you’d like to see.

I’ll post next week on how to design a ‘good’ document (a totally subjective opinion I know) and how to create a quality system. I’ll also post some info on how you can ‘optimise’ documents for the indexing service that Serio uses.

Monday, 25 Jun 2007

This is a follow-up and continuation of last weeks Knowledge base Content post. In writing this post it veered some way from my chosen topic, hence it’s posted under Technology, but it’s something I think it’s worth writing about – combining both local and specific internet search results in a single relevance-based list.

Third-party content

Third-party content is often taken directly from, or derived from, trouble-ticket data (I discussed trouble-ticket [Incident] data last week). I’m describing it here because it’s a type of content you don’t control. Typically hardware and software vendors publish this kind of content for the benefit of their customers. Sometimes the content is free, other times it's restricted and paid for (The Serio knowledge base is found here).

Third-party content presents some interesting challenges, the most important of which is integration when the content exists on an Internet website. I’m going to discuss these challenges here, as this is something I’ve been asked about before.

In an ideal world you’d set-up your own knowledge base, and simply ‘add-in’ third-party knowledge base sources – so that when you do a search, you can search at the same time:

your local content (your own trouble-ticket data and documents),
the knowledge base directory at vendor A,
the knowledge base directory at vendor B and so on.. 

and have a single, consolidated results list based on relevance.

It sounds great, but is very difficult (impossible?) to implement at this time. In a nutshell, if the content exists on another site you can either:

  • Spider the content yourself, like a search engine does. However, webmasters have a habit of banning spiders they don’t recognise or which operate without permission on their websites, so as to conserve bandwidth for real users
  • Ask the remote website to query it’s own content for you – but this presents problems when constructing a single results list based on relevance because your own knowledge base software cannot see the actual document (ie, does a remote document rank above or below a local, private document).

So, like I said, it’s technically demanding – even leaving aside the ‘terms of service’ issues that arise when using the content of another ogranisation.

Tip: If you are a Serio user, there is something you can do – add your best external knowledge base sources to your ‘Useful Links’ chapter (see ‘Useful Links’ in the HowTo guide for more information).

Probably the best hope for solving the problem I’m describing lies with major search engines such as Yahoo! and Google. What they need to do is allow searchers to set-up customised pages that restrict the searching to particular points within sites (where the KB content is specifically, not just a particular URL) and let the search engine perform consolidated search for you based on your choices.

However, for this to solve the problem search engines would need to see your own local (trouble ticket) content, and would need to understand this is private and not to be served to other searchers. The search engines could either fund this by a fee, or by advertising as now.

I'll come back to the 'proper' thread of these posts later in the week.

Friday, 22 Jun 2007

When talking about Best Practice and ITIL (The IT Infrastructure Library), there are many key words and phrases that are thrown about. In this blog I have tried to identify just a few of the more common buzzwords and give a brief explanation of my understanding of them. (If you have limited knowledge of ITIL then the ‘Introduction to ITIL’ whitepaper is a must read).

1. Process Definition - Both Service Support and Service Delivery are split into processes. Each process should have a clear objective and is broken down into tasks, each with inputs and outputs.

2. RWO - ‘Real World Object’ is used to describe the inputs and outputs of each task. These can be physical objects such as a piece of paper, or electronic objects like information that is saved in a specified location. Even something intangible, such as a phone call, could be considered as an RWO.

3. Availability Management - This is a Service Delivery process put in place to identify the availability requirements of key IT systems and services, making sure these requirements are met. There is a very good whitepaper on this subject titled ‘Introducing ITIL Availability Management’. One of the key success factors for availability management has to be it’s reliance on having appropriate and meaningful Availability measurement and reporting. The previous blog post ‘Using Serio to obtain Availability Statistics’ also makes interesting reading.

4. Role - each task is performed or executed by a role. The role can be a human or a piece of automated software and should be governed by a set of rules, for example ‘The questions below MUST be answered before proceeding to the next stage’.

5. Process Owner - One person is responsible for the Process Definition, which should be treated the same as a Configuration Item and is subject to Change Control.

6. Service Desk - The Service Desk is a function, not a process and should be the first point of contact between the Customer and the Service, providing advice, guidance and rapid restoration of normal services. It has more functionality than the traditional Help Desk and should be focused on its main objectives, which are to improve and drive forward the service provided. Service Desk and Helpdesk have been discussed in this previous post.

7. Service Culture - Suggests that any organisation embraces the concept of service and customer care. The aim should be to exceed customer expectations, not in what you deliver but in the way you deliver it. Good Service Level Management (SLM) processes can help achieve goals and some good SLM KPI’s (Key Performance Indicators) have been posted here.

8. Call Logging Script - (and form based inputs). These are a series of questions that should be answered for every call and can increase the integrity of the data supplied whilst helping to reduce any duplication in work and ensuring a set uniformity for how data is recorded. Call logging scripts have been discussed previously and there is even a sample script here.

9. Incident Management - The goal of Incident Management is to restore the normal service operation as quickly as possible and minimise any negative impact. Many Incident Management topics have been posted over the course of the Serio blog, starting with an ‘Introduction to Incident Management’ here.

10. Incident Lifecycle - This is simply the steps that are taken when handling an Incident, from the initial reporting and recording (logging), then progressing through all the other required steps such as classification or assignment and ending in closure or resolution. A part of the Incident Lifecycle is its Workflow Position and Status. This has been blogged about previously and is explained in detail here.

11. Accountability - This is the responsibility of an agent, usually the logging agent or primary agent, to accept complete ownership of the Incident. This agent needs to remain in contact with the customer all through the Incident Lifecycle, explaining about any assignments, escalations, status changes and making sure the customer is kept informed right up to a resolution they are happy with.

12. Balanced Scorecard - This is an aid to managing performance by finding a balance between 4 perspectives of your organisations vision/mission and translating it into KPI’s. These perspectives are

1. Customers - What do your customers want and what do they need?
2. Internal Processes - How is value provided?
3. Learning and Growth - How will we provide future value and measure potential future performance.
4. Financial - What were our previous costs.

This is complementary to ITIL and provides information on Customer Perception, Internal Processes and Finances.

13. Configuration Baseline - This is the configuration of a product (Configuration Item) at a specific point in time. This serves as a reference for any further or future activities and should be recorded in the Configuration Management Database (CMDB) which has been covered in detailed posts starting here. []

14. CAB (Change Advisory Board) - A group or body that will assess, prioritise and approve any potential changes. Its members should be capable of ensuring changes are assessed from both business and technical perspectives. Membership and participation is flexible and should be composed to deal with the specific changes that are being dealt with. This board was discussed in a previous topic called ‘To a New Change Manager’.

15. Functional Escalation - This type of escalation takes place when agreed intervals of time are elapsed or because of the lack of expertise / knowledge. Transferring an Incident from 1st line to 2nd line support is a functional escalation.

16. Hierarchical Escalation - This escalation can take place at any time and is usually performed manually when it is likely a resolution will not be achieved satisfactorily or in time. This should allow enough time for any authorised line management to take action before agreed resolution times are breached. Escalations were discussed in the previous blog article ‘Escalation in Incident Management’.

I hope all readers will find this article useful but know the above list barely covers the multitude of keywords and phrases that seem to be thrown around. If anybody would like my understanding of any buzzwords not covered above, leave them as comments and I may use them in a future post.

Wednesday, 20 Jun 2007

This is a follow-on from my earlier posts about the open source report writer Datavision - the installation post is here and the getting started post is here. If you have not read the earlier post you need to do so before continuing.

In the getting started post last week I did some simple grouping, used some simple calculated fields, and added some variable report criteria.

This week I'm going to do something a little more complex, involving data evaluations and counting.

The Target Report

The report I'm going to create will take a start date and end date, and will list for each Serio Team resolving Incidents the number of Incidents resolved, and the percentage of Incidents resolved on time.

Creating the Report

Start by logging-in to Datavision and click Create a new report.

As previously, I'll use the views provided as part of the Serio SDK. Looking at the documentation for the views, I can see that I can get the resolving team from the view sv_issue_resolution.

So, from the Datavision menu, choose Insert...Database Field and from the list provided under All Database Fields, drag pending_team to the detail band, as I've done in Figure 1. P160 Pendiing Team

Figure 1 - Pending Team

Now we need to group by the Team. From the menu, choose Insert...Group and select the column sv_issue_resolution.pending_team. Having created a group, you can add a computed field to count the group. To do this, choose Insert...Special Field and drag a Group Record Count over to the Group #1 Footer band (do this by dragging and dropping).

This gives us a count of records by team. However, now we need to find out how many were resolved on time. I can see by consulting the Serio documentation there is another view called sv_issue_sla that contains SLA data - so I'll add this table to the detail band and perform a join between sv_issue_resolution and sv_issue_sla.

From the Datavision menu, choose Insert...Database field. Add sv_issue_sla.pending_mins_actual and sv_issue_sla.completion_mins_target to the detail band by drag and drop, as I've done in Figure 2. These two columns contain our SLA target and actual SLA achievement. P160 Add SLA fields

Figure 2 - Add SLA fields

To make the join between the two views sv_issue_resolution and sv_issue_sla, which we can do now we've placed database fields from both tables, select Database...Table Linker and link the two views as shown in Figure 3.P160 Linking Tables

Figure 3 - Linking Tables

Now it's time to look at a really cool feature of Datavision - formulas. The formula language is something called Ruby - google for 'ruby script' and you'll find lots of info about it. For me this makes Datavision a serious tool.

Here is how I'm going to use a formula. I've brought in our SLA target and actual SLA timing. If the target time we took is less than or equal to how long we actually took to resolve the Incident, I'm going to return a 1 - if not, I'll return a 0. Then in the footer I'll add-up all the 1's I have, and this will tell me how many Incidents were on time.

It sounds harder than it is. Here is the formula in Ruby:

if {dbo.sv_issue_sla.pending_mins_actual} <=

P160 FormulaTo add the formula, click 'Insert..Formula Field'. Then from the Fields window, choose 'Field...New Formula'. Give the formula name (such as 'On time') and then enter the formula above, as shown in Figure 4. 






Figure 4 - Formula


Having created your formula, drag it to the Detail band.

P160 Aggregate FieldNow we need to add-up all the 1's from our formula. Luckily this is easy in Datavision. First of all, click the 'On time' formula and then, while it's selected, click 'Insert...Aggregate Field' from the Datavision menu. Create a 'Sum' aggregate field as shown in Figure 5. 





Figure 5 - Aggregate Field


This will add-up all the 'on time' resolutions for each team, and give us a grand total at the bottom. I think that's really neat.

We are now almost finished. We need to tell Datavision to only count resolved Incidents, and from the Serio documentation on the views I can see this is what we need:

sv_issue_sla.issue_status in ('p', 'c') and
sv_issue_sla.type_code = 'i'

From within Datavision, select Report...Select Records and enter the SQL above.

Finally, We need to hide the Detail band - we are not interested in it's contents. Right-click on the 'Detail' label, and click 'Supress'. Do a little bit of tidying-up by removing unused headings, and your report definition should look like Figure 6. P160 Final Definition

Figure 6 - Final definition

And you can see the finished report attached (exported to PDF).

Tip: The default font seems to be Time New Roman, which I think is rather ugly. If you click Format...Default Format you can change this however to something more attractive.

Monday, 18 Jun 2007

My post today is all about Knowledge base content, and how you can make a start creating your own.

First of all, I’ll offer a definition in my own words. What is a Knowledge base?

It’s a special kind of database for storing a workgroup's or organisation’s knowledge and expertise. Typically a Knowledge base contains articles that relate to fault fixing, how-to documents, user guides, white papers and so on. There is also usually a retrieval system (often a search engine) and way of classifying and grading content.

Knowledge bases offer all sorts of possibilities. In Incident Management, they offer the possibility of a genuine lift in first time fix rate. They offer new staff a chance to make a bigger contribution more quickly, whilst reducing dependence on a few key engineers.

A knowledge base is bit like motherhood and apple pie – it’s almost impossible not to be in favour of it. So why is it then that so few companies seem to have effective Knowledgebase content in place? I was at a social networking event recently (a breakfast event, more lively and interesting than I expected it to be) and ‘reducing dependence on key technical staff’ was one of the things that came up for discussion.

Knowledge base content was one of the solutions proposed, but only a couple of us there had knowledge base content we were trying to develop. One guy claimed ‘we’ve got a really effective Knowledge base’ to which I asked ‘How do you know it’s effective?’.

I will go on to answer my own question – most likely in a future post. In the meantime, I’ll stick with why it seems so few companies have Knowledge base content of their own.

The answer lies in the content word. Where does the content come from? Who writes it? How can we make sure it is accurate? How can we ensure that, as technology changes and moves on, so does our content? Where does quality come into things? How can I create content when we are all so busy? How can I get any kind of objective measure of the usefulness (or otherwise) of the content?

The bottom line is it’s all about content.

In preparing this article, it became clear that there was almost a ‘hierarchy’ of content. I’ll try to define each (as I’ve seen it used in IT Service Management) and describe some of it’s relative strengths and weaknesses.

Trouble-ticket information

In ITSM, this might be the most commonly-found – because we create it as part of the task of resolving customer Incidents. An Incident might consist of a fault description and (eventually) a resolution, which offers us a knowledge base article as a 'free' by-product.


  • It’s free! (Well, almost).


  • Tends to be focus on problem resolution, but that isn’t the only thing we do – or the only thing we want. We want to things correctly in the first place.
  • Requires engineers to really take the time to explain what they did. The more time-consuming the write-up of resolution, the more likely the engineer is to gloss over something important.

I'll continue this thread in future posts.

[Update by blog admin: follow-up posts are here and here ]

Wednesday, 13 Jun 2007

Another day, another 'Web 2 not working' survey writes Tracey Caldwell.

Did you LinkIn then log out? Did you leave Second Life to get a life? Nothing to say on your blog or wouldn’t know a wiki if you met one in the street? You may not be alone.  Web research company Hitwise has found that the vast majority of people are lurkers, watching and not contributing to Web 2.0 sites.

Web 2.0 is not working, proclaimed news stories all over the web, based on a keynote speech  presented by Bill Tancer analyst at Hitwise on the "State of the Web 2.0: Measuring the Participatory Web”. Hands were thrown up in horror at the Hitwise figures showing only 0.2% of visitors to Flickr actually post pictures and a miserable 0.16% posted videos on YouTube.

Web 2.0 participation is certainly not widespread in business where hierarchical company structures and competitive career structures work against the Web 2.0 ideals of knowledge sharing and communal advances.

Web 2.0 for the business is unimaginatively dubbed Enterprise 2.0, a terminology that has the effect of making a global interactive networking phenomena sound like a rather dull CMS bundle. Given its uninspiring moniker it comes as no surprise that Enterprise 2.0 too seems to have stumbled at the starting gate.

BBC technology correspondent Rory Cellan Jones carried out an amusing personal study of the potential for Web 2.0 in his working life and concluded that at forty something he is too old to Twitter and too mature for Myspace.

A study that seems only slightly more scientific in that it included more than one respondent was conducted by NetBenefit. The hosting provider claimed its survey “Explodes the myth of poor take-up of web 2.0”. The write up of the poll breathlessly revealed that 60% of respondents are actively using web 2.0 technologies: “Despite recent criticism that Web 2.0 is all marketing spin people feel there is real substance to the new technologies being deployed such as blogs, Ajax and mash-ups with 69% of companies disagreeing that Web 2.0 is just hype”.

Turns out the survey was carried out amongst delegates at Internet World with an undisclosed number and type of respondent. The results also revealed the unastonishing revelation that Web 2.0 is seen as a natural progression in the usage of Internet technology “with 83% agreeing that it is an online 'evolution' rather than a radical step change in the way we use the World Wide Web”.

All this “Web 2.0 is not working” stuff does seem to be based on the slightly dodgy premise that minority participation is a problem though. In most sectors of society, a minority are the participants or the creators, from music, to software development, to R&D in industry. Tom Loosemore at the BBC is a Web 2.0 maven; tap into his blog for how Web 2. 0 can work in business.

Or Connected Internet has produced a nice, very short summary of what social Web 2.0 can contribute to business.