Here's my quick on-the-spot notes of Mark O'Neill's (@marxculture) excellent presentation, on how a government's IT can innovate.

Citing Andrew Savory, never thought I'd see govt. spokesperson be entertaining and informative. Reminds me of my excellent experiences working for the Swiss Parliament services in the late nineties.

Here's my unedited notes - slides should be available soon. URLs and emphasis added by myself.

UK gov spends 20 billion pounds a year on IT, with 20 top suppliers.

Mark's got a 20MB mailbox to manage this.

Different velocities: technology, business society.

His role: track and align to those velocities.

Velocity of change in his government IT world is "very different" from what it is on the outside. The gap is increasing.

The more you diverge from the velocity of the market, the higher your costs are.

The options are: do the same, do nothing or ask a different question.

The challenge: no money - although they're spending 20 billion pounds a year...

The government is currently driven by the policy cycle: problem -> draw up a policy -> interpret and implement policy -> monitor and evaluate. The customer is not part of this picture. Need an innovation model.

He shows a picture of a washing machine for dogs: there is an e-petition about this, the e-petition site (http://epetitions.direct.gov.uk/) got 16k such petitions in 4 weeks, 3.8 million visitors, 20 million page views, 1.5 million signatures. The e-petition site was built in 6 weeks with 6 people, cost 80 thousand pounds including security costs. The system will be released as open source shortly.

The future: small projects are developed by his office, up to 3 months with contracted companies, if more than 3 months need to ask different questions. 20 billion pounds a year should be one of the most dynamic, diverse and entrepreneurial market in the world. What needs to be done to achieve that?

Leaner procurement mechanisms. Use open standards and open source. Look at the processes, check how much paperwork and overhead is actually necessary. Challenge to new projects includes two questions: what is it that you want to do, and why do you want to do it that way.

Decompose the project in smaller units of work - also gives more chance for SMEs to jump in.

Three layers: infrastructure, app, support. Procurement is currently often based on a complete silo - moving to smaller units can help reuse and sharing.

Rethink the approach to make it possible to buy an excellent application form an SME that does not provide infrastructure or services.

Working on G-Cloud, private onshore cloud for UK government services. (http://www.cloudbook.net/directories/gov-clouds/uk-government-cio-council).

Talking of "agile" "cloud" is a bit like talking about "magic" these days ;-)

Conversation always trumps process.

Two key differences between agile and waterfall.

First difference: with waterfall you talk to developers, they go away for six months, come back with something that you don't want. Agile: you talk all the time.

Second difference: with waterfall, you might not be around anymore when problems arise. With agile, you could be fired after three months...

Tools are hard. Discuss, share, build, learn. Cannot deliver success without using efficient tools, take example from open development teams in the outside world.

Need to build mechanisms to learn, share and discuss what the team is doing.

Success factors:

1. Be the most dynamic, diverse and entrepreneurial market in the world.

2. IT should just work.

3. Reuse, dialogue, agility, ownership should be part of the day-to-day business.