Will Continental get my business again?

I dont know how many of you have read the news that former President of India, Abul Kalam was frisked at Delhi airport waiting to board a Continental flight to New York. I did, followed with interest the various blogs, news items about uproar in the assembly, insinuations that Hillary Clinton should be subject to a similar tit for tat (no puns here :)), reactions if a similar incident had happened in China blah blah blah.

A few points immediately come to mind - Indian's recent preoccupation with China, a new found sense of assertive outrage (I havent seen too much of this earlier) and the sheer number folks writing in the comments column expressing their displeasure in no uncertain terms.

The Chinese connection is the easiest to understand - I think the rise of the internet and thus freely available information has made Indians realise just how far behind we are to the Chinese in terms of Global influence and development - I think this feeling of jealousy is good - good for us to wish and work towards a better standard of living, development and better support for folks like us living elsewhere but still carrying the Indian passport with demonstrated pride.

However, the other side of the coin - the spirit of Indian freedom allows folks like me and everyone else to express themselves without any fear - I wonder if ordinary Chinese would have the same freedom of expression. I dont know but what I read in the papers suggests - perhaps not. Lets ensure India retains that precious and irreplaceable freedom of expression.

Now back to the news item - I actually have 2 questions here - One - would we all perceive the same sense of outrage if say a Laloo Yadav was frisked? I say perhaps not :). Two, would Continental ever get my business again? That's easy - NO. Not because of anything else - but simply for the sheer sense bullheadedness of their staff - I think doing something like this in an emotionally charged country like India was downright stupid - wonder what the person who controlled the World's fifth largest Nuclear Button could have carried in his shoe is beyond my comprehension.

I cant trust the airline which couldnt figure that one out with my life now, can I?

A Whale of a time...

June & July are the months of the annual whale migration from the cold Antarctic where they eat to the warm tropics where they breed. Sydney is on their journey and thus we are privileged to witness one of Nature's greatest sights - whales swimming past us, with their jets of water released from their version of a blowhole. Interesting - these huge creatures - some of them weighing well over 40 Tons dont eat for months on end - the females eat only after they have given birth.

Yesterday, we took one of the numerous whale watching cruises from Darling Harbor to see the magnificent spectacle. The ship went down the Parramatta river under the Harbour Bridge and past the iconic Opera House in glorious sunshine, with strong cold winds blowing past us. The Heads - the Heads is the name given to the area where the river meets the Pacific - were rough and for us sitting right at the foredeck , it felt more like a ride on one of the rollercosters at Luna park (a few miles to our left) than the ocean. The sea remained rough all throughout the ride and it was about an hour from the Heads that we first came to the Whale migration spectacle.

It all began innocuously enough, the volunteer sitting next to me pointed to something that looked suspiciously like a larger surf on the ocean surface about 600 meters away - it took us a few more minutes to realise that we were indeed in sight of the largest creature the world has ever seen. Closer up, at about 150 meters away, the blowhole was jetting water up at least 10 meters - often the sheer amount of space on the ocean dulls the sense of time, distance and size - however there was no mistaking the sight of the creature that came up a couple of seconds after we saw the water jetting up the blowhole. It must have been at least 50 feet long, dark grey in color with spots underneath its jaws and black fins spearing through the rough sea. The mind was numbed for a moment with the spectacle before the scramble began to get the cameras and the recorders out and in action. Thrilling stuff.

After about an hour of witnessing these marvelous creatures and after the volunteer mentioned that he can spend all his life watching them (& I agree with him), we began the journey back to Sydney. We went into the cockpit for some coffee and I saw a very pertinent sign there - 'We love Japanese but hate whale killing'. As my wife and I sat drinking coffee in companionable silence, we both spoke almost simultaneously - how can someone have the heart to kill them? They are so beautiful...

Hard to imagine - if you dont believe me, please take a look and let me know if there are grander sights on earth.

Dada makes news again...

http://www.itimes.com/public_main_community.php?gid=16998&ref=toi_sg

I dont know how many of you have read the news - Sourav Ganguly the enfant terrible of Indian cricket is threatening to get into active administration. Saurav was always someone who fascinated me - brash, outspoken, giften (both with the bat and with a golden arm), mercurial and with a mind of his own - almost everything one doesnt credit a Bengali with. From a player accused of being too lazy to carry his own baggage in his first tour, he emerged - first as a supremely giften No 3 bat in England where Indian hearts immediately realised was the emergence of the next great batting line up (Dravid made his debut the same match with a skillful 90 odd) and then as a Captain - with startling clarity of thought, ruthless in his execution, skillful in team management and lucid in his commentary. A new chapter in Indian cricket history was waiting to be written - & what a chapter it was.

Saurav's new innings seems very interesting - we have an obviously intelligent man, highly experienced and someone who always got the best out of his team - entering cricket administration. I hope his innings at the administrative helm becomes as successful as the one as a player.

He has the best credentials anyway...

There are News and there are NEWS again

I dont know how many read this remarkable news - http://news.smh.com.au/breaking-news-world/south-korean-president-donates-millions-20090706-da9v.html

Great news as these are normally sent to the back pages - almost as if good news are irrelevant to the Press folks who want to remain almost totally in the grips of the sleaze and squalid. Human nature is one which is naturally benevolent, visionary and farsighted - the environment, pressure, competition and circumstances dulls the edges and makes it more malevolent than it actually is. I think the Press has an essential role to play in popularizing the good side of us - decreasing its almost obsessive interest in crime, politics and sensationalism. If you look at the front pages of any newspaper, the headline news are almost always sensational and negative...why cant we have such a news as the headline? Why cant the newspapers be filled with positive news and banish the negative ones to the back pages? I wonder - but then I am not a newspaper man...

Perhaps, we can revert back to the tradition of India's national newspaper - The Hindu which was the only newspaper not to carry news of Gandhiji's assassination on its front pages - because it then used to solely publish advertisements on its front page

Interesting, indeed.

Tennis and Tantrums

The last few days has been a study in contrast for me - waiting is never a good time if you are like me - impatient, full of beans...the one good point of waiting was the opportunity afforded to work less and watch TV more. Thus Wimbledon '09 and some of the finest matches ever played happened for the right time for me and I was priveleged to watch some of the matches. A few of them stood out - I like the way Federer took apart the giant Croat Ivo Karlovic, the semi finals with Haas was one played in the best possible sporting spirit (are the Aussies and the Poms watching and listening in the Ashes build-up?), the finals was one of the best I have ever seen.

I must admit I have never stepped into a Tennis Court (a Lawn Tennis Court - I do play a bit of Table tennis - better than a bit I daresay) and thus am blissfully unaware of the technical aspects of the game, the speed, skill and ball-sense that is needed to be a Tennis player. However, I have been fairly consistent in watching Tennis - especially the ones beamed live from the hallowed grounds at Wimbledon all the way to an India just waking up to the possibility of live matches available of Indian Television. My mind goes back to the matches on '84 which is probably my first recollection of watching tennis and I was instantly smitten by the brash, bold and bountifully talented McEnroe - his exhibition of tennis and tantrums as an art in 1984 I think has never been bettered and add his marvellously emotive & expressive face, you have all the makings of an anti-hero. I do recollect the boom boom wunderkid Becker in '85 and his titanic struggles with Andres Jarryd and Kevic Curran - dont recollect too much of the matches for the next few years...till 1989 when I recollect the match between Edberg and Becker then in the midst of their great grass-court rivalry.

Anyway enough of digressing - lets get back to the matches on display over the weekend - both the finals were great spectator marvels - the ladies final was remarkable for the power, accuracy and poise of Serena who was quite clearly the better of the two sisters and the mens' finals was remarkable as a slugfest between two of the three most talented players on the planet. The interesting fact was that Federer outdid Roddick in the aces columns - something few of us could comprehend - just goes to demonstrate the accuracy and precision of the Swiss maestro that makes up for the obvious lack of brute power. While the groundstrokes were a treat to watch and the serving par excellence - what I missed most was the loss of volleying as a key attacking component of an all round game. One misses the accuracy of an Edberg, the athleticism of a Becker and an inventiveness of an McEnroe at the net - games now a days lack that bit of spectacle when the volley is little used.

Well, I cant quibble after being priveleged to watch one of the longest and best matches played on Center Court at Wimbledon now, can I?

Letting Sleeping Dogs lie...

Indian politicians suffer from one incurable disease - not being able to let sleeping dogs lie.

Look at the Lieberhan commission and its reporting - it took the commission millions of dollars and 17 years to table a report which was clear as daylight the minute one sees the Television footage - what took them 17 years to come to a conclusion which is not going to make a difference to our country one way or other? How is the report going to benefit the country? What is the positive side of this report - I can think of quite a few negative ones though & we are already seeing a few being played out? When will we grow up - in intelligence, stature, vision, patriotism as opposed to jingoism - to focus on areas that we really need to improve and create a difference? The more I think about India, I feel more sad - sheer waste of some of the finest talents the world has ever seen. At the same time, when the same group of politicians put their mind into something, they can make a difference - look at Modi in Gujarat and Nitish in Bihar - two ends of the development spectrum - one starting and building from a positive base and the other starting from somewhere close to the rock bottom in the development landscape. What they have achieved goes beyond GDP and numbers - they have inculcated pride in their states and the people living in them - no longer will Bihari be a metaphor for the under-developed parts of India and hopefully no longer will Gujarat immediately invoke Godhra war cries from each of the religious camps

Can we have more enlightened, educated, enterprising politicians please with the necessary expertise to WANT to make a positive difference? This is where India has been singularly unlucky - we really never had a group of folks at the top wanting to make a positive difference or not getting the necessary freedom of thought and action for doing so.

Hope we have a day soon when 80+% politicans are in the job because they want to see a better India - not just a better themselves & their narrow communities. Till such time, I can only consider the progress we make as being made despite the system & not because of the availability of an enabling environment.

