Monday, December 19, 2005

Why did the chicken cross the road?

If you have worked in IT Consulting you will realise the following answer to a simple question could have only been answered by an over priced consultant from one of the Big Five Consulting companies (PWC,Anderson,KPMG,CGEY,D&T). I use the following also as a cheat sheet when responding to RFPs where I need to use big fancy words.

Q. Why did the chicken cross the road?
A. Deregulation of the chicken's side of the road was threatening it's dominant market position. The chicken was faced with significant challenges to create and develop the competencies required for the newly competitive market. Big Five Consulting, in a partnering relationship with the client, helped the chicken by rethinking it's physical distribution strategy and implementation process. Using the Poultry Integration Model (PIM), Big Five helped the chicken use it's skills, methodologies, knowledge, capital and experiences to align the chickens people, processes and technology in support of it's overall strategy within a Program Management framework. Big Five Consulting convened a diverse cross-spectrum of road analysts and best chickens along with Big Five consultants with deep skills in the transportation industry to engage in a two day itinerary of meetings in order to leverage their personal knowledge capital, both tacit and explicit, and to enable them to synergize with each other in order to achieve the implicit goals of delivering and successfully architecting and implementing an enterprise-wide value framework across the continuum of poultry cross-median processes. The meeting was held in a park-like setting, enabling and creating an impactful environment which was strategically based, industry-focused, and built upon a consistent, clear and unified market message and aligned with the chicken's mission, vision and core values. This was conducive towards the creation of a total business integration solution.

Category: Software Industry Humour

Project Management Proverbs

