In 2005, as I was leaving a company, I was asked to pen down what may be the problems. I wrote the following letter to the then Director who had asked me for feedback. Names have been abbreviated. I have no idea how much this helped or did not help in the company, but I see similar issues in almost all companies. Its kind of weird how these issues exist time and time again.

Hi Mxx,

These are my thoughts based on what I perceive in EP and also in FSS. Most of it is my opinion (mostly as an outsider - as there are things about which I would not even know by now!)

First the EP groups as such.

The EP project is quite big. In fact , my previous company was almost half its size - to put things in perspective! To think about things for EP, I just thought what I would be doing if I had to ever lead such a big group.

So, in my opinion I would say the project has to be run as a company within the company - with a different set of rules than other projects. Things which apply to a group of 10-20 people cannot be extrapolated to something as big as 200 people. Its like the difference between driving a maruti 800 and a F1 car!

So there should be a full time support staff. This means that the following roles would have people dedicated 100% to EP ( if something like this exists, then I am not aware of it ) :

- HR ( 1 person from HR only for EP - who takes care of new recruits, inductions, change of group from other groups).

- Admin ( 1 person for the admin needs , and seating arrangements ).

- IT ( 1 or 2 people who look after the computer installations, licensing, new computer setup, virus etc)

The above information should be available easily - probably as part of induction or an intranet.

The other issues I see are two folds :

1. Communication , and,

2. Duplication.

1. Communication:

-----------------

There is a big communication gap even within teams. Take the instance of DSP. Its a big team ( 20+ people) and they are spread around on 3 floors. It took me 2+ weeks to meet everyone. And then almost a month to find out where the people are. Anything that needs to be circulated in the team has to be either through email ( Lotus Notes is *not* a good email client - opensource stuff like Thunderbird are much better ) or through team meetings.

Team meetings cannot be called every other day, so any communication has to wait till the week day when most teams have their meetings. Emails get lost as there is a quota limit, and also cause there is no filtering/tagging mechanism in LN. Now when free email like gmail is 2.5GB and with a huge number of features it is ridiculous for a company like FSS to still cling on to some archaic tool and space limits. Quite a lot of work can be done faster if people of the same team sit together. It will be easy for managers to get updates, for developers to find answer to queries - and also leads to team building.

So, I would suggest an immediate seating plan to go in place to get people of the same team together. Another helpful tool would be a big whiteboard for each team - which can be used by the team to discuss something, or for keeping the approaching dates up for easy reference (whatever a team wants). Having boards in rooms does not help - you cannot keep things up there indefinitely.

Another communication problem is what came out with the IRMA guidelines. No one was paying any attention cause it is not easily available. All these guidelines are either being sent through email , or being put into the EP file server ( where the hierarchy is not easy to see). Such things since being project wide would make more sense to be in one place and easily accessible. The best option here I see is having an intranet for EP. Guidelines/ howtos / rampup / software list / lab lists / etc can easily go here as webpages - which allow people to see the situation from anywhere.

Another disconnect I felt was that there is no ramp up plans in place. When I joined ( and I guess K is also going through the same kind of problems) there was no ramp up given. Even though we are experienced guys , we cannot work without inputs. And this is leading to an extra long rampup time. I suggest that ramp up plans be put in place which should be in 2 parts 1) A generic rampup on the tech, and about the DDF working. 2) Role specific ramp-up (tech lead/ architect/ management level). These things have not been thought of and there are no such things in place now - which leads to neglecting the rampup cause everyone is so busy - which leads to people working less efficiently - and hence people become more busy ... etc.

Another thing missing is the visibility of the roles of upper management to the developers. A person recently promoted was given a card from A.J. , and asked me later who was AJ cause he had no idea why the congrats came from him. I suggest that the intranet also have a profiles section for the people in charge so people who don't know will still be able to find out.

There also seems to be no process in place for induction of a new person in the team. Cubicle space, workstation procurement , setting up of software - no plan exists for this. I had to sit without a comp for 3 days, and the comp was only operational after 1 week ! I was thinking this was slow - but with new people joining the group i see that the wait time is more than 1 week ! Time wastage.

2. Duplication

--------------

Duplication of activities I feel is a critical time killer. Almost everything has to be done 2 times.

Take the case of effort updation. It has to be updated in MPP on a task basis *and* in Timesheets on a totally different basis. EP ( and FSS probably ) needs a convergence of these things. The Time sheet application is very old - and people only fill it in cause salaries are tied to it. I find it utterly unbelievable that a tech company is tech starved. How else could it be that in a time of AJAX and upcoming W3C specs employees are still forced to use a browser ( netscape 4.5 ) from yesteryear. I have also found instances of places in A where a pop up comes that you *have* to use IE for accessing certain things. Bad design ! People should be developing to the specs not the application.

And since MPP access is not to the developers, the managers need to indicate the tasklines using something else. So, for the managers its mpp for management meetings and xls or scraps of paper for developer meetings.

