Non-Commitment, the new (or rather old?) Management Disease

Non-Commitment!

These days, I hear / feel / see this disease that seems to have plagued management of my organization.

Just to elaborate the point, Lets take a few examples… (of course the names are indicative and not real)

1. Rajesh is in a new responsibility of handling a few freshers below him. He has a few years of experience. At the start of development of new project, he is been consulted about the dates and plans. But, as it always turns out, there were requirement gaps and whole new additional functionality clarifications comes later in the project increasing his workload. Since, Rajesh has already committed on the delivery date to his seniors, he, along with his team, even-though-grudgingly, toiled through the weeks till the delivery to provide a feature complete module
2. Many people join the offshore IT services organization like mine in hope of going to another country (and possibly earn some extra money). Nameet was no exception. He was a brilliant programmer and a highly team-person, the one who gets gelled into the team nicely. But, to his misfortune, for all the commitments he made for completion and quality the work, he never got any commitments from the organization about his career progress. All he got was promises. There was no one (senior) who stood on the promises which were made. [All the years of staying the organization had also taught the seniors to not promise anything in writing!] … Well, outcome was obvious, my organization lost a good programmer and team person.
3. Sanjay, being in the organization for quite some time, had learnt a thing or two about how management works. He wanted a transfer and he started the process of talking to seniors around 3 month prior to when he really desired to get transfer. [Update: There is slang term for this, CYA.. go look yourself up if you do not know what that means]. When he was asked to work on some proposals, he committed for the work and did not care if that meant staying up till 3AM every other day for 15 days. But seniors, despite 3 months lead time, were not ready to provide any commitment on transfer for Sanjay. Neither was any response (positive or negative) provided in written communication. So much for soft-skills training that my organization mandates to everyone.
4. Everyone has likes and dislikes about jobs. Hari did not like maintenance work. He, being the bright and self-confident person, wants something bleeding edge. So when he was moved into maintenance project with low activity, he asked for change of project. Seniors, agreed after series of “discussions” but did not provide any commitments on when it will happen.

As I am trying to highlight, all these incidents involve different teams and different people but the theme is unmistakable. Juniors, are been asked for commitments and are providing commitment and are living upto it, even if that means lot of hard work and weekends, nights lost. But seniors, when it comes to reciprocating the deal, are consistently evading it!

I would venture to say, that a leader should provide a clear indications to his/her subordinates, about the responsibilities and time-lines to complete them. But he/she should not evade his/her own responsibility to provide clear time-lines / risk mitigation when it comes to fulfilling the subordinates aspirations. At the same time both need to attack their responsibilities with transparency to other party to boost the confidence!

I can clearly see few big benefits by not evading responsibilities:

1. Juniors are not in dark about when things will happen and if they do not happen, what are their options.
2. Seniors would be more esteemed personalities in their juniors eyes. At least, they would not be back biting A**holes.
3. Overall team spirit goes high when Seniors and Juniors join hands and transparently act on issues.

Client Side Communication Norms

When a person is traveling to travel to client location, he/she should be aware of cultural differences between his/her original location and the client location. This helps in quickly establishing oneself at client location… though the real awareness can be built only after the real interaction with the customers.

Communication Norms

Are they direct or indirect in their communication?
Indirect communication, even though is worse way to communicate, is often employed in avoiding a direct but disturbing communication. e.g. Say client wants to really say that, ‘Infy is giving me really high price and timeline. i cannot accept this one.’ or he just wants to pressurize Infosys person to give him the best deal, so he would say, ‘i did a project x times bigger that the one we are talking about and .. i did it in so and so time, how come u need so much time / money’
Indirect communication is also employed in various subtle ways in meetings to de-risk oneself by saying, ‘as per xyz person….. ‘ or ‘you can better talk to xyz if you want more details / concrete answers’
But apart from this, if we keep ourselves on toes, we can get most of the communication in direct form. We should ask first person questions, objective questions, multiple but defined choice questions in order to extract the information from the client in form of direct communication.
At the same time, one must understand that as a human nature, indirect communication is a inherent part of human communication and you playing little parts once in a while in such kind of communication can actually gain trust of and comfort with client person quickly. [e.g. gossip, crib, etc ]

Do they prefer written or oral communication most of the times? In what kind of situations do they prefer written communication?
For majority of the communication, business client prefer the Oral communication but expect a formal written summary communication [e.g. Meeting Minutes] of the same.
They also prefer to change the information provided earlier [documented in formal communication] via oral communication, that too in a very off-hand manner. But they remember such instances very particularly and can beat you up for not accommodating such changes in the actual implementations.

