Monday, September 22, 2008
Can government collaborate in online service development? | Tweet |
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.
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.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.