This has been out on the net for years but came across it again today. The IT Project Management Proverbs I & II. Of these I liked the following the most:
  • Any project can be estimated accurately (once it's completed).
  • The most valuable and least used WORD in a project manager's vocabulary is "NO".
  • The most valuable and least used PHRASE in a project manager's vocabulary is "I don't know".
  • Nothing is impossible for the person who doesn't have to do it.
  • You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.
  • At the heart of every large project is a small project trying to get out.
  • Too few people on a project can't solve the problems - too many create more problems than they solve.
  • A change freeze is like the abominable snowman: it is a myth and would anyway melt when heat is applied.
  • A user is somebody who tells you what they want the day you give them what they asked for.
  • What you don't know hurts you.
  • A badly planned project will take three times longer than expected - a well planned project only twice as long as expected.
  • It takes one woman nine months to have a baby. It cannot be done in one month by nine women.
  • Fast - cheap - good: you can have any two.
  • Good project management is not so much knowing what to do and when, as knowing what excuses to give and when.
  • If everything is going exactly to plan, something somewhere is going massively wrong.
  • For a project manager overruns are as certain as death and taxes.
  • Some projects finish on time in spite of project management best practices.
  • Good project managers admit mistakes: that's why you so rarely meet a good project manager.
  • There is such a thing as an unrealistic timescale. The more ridiculous the deadline the more money will be wasted trying to meet it.
  • The first 90% of a project takes 10% of the time the last 10% takes the other 90%.
  • The project would not have been started if the truth had been told about the cost and timescale.
  • To estimate a project, work out how long it would take one person to do it then multiply that by the number of people on the project.
  • When the weight of the project paperwork equals the weight of the project itself, the project can be considered complete.
  • There is no such thing as scope creep, only scope gallop - Anything that can be changed will be changed until there is no time left to change anything.
  • If project content is allowed to change freely the rate of change will exceed the rate of progress.
  • If you can interpret project status data in several different ways, only the most painful interpretation will be correct.
  • A project gets a year late one day at a time.
  • If you're 6 months late on a milestone due next week but nevertheless really believe you can make it, you're a project manager.
  • No project has ever finished on time, within budget, to requirement - yours won't be the first to.
  • The first myth of management is that it exists.
  • If an IT project works the first time, it is wrong.
  • The person who says it will take the longest and cost the most is the only one with a clue how to do the job.
  • Difficult projects are easy, impossible projects are difficult, miracles are a little trickier.

Category: Software Industry Project Management

Friday, December 09, 2005

IT Widows & Widowers & Orphans

Another article that talks about the impact of the IT industry work style and its impact on the family of the person working in IT. This is from "The Hindu"'s "Speak Out" column that appears in the Saturday paper.

[QUOTE] I'm a mother of two. Most of the time, I find myself playing substitute father, since my husband not only works late, but is often away on tours as well. If anyone can offer tips on how the family can manage both work and home, they would be appreciated.[/QUOTE]

I believe this article speaks out about the general lifestyle of people working in IT and more specifically the men who end up choosing work over families. Am not sayint that there arnt women who end up choosing work over families but just the sheer ratios of men to women working in IT results in more men spending more time at work. End result the family suffers with the spouse being an "IT Widow" akin to a "Golf Widow" where the husband spends all his time playing golf. Here instead the husband spends all his time at work or working from home or being away from home for work. Am sure the phenomenon of an "IT Widower" exists where the husband works in a non-IT field and doesnt get to see much of the IT wife.

Compared to being an IT Widow or Widower I believe there is one thing worse. IT would be an IT Orphan. This can be best explained with the following true example. A couple works in the same software company. Both are at a pretty senior level and have a small son. The poor kid spends most of his time with either his grandparents or uncles/aunts as his parents are usually travelling or working late. At any given time I have not heard of the parents being in the same city at the same time for more than a couple of days and during those days they are invariably working late. This poor kid is the "IT Orphan" who has parents who can spend a lot of money on him whenever needed but cannot afford to spend time with him. Time which is much more precious than money !

Solutions are needed and quickly for the sake of the Widows/Widowers and Orphans.

Category: Software-Industry

Thursday, December 08, 2005

IT Life - Words & Phrases

These words/phrases have been overused by people I worked with/for and are related to software projects I have worked on and had the responsibility to work on it myself or had to get someone else to resolve the issues. In all cases the problems were so many and so severe that if it was possible I would like to have the associated words totally banned or use alternatives or invent some kind of filter (on my ears) as I would prefer to not hear these words or phrases ever again. Each time I hear these words I remember the not so distant past where I heard these words over and over and over and over and over again. The list is chronologically ordered but not in any particular magnitude of hatred. The list also shows the progression and changes in what I used to do and what I do now.

1. JScript
2. JavaScript
3. ASP
4. Website Link Checker
5. Word Wrap
6. AutoCAD Viewer
7. File Formats
9. Out Of Memory
10. Applet
11. Application
12. AWT
13. Swing
14. Category
15. Transformation - Staging Transformation, Structural Transformation, Behavioral Transformation.
16. Object-To-Relational Mapping
17. Database Error
18. Gemstone
19. Process Costing
20. Performance Tuning
21. Dispatcher
22. Stuck Purchase Order (PO)
23. Stuck Pricing Request (PR)
24. Supplier
25. Buysite
26. Marketsite
27. Page Cannot Be Displayed
28. Workflow
29. Pager
30. On Call
31. 24x7 Support
32. Production Critical Application
33. Serial
34. Parallel
35. Severity
36. Priority
37. Outage Report
38. Issue
39. Escalation
40. Level One Help Desk
41. Ticket
42. Bug
43. Enhancement
44. Release Notes
45. Smart-Form
46. Meet-Me-Line
47. How is it going?
48. Conference Call
49. Root Cause Analysis
50. Preventive Action
51. Weekly Status Meeting
52. Daily Noon Status Meeting
53. Seebeyond EWay
54. Broker
55. Adapter
56. Re-process Error File
57. MJQ
58. JMA
59. Catalog Load Problem
60. Long Running Report
61. Tornado
62. Virtual
63. Advisor
64. Voice
65. Recognition
66. Prompt
67. Text-to-Speech(TTS)
68. Business Requirements
69. System Requirements
70. Requirements Traceability Matrix
71. Test Cases
72. Disaster Recovery Planning
73. Go-No-Go Meetings
74. Tollgates
75. Block-Point-Release
76. Project Plan
77. Testing Plan
78. Testing Strategy
79. QA Review
80. Automated Testing
81. Use Cases
82. Swim Lane
83. Design Document
84. Change Request
85. Auto - Diagnostic Trouble Code (DTC)
86. Oil Life
87. Odometer
88. Trigger
89. File Format
90. Data Sharing Agreement
91. Schema (XSD)
92. Integration/System Testing
93. Bag-Phone
94. GPS
95. Fixed Bid
96. Request-For-Proposal
97. Proposal Response
98. Estimation Methodology
99. Effort
100. Middleware
101. Schedule
102. Transition Plan
103. Quality Plan
104. Automotive Warranty
105. White-paper
106. BPEL
107. Data Model
108. Design Review
109. SQLJ
110. Firewall
111. Secure-ID
112. Quality Assurance
113. Monthly Audit
114. Process Audit
115. Just like that Audit
116. Audit Finding
117. Audit Observation
118. Non-Compliance
119. Monthly Metrics
120. Resource
121. Revenue
122. Forecast
123. Target
124. Defect
125. Tracking
126. Appraisal
127. Feedback
128. Goal Setting
129. Billing
130. Invoices
131. High Priority Issue
132. Status Report
133. Change Request
134. SMART Goals
135. Working Weekend
136. Comp Off

I feel much better now that I have listed out these words. I cannot expect people to not use words on the list but don’t think I can ever get used to them getting repeated over and over and over.

Category:Software IndustryRant

Wednesday, December 07, 2005

Padams of Poos

I think these are lillies - let me know if they are something else. Taken this morning in a sudden burst of enthu. The watchman gave me a weird look as he couldnt figure out what I was upto so early in the morning.


Monday, December 05, 2005

How long does it take to count 38000 characters one character at a time ?

One of the guys working on my team (called V) came across an error while putting together a query for generating a report. Trying to figure out the error message he sends out a note to internal experts of the reporting tool (Business Objects - hilariously referred to as BO in short. In the past I have heard of people comment about someone elses BO but that was in a more personal sense :-) )asking for help. Someone well versed in BO :-) writes back that the tool supports auto-generated queries of a maximum length of 65536 characters. Luckily I was talking to V on the phone and also had netmeeting running where I could see his desktop and other sample reports he had developed. I was shown the email from the BO expert :-) in response to his plea for help. I suggested V check the number of characters of the query. I hear V give a big sigh. I didnt understand why he was sighing. I heard him say "I need to count the characters of this query" in a quizzical way. I go whats the big deal, copy it from the reporting tool, paste it into word and then you can get the counts. I saw him copy paste from the tool to word. Then I was shocked speechless when I hear him mumble 1,2,3,4,5,6,7,8...... all the while moving the cursor in word a character at a time ! I was so shocked by this that by the time I could croak out a "V what are you doing ?" , V had already reached ....31,32,33 and was begining to go strong . Phew ! I told him to stop what he was doing and showed him the magic of Tools-> Word Count in Word and voila ...we see 38560 characters and change. V was very relieved and sounded very sheepish :-). I was more relieved as I had just saved atleast an hour of Vs time today if not more...he could have counted all the way to 15000 and then lost count and then started again or worse still taken all night to work on counting the characters ! I wish people would think a little before doing stuff like this.

