I lost a customer. It’s not the first time of course, that’s part of the business. What’s interesting though are the reasons: thus I gained some insights.
Without disclosing the organizations involved I can tell you that it was about a 2 year contract for an ASP-based social software solution. The software should support a project that involves several firms and organisations in several European countries so it’s about a collaborative effort to develop new insights and applications on a specific and innovative issue. Sounds like a perfect fit for an ASP (t d f)-based social software solution.
So you might ask, what did they decide upon? Well, the decided to use Confluence (t d f) - an excellent wiki-engine. Fine so far, but the interesting issue is the cause for their decision against my proposition.
Social computing technologies are intended to be easy to learn and use. Just as the PC took off inside the organisation with the arrival of the spreadsheet, and email took off with the arrival of the @, so social computing is expected to take off with the advent of easy-to-use tools. (The IT manager’s guide to social computing)
They intend to structure the workflow between the partners and the work-packages very stiff. The partners are supposed to not (!) collaborate too much but rather deliver results based on those work-packages. That’s supposed to ease the work and agenda of the project-manager. Now the main argument was that a tag-based application is difficult to learn in order to result in desirable deliverables and that Confluence will support that strict model of siloed collaboration void of the new forms of (social) communication. Amazingly they do not plan communication as a relevant aspect of the project although they mentioned some of them might never see throughout the project.
Well - for me - the relevant issues and lessons learned are:
1. don’t expect your potential customers to be inline with collaborative management practices
2. think precisely about the benefits for those you are talking with aka management vs. individual user vs. organizational benefits
3. be careful with innovative concepts and labels. Rather term them the old way. Redundancy (t d f) (Groupware, structure) is relevant.
4. mind the chasm (see the chart).
5. serendipity seems dangerous
6. try to understand the (sometimes hidden) agenda.
7. Confluence seems compatible with top-down project-management (don’t understand what makes it different) approaches
8. Wikis are now part of traditional project settings loosing their open and collaborative concepts.
Guess, what I’m going to do in the future. Will tell you eventually 
Related posts
Tags: Business, Innovation, Social Software
Hide Post Comments | Permalink • 
• 
Sorry to hear about that. The substantive point about some people being uncomfortable with bottom-up methods echoes some of the experiences we have had over the years; but I am optimistic about our ability to overcome such fears or reflexes.
Regarding Confluence, we use it a lot and in my view there is nothing in the product that predisposes it to top-down PM. Like everything, it’s about how it is used. Every user has their own wiki and blog as well as the group spaces, and tagging is open to all (although the tool’s ‘label’ feature is not as well exposed as I would like). I have seen a preview of the next major version (2.3), which has some more explicitly social networking features, but I don’t know if this would address your concerns.
From what you say about their intended workflow, they would have got it wrong with any tool
I completley agree with what you say it is just that I understood that a wiki is just another tool (CMS) that can support a vey “antiscocial” implementation.
I think they could have used any other wiki clone for that matter as well, Confluence is surely a good decision.