Another place of duplication is the passwords. I have 4 FSS passwords ( desktop login, email, timesheet, ESS ) and a few more from Nokia ( PI access, Webmail, webpronto). No convergence at all. Why can't i automatically have the same login/password at least on a FSS level if not on a client level ? It not an impossible task - WIPRO is a good example of it. Everything is authenticated based on the Active Directory password. It just takes some will to change the existing system. But most people have gotten so used to it that they are not willing to change :(

Another issue of duplication is the document updates - have to be done in both DOORs and in PI.

An underlying thread that I find in all the duplication that I theorize is that initially some tool was being used - which was found lacking in some aspect. So, people started looking for a new tool, and *added* that. I think that is a typical knee jerk reaction. What should have been done for any new tool is to see how it can replace some other tool - and only if there is an efficiency benefit (not just a feature benefit) it should be taken up.

I don't know if something can be done for the above issues - people are so busy that they don't have time to think. But whatever happens, don't add something if it is not replacing something first.

I think that the work is still holding up because you have some very very hardworking people. They put in the extra efforts and keep pulling things together - but there is a limit to that too.

You have also asked me for inputs on team members and FSS in general.

Team members in EP

-----------------------

- Very hard working people. But not many bright people. People know how to work hard, but not smart ( typical managerial dribble - but I think you will know what I mean).

- People don't know the upper management or their roles. Mxx is known as the big guy, but not many people ( specially the juniors) know your role. Ditto for V, S, A.J..

I don't know if it will be politically correct for making comments on people specifically, but since this is going to be confidential, I have a few observations :

- Recently promoted people : People have been promoted to higher tech/managerial roles. I think that they are not really ready for it - and have been promoted as a way to keep people in the company. They need grooming. Especially the managers. The senior management needs to keep a constant grooming going on. Also, the promotions seem to have gone into a few people's head and they think greatly of themselves. It becomes difficult to work with these people as they are unhelpfull - and wanted to be treated extra nice ( maybe its my problem as I cannot sweet talk much).

- I think P needs to be assertive. Most of the meetings turn out to be quite a fish market cause things are not kept on track. And assertiveness does not mean being assertive on deadlines. I think P is trying to pacify everyone - but the problem is not everyone gets pacified. Here I would like to state that since I don't know many of the reasons for the decisions, maybe I am perceiving something which is not there.

- Another comment that I have often heard is that the management bends over backwards to keep the N people happy.

- N people complain that they are kept in the dark. Its not about sharing of plans etc - what they say is that they are not told the actual reality, and it is being masked under a smile and "everything is going fine" - while they being here know that things are not ok. I think that the main problem comes from the fact that we still treat the N people as not part of the team , and only as an irritant. If they are treated as part of the team then only will we be more open to them. Currently I am seeing an erosion in trust.

- No overall Architect : When there is contention between the teams , there is no one who has overall knowledge. R comes pretty close to it - but he is too overloaded.

- Which brings me to the overloading of R. I think something should be done to make other people take up ownership - as R has the habit of taking everything upon himself.

General FSS

-----------

The general impression is that FSS is not a fun place to work in. Also it is not the best paymaster ( this is from a non-newbie perceptive - freshers are just glad that they get a job anywhere). I will not talk about salaries - you know more about it than me :-)

The fun factor is missing from the work spaces. Its not about having an annual gala event where people blow up money. Its about peer comparisons. Nothing seems to be happening here which people can identify with as a sense of achievement. Also the impression about N projects is the huge "process" that is being followed - and people from non-N projects don't want to move in , or have sympathetic comments for those who are.

Even if something like EP gets done on time - and that is taken as an achievement ( as it will inevitably be ), most people will just chit-chat over chai/coffee that management had pushed everyone tooo much for the completion, and the project was a very lousy place to work in. Catch 22. Image drop.

With a negative image - you will never get smart people in.

Processes . Hmm... Everyone has a personal grouse against processes it seems. I think its because people don't know what they are for. My way of thinking is that processes are important cause they facilitate things. But here I feel that processes are done for process sake. And almost too often it is tied with the actual implementation.

What I mean is that supposing a project is to be undertaken. The Process( CMMi etc) talks about the things which need to be done. As a CMMi Lev 5 company all the projects need to comply with this. But what happens is that the implementation ( use MPP, don't use html , etc) is taken as the process. This has lead to processes which are not really useful. If the process talks about finding defect density and tracking it, it does not specify that you can only use one tool - which is the case here. So, if something more efficient comes by , it wont be taken up. Similarly for IT processes. It should specify support for the IT infrastructure, not just which softwares to support. If a requirement comes for a new software, the IT should be able to support it , not say that the policy is not to support. There is a lot of negativism here.

Most people perceive quality as something which has to be done - not something which is a control mechanism. If a defect density is supposed to be 4 per ksloc, people get confused and think that they have to get that magical figure. Quality is not a much understood topic. Also, I am not too sure how much data was/is being fudged to get good quality figures. People fear RCA.

Other issues that I have personally ( this is totally an individual thing) is slow network access, blocked sites, blocked messenger services, no CD rom drives. Basically gives the feel that the company does not trust any of the employees. Seems strange that a company which talks about end to end communications is blocking communications inside it (it is probably a huges hangover).

Well, the mail turned out to be more that I had thought I would write. Its a mind dump.

regards,

Vibhu..