To answer the question in the post title: I didnt get to find out but I know it took V almost 1 second per character. It took Microsoft word less than 1 second to count 38000 characters.

Category: Humour Rant

Friday, December 02, 2005

Battle Scarred Survivor of IT - II

The following are comments on the article I identified with so much I felt the need to save them out separately. The first one in particular echoes my feelings so much I was shocked I was reading something written by a total stranger as me and a colleague have had the same conversation several times. We didn’t win several proposals this year because we tried to factor in the fact that aggressive schedules end up burning out the team. Other companies won the projects just because they offered lower rates and shorter schedule durations. The technical solutions were not even considered.

“I work for one of the big Indian I.T. companies. When I used to toil for 14 hours a day 6.5 days a week in India, I used to think that when I run things, things will be very different. That the estimates will be realistic and every body will work normal hours. When I got a chance to bid for projects and prepare proposals for clients in the U.S., I could see the root of the problem. It starts right from the moment when the customer asks for a proposal. There is intense competition amongst vendors (most of who are based in India) With little difference among them; the lowest cost becomes the clincher. My efforts to push back on ridiculous estimates resulted in only one thing – loss of opportunity for my company. The competing rival was more than happy take the opportunity since he did not mind making his people toil to produce results. With a number of Indian vendors cutting each other throat alongside the emergence of software factories in China, Eastern Europe, South America I do not see a realistic solution to this problem at this juncture. There will always be some one on the globe willing to work hard for a “lot of money” (from relative perspective). Things like pushing back and learning to say a “plain no” are not likely to produce long lasting results. “