Indian Airports...

I commenced writing this on a notepad waiting interminably in the waiting hall in Calcutta airport for a flight back to Sydney via Bangkok and it stuck me - I was probably in the most ancient looking airport I have been for a very long time.

I travel often to India - a lot less often than when GFC was an unknown 3 letter word - and occasionally travel through Calcutta where my parents live. I rarely have time to kill at the airport but this time I checked in earlier than usual - blame the unusually less traffic - but it stuck me suddenly - Where did Calcutta get left behind in the rush to modernity? As I began typing this on a notepad (as evidently the wifi wasnt working - does it ever work??? Can someone comment on this?), I realised - not just Calcutta but all the Indian airports have been left behind, way way behind. Forget the snazzy new terminal at Changi or the gigantic terminals (& half empty most of the time) at KL, even smaller airports across APAC look great, have good service, good lounges, working wifi and decent shopping and food. In Calcutta, all we had for food was a coffee shop and a cold drink vendor who didnt even stock Thums Up which my daughter and I both adore. Nothing to eat. It was a sad state to see the city which was called Paris of the east fade away so suddenly and absolutely - and one cant even blame a war or natural disaster on this.

Makes one feel very sad indeed. Where does all the tax money that folks like me pay (despite living and working in Sydney) go? The government claims to make progress - where??? Someone will claim that we need to spend on poverty alleviation - but there can be no development until the base infrastructure is in place - that has to commence with world class airports and services at the primary entry points.

Is someone listening?

The memory is 26 years young...

They say memories fade with time, become sepia tinted and the edges get blurred, the details arent quite there...there is one memory though of a 13-14 year old, energetic kid that refuses to do any of those - the memory of India winning the 1983 cricket world cup. My childhood days in Calcutta were full of intellectual discussions - whether Zico should or should not have taken THAT penalty shot, whether Paolo Rossi was indeed the great striker he came to be in the '82 Football world cup or whether a Maradona can ever become the all round great Pele was...however all the sport centric discussions centered around football, often about the local matches but occasionally on the global scale - typically a few months prior to the world cup. All this changed through one thrilling week in June when India went through to the last four and then the finals of the Cricket world cup. I was always more than a decent cricket player and played for my class and club as a studious opening batsman till I was about 12 years old, and a considerably better cricketer than a footballer but we all - as Calcuttans - loved our soccer. Thus even though I was known to be a good cricketer, I never got the recognition that the good football players in my class got - I was merely an appendage but the footballers were the REAL thing. Those couple of weeks changed the way we kids lived, breathed and most importantly played -suddenly I was more popular than the footballers and classmates and neighbouring kids suddenly wanted to be seen with me and discuss THAT square drive the ebullient Srikanth (he had a single K in his name those days) played to a rampaging Roberts and whether Viswanath would have hit the same shot behind square as opposed to in front of...it was a game changer not just for India, but also for one of its insignificant kids in a Calcutta moffussil. The best memories for me are of the match itself. My uncle took a day off from work, my grandfather - then recently retired said he retired at the right time & for a change didn't ask me to study for my Class 9 exams, my grandmother was wide eyed with wonder that her country was in the FINALS of the world cup - a festive atmosphere reigned for the hours leading the finals. We had our usual share of neighbours, friends, relatives - all crammed into the 12 feet by 12 feet living room with us small kids being banished to squat right in front of the television while the elders occupied the pride of places on the sofas and the chairs. However, all discomfort - perceived and otherwise - disappeared the moment the match started. For me and my memories, there are 3 incidents that stand out - the square drive from Srikant that hit the boundary boards at point even before the fielder at point completed twisting around, the inswinger that got rid of Greenidge and the easy Lloyd catch by Kapil at mid off off a swinging Binny delivery. I am not mentioning about the the defining moment here - that catch of Viv - not because of sepia tints but because I only saw the replay - I was answering nature's call then the live images were beamed and I only heard the eruption of noise from the toilet which told me a key wicket had fallen. Time has passed and while India has moved on to become the most serious force in commercial cricket, it still hasn't won the world cup, it still hasn't beaten Australia in Australia and SA in SA - till those happen, I lie content with the non-sepia tinted memories as a 14 year old - & for a change, recollect the win over Pak in Pak five years back...more on that one in another post perhaps.

A New Paradigm - Blue Ocean Strategy

Blue Ocean Strategy is a thought provoking articulation of a strategy in creating value-innovation - essentially creating new markets rather than competing in existing markets - Red Oceans. This is a very interesting approach by Professors Chan Kim and Rene Maugorgne of INSEAD


Essentially the business world consists of 2 parts - the highly competitve, price/quality differentiated existing markets (called the Red Ocean as a metaphor for intense competitive landscape) and the newer, emerging, innovation defined markets ('Blue Oceans') which are often extensions of existing Red oceans but with some unique identifiers that create value.

The strategy talks about creating unique value and uses a very user-friendly tool based approach to develop the RERC (Reduce, Eliminate, Raise, Create) Grid to commnence developing the strategy. Additionally several strategies used by companies in varied fields from Culture and Entertainment (Circue du Soleil) to FMCG (Yellowtail) are described and elucidated using very easy to comprehend graphs and tables. All in all, a very interesting and perceptive look at creating differentiation in a crowded marketplace.

At HCL, the Blue Ocean strategy is one of the three key cornerstones for creating a value system - the others being the Employee First and Integrated Service Delivery. At HCL, we are constantly encouraged to think out of the box and use the available tools and frameworks in BO to draft business ideas, templates and define ideas for exponential revenue/profit generation - the key to the business strategy is 'Exponential' & not linear value/revenue/P&L creation

