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
Software-Industry
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
Software-Industry
posted by Sushil at 4:36 am
2 Comments:
Sushil - very very well written and 100% accurate as well.
The piece was so full of humour and sarcasm that it triggered a tremendous sense of amusement.
I have been in all these situations you mentioned as well and it is easy to see that this happens all the time and in most projects. Rants aside, I wonder, what sort of a solution plan can one possibly offer to such a pathetic work life situation that most IT people are subjected to?
There are solutions, definitely. But will economics come in the way?
Excellent post! It is really sad that we have no option but to rant and continue to working. This seems to be the business model that the majority of the Indian software consulting firms follow.
I found this sentence in your post too much - “its okay if this doesn’t work that way, we can always teach the users to change their process”. It reminded me of similar such instances that I've seen, most of them related to User Interface development.
One funny client requirement that I heard from a nearby project was to authorize and authenticate users in a website without having them log in! No, they have not heard about Windows authentication either! Too weird.
Post a Comment
<< Home