“Here's a tip for any company in the west planning to outsource to India. If you feel that a project can be completed in 6 weeks by 4 people, always demand that it be completed in 2 weeks by 3 people.”

“Companies need to stop hiding behind the excuse that the time difference between India and the west is the reason why people need to stay in office for 14 hours a day. Staying late should be a negative thing that should work against an employee in his appraisals. Never complement someone for staying till midnight or working 7 days a week .”

“If time estimates go wrong, the company should be willing to take a hit and not force the employee to work crazy hours to bail projects out of trouble. This will ensure that the estimates made for the next project are more real and not just what the customer has asked for.”

“The solution is changing the dimensions of the competition. Innovation is the key. When employees come up with ideas to improvise on the work, we need to listen to them and see if there is any merit. We need to commit time and energy to this cause. That's what Kaizen and CMM's level 5 are all about, but do we really implement them seriously? “

“I have seen many young employees staying back at work not necessarily because they have extra work thrust upon them, but just because they have nothing better to do. I think this culture of staying late has been the handiwork of (at least some if not most of) the employees as much as it has been a creation of business requirement for some organisations. “

“I would also put some blame on the employees also. To my experience many of the employees working on the project are technically incompetent, as a result they can not apply or use the technology to the fullest and in the most effective way. The saddest part though is many of them don't consciously take any effort to improve it also.”

“The problem is that the industry neither grooms its developers to become PMs nor facilitates successful PMs from non-Technical background to fit into their new role. The non technical type of PM fails mostly because of the Technical leads who see him as a challenger to their career and ensure that he fails. The organizations also do not recognize this as a cultural issue and try to resolve it.”

“If we try to say something about this to our seniors we are immediately labeled as the ones having an attitude problem! That affects appraisals and salary. Those who play TT in afternoon but sit till 1 in the night are given promotion because seniors see them sit till 1 in night. The hours one sits in the office has suddenly become a scale for how much hard working one is rather than seeing his productivity. “

“I used to go home by 6 am early morning, and be back by 12 noon. This has continued around for more than 6 months. Its like zero invention time. Most of the work that was done during night was scrapped and there was lot of rework.”

“So, the US is great work place? Think again. The IT dept in US are full of politics and cover-your ### attitude. All the glory is taken by the boss and the #### are passed to the guy at the bottom of the food chain... “

“I don't know about Google/ Yahoo, etc. but almost all Indian software firms seem to follow the sweat shop model. The general steps are: 1. Get a project by promising everything the client wants. 2. Assign an impossible schedule to the developer (forget Analysis, Design and start coding ASAP, SDLC be damned). 3. Frown upon any employee that leaves the office on time and wants 5 days a week. 4. Forget innovation, copy paste any code you need to meet the insane schedule. 5. Failure to meet the schedule or bugs reported by the client results in more reprimands. “

“Most of the times the deadlines can be satisfied, if we do quality work for 10 hrs (instead of 8 hr.) and maybe on sat. also, in some extreme cases.”

“As for the new generation earning more money - it is just an illusion. When I started working at the age of 23, my dad and I had the same paycheck. However he lived in a huge house given by his employer, all utilities were payed by the employer, and his pension was the last paycheck that he drew, which needless to say is substantial. If I factor all that in, I made considerably less than he did.”

