Skip to content

Behind Glass Walls

Can enterprise and transparency mix?

Archive

Archive for October, 2009

Here we go! I’m involved with a student consulting team at QUT. Our task was to create a Business Proposal to encourage the QUT Library to genuinely adopt Web 2.0 technologies and techniques. The team consists of:

We’ve really tried to cover a wide range of areas, and think we really can show solid reasons for the uptake of Enterprise 2.0. As part of our report, we produced a video, detailing the content of the report in audio and visual form. Enjoy!

By ToniVC from Flickr under CC BY-NC-ND

By ToniVC from Flickr under CC BY-NC-ND

Enterprise 2.0:

  • Where did my Time go?
  • Generic Toolbox or Specific Solution?

Dion Hinchcliffe‘s article on 14 Reasons Why Enterprise 2.0 Projects Fail provides some insight into the current effectiveness of the QUT Library’s initiatives, and some lessons that they could take on board. There is a a definite road bump in the form of governance (point seven), as well as islands of participation surrounded by inaction (point ten). I’m going to talk about “Pushing Enterprise 2.0 as a generic toolbox instead of the solution to specific problems” (point eight), which can lead to “Not waiting long enough to let critical mass build” (point fourteen).

There are a range of issues in the area of pushing Enterprise 2.0 as a generic solution, rather than choosing solutions that best fit specific problems.

For example, the Library does have a twitter account, which at the moment is almost exclusively used for announcements and Library news. This is an old point, but Twitter usually works best as a social platform, not a broadcast platform. It can be used that way, but I think this could be partly due to seeing Web 2.0 and Enterprise 2.0 as a hammer, and treating everything as a nail.

A central issue for the Library is one of time. Staff time. Student time. Students have little time to spare, and adding to that load through extra features on the Library website may not be the best path. Instead, some specific issues should be addressed.

For example, rather than incorporating rating functionality that requires extra work, a recommendation system could use the number of visits, visit lengths, and time of stay to calculate ratings for each resource. This would utilise a core element of Web 2.0 – data is important, and can be used for a huge range of things. Essentially, the ratings are already there, just waiting for an algorithm to extract them, and a method of displaying them.

Finally, in the course of using tools that might not fit the purpose or building functionality that requires more user input, there is a very real risk that these errors will not be seen as the cause. Lack of adoption might be blamed on promotion or issues from lack of strict governance. Finding tools that fit a specific problem is only the first step – how the tools are used, and the extra time required is an important consideration.

For the Enterprise 2.0 Proposal, our group has been using Google Groups to coordinate tasks, meetings and information. We’ve also got a Google Doc going to build the actual report. Combining Google Groups and Docs provides one location for discussion, planning and comments, and a separate place to construct the report. Some of the features I’ve found most useful in Google Groups is the mailing list facility to contact all group members. The messages are also stored on the group, which is great for referencing the conversation later.

Image of the front page of our Google Groups page.

Image of the front page of our Google Groups page.

I can see some of this functionality being very useful for geographically separated businesses. The usual issue of control over the storage of the data applies, but for travel planning, recording meeting minutes or project groups, Google Groups might be just the thing to keep organised.

This post is a continuation from my previous post, looking at some of the issues in collaboratively constructing documents. There are a huge range of options available for collaboratively producing documents. From sharing a file via USB or file hosting website to online editing and annotation, each method is best suited to different purposes. The main considerations include:

  • Control:  Where is the document stored? What happen when services/people are not available?
  • Security: How easy is it to control who can access the document? What system is used for authentication?
  • Versioning: Are different versions stored and are they clearly organised?
  • Document Type: File/desktop app (eg. pdf, doc or odt)? Browser-based (eg. wiki, word processing)?
  • Formatting, Layout and Markup Language:
    1. Plain Text (“lowest common denominator”) – no formatting
    2. lightweight markup (WikiText, BBCode, Textile) – simple to compose, easy to read in plain text form
    3. WYSIWYG (MS Word, OpenOffice.org, LaTeX) – document preparation systems with full formatting support

In looking at these attributes it is clear that using a Wiki for a sensitive or critical document may not be the best choice. Similarly, sharing a MS Word document via USB drive will quickly cause chaos through incomplete or confused revisions. It is necessary to determine the above attributes before choosing a method of creating the document.