Posts
I have participated in the beta testing of software for over 20 years now - it's a great way to get an early look at new developments and to have a level of influence over the development process as a customer (in one case I was even hired as the lead designer on a subsequent product).
Lately I've been participating in a number of private betas for online applications. One of these has just gone into public beta (SlideRocket - an online presentation solution designed to compete with PowerPoint). In this case the developer has made their full issues and fix list available publicly and there is quite an active community helping them improve the application, such as through their User Voice section.
This has made me think about how government develops online services for public use - what prevents us from considering collaborative development in this way?
There are obvious upsides and downsides to a public beta approach for any organisation.
On the minus side, it exposes the service early, meaning that government doesn't have as much time to determine the message for the release and providing detractors with an early opportunity to attack.
It also puts a lower quality solution 'out there', providing opportunities for the public to draw a negative view of the service due to its less than fully developed state. This can make it harder to draw people back when it is more fully developed.
Thirdly, putting a public beta out provides malicious elements more opportunity to find security holes and cause damage.
On the upside, a public beta provides for a much more rigorous level of scrutiny by the public and experts before the service is finally release. This allows issues to be identified and addressed and improves the usability, functionality and stability of the service. It also comes at a lower price tag than running 5,000 focus groups around the country (and internationally).
It also allows several bites at the cherry for government announcements. Firstly comes an announcement on the public beta, positioned as an opportunity for the broader community to test, reflect and comment on the service. Then comes the release announcement, where the government can launch the service - more confident it will hit the mark.
On balance I believe the downsides can be mitigated through careful communications management, whereas the upsides provide enormous efficiency benefits around the consultation area.
It does require a change in project management approach - unforeseen bugs and feature issues will be raised through the public beta process and need to be managed adequately.
I'd also suggest that there would need to be less focus on date/cost and more on adequate service quality to meet customer needs.
I believe this is a broader focus change needed in IT development anyway. I am quite concerned by large projects defined around delivery dates rather than meeting the appropriate level of solution performance for customers.
I wonder which of my upcoming projects is appropriate for consideration in a public beta... I can think of several immediate options.
Monday, September 22, 2008
Can government collaborate in online service development? | Tweet |
Saturday, September 20, 2008
Gershon recommends procurement integration | Tweet |
The first public comments from the government on the Gershon Report are beginning to emerge, with The Australian reporting on Thursday, Tanner targets agency wastage in bid to save $1bn.
- allowing public servants to spend more time being customer-focused through spending less time grappling with inconsistent and/or low usability internal systems,
- through reductions in frustration and workplace stress (which impact service quality),
- through easier hiring and transferring of staff who need to adapt to fewer systems in job changes, and
- better information flows within and between agencies to cut delays.
Friday, September 19, 2008
Why you should pay attention to intranet search logs | Tweet |
My team keeps a close eye on what people search for in our intranet.
It helps us identify patterns in staff behaviour and better support their needs.
In browsing for other online information, I came across a case study from 2006 about a government agency which provides a similar picture of the value of paying attention to intranet search logs.
Thursday, September 18, 2008
Improving an intranet staff directory | Tweet |
My team has been throwing around approaches for improving our internal agency staff directory on the intranet to make it more of a knowledge resource for staff.
As this is the most used tool in our intranet (people need to contact other people), improving the service contributes measurably to our staff's capacity to collaborate and discover the information necessary in their roles.
The more we can streamline people discovery, the more time we can save staff.
Thus far discussions have focused on our own experiences across a number of online staff directories over the years.
For my contribution to the discussion, from my experience over a twenty year span, the first staff directories were based on the paper phone directories used before intranets were common - alphabetical lists of names, titles, teams and phone numbers, divided by region or area.
These lists - and intranet directories - were useful in finding a known person, were you could identify their name and area.
However they had more difficulty in locating unknown people - subject matter experts - as area and team names did not always reflect their activities and without knowing who to contact it was hard to find an appropriate name.
Also traditional staff directories are only name, number and rank - they do not provide details on skills, relationships or communities, which help link people collaborate more effectively.
Therefore I've described three cases I want our future staff directory to cover.
1) Locating details for known people
2) Locating experts
3) Engaging networks of knowledge
As part of these cases, we're considering Facebook and LinkedIn style features, such as,
Involvement in all of these areas would be optional, allowing staff to better self-manage their privacy. However, as in any situation involving information sharing, you get greater value when you share than when you silo knowledge.
Over time this approach lends itself to integration with collaboration tools, forums, wikis, groups and blogs, as well as team-based tools such as group calendars and mailing lists.
We've been looking online for reference material on the topic of staff directories, drawing on the experiences of a number of private sector organisations who have implemented similar types of directories.
A couple of the resources we've found useful include,
I'm very interested in the experiences of other government and private sector organisations in this space - so drop me a comment if you have suggestions to add.
Wednesday, September 17, 2008
A glimpse at the future of the semantic web | Tweet |
Fresh+New, a blog written by Seb Chan from the Powerhouse Museum, has brought to my attention Aza Raskin’s Ubiquity, a very interested look at the possible web of the future, using semantic browsers to provide a more connected experience.
More details are in Seb's post, More powerful browsers - Mozilla Labs Ubiquity, or on Aza's blog.
Below is the video introducing Ubiquity.
Ubiquity for Firefox from Aza Raskin on Vimeo.