”Software, being intangible, it is not possible to fix a schedule at the beginning of the project and then try and stick to it. The schedule should always be in a process of modification as the project progresses. *This* is what managers' just don't understand. How can you predict when this project shall end, when so many undefined variables are there? “

To wrap up, here is some humor: “How To Interpret Employment Ads”

  • “Join Our Fast Paced Company” - We have no time to train you.
  • “Casual Work Atmosphere” - We don’t pay enough to expect that you will dress up.
  • “Must be Deadline Oriented” - You will be six months behind schedule on your first day.
  • “Some Overtime Required” - Some time each night, some time each weekend.
  • “Duties will Vary” - Anyone in the office can boss you around.
  • “Seeking Candidates with a Wide Variety of Experience” - You will need to replace three people who just left.
  • “Problem Solving Skills a Must” - You are walking into a company in perpetual chaos. Haven’t heard a word from anyone out there. Your first task is to find out what is going on.
  • “Requires Team Leadership Skills” - You will have the responsibilities of a manager without the pay or respect.
  • “Good Communication Skills” - Management communicates poorly, so you have to figure out what they want and do it.

Battle Scarred Survivor of IT - I

Thanks to Echo for a link and post to a very interesting article which is very close to my heart. I have spent several years as a developer and a couple of years as a team leader and now most recently as project manager. Having seen all hours of the day and night at work over several different projects at several different clients this article wasn’t too much of a surprise to me as I have seen all of this happen in different ways in different forms. I feel I have survived many battles in the field but keep wondering how many more I can take before it gets to be too much.

This post is split into two sections. This is part one and contains my thoughts and rants, while part two contains some comments from the post that made me write this up. Most of my thoughts attempt to give the project managers side of the problem.

********Also before people take offense these are my views and experiences and there will always be exceptions to the rule. So un-ruffle those ruffled fluffy feathers my fine feathered friends. ******************

I have spent sleepless nights/days/weeks/weekends in Indian and multinational companies with 50, 5000, 25000, 150000 and 300000 employees with bosses who are Indian, American, European and Chinese. This problem I feel has nothing to do with whether you are working for a small/large or Indian/Multinational company and regardless of the nationality of your boss.

Only in one company in Chennai did I not have to work beyond 7 PM and even the 7 PM deadline was caused because I was a new driver and didn’t want to drive in evening rush hour traffic. The other difference of that company with all the others was that it was a product development company and I was working on developing a software product. All the other companies I worked for have been in software consulting roles.

In my experience the problem starts with the sales teams who over hype everything and promise way more than is practical to the clients. The proposal writing process(there is enough for a separate post on this topic) is made interesting by a game of role playing that is done. In the game the software development gurus/studs/studdettes & project management gurus/studs/ studdettes of the organization are looked up on the internal skills database and their resumes obtained so as to make the proposal more believable that we have skilled people available to work on the project as soon as we win it. Incredible amounts of time are spent on deciding what role to fit the studs/gurus when the project is won. Finally by some complex decision trees this is also decided. In all reality the gurus/studs will be already allocated to projects from which they are not likely to be released.

The problem of people having to live at work is also caused by clients who are not clear about their requirements. They expect you to accurately estimate the effort required to put together a system which you have never built before. Estimation models can be used for this but there are limits to the accuracy of UCP, FP, COCOMO or whatever other methodology/tool that could be used. The limitation is typically the human factor. Regardless of what your estimates using the estimation model say, the actual parameters used for implementing the project such as the skillset and experience of the people working on the project are never usually factored in. Their commitment to diligently working on project work cannot accurately be measured either. So this makes the estimate plain worthless. Estimates also go based on skeletal information available and not concrete details. Projects won on Fixed Bid cost are a sure fire way for disaster as the client can afford to be lax with conducting their requirements clarification sessions and also with their acceptance of the final application. In my view estimates should be done only for coding effort only when the design is completed. Hopefully by then all requirements would be clarified.

