Rather than starting with the assumption that 2.0 (or social) is the answer to anything and try to make the enterprise fit in, he starts with the opposite approach. He starts with problems and ends with a solution that appears to be enterprise 2.0. Like it or not but enterprises are organized on processes that are essential and vital and this won’t change. I’m to talking about the caricature of processes we’re being inflicted to make it too easy to hold them up to public ridicule. but what they should be. Caseau makes it clear that processes should be as light as possible to be manageable, as agile as possible to be improvable. Hence the importance of lean management. Things become really interesting when enterprise 2.0, rather than being seen as a danger for steadiness and processes appears than being a lever that serves agility and innovation. In this context, conversational systems support ongoing learning, innovation and ongoing improvement.

From Bertrand Duperrin's review of Yves Caseau's book on Enterprise 2.0.

I like the reference to lean management (I've talked about "Lean Operations" myself), although in some circles there is a natural skepticism that this this is a codeword for cost cutting and down sizing. That's not what I mean when I talk about lean and I don't think Caseau does either. Being light, lean and agile is also what I think Andrew McAfee's original paper on Enterprise 2.0 was all about too.

Naturally, if you are skeptical about "lean", you might ask what we mean by light and agile? Well, here is a starting point: 

• Individuals and interactions over processes and tools.
• Working [products and services] over comprehensive documentation.
• Customer [participation] over contract negotiation.
• Responding to change over following a plan.

So then, how did the experiment go? First, let’s remind ourselves of the prototype’s primary objectives

1. To test, in public, a prototype of a new, single UK Government website.
2. To design & build a UK Government website using open, agile, multi-disciplinary product development techniques and technologies, shaped by an obsession with meeting user needs.

The prototype was developed in 12 weeks for £261k. It launched 1 day late, but given the need to recruit and gel a suitably skilled project team from inside and outside government, Objective 2  can reasonably claim to have been delivered. A boundary-pushing experimental prototype (aka a Minimum Viable Product ) was delivered by an in-house team working in an open, agile way, placing user needs at the core of design process.

This isn’t a new approach, but it’s one that still all too rare across government...

But what about Objective 1? The reaction to the prototype itself?

...

...the reaction that really matters came from real users. Actively asking people what they think about a new product is always chastening yet ultimately rewarding, akin to a visit to the stern dentist. And we were thrilled with the volume and quality of user feedback garnered. People are so keen to help Government improve our products. We just have to ask for help, listen and respond.

The prototype was by no means perfect - and the Alpha team recognise that. But it was a prototype and that's the important difference - a completely different approach to IT in government is on display here.

Kurt Nielsen, the hospital’s director, says that while the doctors are not particularly adept at information technology, they have gradually embraced it. And it helps that the staff was involved in developing the innovations.

“My staff at the hospital is very, very satisfied,” he said. “We build these systems in an incremental way, and seek their input throughout.”

Talking of Social Business Design, I've written before about the need for new approaches to IT in healthcare. It sounds like the Danish have the right attitude more than anything else.

Most of us have built and reviewed and rebuilt intranets using Waterfall project methodologies. It’s the process of understanding all of the requirements and risks first, developing specifications to describe them, and then implementing the solution. Using this approach, however, typically results in late and over budget intranets. This is because intranet projects are often plagued with changing requirements, unanticipated integration challenges, and usability annoyances that are difficult to accommodate in the fixed scope of the project

I can't tell you how strongly I agree with the recommendations here - its one of the reasons I've been a fan of the MIKE 2.0 methodology, to help break that waterfall approach failure cycle with not just intranets projects but any kind of information management, knowledge management or collaboration system implementation.
BTW I couldn't find the original article, so hat tip to Matthew Hodgson for sharing it.