Blog post

Government 2.0 Requires Perpetual Beta

By Andrea Di Maio | September 22, 2010 | 5 Comments

web 2.0 in government

In a conversation with the CIO of a parliamentary organization, I discussed the role of social software in supporting some or most of the parliamentary processes, both purely internal to the organization, and involving specific external stakeholders (such as union representatives, university professors, domain experts, and so forth).

While it appears that some of these processes have clear boundaries in terms of who participates and the information accessed and required, this is not necessarily true. For instance a bill could be drafted by a group of members from a particular party or party coalition, engaging stakeholders of their choice, to then appear into the parliamentary processes for internal and formal discussion. One could argue that once the bill enters this process, the workflow could be supported by an enterprise platform, providing the collaboration functionality that is required by the formal process. On the other hand, during the formal discussion proponents may be willing to submit evidence gathered during the preparation of the draft. All they can do is to re-enter or import such evidence into the enterprise platform, as opposed to creating discussion spaces that allow a seamless conversation to occur. While this is nit necessarily a showstopper for the enterprise platform, the more such cases, the less the perceived value of the enterprise platform with respect to – say – email.

Since this parliamentary organization is in the process of developing the requirements for their new internal portal, which should presumably provide a full range of social computing options, the discussion geared toward how to determine which functionalities would really make the difference and increase the value for members and other stakeholders.

The traditional approach would be through talking to users and engaging a consultant in synthesizing the findings in a requirement document, prior to a proper tender. But do they know exactly where they want to take their processes or – better – where the use of social software by various stakeholders will take them? While the concerned jurisdiction is certainly not amongst the most advanced in terms of technology uptake in government, most MoPs are exposed to technologies like Facebook, Twitter, YouTube on a personal as well as political basis. Their children and grandchildren use those regularly, their communications staff scan social media to perform sentiment analysis and find supportive as well as negative opinions expressed about their political persona, and so forth. Their adoption of social media for critical processes may happen more quickly and abruptly than expected. As a result, an enterprise collaboration platform that looks like the most reasonable solution today may become inadequate very soon.

So the alternative is to be in a state of perpetual beta, to make pilots and experiments the normal course of business, to build a very simple and open architecture around which to enable experiments with open source or consumer tools, allowing individuals to make their choice about the particular collaboration space they want to build, giving them control of the boundaries, of the definition of what is internal and what is external.

Of course this requires certain tenets, about information security and confidentiality, and the ability to distinguish official documents (which could be digitally signed) from drafts for discussion. It should allow the background information supporting the MoPs in the discussion of a bill to include internal elements (such as the records of previous discussions) as well as external elements such as wikis, Facebook groups, YouTube movies and more, at their discretion.

Are parliamentary and government organizations ready to be in perpetual beta mode? I doubt it. Can they get value out of social software with a more traditional, waterfall approach? I doubt that too.

That’s one of the main challenges of government 2.0, one that makes it far more difficult and far less friendly than it looks like.

Comments are closed


  • Hi Andrea – really great article. I think that perpetual beta psychology is actually what we have with or without Gov 2.0 – no sooner is a system in place then the landscape moves on, the participants question its efficacy, and the road to its replacement is begun.

    The ‘waterfall model’ of requirement definition, procurement, big implementation and maintenance is poorly suited to the dynamism of the environment into which the solution is placed.

    Perpetual beta might be more likened to the iterative approach of software development – for example we know google is fond of both perpetual beta and iterative development 🙂 For government to respond in a better and more agile way, it *needs* to embrace the perpetual beta psychology.

    ‘The only constant is change’ – Heraclitus.

    Government needs to be able to change constantly, to react fluidly – not in fits and starts. That, for me, is the promise of Gov 2.0. Thanks,


  • Doug Hadden says:


    Business Process Limitations
    You’ve hit the nail on the head. It’s a left/right brain challenge. Enterprise software has focused on managing explicit business processes. Not enough on engagement or creativity. (i.e. in our process, a creative miracle happens here). BPM is starting to show diminishing returns.

    Can enterprise software adjust to this? Not if there is the “hammer” attitude where every problem looks like a nail/process. [My company has developed this approach for our Government Resource Planning suite, so there’s no reason why the approach won’t work with other vendors.]

    Lack of Controls in Web 2.0
    This is one of the knocks on social media. My sense is that the failure of traditional collaboration tools to gain widespread marketshare like GroupWise and Lotus Notes is too much control. Restricted the creative and thinking processes. Many Web 2.0 tools are open source, so governments are able to turn Wikipedia into Intellipedia. [We’re using open source Web 2.0 tools for product requirements management, mainly because we don’t want to adapt our process to the vendor’s way of doing it.]

    Fate Favours Early Adopters
    The issues of security, privacy, external vs internal etc. will discourage laggards. These issues will be resolved over time. Fate will favour the early political adopters. Politicians or parties have benefited from early adoption of some techniques. Examples:

    CCF party in Canada (predecessor to NDP) used new canvassing methods to win a by-election in the 1950s, now it is a standard process for all parties.

    Databases and analysis have become increasingly important where parties gain incremental advantage as they innovate. For example, often credited with the Bush 2004 election win.

    Obama leverages social media to galvanize support. Now the Tea Party is leveraging Twitter.

    Goodluck Johnson declares running for President of Nigeria on Facebook.

  • @Colin – I fully agree that most if not all Gov 2.0 pioneers do exactly this, a series of pilots and experiments. The problem, as usual, is with the many others who are not enthusiasts or converted, and expect your experiments to prove a point and let them make a business case and figure out the ROI upfront. Unfortunately the only thing you can prove is that experimenting (and empowering your employees) has to become the normal course of business. And this is quite scary indeed for many.

  • @Doug – Great point about the diminishing return of BPM, which perpetuates the automation of existing processes rather than push people to think about different ways to achieve the same outcomes.
    I also agree on the lack of control (but this is not something people accept so easily in a government environment).
    Last but not least, I take your point that politicians who move faster on this get an advantage. I am not totally sure this is the case for government organizations though (i.e. the “machinery” of government).

  • Enjoyed the article Andrea, and I definitely agree with Colin’s statement that we are, and need to be, in perpetual beta mode with whatever aspect of our business we happen to be considering at the time. We need to continue to adapt to understand the changing ways our citizens are engaging with each other in order to understand how best to reach them and how best to serve them.