What are the usual expected response times for emails?
From client anywhere between 15 minutes to upto a week. It depends on how much client is involving him/herself in the project. If he feels the ownership of the project, he / she would be very prompt in replies [often this is NOT the case]. If client involvement is minimal, then tactics like multiple follow ups / reverse signoffs would need to be employed in order to formalize the communication.

What are some of your own findings?

1. You need to be positive in your communication but you should be very firm in not bowing to the pressure often. Client would always, i repeat, always try to get the best deal, even an unfair deal out of you. Its upto you how much you would agree to let him/her get away with it.
2. Some of the grammar phrases and usage of language would be different between Indian English and client language. Try to keep an open mind to receive a critical and irritating feedback on it. And try to correct such usage to fit the client’s view. e.g. usage of word ‘Fetch’ turned out to be very offensive to my customer since, fetch is something they use only ask their dogs to get something! Continuous smiling and nodding even when we have not understood what they are talking also proves to be unapproved by client.
3. Small talk is a very big talk! We Indians fail to make any small talk. While the US customers are big small talkers. That makes them comfortable in the group and very very uncomfortable for you in the same group since your participation in the small talk limits often to just smiling.

Meeting norms

What is the typical duration of their meetings?
1 hour
What is considered to be “appropriate” participation?
Participation in intial phases, is expected to be formal one.
In consecutive meeting, being little informal, making small talk is expected. gossip in small doses is welcome. humor is welcome too.
How do people respond to distractions like phones ringing, during the meeting?
People will typically be very family oriented so any phone from family would be given a due attention though would be curtailed soon. For the caller outside the family, the call would be received and would be courteously if its ok to talk later on.

Language used

What is the key business language?
Depends on locality is guess. For US Customers, its English.
Do you hear client folks use any other language?
Never. And they always hear us (Indians) talking in native languages in front of them and is highly unapproved by them.

Dressing and grooming

What is the expected dress code?
Varies client to client. Most financial clients would expect formal dress code.
What is considered to be completely inappropriate?
Varies by client and occasion. Most of the times floral and bright colors is a no-no.

Work values/ethics

What are some implicit norms in the organization that would not be documented anywhere for e.g. picking up stationery items, usage of common areas like cafetarias etc
Well, almost everywhere, few things are expected.
1. keeping volume level in check
2. not eating Indian food at desk [it would spread its strong aroma in entire office floor]
3. being courteous and positive in communication, etc.

Feedback from the client

Our strengths
Probably the biggest strength of us is the price and quality combination. Our lower price than direct contractors in US at the same time none or almost negligible deterioration in quality tempts many clients to go to offshoring / Infosys.
Active communication is also one of the key strengths.
Quick turnaround time due to 24 hrs open shop [onsite+offshore combined]

Our areas of improvement
Being open for bullying around. Most of the people at customer side would give their own life a first priority e.g. vacations and spending time with their family etc. Due to this they would be very open and rude about when they can finish their part of the work. Infosys team more often than not, fells pray to bullying from customer and onsite Infosys team about maintaining schedules even when the delay was all due to customer.
Too much smiling is a complete turn down.
We say ‘Yes’ when we do not understand what client is talking about and often find ourselves to have said Yes to something we didn’t wanted on our head. So start saying NO when not sure. you can get thing clarified and say yes when it is appropriate later on.

Cheers,
VJ

Pains of software project endgame

In last 5 years of Software development, I have always seen that almost invariably, the endgame of the project is the one which pains the most. Here are few of the things that I have been observing which went wrong in the project.