The sales people who want to quickly make the deal usually agree to the “aggressive but do-able” schedule. They win the deal, spend company money celebrating and then inform the offshore team what the schedule is. Even teams working on the proposal from the offshore centers are typically kept in the dark about what is finally submitted as part of the proposal. Offshore teams at this point have two choices: take it or leave it. The team usually ends up taking it as there is no other work around or there is pressure from above to do so. So even before starting the fate of the project is sealed. Major offerings of Nights and weekends of the team members are sacrificed at the altars of “profitability” and “utilization” and “strategic clients” with “critical projects”. Additional offerings of the personal lives of software employees are offered at the other minor deities shrines of “CMMI Quality Initiatives”, “ISO Initiatives”, “BS7799”

The people who end up working on the projects are usually the ones who are available at the time the project is won. Some (usually a lot) may be new recruits who have no clue about the company processes like the quality initiatives etc. That is okay provided they have the skills required. Ha ha! They may not even have the skills required. Skills can be obtained through training right? Wrong. There is only so many things you can teach a person in the available timeframe so it usually ends up being a “here is the overview you should be able to pick the rest up as you go along” approach. If the available experienced staff are considered to be much better, think again. The only reason they are available is because their prior management didn’t want them. The really good experienced resources are usually kept busy and never learn the meaning of words like “Bench” or “Beach” (the Americanism of the bench) as applied to the software industry. If you have been a good manager in your past birth you may get a couple of team members who have the skills and the experience(either/or conditions need to be applied here) in some portions of each). The manager hopes to run the project banking on the strengths of these “key” people. Little does the manager know that the people he was counting on are just good actors who act like they are competent but in reality are as bad as the rest.

When the project starts off things seem nice, and the project manager vows (dreams) to run at-least this project differently from the last one where he had to work late and burn himself and the team trying to deliver on an “aggressive” schedule. Things have started to go downhill from the beginning. How ? With the whole onsite-offshore way of development, there is a short period where one or more “key/lead” members are sent onsite to figure out what the hell the client really meant when they floated the project request for proposal. This is the time where the people onsite clarify the minor gaps in the understanding of the project. J After a couple of days the originally expected minor gaps are now revised to be huge honking gaps in understanding that rival the size of the death valley. The estimates are at this point not worth the paper they may be printed on and the project is soon officially behind schedule just within a week of starting. Their covers of being smart and capable being blown wide open in front of the client, the people sent onsite tend to flake out and either have one or more nervous breakdowns. They are now capable of only simple tasks such as forwarding email, browsing the net and fetching coffee.

The project manager offshore starts working on developing an ulcer and has facial features that now resemble a mix between a condemned man and a lunatic. The condemned man is the realist/pessimist who knows that there is no way the project can be delivered in time with the understanding of the actual scope and scale of the project. The lunatic part is the eternal optimist who believes there is some loophole in the space time continuum that could result in the project completing on time. The lunatic believes that working longer could help in the search for an elusive wormhole the finding and entering of which allows the completion of the project on time. If the project manager is lucky his prayers for a heart attack are answered and he can rest for a bit. Otherwise it is the same grind trying to motivate the team, trying to find ways to get out of the rut and keep the project “back on track” behind schedule.

The team gamely struggles on trying to wrap their sleep deprived (from their last project) brains around the new business scenarios and terms that are totally unfamiliar to them. Some actually need dictionaries to understand the meaning of some terms. The ones that seem to understand the process flow shake their heads like they understand completely and then end up coding something that doesn’t behave anywhere similar to the original requirements. They then try to justify their mistake by coming up with reasons like “its okay if this doesn’t work that way, we can always teach the users to change their process”. Answers like that make me want to $!$!#@$# the person (don’t ask me what that meant). But of course you have to reason it out with them nice and politely why they need to change their code to make it work the way it should have.

Sometimes people do things to ensure they work late. One example is to come in late and then take a breakfast break and then a horu long lunch. Of course you could also do things like wipe out source code you worked on for over a day without checking it in, delete all requried data for testing, keep running code with infinite loops on shared servers to make sure everyones work is affected. Other options include changing the data types on shared code without reason causing compilation errors for the entire team, changing the signatures of key interfaces :-).

