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.

Evolution of Web from 1.0 to 3.0

Journey from ....web1.0 ...........to web2.0..............to web3.0...

Enterprise 2.0 (Part 2) - Use Web Standards to unlock data

In my previous post on Enterprise 2.0 , I wrote about adopting people centric/social focus of web2.0 within company intranet and build corporate facebook as central piece of intranet. One of other aspects of web2.0 is use and adoption of web standards and creation of rich UIs. Web2.0 has put emphasis on making web systems standard compliant, something which was done but not with same zeal in Web 1.0 world. Some of standards and technologies which we find in web2.0 systems are:

• XHTML (transitional and strict)
• CSS 2.0
• JavaScript (AJAX style)
• Microformats
• Clear and sensible URIs
• REST style of architecture

I remember that until few years back, many developers I knew, use to shy away from working on HTML/JS/CSS , treating them like low grade vassals. Coding backend was always considered sexier proposition. Web2.0 thankfully has brought focus back on these simple but powerful technologies. Proper delivery of content and creating rich and responsive UIs is as complex and important a task as it is to code backend to support business logic. Anybody working in an organization would tell us what kind of "shitty" applications they have to deal with everyday. And reason for this is that almost no effort was spent on “designing usability” of those applications. I have seen applications where users have to navigate 4 screens just to choose a value for a text field. Usability aside, there has generally been an ignorance about adopting web standards while building web applications behind firewall.

The reason that web standards should be adopted and enforced is for simple reason that standard compliance makes it easier to integrate applications and at same time reduce the barriers to access the data. As I wrote on one of my previous posts, properly designed URI space can be so helpful in unlocking the information and making it easier to access and reuse. Use of validated XHTML for building UIs is that semantic is built right in the web page and another application can parse it and do something useful with it when needed. Microformats are another simple but powerful format for encoding the data. Many organizations struggle with multiple sources and formats of employee profiles and resumes scattered all across variety of systems. There could be few online profiles, directory entries, PPT profiles (trust me) or employee bio-data kept in a word file and stored in file storage. This all could be simplified by adopting “hRes like Microformat” to encode employee resume making it human readable and machine parsable at same time. Any other system which might need word format or pdf format of resume, can just parse the microformat based resume (passed as an URI :)) and emit it in a word format. This is only a simple example but goes on to show how using web standards makes data and information more mobile and Integrate-able and you don’t always need heavy duty SOA to make that happen for you.

In essence, organization IT has to have guidelines and principles which should dictates that all internal web systems follow web standards and these guidelines should be know to all those who manage and build web systems within organization. Adoption of these simple standards would result in value creation resulting from unlocking of the information which otherwise get entrapped, becomes static and get stuck in silos of application landscape.

SQL flavoured Chocolate.

TheDailyWTF (What The Fu**) is so hillarious, Just came across this funny piece. full article here, try finding out an SQL statment on a chocolate wrapper below:

Enterprise 2.0 (Part1) - Build people centric intranet

It is largely known that enterprise IT lags behind internet IT by a generation or two. Internet is the battleground where innovations happen before they slowly find their way behind firewall. Adoption of web2.0 within an enterprise is also not exception to this rule. Web2.0 like SOA is a classical story of blind man and elephant, but by now there is a general consensus that web2.0 is about taking web to next evolutionary level in terms of tools, standards and user participation. Web2.0 has made web applications more people centric rather than content centric. In web1.0 world, web applications were more about content and its organisation and less about people and users who consumed the content. Web2.0 has chnaged this. Take a look at flicker, orkut, twitter, wikipedia to name a few, all of them place people at the center. Collaboration on content and community sharing is hallmark of these applications. The whole being more than the parts.

This naturally is a fine example for any enterprise to transition its old intranet into an intranet 2.0. Intranets for long have been content and document centric. They served their purpose but they need to retire and be replaced by people centric intranets to make them more effective. After all, intranet is meant for people so that they can use IT to do their core business more efficiently. The focus has to move from mere document management and storage to creation of people network within an enterprise. This is typically true for traditional Knowledge Management systems , which are central part of an intranet. Most KM systems have put heavy focus on document management, whereas knowledge is less about documents and more about how it is created, used and shared by group of people within the organisation. And this is where web2.0 and its social nature come in picture. Intranet and Knowledge Management systems within enterprise have to evolve into people centric networks, somewhat similar to what we see on Facebook or so many other group sharing applications on internet these days. The benefits of people centric intranet are just too huge to be ignored for any organisation and they need not look beyond internet for a business case. Web 2.0 applications have shown that community collboration and facilitation works more than central control and vetting. Many enterprises have realised this and that is the reason that we have started seeing many variants of corporate Facebook and twitter like applications meant to be deployed behind firewall. But most organisations , I could safely presume have not really got the point yet and they are still waiting for a business case.......