• Long Project lifecycle – Project life-cycle is too long. Its a already 4 months just the build (post design). This is taking toll on the team since the team is tired of looking at the same code and keep tweaking it.
• Perpetual Requirement changes – The long life-cycle of build phase has allowed customer to have sufficient time to see what was wrong in the current requirements. He is anxious to provide the updates to requirement so that its more useful. He would love to see the changes incorporated in the current build cycle itself. On the contrary, developers (and the manager/tech lead as well) are wary of any such changes since such changes often are not thought through and create more instability than value-add.
• Incremental resource loading – Addition of people in phases does hell lot bad to the project. (We added 3 people in the project almost one month after initial increment of 3 people was done). If you want the team to deliver the best, get everyone on the board at the start (need not be at the start of requirement) but at least at the start of design.
• Why one time resource loading? – For the initial team, inclusive of existing and the new, we had had a very detailed (almost like 15 sessions) walkthrough the requirements and the initial application framework design. It also gave chance to everyone (both new and experienced) to play around the app design to get the feel of it and press out any issues in the design. It also jelled that part of the team pretty good. Come one month down the line 3 new people, everyone is head over heals into their own functionality design and development, no-one is really paying attention to get these 3 people going. So ultimately these 3 people lose out on the great experience of playing with the framework. They also do not get basic requirement contexts as no-one has chit-chatted the requirements with them.
• Biggest failure of incremental resource loading – I did not realize it then, but it was extremely advantageous to the project that I returned from onsite for the design phase. I could relate the offshore team with the requirements in a better fashion since I took the requirements hands-on and had a business context of the complete requirement. I was knowing the answer to eternal ‘WHY’ of many many smallest requirements. I was knowing the background of any particular requirement as to why the requirement so. But to the new 3 people, there was no time for sharing these tidbits of the requirements. Lesson: Get whoever you want at the start and give them a ground up.
• Automation – Unit Testing – Despite my being supportive of it, I failed to make customer believe in advantages gained out of automated testing. We failed by telling the customers that it would take 1/3 the time of total build effort to create and maintain testcases for the application. It was probably a decent estimate of the effort, but what it hides is confidence that can be built due to the automated testing combined with continuous integration process. No customer would say yes to such addition to the project effort (and money) unless he/she sees the advantages that are gained out of it. How I wish, I should have had detailed discussion with my customer to buy his confidence then.
• Automation – Web Application Testing – Since Unit Testing provides you with just that – ‘a unit’ test, we need something which will smoke test the application end-to-end lets say, every 2 hours. This would have created a hell lot confidence in the working of my application. There are many tools which can help here. Commercial as well as free / open source. Rational Function Tester is a promising tool. So is open source tools like Sahi, Selenium and Canoo Webtest. As unfortunate as it is, I seem have not vested time in any one if it anytime. I must do that to find out which one is better than the rest and then make my customer and team use it.
• Lack of coherent requirement documentation – With a big showoff inside the company and also at customer location, we created multitudinous requirement artifacts viz. a usecase document, a ppt showing the part-by-part details of the screen and its possible changes in various flows, minutes of meeting with customer as well as with other application teams, and a mind blowing application look-a-like html clickable mockup. Amazing huh? I am still impressed with my own creation. But with so many artifacts, am now stuck with non-searchable subversion repository of all these artifacts. Now I feel the need of a wiki like structure which would be search-able, navigable, editable by everyone in the project (inclusive of customer!). It would have been so cool in the offshore scenario. Wiki would have kept the revision history, it would have just sufficed one single page for the things covered in usecase as well as things covered in ppt.
• Continuous Integration – Now that customer is changing the requirements frequently when he sees the application previews, I have started to see the correctness of points raised by Martin Fowler. He argues in favor of continuous integration that, if there had been automated testing and hourly build process setup, the team would have been so confident of the build that is been created that it wouldnt have bothered the team about changes in requirements. I admit, whenever I get a change in requirement, I wince and try to find out as many faults in the requirement. [Anyways, sometimes it necessary to do just that in order to get the complete requirement.]
• Agile Test Driven Development – The project with huge complexity like my current project, it would have helped to create a smaller development cycles with smaller and incremental goals. The agile mantra would have been perfect: You build some, you test some and you show some to customer. Again here, even though I am sold to this idea a long long time ago, I failed to make it believable to both my customer and my company. We could have taken a smaller (but COMPLETE) set of goals in hand and implemented them. Based on the success of them, we could have put on additional features. But this did not go down really well with my company and my customers. I also did not press a lot.
• Archaic Technology – All the technology that we use in the current project is something that was published at least 4 years ago. So in order to add the cooler features of web2.0 world today, it takes lot of pain with those old technologies which were never created for such task. Next project I must ensure that I start off with the latest versions of best tools of the market today.

Phew thats a lot of junk I managed in one project! So, does that mean this project is basically a big failure? I am kind of undecided on it right now. I agree that we messed up on lot of stuff but I also see that we still have managed to pull it off so far! With all the gems that constitute my team, I am very proud of my team and has belief that we will pull it through.

Amen!
VJ