Having to talk to the onsite counterpart when you come in first thing in the morning and also as the last thing you do in the evening is another reason for the long hours. My suggestion for this is to cut down on these calls to make them once a day and also split the days so that the onsite person stays up late for a couple of days while the offshore person works late a couple of days. The avoided call can be replaced with well detailed and clear instructions in email/voicemail.

Change demands (also called “requests” in politically correct terms). These are requirements that the client business very conveniently forgot to mention up front when the project estimates were done. This has now resulted in an almost fully developed application that either cannot work in a real world business scenario or would mess things up so badly in the real world scenario that it would result in the dismissal of the person providing the requirements the first time around. These changes are unavoidable and usually expected to be handled within the existing “aggressive” timeline.

A myth has been going around about a project manager who was able to negotiate with the client for an increased cost for the project and for an extension of the schedule. In the myth there was no onsite counterpart. Most of the people who work onsite seemed to have contracted a particularly rare disease called “Spinelessnessitis” where the actual backbone disappears over time and they are unable to use the words of “not possible”, “we require an extension of schedule”, “we have to charge extra” with the clients. These individuals are thus unable to stand up straight and speak up to the clients demands and state the obvious fact of “this is just not possible in this timeframe”.

Onsite counterparts at times tend to be worse than the client when it comes to making unreasonable demands that result in people having to stay late. They usually commit to delivering work overnight when in reality it would take more than a day to do. All they need to do is use the reply of “I will check with the offshore team and get back to you” to the client instead of saying things like “sure we can build a whole new stock exchange system by tomorrow morning”. For those of you that don’t understand the meaning of the word “sarcasm” this past sentence I hope would be a good example. I havnt been asked to do such things but the general idea of “urgent requests” still stays the same. When the offshore manager tries to protect his team by not giving in to their outrageous demands, they all vomit the words of “I commited to deliver this to the client and will have to face them”. J . The offshore manager at this time has to use the sentence of “you committed to it not us – you deliver it” and walk away.

More than racial discrimination I felt there has been a lot of discrimination against the single people. I have seen many bosses pile work up on the bachelors as they don’t have a family, they can take on more work and stay late/ work on weekends. The married ones of course have to tend to demands of family. What happened to equal opportunity employment? Married ones may feel the problem of people staying late is due to the bachelors staying late. But from where I have been I was forced to stay late as everyone else had a life to get to.

Working on Mondays is a total farce especially when you work for clients in the USA/UK. They work on Friday and expect you to get stuff done by working on Saturday India time. That is okay provided the people who need to do that can take Monday off. The management of the Indian companies expects people to do a Monday-Friday + Saturday + Sunday week. So people end up coming to work on Mondays don’t have anything specific to do and end up doing nothing much all day.

The other irritant is the great distance to travel outside the city where IT companies in Chennai have built their larger facilities. This kills a good hour in the morning and at-least another hour in the evening. The bus facilities provided are also of the brain dead variety. The bus services are scheduled to reach the office at 9-9.30 in the morning and leave between 6.30 and 7 in the evening. Cut service buses run between 8.30 and 9 pm. People who typically end up having to work late have to use the cab drop service that starts only at 9.30 and will reach home only at 11-12 at night depending on the routes followed. Regardless of the time one reaches home one has to start back at the same time the next day. People are usually so sleep deprived that by the time they wake up its time to go home.

I feel that User Acceptance testing should be conducted on a time and materials basis so that the clients do their testing and acceptance quickly rather than come up with changes at the late stage of the project.

Clients usually demand an aggressive (meant unrealistic) estimate. Nine out of ten times the date by which they want the application is just a date that has no business impact as is evident when the actual date comes around and the clients don’t seem to be in any rush to use the spanking new application. Clarify the dates they ask for right at the begining is also key to making sure your team is not burned out without reason. Actually no reason is good enough to burn people out working days and nights.

Category: Rants