chieftech’s blog

The stakes a are high for Project Eden, the codename for a long term project to rollout a single electronic document and records management system across all arms of Australia's Defence forces.

The scale of the project is huge and the final cost is expected to lie somewhere between $A100m-$A500m.
Defence estimates it will need to handle 50,000 users within two years and up to 100 million new objects per annum. There will be users at up to 600 locations in Australian and overseas .

Defence has been evaluating vendors since 2006 and has missed previously announced deadlines for making a selection.

I felt very nervous reading this.

I've previously been involved in a very large electronic document and records management system (EDRMS) project for a large international mining company using one of the major systems, so I have a pretty good idea of what the ADF is trying to achieve. I also have a pretty good idea about the challenges, which aren't necessarily technological (and where there are, there aren't necessarily what you might think).

One of the things that concerns me about any implementation like this is that we confuse the desire for a single information system architecture (e.g. one logical EDRMS system to rule them all) with creating a homogeneous information environment that they will try to make everyone use.

This goes beyond simply making the EDRMS easy to use. The typical approach is to use a uniform user interface to meet that goal but all we really end up doing is meeting the lowest common denominator rather than actually satisfying different user needs. Similarly, we also risk ending up with a rigid information architecture that makes the conceptual information system architecture easier to implement, but doesn't actually fit how work is done.

Often these things look great to the guy designing them from his desk in a nice air conditioned office, but the view is very different once you are on the ground (or in my case, 500 metres underground).

Of course, it doesn't have to be that way. I hope they are considering:

• The organisational change aspects and dealing with what I call the "what's in it for me gap" (a user-centred design approach is essential);
• Applying open information access policies within the ADF, with information restricted by exception and managed through activity monitoring and version tracking*;
• How they can apply a Web Oriented Architecture approach, and standards like CMIS, concepts like De-perimeterisation, and even new database architectures like NoSQL; and
• Learning from recent experiences of applying social computing techniques to how people organise, discover and use information (rather than just relying on taxonomies and mechanical search engine techniques).

*Radical I know, but necessary unless you want to end up with a more complex and expensive version of the existing file shares! This isn't about changing information security classifications, but about dealing with information, which is currently hidden by obscurity.

“Wicked problems are a class of social system problems which are ill-formulated, where the information is confusing, where there are many clients and decision makers with conflicting values, and where the ramifications in the whole system are thoroughly confusing.”

Sound familiar? Many intranet design problems share these attributes. Wicked problems require different thinking and design skills to solve than typical problems encountered in the design of symbolic communications, material objects, or even organized services. The intranet, conceptualized as a wicked problem, also needs different approaches.

A *very* well articulated post by ThoughtFarmer's Gordon Ross on why intranets are so simply, yet so challenging. Many people still treat intranets like brochure design projects, but as Gordon explains, intranets really represent a different kind of design problem.

We also hinted at this approach to creating effective intranets in our webinar for Atlassian, on Designing for Adoption yesterday.

According to Burning Man founder Larry Harvey, the difference between a market and a gift economy is that the former is based on scarcity while the latter is based on abundance. And he says a gift economy fosters what Robert Putnam called ‘social capital', that is, it forms connections between people.

Nett is a technology magazine targeted at Australian small and medium businesses, although I think this short introduction to the gift economy is as a good as any. I like the focus on scarcity versus abundance in the quote above. Some of you might realise that the idea of the gift economy is important in social media (which I suppose is why this topic popped up in Nett magazine).

However, I think the concept of scarcity versus abundance can also help with understanding how to apply social computing successfully inside the enterprise. This has less to do with building social capital and more to do with adopting an attitude that 'bits' are plentiful and a resource to be used, not constrained - it also means you can afford to fail. Obviously it follows that if you adopt an IT abundance strategy, you'll need the right systems to support an IT abundance approach.

Social capital inside organisations is still important too, but the ecosystem of public good is different from the dynamics of the closed "internal organisational good" ecosystem. You can support that internal gift economy with an abundance approach to IT, which is how you build internal social capital.