Fixed Price projects - Inconvenient truths by Scot Ambler

In recent times, for some reason, call it bad karma perhaps, I have been part of projects which have had contractual and cost issues. Projects followed BRUF (Big Requirements Up Front) method to accumulate requirements, estimates and pricing were done and contract signed with Customer. The fixed price project was started. And the problems which ensued were typical of so many such projects in industry. They are well documented variousuly, so I am not going to add to that. But I have often wondered why customers insist on agreeing to a fixed price in beginning of a big project when most of times scope can hardly be known. What it does is that, it makes both the parties, the customer and the IT Supplier draw the lines like in a battle and start on a war footing with Sr. Management on both the sides acting like Generals engaged in high strategy. Supplier implements strict change control procedures and become fixated by change management and repelling anything not in original scope. As initial estimates done during contract signing phase can't be relied upon for accuracy, big contingencies are built into estimates but without any surety of its finality. Customer in meanwhile practicaly disengages during project execution waiting for the final delivery to happen as most of his risks are offloaded to supplier. The whole dynamics of a fixed price project creates an enviornment where both the customer and vendor are playing games to protect themselves and not working together to solve the problem for which project is being executed.

Scot Ambler in this articles has articulated what he calls Inconvenient truths about fixed price software development. In fact he goes even further and calls it an unethical practice. Most of points he has highlighted are valid and right on target. Customers have to realise that if they really care about ROI, they need to engage and work with suppliers and not look to offload thier risks in form of fixed price projects. IT vendors or providers on other hand , have to relook into thier own practices which they have been selling to customer for years . As Scot Ambler says "For several decades traditional software engineering theory has told us to do formal, up-front cost estimates. In turn, we have taught our customers that this is the way things are done " . So it is time we teach them that we were wrong.

cuil a google killer

Twitter was on fire yesterday after cuil.com a new search engine was launched after much hype on techcrunch. Everybody seems to be waiting for google killer, maybe scared of its monopoly. Only if it was as easy as that. Google can't be beaten by mere hype and PR. Cuil claims that "...we searches more pages on the Web than anyone else—three times as many as Google and ten times as many as Microsoft." Really!! But I can't find my blog through it, it returns 0 records. what is the deal about this large index!!

Wiki adoption in enterprise - Participation inequality

There have been few online discussions about how emails and word documents are bad and their use in collaborative environments and organisations should be reduced. I mostly agree. Email within enterprise has become most used tool and often work comes to standstill if email is down. So regimented have we become with use of emails that we don’t want to use tools which are far better suited for today's changing times of increased collaboration where participants are often sitting across continents. Email is a great tool but like any other tool it is meant to do a certain task and not everything. While championing the use of wiki for team collaboration, I had few observations:

1. No learning new tool: Many people don’t use wikis because they don’t want to learn a new tool. Even though using wiki is as simple as typing in plain English with some simple mark up, it appears too much to learn for many.
2. Old Habits Difficult to Change: Many just don’t get it why they should not use MS Excel and MS word for certain tasks and instead should be asked to use the wiki. They think the wiki is an overhead and they dont have time to go to a site and put content there. They dont consider wiki as a tool but as some fancy site. Old habits die hard.
3. Email Regimentation: Heavy use of email has regimented us. I have seen many people doing their wiki contributions starting with "hellos" and ending with "regards" like they do in emails.
4. Scarcity is power: Many feel threatened by wiki culture as it takes away the control. Information and knowledge is the power. Scarcity of information is what makes certain people derive their power and authority. They wouldn't want to let it go. They want to keep the information scarce.
5. Openness is scary: Wikis are open and content can be created/edited and deleted by user. That scares lots of people. Many years of corporate life where every tool is controlled and every usage need some sort of approval by someone, this openness and control sounds too good and too scary.
6. No incentive to contribute: Wiki pages are result of collaboration and author names are not displayed on top of page. This puts off people as they are used to announce their names on top of word documents. Word documents can be sent over emails with CC to all those people who would do your year end performance reviews. Personal efforts are recognised and not the collaborative so there is little incentive in contributing to wiki.
7. Volunteering is unfamiliar: Wikis are flat, unstructured and non-hierarchical. That is exactly opposite of what an enterprise is. People who are too accustomed to hierarchies and being directed, volunteering to wiki remains an unfamiliar territory.

All This though is hardly surprising as most of multi-users communities suffer from this pattern of behaviour where very few people contribute and most just lurk around. This is also called as participation inequality and is excellently explained by Jacob Nielsen. As per this theory :

In most online communities, 90% of users are lurkers who never contribute, 9% of users contribute a little, and 1% of users account for almost all the action

The benefits which a simple, social and collaboration tool like wiki can bring behind firewall are immense but there remain few roadblocks to overcome to make wikis a success. I stumbled upon a site called wikipatterns , which does a very nice job of documenting patterns on wiki adoption. It s many patterns some of which I have personally come across, like wiki phobia (somewhat similar to my point 4 above). Reading the patterns, I just realised that I was about to become a Wiki Bully.

Enterprise2.0 - Let conversations happen

Transformation into Enterprise2.0 has to begin with enabling social software. Let employees connect, network , share and have conversations :) You got to know the change agents, the idea generators, the transmistors. The long tail of enterprise.

The long tail of web2.0

Web2.0 celebrityhood

Twitter Addiction

What Twitter is doing to Normal people.