I was one of the speakers privileged to be invited by one of the leading Rotary Clubs in Chennai (formerly Madras) in India to address a very august group on Blue Ocean strategy in a fund raiser event. I thought the event was very well organized, had excellent speakers (despite yours' truly), was very well attended and for me, it was a great experience to share the dias with some of the best known folks in indian academia and industry.

Transformation at HCL – an interesting case study

Recently I was asked to speak at the FST (http://www.fst.net.au/agenda.aspx?confid=2) on transformation and what we did at HCL which elicited attention from some of the leading thinkers, analysts and journalists. I thought it may be a good idea to invite some thought process on what we did, why we attempted to do what we did and where we are in regards to the transformation agenda. Also we may discuss on some of the key learnings we have had as a result of this exercise, some areas where we did better than the rest. All in all I thought it was an interesting session and one of my proudest moments came when I was asked for a copy of the presentation made and asked to present by the CTO of a leading Bank in APAC to his team in Melbourne & Sydney. Not a bad day’s work I would imagine.

More soon to come...

Conversational Marketing

Conversational Marketing is a marketing communications strategy and philosophy that helps companies drive revenue through their CRM strategies. By incorporating a listening based marketing communications strategy such as Conversational Marketing, companies can have more productive communications, be more efficient with their revenue generation and better differentiate themselves from their competitors

Soon to come...

The 10 Best of Shanker-Jaikishen

Let me try and list down the 10 best songs which this dynamic duo created – this is a list of personal favorites and in no way reflect anything other than individual interest. Songs in Hindi movies are irrevocably linked to their picturization and I try and explain the rationale behind each of my picks – with the caveat – this is intensely personal.

1. Awara Hoon: Awara (1951) – the song that began it all, my blog, rekindling of my passion for SJ so tragically lost in the pressure of work, immense re-hear value, lovely touching lyrics, a smooth song to sing in all parties – almost everyone knows the tune and the music is lilting and foot-tapping. The song was photographed lovingly in electric black and white, the mischief in Raj Kapoor’s eyes was inimitable, the motion of the chain-watch hypnotic and was in perfect cadence with the SJ background score. Mukesh as usual, excelled when singing for Raj, if he was the body in ‘Mera Joota hai Japani’, he was the soul in this song. Truly timeless.
2. Pyar Hua Ikrar Hua: Shree 420 (1955) My all time favorite RK song – I just love that interlude music especially and THAT scene is truly amazing – the scene where Nargis and Raj are huddled under the black umbrella in a fair shower – Nargis points out to the three Kapoor kids and lips – hum na rahenge tum na rahenge phir bhi rahengi nishaniyan. I dare you to think of a more poetic romantic situation. Evocative.
3. Nanhe Munhe Bachhe Teri: Boot Polish (1953) - This song made a convert of my niece – a young 6 year old kid & who only loved the new age music...she stood absolutely still when she heard this for the first time and then by the second stanza began humming it. Music – as they say, is divine and the look in her face was indeed divine & reflected pure bliss. I can still visualize the precocious Baby Naaz and the vibrant Master Rattan dancing to this amazing Shanker-Jaikishen beat. David was on hand to lip sync to the magnificent Rafi. Add to the heady mix - consider that Boot Polish was meant to be a songless film and the Aah disaster forced Raj Kapoor to do a rethink & create songs and song situations within a few weeks. Invigorating Stuff.
4. Hai Sabse Madhur Woh Geet: (Patita, 1952) - Dev Anand had this dreamy look throughout the movie and perhaps never more than in this song. This is a song which makes you wonder why there weren’t a lot more of Dev-SJ combination in the early fifties. In fact, the next Dev-SJ combination after Patitia came as late as 1959 - Love Marriage which had the famous dig at O P Nayyar (Tin Kanister Peet Peet Kar). The Talat numbers in Patita picturised on Agha – Andhe Jahan Ke & Tujhe Apne Paas Bulati Hai & the Lata solos picturised on Usha Kiron – Mitti Se Khelte Ho & Kisine Apna Banake, the Lata-Hemant lullaby picturised on Dev and Usha – Yaad Kiya Dile Ne all were amazing and deserved a place in any other list best songs but the song I chose from Patita is for that rare combination of wistfulness, passion and desperation, it evokes a sense of nostalgia and ‘what could have been but for…’. Trust SJ to bring out the right mood and Talat to express it so evocatively. The icing was the debonair Dev looking handsome, lost and forlorn…pictures that stay with you a long time after the movie is over. Timeless...
5. Main Piya Teri: (Basant Bahar, 1955) – This movie is stuff musical folklore are made of. Anil Biswas, the great music director was initially chosen for this musical magnum opus but the distributors insisted on SJ – whereupon Anil made his displeasure very clear and reportedly passed some derogatory remarks on SJ's lack of Classical Expertise. Shanker picked up the gauntlet and along with Jaikishen proceeded to give some of the finest classical based songs ever created. Each of the songs was a gem – the Manna Dey classic in Pilu - Sur Na saje Kya Gaon Re and his ode in Miya Ki Malhar (Bhay Bhanjana), the Manna-Bhimsen number – Ketaki Gulab Juhi in Basant Bahar, the Rafi classics Badi Der Bhai ( Pilu) & Duniya Ne Bhaaye (Gurjari Todi or Lalit – I am not sure, comments welcome), the Lata-Manna sweet duet in SJ’s favored Bhairavi – Main Piya teri…which is probably why I pick Main Piya teri amongst the galaxy of shining stars in Basant Bahar as my personal favorite. Listen to it and let me know if you feel as I do – SJ and Bhairavi were truly made for each other. Also, the old story of Shanker telling Pannalal Ghosh on what, how and when to plan his famed flute is the stuff legends are made of & what are they if SJ aren’t one! The best amongst the very best. Truly Classical...
6. Ae Mere Dil Kahin Aur Chal (Sad/Happy, Daag, 1952) – Amazing song, Talat at his very best. Somehow Talat was never as popular as a Rafi or a Mukesh amongst the post ‘1970 listeners which is somewhat of a tragedy. I thought he has an amazing voice admirably suited to the soft and sad songs he often sang principally for a less Debonair Dev in the early fifties and a more composed Dilip around the same time with so much feeling. The two sides of the Daag classic is an example to boot – Dilip as the drunken hero in the sad version made the audience look up to the heavens with him as he cried ‘Chup raha beraham aasman’ and made the same audience tap the feet in energy as the strains of the happier version floated like the season’s first snow flakes on a cold Boston morning. SJ at it – the sad and soft allied to the enterprising and energetic. Super Stuff.
7. Ae Bhai Zara Dekh ke chalo (Mera Naam Joker, 1971) - For sheer joi de vivre this is hard to beat. Mera Naam Joker was a disaster at the Box Office prompting Raj Kapoor to banish himself from the screen and SJ from the Music Studio but the movie was a musical marvel - one of the finest all round musicals of all times. The pathos laden strains of Jaane Kahan Gaye wo din contrasted perfectly with the playful Asha classic Paan Khaiyo saiyaan hamaro. The philosophical Jeena Yahan Marna yahan found a telling riposte in the sparkling Kehta hai joker. But for me the finest was the Manna contribution to Mera Naam Joker - the song fluctuated constantly, with the fast and the slow strains and the meaningful lyrics ending quite magnificiently with Veeran duniya ka basera hai. It got Manna a well deserved Filmfare best singer award. Philosophical stuff with a rythm about it.

8. Ye shaam ki tanhaiyan (Aah, 1953) - Again I am picking a song from what was a box office disaster prompting Raj Kapoor to make a musical Boot Polish instead of what was supposed to be a bold attempt at making a songless wonder. Hear this and leave a comment - has Lata ever sounded better? Aah had amazing numbers, the Mukesh Lata duet (Jaane Na Nazar), the Lata solo picturised on the other sister (Sunte the naam hum) and the Mukesh lullaby (Chhoti si zindagani) come to mind immediately but this Lata solo was - for me - the pick of the jewels in the Aah crown. Sheer Melody from the melody queen.

9. Baharon Phool Barsao (Suraj, 1966) - The pick of the prolific Rafi-SJ-Rajendra Kumar collaboration for me. Suraj was a great musical despite Shanker's fascination with Sharda in Titli Udi. Baharon Phool Barsao had it all - excellent initial music breaking into a crescendo, good lyrics, Rafi's romantic voice, the amazing use of orchestra and the clever use of the variation in Rafi's voice. My friends may wonder why I havent picked some of the better known Rafi-SJ combinations but for me melody is key, rythm and beat come later. For sheer romance and melody, this ditty is hard to ignore amongst the ten best. The most romantic voice singing one of the most romantic numbers. Beautiful.

10. Jiya Bekarar Hai (Barsaat 1949): The song that started a rage - SJ's initiation into Bollywood as a musical entity. Legent has it that the team sat on the footpath outside the recording studio wondering about their future - little knowing they had created history - the best, most versatile and the most popular music directors of all time were born. Barsaat had several first, Lata singing all the songs for both the heroines, the use of significant orchestra, a single song sung by two different people in tow different locations to different sentiments (the rumbustious Mukesh and the doleful Lata in Patli Kamar Hai) but for me Jiya Bekarar Hai is the key song in the SJ repertoire. If this song isnt as good as it was, SJ would not have become what they did - the best of all times.

You may realize I have been partial to the early fifties – I think the duo gave their best music when they were together – in the true sense of the word – and a lot less effective or evocative when a lot more than the hyphen separated them.

Consultative Elicitation

Introduction:

I have been a consultant for a significant portion of my working career working mainly in Financial Services (Capital Markets principally), Retail, telecom as Vertical Domains, CRM and Offshore Development Process/Methodology Definition as Horizontal competencies in geographies ranging from North & South America to Continental Europe, Japan and APAC. This experience has stood me in good stead to understand the nuances of what to expect from customers who know something is not quite right but probably don’t know exactly what or how to influence the outcome positively. Consulting has been a much maligned term especially in India and some developing markets but one must know that before one can commence writing code or testing it – one needs to ensure the requirements are elicited and documented to the best extent possible. As one moves from effort based pricing to outcome based pricing, this is becoming critical to define ROC and ROI.

Consultants would always tell you that the customer never knows what they want to do. However, they almost always know what they want at the end of it all – the problem is that this ‘to be state’ is very often information driven and not data driven, its emotion driven and not facts driven and most times is individual driven and not organizational driven. Unfortunately few of us are experts in interviewing techniques (‘Elicitation’) and get customers to talk candidly about their issues, perceptions, opinions, tasks and bring them I into the context of defining necessities, needs, wants and desires. Sherlock Holmes once commented the issue with simple cases is the largesse in terms of clues and the good detective knows which is important and which are not – it’s often similar in Elicitation. Most consultative Elicitation commences from a position of extreme information overload but less reliable actionable data. So the first step is often to determine which the data elements are that need further elicitation and which need to be kept in abeyance. Let’s now understand how to approach such cases of Consultative Elicitation.

Research: I always tell people that the key to a good consulting effort is the background research one does on the prospect and areas of initially isolated concerns. The research needs to be comprehensive ranging from Market facing data (Revenue, Growth %, areas of growth, areas of growth vis-à-vis market, profitability, profitability around different business areas, strategic direction, cost of support, cost of operations etc), Internal Strategic Initiatives – Internal research data, HR management and initiatives, Press Releases etc. This would give a very good idea where the issues and concerns could lie thus focusing the attention much better during the next phases. This ensures the initial discussions and interviews become validation statements rather than Q&A sessions cutting out valuable time and increasing management attention. Articulating a research objective sets the stage for a successful interview.
Developing the Base Questionnaire - The right questions are those that help us get beneath the surface and understand the customer’s world, work, and concerns and validate assumptions. These would be more in terms of validating some of the data and associated conclusions one could have drawn from extensive research. This would result in either focusing more on the areas of concern earlier identified or going back to the drawing board for further focused research. So initially, it’s recommended that one speaks about overall objectives, options, directions and broad level concerns.
Developing a Good Questioning technique: It’s a good practice to clearly enunciate and understand the overall objectives internally before meeting the customer & commence asking questions. What do you hope to accomplish by interviewing the customer? Do you want to explore broad options or understand a specific business processes? A wandering, unfocused interaction will yield paltry results and frustrate the customer. Once you’ve defined the broad objective, brainstorm a list of all the questions, suggestions etc related to the topic. It’s a good practice to organize the questions in a set of matrices – on the horizontal plane from general to specific and familiar to unfamiliar & in the vertical plane around opinions, recommendations, perceptions, risks & emotional issues (including HR issues). The process of preparing questions helps to identify key topic areas to cover. Following a set list of questions isn’t the point: successful interviewers invest time in designing and testing questions—but then use them as a guide, not a script. As you prepare for an interview, consider different types of questions. Each type will serve a purpose and elicit a different response:
1. Context-Free Questions
2. Meta Questions
3. Open Ended Questions
4. Closed Loop Questions
5. Leading and Show Me Questions
6. Past-Present-Future Questions
Develop In-Depth Questionnaire Patterns: The key to elicitation is developing the detailed requirements is analyzing data obtained from Research, User Interviews, Manager Interviews etc and reverting with a series of if-else, what-if and but-if logic loops. These would enable the interviewer to focus on key core issues while ensuring the tangential ones and symptoms of problems get documented as such. You could think the data is adequate when all the data from Research, User Group Interviews, Other Interviews, and focus interviews is able to identify a set of concerns / issues (process, technology or people) which would explain at least 90% of the issues and concerns expressed.
Data Analysis Template: FTSC: One good practice which I have come across is to analyze all data on the basis of the FTSC dispersal – Foundation, Tactical, Strategic and Continuum. Basically it means that all issues or data could either be related to Foundation (base issues, typically operational and can be rectified by minor operational modifications) Tactical (short term, needs some operational and process tweaking), Strategic (medium term, market facing issues which need broader and senior management), Continuum (Broad Operational areas - fairly operationally efficient but need constant monitoring and efficiency checks).
Conclusion Template: The most critical aspect is the presentation of the issues, suggestions and recommendations. Always remember the client is almost always aware of the issues – the symptoms & sometimes the underlying causes – and tailor analysis to
1. Symptoms observed
2. Possible Causes
3. Probable Causes after data analysis
4. Criticality of causes
5. Recommendations – Process, Technology, Others
6. Suggestions – Process, Technology, Others
Some Pointers: Before you rush off to try out your interviewing skills, practice. Start with a colleague, and then try your interview with an internal customer proxy or subject-matter expert. Its always a good practice to work in pairs with the members taking turns to ask questions and BOTH taking notes. Its better to limit the questioning sessions to 4-5 hours in a working day and keep at least 30 minutes between sessions for note-sharing and data sharing. Avoid using this time to draw conclusions but use this solely to flesh all details and document them effectively. A quick 30 minute discussions with all interviewers at the end of the day – typically informal – is a good idea to get some first impressions about the people, who seemed very open and others who probably were not. At the end, just remember consulting is not rocket science – all it needs is a thinking mind, perception, an eye for detail and documentation ability. Its good to have the requisite domain knowledge but often I have seen its needed as a team – not with every individual.

An Evening in Sydney

The most arresting aspect of Sydney – it’s a lovely city and I have nothing against it or the beautiful people who inhabit it - is the fact that all shops and commercials establishments close at 5 PM. Yes, you read it right, 5 PM every day including weekends (actually they close earlier then) except Thursdays. I am not a great one for shopping or doing the tourist rounds – in fact, the only occasions when I went across the street to view the Eiffel Tower when I lived in Paris was those infrequent occasions when friends & relatives used to drop in and insist I show them the Eiffel Tower…actually, but my idea of a holiday is be in the midst of 10 million other human beings in Calcutta reading a good book and sipping the local hot brew in the day time munching on samosas or kachauris or drinking something a bit bitter later in the day… anyway more about my likes and dislikes later but about Sydney first before I digress once again.

This aberration in global terms at least of establishment owners finding places to drink rather than open one themelves leads to some peculiar problems for folks like us who have to earn an honest living by working till pretty late in the evening. When I come out at about 10 pm in the evening which is late by Sydney standards, I very often am the only person in the North Sydney suburb where I live and work when I am around. The biggest tragedy is that the bars close up at 10 (PM, not AM) leaving people like me search and scrounge around for places to get an honest bitter. Tough times folks.

More to come on Sydney…Interesting experience its been so far...

Transforming Contact Centers Using Knowledge Centered Support

Introduction:
I was driving a team responsible for building one of the leading Knowledge Management tools in the world while driving the CRM practice for my orgainzation. Without a lot of background knowledge on CRM & especially Knowledge Management or Contact Center Applications - given my background in software engineering for Financial Services - I was swamped with the data and my corresponding lack of knowledge initially... but the topic was so interesting and topical that I was intrigued. Intrigued enough to spend the past 2 1/2 years - incidentally loving it -working on several contact center consulting projects & CRM implementations especially in the Telecom and Financial Services Industry. Amazing experience and this article is a compilation of some of my thoughts around Contact Centers and Knowledge Management over the past 2 odd years...

Base Camp:
Over 92 percent of U.S. consumers form their image of a company based on their experience using a call center. However, Call Center is regarded as one of the major 'cost elements' for accounting purposes. The tool or process that is most essential for customer attrition is regarded as by many as a 'cost element'. Funny right?

The Customer Service and Support (CSS) centers of today need to transcend much beyond handling customer requests with minimal cost. CSS has to be enabled to make the transition from being regarded as a ‘necessary cost center’ to an ‘indispensable profit center’. The key to this, I argue are Knowledge Management, Channel Integration, Effective HR Training, Integration with Back end systems and a Culture of Continuous Customer Centricity.

Why is KM so important?
Lets understand why KM lays such a crucial role in a contact center or a CSS channel:

1. Minimize time to resolution – the key to customer satisfaction during a call or a transaction is not just the time taken to identify the customer (which is pretty straight forward given the investments most companies have made in stand alone CRM & IVRS systems) but the time and efficiency by which the customer issue or query is resolved to complete satisfaction. This requires a high degree of sophistication in terms of Knowledge Management, Integration etc.
2. Knowledge Driven Service Model – A good KM model allows companies to capture unstructured data, information and structured data and make it available to all employees and customers, as well as outsourced contact center agents/companies. This presents a model for effective updation and modification of Knowledge Management & ensuring the knowledge is captured and processed into identifiable and re-usable chunks of data
3. Customer Loyalty: Effective KM sharply reduces the need for escalation or change in agent due to specialization within a contact center. There is a direct cost benefit of reduced escalation & additionally, a more strategic impact on customer satisfaction. We all – as customers, recollect positive experiences with pleasure which makes customer retention easier and good press due to increased CSAT.
4. Customer Data: Market research practitioners will agree that Customer feedback is extremely difficult to gather, analyze, authenticate and draw actionable items from with a large degree of certainty. With effective KM in Contact Centers there is an easier way out than asking Customers to fill in long questionnaire or answer interminable questions from an often bored and dispassionate interviewer. Knowledge-powered Web sites and other channels enable the business to capture the customer's dialogue with the organization, which can be easily analyzed and action items derived for customer insight and increased wallet share.
5. Pursuit of constant improvement: A structured KM program allied to effective tools breeds a team of people constantly trying to improve available knowledge. This is especially true for companies with a large and diversified customer base and correspondingly large Channel Management office.

A step by Step Primer to Implement a KM Solution for a CSS:
About to come...

My Present Area of non-professional interest...

Presently, my interest & research centers around Shanker-Jaikishen - a duo of music directors who revolutionized music in Hindi Films with some breathtaking compositions in the early fifties and remained the supreme duo till the untimely death of Jaikishen in 1971...This interest got re-kindled when I was on a recent visit to the Bay Area. While I was in a cab proceeding from the SFO Airport to Menlo Park, my phone rang - the tune was set to a song from a movie called Awara released in 1951. The cab driver - a white caucasian - immediately began humming the tune under his breath. Once he realised I had completed my call, he turned to me and asked if I was from India -& whether I know Raj Kapoor - the actor on whom this song was picturised - its incredible to imagine this scene - a white Russian emigrated to US 30 years back and still remembers a tune he had briefly heard when he would have been 10 or 12 years old...amazing...that set me thinking - what kind of geniuses could have created a tune that rests in the sub-conscious mind for 55 years and remains fresh?

Operational Risk

Introduction:
Operational Risk is an area of emerging interest and was a lot more nascent when I got into it and the sheer paucity of information - reliable, simple and accurate - prompted me to write this artice along with a good friend & cousin (in that order) Raghu. This was published in several magazines a few years back and I hope proved to be somewhat useful for practioners in Financial Risk.

Summary: Barings, Daiwa, Natwest, Sumitomo suffered catastrophic losses in the area of operational risk, causing regulators and banks world over to refocus on the topic.
As businesses become more and more competitive, as the pace of change inside and outside the organization continues to increase exponentially, as the market place becomes more and more complex due to technological advancement and innovations, the management of operational change and the risks has become a critical success factor. Business operations will need to be as efficient as possible to deliver seamless service to the customer. Risk management structure and practices will need to mature to satisfy all stakeholders versus shareholders, employees, government, regulators and the society as a whole.
As the new millennium unfolds, the challenge for business leaders and decision-makers is to adopt an integrated approach to strategy, value proposition, customer service, capital management, finance, operations, risk management and corporate culture.
What is Operational Risk?
Operational risks are enterprise wide and inherent in any business. It is more pronounced in industries like nuclear power plants, chemical industries and as has been seen lately in the banking industry.
An acceptable and recognized definition for OR is yet to evolve. However, the description of OR ranges from narrow definition of covering operational breakdowns in processes to broad definitions which capture all risks that are not credit or market risks.
Historically, OR was associated with only operations and technology. The Financial Services Authority, (FSA), U.K., describes OR as the "risk of loss, resulting from inadequate or failed internal processes, people and systems, or from external events." Significant operational losses in recent years in the banking industry have highlighted that OR can arise from internal and external fraud, failure to comply with employments laws or meet workplace safety standards, policy breaches, compliance breaches, key personnel risks, damage to physical assets, business disruptions and system failures, transaction processing failures, information security breaches and the like. With increasing attention being paid to social, ethical and environmental issues, the scope of OR management has extended to monitoring and managing these risks as well.
The Basel Committee on banking supervision has recognized that managing OR is becoming an important feature of sound risk management practice in modern financial markets. The committee has noted that the most important types of operational risk involve breakdowns in internal controls and corporate governance. Such breakdowns can lead to financial losses through error, fraud or failure to perform within accepted time lines or cause the interests of the bank to be compromised in some other way, for example by its dealers, lending officers or other staff exceeding their authority or conducting business in an unethical or risky manner. Other aspects of operational risk include major failure of information technology systems or events such as major fires or other disasters.
Operational Risk - The Drivers
The banking industry is by far the most advanced than any other in attempting to manage the credit, market and operational risks in an integrated manner. Regulatory pressure has helped and goaded the banks to adopt a strategic approach to operational continuity and risk management. It is being realized that by managing risks on the operational side, banks can maximize returns through more efficient use of capital, thereby increasing shareholders' wealth.
Globalization, consolidation, outsourcing, nearshoring and offshoring, breaking of geographical barriers by use of new technology, consolidation, growth of e-commerce, competition etc. have significantly increased the profit-making opportunities of the banking industry. At the same time, increased regulatory focus, increased awareness of "uninsurable" risks, greater focus on corporate governance areas, renewed emphasis on corporate accountability and director's liability, public expectations etc. have become the key drivers compelling organizations to focus on management of operational risks. The industry's risk-control structure has more often than not, not kept pace with the hectic changes taking place at the operational level functionality of the bank.
The Basel II Norms
The Basel committee, saying that operational risk has become too important to ignore, decided that banks must take a disciplined and proactive approach to managing it. Though the final guidelines are still not very clearly defined, it is required for banks to apply an explicit capital charge to cover losses arising from operational risks. Ultimately, this would require two measurement models:
Measuring operational risk and
Measuring to determine how much capital must be allocated.
These models are currently in their formative stages with multiple ideas and proposals being discussed. In the meantime, many "best practices" banks have created reserves for operational risk losses by substituting non-interest expense for the data that the models would otherwise provide. A few banks have made a fair degree of progress in developing more advanced techniques for allocating capital with regard to operational risk. To determine their capital allocation, they simply use a percentage of non-interest expense. These banks have allocated 8 percent of non-interest expense to sometimes as much as 20 percent. If the top 100 banks - which have a combined $500 billion of non-interest expense - set aside 30 percent, the allocation would total $150 billion. As with buying insurance, the banks would have to take an annual charge - using current interest rates of about 5 percent - of $7 billion to $8 billion to buy access to this reserve.
On a microeconomic level, a commercial bank with say $1.0 billion of non-interest expense would have to take an annual charge of about $40 million to finance a $250 million of allocation by similar calculations. Thus this would severely limit the bank's risk taking and consequent profit making abilities. In absence of good models or best-of-breed operational risk management scenarios, banks could rely on this percentage calculation of averaged historical data or another data substitute to establish the required capital cushion. The illogical aspect of this plan is that, regardless of operational risk performance, all banks would be treated alike, and better performers would be penalized as they would have access to correct and accurate data increasing the need for minimum capital allocation calculated on standard derivative functions.
On the other hand, banks that can define, design, develop and follow best practices models to accurately measure their operational risk can allocate just enough capital to cover their exposure by using the newer and more accurate derivative functions. As a result, banks that manage their risk efficiently, measure it effectively, and allocate capital effectively would be rewarded with a smaller regulatory burden and more capital to support innovation and expansion. At the same time, their customers would be protected not by unnecessary amounts of external insurance but by solid operational risk management.
More importantly, true competitive advantages arise from developing an organizational culture that proactively manages day-to-day risk, identifies new risks progressively, shares best practices in the organization and beyond and systematically tracks risk exposures. Building the right culture for that begins with instituting a disciplined approach to operational risk management, starting with the board and filtering down through every level and business unit and across every major process in the organization using a software framework customized to peculiar needs for each bank and country of operation. Once the infrastructure is in place, banks must learn to assess the quality of their risk risk-management programs continuously and assign monetary values to the risks they confront, understand the same and take effective measures to mitigate the same. This is the starting point for building a model that banks can use instead of the standard percentage rate that regulators will probably assign across the industry making the better banks enjoy less leverage.
Measuring Operational Risk
Operational risk is more difficult to measure than market or credit risk due to the non-availability of objective data, redundant data, lack of knowledge of what to measure etc. The data requirements for measuring market risk are pretty straight forward - prices, volatility and other external data, packaged with significant history in large databases easily accessible and measurable. Similarly, credit risk relies on the assessment and analysis of historic and factual data, which is easily available in most core banking systems.
Operational risk, however, is an ill-defined "inside measurement," related to the measures of internal performance, such as internal audit ratings, volume, turnover, error rates and income volatility, interaction of people, processes, methodologies, technology systems, business terminology and culture. Uncertainty about which factors are important arises from the absence of a direct relationship between the risk factors usually identified and the size and frequency of losses.
Capturing operational loss experience also raises measurement questions. Further the costs of investigating and correcting the problems underlying a loss event could be significant and in some cases exceed the direct costs of operational losses. Measuring operational risk requires both estimating the probability of an operational loss event and the potential size of the loss.
Thus any mathematical approach to operational risk struggles with lack of objective data. Operational risk could cost the 100 biggest banks $14-15 billion a year given the evolving nature of operations and a single enterprise-wide historical view of operational risk may not be the right approach.
Instead, banks should develop suitable internal measures of operational risk to substitute or add to available historical risk data. This means identifying categories and classes of risk and gathering all readily available information, which together can support a reliable measure of operational risk in each area of activity and for each category or sub-category. Information can be data on risk experience, inherent risk on risk-scoring mechanisms and subjectively based measurements of risk impact and likelihood. Better operation risk management means that banks are less likely to have major losses through error, fraud or failure to deliver quality service.
Along with protecting a company from potential damage, proactive risk management contributes to the bottom line. The benefits include protection of assets by preventing major losses, protection of shareholder value, avoidance of regulatory censure, the ability to render services without interruption, and the maintenance of a good reputation and public confidence. In the long run, the new Basel II guidelines will motivate better control of operational risk, leading to greater efficiencies in pricing and, ultimately, lower costs for lending money. Institutions with enterprise wide operational risk awareness and ownership and clear processes to monitor and manage it will be best equipped to embrace change and profit from it.
Risk Management Tools
A robust operational risk management process consists of clearly defined steps which involve identification of the risk events, analysis, assessment of the impact, treatment and reporting.
While sophisticated tools for measuring and managing operational risks are still to evolve, the current practices in this area are based on self-assessment. The starting point is the development of enterprise-wide generic standards for OR which includes corporate governance standards. It is extremely important for a robust risk management framework that the operational risks are managed where they originate. Risk management and compliance monitoring is a line management function and the risk culture has to be driven by the line Manager. It is, therefore, the line manager's responsibility to develop the generic operational risk standards applicable to his line of business. The purpose of this tool is to set minimum operational risk standards for all business and functional units to establish controls and monitor risks through control standards and risk indicators.
Once the standards are set, the line manager has to undertake a periodic operational risk self- assessment to identify key areas of risk so that necessary risk based controls and checks can be developed to monitor and mitigate the risks.
Control standards set minimum controls and minimum requirements for self-assessment of effectiveness of controls for the key processes.
The risk indicators identify operational risks and control weaknesses through statistical trend analysis. The risk indicators are reviewed periodically to ensure that they are constantly updated.
Reporting is a very important tool in the management of operational risks since it ensures timely escalation and senior management overview. Reporting should include significant operational risk exceptions, corporate governance exceptions, minutes of meetings of operations risk committee and real-time incident reports.
Operational risk management is one of the most complex and fastest growing areas in financial services industry. The methods to quantify the risk are evolving rapidly though they are not likely in the near future, to attain the sophistication with which market and credit risks are measured. Nevertheless, it is extremely important that the significance and impact of this risk area on the overall viability of a banking enterprise is given due recognition so that there are strong incentives for banks to continue to work towards developing models to measure operational risks and to hold the required capital buffers for this risk.

Tsunami Disaster & Rotary Members Visit Dec 26-31 2004

Introduction:

Rotary along with Sherlock Holmes, P G Wodehouse, Shanker-Jaikishen, Mohd Rafi, Pink Floyd has been my one of my abiding passions. Befitting a Gemini, I am prone to frequent mood and interest changes but Rotary has been one of the 'one fixed spots in a changing universe' as Holmes said about Watson.

At Rotary, we are committed to make the society we live in a better place to work while enjoying all the camaraderie, friendship and fun we share. I am priveleged to belong to a Club in India called Rotary Club of Madras, Chenna Patna (RI Dist 3230) and we did a fair bit of work during and after the Tsunami that stuck our coast the morning of 26th Dec 2004. I have attached a report which I published after I visited the coastal areas a few hours after the disaster trying to lend a helping hand to my fellow countrymen.

REFLIEF OPERATIONS AT KARAIKAL/TARANGAMBADI

The sight that greeted us was incongruous and would have been funny but for the fact that the mood was somber. One Ford Ikon, a Cielo, an ambulance and a few buses were scattered around in a large field along with scores of two-wheelers and one could appreciate the fury that had been wrought when one looked back and saw the now-calm sea was a good 700 meters away. Once in a while, Nature reminds us she is the boss is and we helpless human beings can only look on in awe at the power when on display and in sorrow at the destruction that is wrought.

Rotarians Capt Ravi, Saiseshan, Major Lakshmanan, Praveen Mehra and I; accompanied by my colleague, Anil of HCL Technologies and a few others left early for Karaikal in two cars. It was a good 6 hour drive & we reached Mr Ilangovan’s spacious office close to 1 pm and the mood in the normally cheerful little town was one of distress and sadness. Mr Ilangovan and Mr Chockalingam – 2 Lions as any – accompanied us with some of their associates most notably Mr Kesava who runs an orphanage and Mr Satya for a tour of affected areas and we saw for ourselves the state of roads, houses, bridges and boats.


Roads which proudly once carried 3 buses side by side and boasted a view of the sea rivaled by few, now looked forlorn, their width reduced to a few feet incapable of carrying even our car, the proud embankments reduced to rubble and lay scattered across us, the sides of the road a steep gradient now with water on all sides and a few feet away we saw a most distressing sight – a blue plastic chair on which presumably an old man would have been sunning himself in the early morning warmth and would have watched helplessly as the waves hit him.

The tragedy hasn’t spared anyone from any strata of society. A young doctor slated to go to UK for further Doctoral studies in a week’s time lost his life as he went to play tennis with his friends. His body was found about 2 Kilometers from the shore - a young life and talent lost in prime. Scores of fishermen & their families lost their lives, homes and livelihood and the waves stuck with force and surprise. Several pilgrims lost their life while they were on the beach after spending the morning in the pew praying. More than a hundred patients lost their lives as their hospital – more than a kilometer from the sea shore - was washed away and we saw the now-ghost like frame of the building with no doors or windows.

After a reconnoitering of the area with our new friends, we were informed that there was a good deal of aid material available in Karaikal proper, but the areas near Karaikal like Poompuhar, Tarangambadi etc were without proper aid as they were difficult to reach. We then went to one of the major relief camps at Tarangambadi where we saw 1500 inmates packed into a small school building living off aid. They were eating out of leaves and whatever they could get their hands upon and our distribution of plates and glasses was very welcome. There were not enough medicines and doctors at the site were glad to see the quantity and quality of drugs that we were carrying, drinking water is in perennial short supply and we were able to unload some of the water packets we were carrying. Clothes and bedsheets were to be distributed in areas where they are really needed and our friends in Karaikal were planning a trip to Thirukkadayur to distribute the balance over the next day or two. We also met a hard working Rajya Sabha MP, Mrs Gokulindira and the Project Officer, Mr Balasubramaniam who asked us for further relief material and long term assistance to rebuild houses, schools, hospitals and boats.

There is request for further material most notably, utensils, medicines, drinking water sachets, Bedsheets & Chatais (mats used for sleeping). There is also the need for like minded people to volunteer and ensure distributions reach the right people. Most important there is a very real need to assist the affected people to rebuild their shattered lives – vocational training for widows, houses, boats & fishing nets for the fishermen, schools for children and long term medicinal assistance for people affected both physically and mentally by this most unexpected tragedy.

The most poignant memory of this trip was when we called a certain Dr Valluvan’s number who was a close associate of our new friends in Karaikal. The recorded message ‘this is Dr Valluvan speaking, I am fine…’ the sound dies away to waves pounding in our ears and we could visualize the valiant doctor even at the last moment letting his friends know he is fine. In heaven.

Coelreidge came to mind...Water water everywhere, but not a drop to drink….

XP - The New Way to Develop Software

Introduction –
Object-oriented programming using the Java language has become immensely popular. It has revolutionized software development to some degree, but recent studies show that half of software development projects are late, and one-third are over budget. The problem isn't the technology; it's the way software is developed. So-called "lightweight" or "agile" approaches, coupled with the power and flexibility of object-oriented languages like the Java language, offer an intriguing solution. The most popular agile approach is called Extreme Programming, or XP. Using XP on OOPS language projects can increase the chances of success dramatically.
Extreme Programming (XP) is a deliberate and disciplined approach to software development. We found XP to be successful because it stresses on customer satisfaction and the methodology is designed to deliver software as per customer needs and when it is required. XP empowers our developers to confidently respond to changing customer requirements, even late in the life cycle. XP prescribes a core set of values and practices that allow software developers to do what they do best: write code. XP eliminates the unnecessary artifacts of most heavyweight processes that distract from that goal by slowing down and draining the development staff (for example, Gantt charts, status reports, and multi-volume requirements documents).
This methodology also emphasizes team work. Managers, customers, and developers are all part of a team dedicated to delivering quality software. XP implements a simple, yet effective way to enable groupware style development.
XP improves a software project in four essential ways; communication, simplicity,
feedback, and courage. Our XP programmers communicate with our customers – proxy or real and fellow programmers on a continuous basis. Our designs are kept simple and clean and we get feedback by testing the software starting on day one. Deliveries of the system to the customers starts early and changes are implemented without the traditional problems of change management as in Classical SDLC. With this foundation our XP programmers are able to courageously respond to changing requirements and technology.

The anxiety about what XP can do to a development process is a typical example of resistance to change from the structured Classical SDLC with its phased development which last for long periods of time and defined stages to a programming concept where the entire SDLC can actually be developed in a single day. As an analogy, its like the early days of Java development. There were programmers who understood object-oriented programming and took advantage of some of the facilities especially inheritance; however, there were many more programmers who ported their C code to the Java language and then announced that they were developing as per OOPS concepts, which led to serious repercussions. Technically, these developers were doing object-oriented programming, but the approach - building one huge object that contained all the code that used to be embedded in their procedural programs - resulted in a serious hit to performance.

The 12 practices of XP –

Extreme Programming, or XP, is constructed on 12 basic practices that given below and for the most part, these basic practices are rarely demanding or difficult to use and follow.
1. The Planning Process - allows the customer to define the business value of desired features, using cost estimates provided by the programmers to choose what should be done and what should be deferred. XP planning addresses two key questions in software development: predicting what will be accomplished by the due date, and determining what to do next. The emphasis is on steering the project rather than on exact prediction of what will be needed and how long it will take. There are two key planning steps in XP, addressing these two questions:
Release Planning is a practice where the Customer presents the desired features to the programmers, and the programmers estimate their difficulty. With the costs estimates in hand, and with knowledge of the importance of the features, the Customer lays out a plan for the project. Initial release plans are necessarily imprecise: neither the priorities nor the estimates are truly solid, and until the team begins to work, no one can effectively predict just how fast they will go. Even the first release plan is accurate enough for decision making, however, and XP teams revise the release plan regularly.
Iteration Planning is the practice whereby the team is given direction every couple of weeks. XP teams build software in two-week "iterations", delivering running useful software at the end of each iteration. During Iteration Planning, the Customer presents the features desired for the next two weeks. The programmers break them down into tasks, and estimate their cost - at a finer level of detail than in Release Planning. Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration.
These planning steps are very simple, yet they provide very good information and excellent steering control in the hands of the Customer. Every couple of weeks, the amount of progress is entirely visible. There is no "ninety percent done" in XP: an application was completed, or it was not. This focus on visibility results in a nice little paradox: on the one hand, with so much visibility, the Customer is in a position to cancel the project if progress is not sufficient. On the other hand, progress is so visible, and the ability to decide what will be done next is so complete, that XP projects tend to deliver more of what is needed, with less pressure and stress.
2. Small Releases - means the developers put a simple system into production early and update it frequently on a short cycle. Releases should be as small as possible while still delivering enough business value to make them worthwhile. XP suggests that Releases should be as soon as it makes sense to do so. This provides value to the customer as early as possible. Small releases also will provide concrete feedback to developers on what meets customer needs and what doesn't. The team then can include these lessons in its planning for the next release.
3. Metaphor - means the team uses a common "system of names" and a common system description in development and communication. Extreme Programming teams develop a common vision of how the program works, which is called the "metaphor". At its best, the metaphor is a simple evocative description of how the program works. XP teams use a common system of names to be sure that everyone understands how the system works and where to look to find the functionality one is looking for, or to find the right place to put the functionality one is about to add. The system metaphor in XP is analogous to what most methodologies call architecture. The metaphor gives the team a consistent picture they can use to describe the way the existing system works, where new parts fit, and what form they should take.

4. Simple Design - The program should be the Simplest Design that meets the current requirements - without much thought about future versions. (That doesn't mean the program shouldn't scale or be inflexible.) The classical SDLC heavyweight approach say that even the very trivial design tasks has to be accomplished up front. XP says design should not be done all at once, up front, under a delusion that things won't change. XP considers design so important that it should be a constant affair. XP methodology always tries to use the simplest design that could possibly work at any point, changing it as the development proceeds to reflect emerging reality. The simplest design should follow the basic premises given below –
a. Runs all the tests
b. Contains no duplicate code
c. States the programmers' intent for all code clearly
d. Contains the fewest possible classes and methods

5. Acceptance Test Plans – First the Test Plans are written, then the applications are tested and validated to whether the software passes the test. Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. XP teams practice "test-first development", working in very short cycles of adding a test, then making it work. Almost effortlessly, teams produce code with nearly 100 percent test coverage, which is a great step forward in most shops. These "programmer tests", or "unit tests" are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the programmer tests must run correctly. This means that programmers get immediate feedback on how they're doing. Additionally, these tests provide invaluable support as the software design is improved. The point is simple. Writing tests first ensures
· The most complete set of tests possible
· The simplest code that could possibly work
· A clear vision of the intent of the code
6. Refactoring - With Refactoring, the team improves the design of the system throughout the entire development. The refactoring process focuses on removal of duplication which is a sure sign of poor design. The result is that XP teams start with a good, simple design, and always ens up with a good, simple design for the software. This lets them sustain their development speed, and in fact generally increase speed as the project goes forward. Refactoring has to be strongly supported by comprehensive testing to be sure that as the design evolves, nothing is broken.

7. Pair Programming - In Pair Programming, all production code is written by two programmers working together at one machine. There are studies to demonstrate that this method produces better software at the same or lower costs than using lone programmers. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code. Pairing, in addition to providing better code and tests, also serves to communicate knowledge throughout the team. As pairs switch, everyone gets the benefits of everyone's specialized knowledge. Programmers learn, their skills improve, they become move valuable to the team and to the company.

8. Collective Ownership - Each piece of code is subject to Collective Ownership, so any programmer can alter any piece of code with proper use of a tool to monitor the changes. All the contributors to an XP project sit together, members of one team. This team must include a business representative - the "Customer" - who provides the requirements, sets the priorities, and steers the project. It's best if the Customer or one of her aides is a real end user who knows the domain and what is needed. The team will of course have programmers. The team will include testers, who help the Customer define the customer acceptance tests. Analysts may serve as helpers to the Customer, helping to define the requirements. There is commonly a coach, who helps the team keep on track, and facilitates the process. There may be a manager, providing resources, handling external communication, coordinating activities. None of these roles is necessarily the exclusive property of just one individual: Everyone on an XP team contributes in any way that they can. The best teams have no specialists, only general contributors with special skills. Any person on the team should have the authority to make changes to the code to improve it. Everybody owns all the code, meaning everybody is responsible for it. This technique allows people to make necessary changes to a piece of code without going through the bottleneck of an individual code owner. The fact that everybody is responsible negates the chaos that ensues from no code ownership.

9. Continuous Integration - With Continuous Integration, several times a day, progress is rapid and many integration problems are eliminated. Infrequent integration leads to serious problems on a software project. First of all, although integration is critical to shipping good working code, the team is not practiced at it, and often it is delegated to people who are not familiar with the whole system. Second, infrequently integrated code is often full of bugs. Problems creep in at integration time that are not detected by any of the testing that takes place on an unintegrated system. Third, weak integration process leads to long code freezes. Code freezes mean that you have long time periods when the programmers could be working on important shippable features, but that those features must be held back.

10. 40 Hr week - Tired programmers make more mistakes, so generally the team is limited to work for 40 hrs every week.

11. On-site Customer – Its is better to have an On-site Customer available with the authority to determine requirements, set priorities, and answer questions or in his absence a suitable authority who can check the progress and see if it confirms to the requirement.

12. Coding Standards – It is essential to establish a Coding Standard, so programmers can meet the requirements of the other practices as this type of development requires continuous interaction between the programmers. Having a coding standard does two things:
· It keeps the team from being distracted by stupid arguments about things that don't matter as much as going at maximum speed.
· It supports the other practices.
Without coding standards, it is harder to refactor code, harder to switch pairs as often as one should, and harder to go fast. The goal should be that no one on the team can recognize who wrote which piece of code. The goal isn't to have an exhaustive list of rules, but to provide guidelines that will make sure the code communicates clearly. The coding standard should begin simply, then evolve over time based on team experience.

My Experience

Some of the above are essential to follow and followed as such at our development factory, some are followed on a case to case basis depending on the development patterns. Some of the practices not always used include –

No big up-front design – This is not always possible especially in large development with a vast database structure and most of our clients want to see a design before commencing the development – however, the entire development can be broken down into a series of iterative steps.

Metaphor and stories for coding – Not always required – its importance increases with the number of interdependent coding teams. Generally we ensure that Metaphors are utilized during any development process consisting of more than 4 paired teams over a time period exceeding 40 working days.

The 40-48-hour work week – We believe that human beings, especially as intelligent as our coders are talented enough to understand when they are tired and they need a break, however over a long period, we generally ensure and follow the 40-44 hr/week regime to ensure that all the programmers are fresh to undertake the necessary work-load.

· An on-site customer - Very often, we use a separate Project Manager, who is generally a very senior person, as the proxy for an on-site customer with one additional modification - The Project Manager does not drive or monitor the project development in any way. As part of presenting each desired feature, the XP Customer or his proxy defines one or more automated acceptance tests to show that the feature is working. The team builds these tests and uses them to prove to themselves, and to our customer, that the feature is implemented correctly. All our tests are automated – this is important because in the press of time, manual tests are skipped. Our XP teams ensure that once the test runs, the team keeps it running correctly thereafter by our rigorous Regression Testing Techniques. This means that the system only improves, always notching forward, never backsliding.

Frequent changes – If customers want to add features or change requirements, they are generally are allowed to depending on the complexity of change. The Management team just re-prioritzes features, but we believe that suggested changes should held until the next iteration.

Pair programming - falls into the "sometimes" bucket. One can easily visualize the advantages of pair programming during the design and algorithm-construction phase, but the efficacy during the coding and production phase is subject to actual environment. Also, very often the Project Manager alters the pair-programming rule in another way by assigning the pairs himself. He assign two programmers to work on a set task for one to three weeks. He meets with them and gives them the problem and the architected solution and sets them loose.

Advantages of XP -

Simple and elegant code – Software, which is engineered to be simple and elegant is more valuable than software that is complex and hard to maintain and XP methodology generally throws up simple and easily comprehensible code.

ROI – Our experience in Software Development has shown that a typical project will spend about twenty times as much on people than on hardware. That means a project spending 2 million dollars on programmers per year will spend about 100 thousand dollars on computer equipment each year. Let's say that we find a way to save 20% of the hardware costs by some very clever programming tricks. It will make the source code harder to understand and maintain, but we are saving 20% or 20 thousand dollars per year, which is a big saving. Now what if instead we wrote our programs such that they were easy to understand and extend. We could expect to save no less than 10% of our people costs. That would come to 200 thousand dollars, a much bigger savings. This is certainly something our customers appreciate.
Bugs - Another important issue to customers are bugs. XP emphasizes not just testing, but testing well. Tests are automated and provide a safety net for programmers and customers alike. Tests are created before the code is written, while the code is written, and after the code is written. As bugs are found new tests are added. Our strong Regression Testing methodologies sometimes to about 30% of code ensures bugs rarely get through twice.
Changing Requirements - XP enables us to embrace change. Too often we have found a customer will see a real opportunity for making a system useful with some changes after it has been delivered. XP short cuts this by getting customer feed back early while there is still time to change functionality or improve user acceptance. XP is especially useful when customers may not have a firm idea of what the system should do.

Project Risk - XP was also set up to address the problems of project risk. If customers need a new system by a specific date the risk is high. If that system is a new challenge for any software group the risk is even greater. If that system is a new challenge to the entire software industry the risk is greater even still. The XP practices are set up to mitigate the risk and increase the likelihood of success due to tight and controlled iterations, continuous feedback and repeated tests.
Smaller teams - We use XP generally for small groups of programmers - between 2 and 12, though we have occasionally used this methodology for larger projects of 30 or more people with success. We have found that on projects with dynamic requirements or high risk a small team of XP programmers will be more effective than a large team.

Continuous Interaction - XP requires an extended development team. The XP team includes not only the developers, but the managers and customers as well, all working together elbow to elbow. Asking questions, negotiating scope and schedules, and creating functional tests require more than just the developers be involved in producing the software.
Testability – Our testing methodology is geared to create automated unit and functional tests. Sometimes, we change your system design to be easier to test, but at the end of the day, every functionality is tested - where there is a will there is a way to test.
Productivity - The last thing on the list is productivity. XP projects unanimously report greater programmer productivity when compared to other projects within the same corporate environment. But this was never a goal of the XP methodology. The real goal has always been to deliver the software that is needed when it is needed.

Introduction –
Object-oriented programming using the Java language has become immensely popular. It has revolutionized software development to some degree, but recent studies show that half of software development projects are late, and one-third are over budget. The problem isn't the technology; it's the way software is developed. So-called "lightweight" or "agile" approaches, coupled with the power and flexibility of object-oriented languages like the Java language, offer an intriguing solution. The most popular agile approach is called Extreme Programming, or XP. Using XP on OOPS language projects can increase the chances of success dramatically.
Extreme Programming (XP) is a deliberate and disciplined approach to software development. We found XP to be successful because it stresses on customer satisfaction and the methodology is designed to deliver software as per customer needs and when it is required. XP empowers our developers to confidently respond to changing customer requirements, even late in the life cycle. XP prescribes a core set of values and practices that allow software developers to do what they do best: write code. XP eliminates the unnecessary artifacts of most heavyweight processes that distract from that goal by slowing down and draining the development staff (for example, Gantt charts, status reports, and multi-volume requirements documents).
This methodology also emphasizes team work. Managers, customers, and developers are all part of a team dedicated to delivering quality software. XP implements a simple, yet effective way to enable groupware style development.
XP improves a software project in four essential ways; communication, simplicity,
feedback, and courage. Our XP programmers communicate with our customers – proxy or real and fellow programmers on a continuous basis. Our designs are kept simple and clean and we get feedback by testing the software starting on day one. Deliveries of the system to the customers starts early and changes are implemented without the traditional problems of change management as in Classical SDLC. With this foundation our XP programmers are able to courageously respond to changing requirements and technology.

The anxiety about what XP can do to a development process is a typical example of resistance to change from the structured Classical SDLC with its phased development which last for long periods of time and defined stages to a programming concept where the entire SDLC can actually be developed in a single day. As an analogy, its like the early days of Java development. There were programmers who understood object-oriented programming and took advantage of some of the facilities especially inheritance; however, there were many more programmers who ported their C code to the Java language and then announced that they were developing as per OOPS concepts, which led to serious repercussions. Technically, these developers were doing object-oriented programming, but the approach - building one huge object that contained all the code that used to be embedded in their procedural programs - resulted in a serious hit to performance.

The 12 practices of XP –

Extreme Programming, or XP, is constructed on 12 basic practices that given below and for the most part, these basic practices are rarely demanding or difficult to use and follow.
1. The Planning Process - allows the customer to define the business value of desired features, using cost estimates provided by the programmers to choose what should be done and what should be deferred. XP planning addresses two key questions in software development: predicting what will be accomplished by the due date, and determining what to do next. The emphasis is on steering the project rather than on exact prediction of what will be needed and how long it will take. There are two key planning steps in XP, addressing these two questions:
Release Planning is a practice where the Customer presents the desired features to the programmers, and the programmers estimate their difficulty. With the costs estimates in hand, and with knowledge of the importance of the features, the Customer lays out a plan for the project. Initial release plans are necessarily imprecise: neither the priorities nor the estimates are truly solid, and until the team begins to work, no one can effectively predict just how fast they will go. Even the first release plan is accurate enough for decision making, however, and XP teams revise the release plan regularly.
Iteration Planning is the practice whereby the team is given direction every couple of weeks. XP teams build software in two-week "iterations", delivering running useful software at the end of each iteration. During Iteration Planning, the Customer presents the features desired for the next two weeks. The programmers break them down into tasks, and estimate their cost - at a finer level of detail than in Release Planning. Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration.
These planning steps are very simple, yet they provide very good information and excellent steering control in the hands of the Customer. Every couple of weeks, the amount of progress is entirely visible. There is no "ninety percent done" in XP: an application was completed, or it was not. This focus on visibility results in a nice little paradox: on the one hand, with so much visibility, the Customer is in a position to cancel the project if progress is not sufficient. On the other hand, progress is so visible, and the ability to decide what will be done next is so complete, that XP projects tend to deliver more of what is needed, with less pressure and stress.
2. Small Releases - means the developers put a simple system into production early and update it frequently on a short cycle. Releases should be as small as possible while still delivering enough business value to make them worthwhile. XP suggests that Releases should be as soon as it makes sense to do so. This provides value to the customer as early as possible. Small releases also will provide concrete feedback to developers on what meets customer needs and what doesn't. The team then can include these lessons in its planning for the next release.
3. Metaphor - means the team uses a common "system of names" and a common system description in development and communication. Extreme Programming teams develop a common vision of how the program works, which is called the "metaphor". At its best, the metaphor is a simple evocative description of how the program works. XP teams use a common system of names to be sure that everyone understands how the system works and where to look to find the functionality one is looking for, or to find the right place to put the functionality one is about to add. The system metaphor in XP is analogous to what most methodologies call architecture. The metaphor gives the team a consistent picture they can use to describe the way the existing system works, where new parts fit, and what form they should take.

4. Simple Design - The program should be the Simplest Design that meets the current requirements - without much thought about future versions. (That doesn't mean the program shouldn't scale or be inflexible.) The classical SDLC heavyweight approach say that even the very trivial design tasks has to be accomplished up front. XP says design should not be done all at once, up front, under a delusion that things won't change. XP considers design so important that it should be a constant affair. XP methodology always tries to use the simplest design that could possibly work at any point, changing it as the development proceeds to reflect emerging reality. The simplest design should follow the basic premises given below –
a. Runs all the tests
b. Contains no duplicate code
c. States the programmers' intent for all code clearly
d. Contains the fewest possible classes and methods

5. Acceptance Test Plans – First the Test Plans are written, then the applications are tested and validated to whether the software passes the test. Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. XP teams practice "test-first development", working in very short cycles of adding a test, then making it work. Almost effortlessly, teams produce code with nearly 100 percent test coverage, which is a great step forward in most shops. These "programmer tests", or "unit tests" are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the programmer tests must run correctly. This means that programmers get immediate feedback on how they're doing. Additionally, these tests provide invaluable support as the software design is improved. The point is simple. Writing tests first ensures
· The most complete set of tests possible
· The simplest code that could possibly work
· A clear vision of the intent of the code
6. Refactoring - With Refactoring, the team improves the design of the system throughout the entire development. The refactoring process focuses on removal of duplication which is a sure sign of poor design. The result is that XP teams start with a good, simple design, and always ens up with a good, simple design for the software. This lets them sustain their development speed, and in fact generally increase speed as the project goes forward. Refactoring has to be strongly supported by comprehensive testing to be sure that as the design evolves, nothing is broken.

7. Pair Programming - In Pair Programming, all production code is written by two programmers working together at one machine. There are studies to demonstrate that this method produces better software at the same or lower costs than using lone programmers. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code. Pairing, in addition to providing better code and tests, also serves to communicate knowledge throughout the team. As pairs switch, everyone gets the benefits of everyone's specialized knowledge. Programmers learn, their skills improve, they become move valuable to the team and to the company.

8. Collective Ownership - Each piece of code is subject to Collective Ownership, so any programmer can alter any piece of code with proper use of a tool to monitor the changes. All the contributors to an XP project sit together, members of one team. This team must include a business representative - the "Customer" - who provides the requirements, sets the priorities, and steers the project. It's best if the Customer or one of her aides is a real end user who knows the domain and what is needed. The team will of course have programmers. The team will include testers, who help the Customer define the customer acceptance tests. Analysts may serve as helpers to the Customer, helping to define the requirements. There is commonly a coach, who helps the team keep on track, and facilitates the process. There may be a manager, providing resources, handling external communication, coordinating activities. None of these roles is necessarily the exclusive property of just one individual: Everyone on an XP team contributes in any way that they can. The best teams have no specialists, only general contributors with special skills. Any person on the team should have the authority to make changes to the code to improve it. Everybody owns all the code, meaning everybody is responsible for it. This technique allows people to make necessary changes to a piece of code without going through the bottleneck of an individual code owner. The fact that everybody is responsible negates the chaos that ensues from no code ownership.

9. Continuous Integration - With Continuous Integration, several times a day, progress is rapid and many integration problems are eliminated. Infrequent integration leads to serious problems on a software project. First of all, although integration is critical to shipping good working code, the team is not practiced at it, and often it is delegated to people who are not familiar with the whole system. Second, infrequently integrated code is often full of bugs. Problems creep in at integration time that are not detected by any of the testing that takes place on an unintegrated system. Third, weak integration process leads to long code freezes. Code freezes mean that you have long time periods when the programmers could be working on important shippable features, but that those features must be held back.

10. 40 Hr week - Tired programmers make more mistakes, so generally the team is limited to work for 40 hrs every week.

11. On-site Customer – Its is better to have an On-site Customer available with the authority to determine requirements, set priorities, and answer questions or in his absence a suitable authority who can check the progress and see if it confirms to the requirement.

12. Coding Standards – It is essential to establish a Coding Standard, so programmers can meet the requirements of the other practices as this type of development requires continuous interaction between the programmers. Having a coding standard does two things:
· It keeps the team from being distracted by stupid arguments about things that don't matter as much as going at maximum speed.
· It supports the other practices.
Without coding standards, it is harder to refactor code, harder to switch pairs as often as one should, and harder to go fast. The goal should be that no one on the team can recognize who wrote which piece of code. The goal isn't to have an exhaustive list of rules, but to provide guidelines that will make sure the code communicates clearly. The coding standard should begin simply, then evolve over time based on team experience.

My Experience

Some of the above are essential to follow and followed as such at our development factory, some are followed on a case to case basis depending on the development patterns. Some of the practices not always used include –

No big up-front design – This is not always possible especially in large development with a vast database structure and most of our clients want to see a design before commencing the development – however, the entire development can be broken down into a series of iterative steps.

Metaphor and stories for coding – Not always required – its importance increases with the number of interdependent coding teams. Generally we ensure that Metaphors are utilized during any development process consisting of more than 4 paired teams over a time period exceeding 40 working days.

The 40-48-hour work week – We believe that human beings, especially as intelligent as our coders are talented enough to understand when they are tired and they need a break, however over a long period, we generally ensure and follow the 40-44 hr/week regime to ensure that all the programmers are fresh to undertake the necessary work-load.

· An on-site customer - Very often, we use a separate Project Manager, who is generally a very senior person, as the proxy for an on-site customer with one additional modification - The Project Manager does not drive or monitor the project development in any way. As part of presenting each desired feature, the XP Customer or his proxy defines one or more automated acceptance tests to show that the feature is working. The team builds these tests and uses them to prove to themselves, and to our customer, that the feature is implemented correctly. All our tests are automated – this is important because in the press of time, manual tests are skipped. Our XP teams ensure that once the test runs, the team keeps it running correctly thereafter by our rigorous Regression Testing Techniques. This means that the system only improves, always notching forward, never backsliding.

Frequent changes – If customers want to add features or change requirements, they are generally are allowed to depending on the complexity of change. The Management team just re-prioritzes features, but we believe that suggested changes should held until the next iteration.

Pair programming - falls into the "sometimes" bucket. One can easily visualize the advantages of pair programming during the design and algorithm-construction phase, but the efficacy during the coding and production phase is subject to actual environment. Also, very often the Project Manager alters the pair-programming rule in another way by assigning the pairs himself. He assign two programmers to work on a set task for one to three weeks. He meets with them and gives them the problem and the architected solution and sets them loose.

Advantages of XP -

Simple and elegant code – Software, which is engineered to be simple and elegant is more valuable than software that is complex and hard to maintain and XP methodology generally throws up simple and easily comprehensible code.

ROI – Our experience in Software Development has shown that a typical project will spend about twenty times as much on people than on hardware. That means a project spending 2 million dollars on programmers per year will spend about 100 thousand dollars on computer equipment each year. Let's say that we find a way to save 20% of the hardware costs by some very clever programming tricks. It will make the source code harder to understand and maintain, but we are saving 20% or 20 thousand dollars per year, which is a big saving. Now what if instead we wrote our programs such that they were easy to understand and extend. We could expect to save no less than 10% of our people costs. That would come to 200 thousand dollars, a much bigger savings. This is certainly something our customers appreciate.
Bugs - Another important issue to customers are bugs. XP emphasizes not just testing, but testing well. Tests are automated and provide a safety net for programmers and customers alike. Tests are created before the code is written, while the code is written, and after the code is written. As bugs are found new tests are added. Our strong Regression Testing methodologies sometimes to about 30% of code ensures bugs rarely get through twice.
Changing Requirements - XP enables us to embrace change. Too often we have found a customer will see a real opportunity for making a system useful with some changes after it has been delivered. XP short cuts this by getting customer feed back early while there is still time to change functionality or improve user acceptance. XP is especially useful when customers may not have a firm idea of what the system should do.

Project Risk - XP was also set up to address the problems of project risk. If customers need a new system by a specific date the risk is high. If that system is a new challenge for any software group the risk is even greater. If that system is a new challenge to the entire software industry the risk is greater even still. The XP practices are set up to mitigate the risk and increase the likelihood of success due to tight and controlled iterations, continuous feedback and repeated tests.
Smaller teams - We use XP generally for small groups of programmers - between 2 and 12, though we have occasionally used this methodology for larger projects of 30 or more people with success. We have found that on projects with dynamic requirements or high risk a small team of XP programmers will be more effective than a large team.

Continuous Interaction - XP requires an extended development team. The XP team includes not only the developers, but the managers and customers as well, all working together elbow to elbow. Asking questions, negotiating scope and schedules, and creating functional tests require more than just the developers be involved in producing the software.
Testability – Our testing methodology is geared to create automated unit and functional tests. Sometimes, we change your system design to be easier to test, but at the end of the day, every functionality is tested - where there is a will there is a way to test.
Productivity - The last thing on the list is productivity. XP projects unanimously report greater programmer productivity when compared to other projects within the same corporate environment. But this was never a goal of the XP methodology. The real goal has always been to deliver the software that is needed when it is needed.