Creating a Strong Team by Using Individual Strengths

Following is quoted from my article Key Success Factors which described the key success factors behind a record that I created in a SEI Level 5 software company that I worked with – that of delivering all software projects on time to the utmost delight of the overseas customers. Using individual’s strengths in the team was one of the key success factors.


In a team, it is important that one member’s weakness is covered by someone else’s individual strengths in such a way that each one contributes through his strengths and the team as an entity is solid. A good team is one where everyone puts in his or her strength and covers others’ weaknesses – without any ego problems, without taking pride and without belittling others.

I am sure you will ask, “With this approach, you can never help people overcome their weaknesses”. On the contrary, a good manager uses the strengths of his team-mates while slowly working on their weaknesses – so that the weaknesses are overcome without making the team-mate too conscious of his or her deficiencies. A person normally does a good job when working on the job which he loves to do. Success is a big motivator and the motivation of a job well done gives him the energy to do the other jobs which he does not like to do, and thus helps him to overcome his shortcomings too in the course of time. A motivated person can certainly work over his weaknesses better than a person, who cannot even use his strengths, can. I believe that it is the manager’s job to see that the individual’s strength is used and he feels motivated.

I have seen some people who mainly look at the weaknesses and keep pointing out errors and personal deficiencies. Nagging a person for his weaknesses makes him very conscious of himself and he cannot even use his strength. Only a very strong person, who is truly self-motivated and strongly believes in himself, can continue to perform consistently in spite of continuous nagging by his superior.


One very important key success factor which I practiced (but did not list in this article when I wrote it back in 2002) was “Effective Client Management”, or effectively managing client expectations. I now call it the policy of being “Polite but Firm”.

Managing Client Expectations

Most of the delays in projects are due to scope creep. Scope creep occurs because the project heads are not able to say “NO” to the client requests. The client does not know what impact it has on the project, but he is certainly interested in incorporating all the bright ideas which crop up after sign-off.

The key to success, in fact one of the most important one at that, was that I was able to say “no” very politely to the client and explain to him that I was saying “no” in the interest of the client and his project, not because I did not want to do it. And mind you, I still had excellent relations with the client.

Drawing a Balance between Customer Pressures and Employee Pressures

IT arena is fraught with acute shortage of skilled and trained staff. Particulalry for in-house IT, the developers may be the authors of the software developed or may have got trained on the products being used. When they leave, it takes time for a new recruit to take control of the code level details of applications which someone else has developed. With the IT job markets booming, the in house IT manager has the constant risk of losing trained persons to the software companies. He has to keep them constantly engaged and motivated to avoid the pressures of natural attrition.

On the other hand there is a constant pressure from the internal clients for continuous changes and for change responses at break neck speeds. Developers too get demoralized due to client pressures, when the client wishes, nay demands, that his requests be met instantly.

The IT manager has to draw a balance between the pressures of the internal client and the fear of loss of employees. The more the CIO lets the customer pressure pass on to his employees,  the more will be his pressure on attrition. I have seen CIOs committing aggressive dates to their internal customers either under pressure or to please them. And then they get jittery and put tremendous pressures on their staff to deliver on the promised dates as their own reputation is at stake. When the IT manager bends backwards to satisfy customer requests, he is bound to put pressure on his team to deliver on unrealistic timelines. This increases the risk of employee attrition due to undue pressures. The burnout has to happen sometime and the employee will call it quits. Then the CIOs panic and bend backwards to retain the employee when he or she puts in resignation or threatens to leave. This adds to the pressure of the CIO – leave alone the tremendous pressures he goes through if he has made unrealistic commitments to the customers.It has a snowballing effect which can break the CIO’s back. Whether it is the burnout of the IT staff or the CIO, in the long run who suffers the most? It is the company which loses out and the company’s IT plans which get jeopardized.

So in the long term interest of his company, it is best for the CIO to stand erect in front of both the customer and the employee and not bend backwards neither in front of the employees nor the customer. He should have a win win relation with both.

This requires that the IT Manager has good client management skills and that he does not succumb to pressure. He also needs to have the skills and the confidence in himself to be able to tell the customers realistic solutions and timelines. The CIO may thereby displease the customer, but will benefit the company and prevent the company’s IT plans from going haywire. If the IT Manager is too concerned with his own image and with earning brownie points, he may compromise on company’s interests. Not many companies understand this balancing that the CIO has to do for long term interest of the company.

Customer Satisfaction (CSat) Survey for ITs


While Customer Satisfaction (CSat) surveys can be good to improve services in most cases, in IT my experience is that it can be detrimental to the organization if the IT head is too much conscious of how his customers view him, or if he tries to please his customers in order to get good CSat surveys. The IT head often has to do things that are right for the organization even if it may displease his customers. I can cite real life situations in my experience which illustrate this.

We had a new business opening up at Canada and a department which was in India started operating out of Canada too. They were using one of my internally developed customized packages for a critical service delivery process in Indian operation. The same software was to be deployed in Canada. When we started implementing the system in Canada, the process head at Canada asked us for changes to be incorporated in the application.Instead of simply making the changes as requested by my users, my team has now learned to question why the change is required. According to us there was no need of a change in the process as the same process was in operation in India – only the persons owning it in India and Canada were different. We requested that a common Point of contact be appointed from among the department who could study the processes in operation in both India and Canada and suggest if there is really a change required. On detailed study it was found that there was no change required and the same system could be implemented in Canada too.

I may have displeased my internal customer initially by not complying to his request, but by having one version in India and Canada, I gave my company the following solid benefits:

  1. Saved time of developers and thus cost to company by avoiding the customization effort
  2. Saved time to deliver the product to Canada operations as customizations would have taken time to complete
  3. Ensured one less number of version of software to maintain – thus reducing the staff requirement in my department and saving cost to company

The above were primarily benefits for my department and indirect benefits to the company. What is more important is the following list of benefits which directly benefit the company:

  1. Ensured uniformity of procedures at both locations thus resulting in better processes, faster learning time, no relearning required on employees transferring from one location to other
  2. Ensured that the software did not become prone to errors as every change makes it vulnerable. Thus also minimized errors and chances of  interruptions to operations due to software breakdowns and bugs.
  3. Made it simple – the lesser the versions of processes, simpler the operations

A similar incidence came to light in another department when a process which was running in Chennai city office was replicated in Mumbai city. In this case too, my application which was used in Chennai was to be used in Mumbai process. And again there was a change request. In this case, there was somehow a slip and before my team manager could insist on a uniform process at both cities, someone lower down in his team had already created two different versions and given it to Mumbai. I came to know about it when I got a thank you mail and appreciation from my Mumbai internal customer! I may have made my client happy but did I do the right thing for the company?  And in Canada, I am sure my customer may not be as happy as my Mumbai customer, but I am sure I did what was right for the company. Remember, they are both my internal customers.

And if there is a CSat survey, my Mumbai customer will certainly give me the best ratings and the Canada one may not, but should I ignore the interest of my company for the sake of a few brownie points? I am dead clear I will not – even if it means I am the most hated person in the company.


How and why IT fails – My interview in CyberMedia India Online Magazine


Following is my interview published in CyberMedia India Online at

How and why IT fails

Monday, March 03, 2008

Prem Kamble, Vice President, Global Software Infrastructure, Sutherland Global Services, shares his experiences with Pratima Harigunani of CyberMedia News.
It was a candid speak and some bird’s eye view on the reasons, mistakes and mishaps that go behind failures of apparently promising IT deployments in an organization. For successful implementation of IT, a go-getter ready to experiment and take risks is a must, says Mr. Kamble.

What kind of IT initiatives falls in the failure bucket? Are they being talked about?

There are many failures that are not often talked about. Failures can be delays. In some cases, applications bought or developed but not used are failures. And no, they are not talked about. Most IT seminars discuss technology but rarely the people issues, which is the single most critical factor in success or failure of IT initiatives. The issue which I call the IT – Management divide is never discussed in seminars. We should have the courage to discuss this threadbare and not push it under the carpet.

Why do they fail?

The greatest pitfall in this otherwise fantastic technology is communication. There can be failures in communication of requirements: the business expert knows the process well but fails to communicate, or the person has incomplete knowledge, or the IT expert who listens interprets wrongly. Most often, the businessperson does not understand IT and the IT person does not know business.

How have you tackled such failures so far?

To minimize this big communication gap, pundits in this field have prescribed a method of not only documenting the requirements but also signing off. Because only if someone has to signoff the requirements is he really serious about it. Unfortunately this is not always practiced. The other very successful method I have often used is to find the right person and put him in charge of the implementation project. Since people and their attitude make a big difference in successful implementations.

Who should take the blame of a failure? The CIO or the users? Is it ever seen as a joint accountability?

Yes, it is a joint charge. Any computerization is a team effort between the IT and the end user. Either both succeed or both fail. But there is one more party, which plays a major role in the success or failure –the senior management, who has to look at it as a team effort and not as an IT initiative. IT institutions and event organizers like you are also partly to blame, for not discussing the real issues which are people issues.

So what is the right way of solving failure dilemmas?

The Communication pitfall should be taken care of. The user requirements should be shared and gathered properly to start with and signed by the user. Proper documentation and trials are important too. Most importantly, senior management’s involvement in the right degree makes a lot of difference. I say the “right degree” because sometimes, over-reacting to issues may make matters worse. The senior management has to be aware that most often, they are more of change management issues than technical issues.

As a CIO, what should one remember in tackling failure situations?

The role of CIO is not to do with only technology. One needs tact more than any other skill in handling the people issues. There are people, political and psychological problems to be combated. The CIO should sense a possible failure and act immediately. The trick is to find people who can endorse and espouse the IT initiative. You need people with enthusiasm and risk-appetite here. I have, in my experience, seen user department heads who were eager to have automation but too scared and not ready enough to experiment. I have in the past brought back projects from the brink of failure by hand picking from the user departments a person who was a go-getter, a risk-taker and courageous to try out, and putting him at the helm of implementation. Such people are instrumental in driving an IT change.

What is easier in implementing the right IT solution, is it being convinced by the right vendor or convincing your organization’s people?

There is nothing called a right IT Solution. The trick is in making it work for people because the best products can fail and not so good solutions can succeed – the difference is people.


© CyberMedia News Tags:IT Management,Software,Computers,Change Management,InfoTech,Information Technology,InfoTech Management

Finding the Best IT Professionals
I was discussing with a friend who runs his own software company. He was keen to devise a test to be able to recruit the best candidates for software development. And who according to him were the best candidates? The ones who are extremely sharp, particularly the ones who can crack puzzles instantly, those who believe that they are intelligent and the best.

I personally do not emphasize on testing the skills of the candidates. I look more for an attitude of learning. In the field of information technology, there is so much to learn that you can never know all. So I rarely test the knowledge of the people I interview. Even for those already working with me, I do not expect instant solutions when I ask them a solution to a technical problem. I am okay if he says, “I do not know, but let me look up and see if there is a solution”. And he may have to look up manuals, user groups, web articles, etc. There are some who feel awkward to say “I do not know if there is a solution” and will instantly say that there is no solution. I am in fact happier if the guy says that he does not know of an instant solution but will need to research”. A person who is ready to research is a person who can look at alternative solutions and is not “fixed” to only one solution.

And that is another very important quality I look for in a software professional – HUMILITY. Humility to say “I do not know, but let me look up and learn”. For that is what is most important in IT – not to know the solution but to be able to dig, research and find a solution. The knowledge out there is so vast that you need to be a seeker and not a know-all. That is where the real sharp people who think that they are the best can be serious failures. They may not have the humility to think that they may not know, and the vast field of IT can completely floor their ego.

Those are the best IT professionals who have the humility to say, “I probably don’t know some part of it, let me explore and find out”. It is the attitude which matters not the skills and knowledge. He who gives the right solutions may not always be the one who knows the best solution, but the one who has the attitude to find the right solution.

Ensuring Master Data Accuracy and Currency in Live Systems

Ensuring data accuracy is a major challenge even for technologically advanced corporates. There are two aspects to this problem:

  1. Data Inaccuracy due to errors of entry
  2. Data Inaccuracy due to lack of data currency – that is, data may have changed but the change is not reflected in your automated systems.

There was a company which bought a renowned ERP system and got the best consultants to implement it. One of the systems implemented was HRMS system. Huge investment was made in the software and hardware, in people, in training, and a team was created consisting of technical and functional experts. The last was something which never happened in this company which had significant automation through software developed in-house (including in-house developed HRMS which was now to be scrapped). Never in the history of the company did a team of functional experts from the department move out of the department to devote full time on in-house IT project, leave alone even have a namesake team of functional experts set aside within their department to assist in IT projects.

After several months of trials (again, a practice which was unheard of while implementing in-house systems), the consultant team left and after years of implementation, this company still did not even know the correct head count in the company. Of course, the culprit was not the software tool, but the people and processes around it.

Changes to the employee data happened in the company, like new recruitments, resignations, internal transfers, people movement, etc., and they were not being reflected correctly in the HRMS reports. Obviously, someone who was responsible for prompt entry of this data was not doing it. Department wise, team-wise headcounts, which were very critical for accurate reporting, never matched with reality. There were delays of upto 15 days for entry of a new hire into the system. After a massive effort, the process for new recruits was trimmed. But other changes in people status continued to be a problem.

The company tried a centralized service for all data capturing. Data from all sources was sent to a centralized team which entered into the ERP. This led to other serious problems and there was no improvement in the promptness and accuracy of capturing employee changes. Centralized data entry was like reliving the problems of decades old data entry practice which was in those days limited by technology. New technology later brought relief to some of these problems through distributed data entry. Whereas this company decided to go back to the age old centralized data entry and paid the price for it.

Let us analyze the problem. There can be primarily three issues in data capturing in this situation of centralized data entry:

  1. Data transcription errors
  2. Incompleteness of data – some fields missing such as codes
  3. Transaction not communicated at all – i.e., one change in employee which happened was never informed to HR

The data generally moves in the following way in this centralized data entry process:


There are transcription errors when data moves from one stage to another.

The solution in this case is based on two best practices or principles which I have defined.

  1. The data should be entered at source.
  2. The data entry process should be an integral part of the transition process so that the process cannot be completed unless the data is entered.

Let me explain these principles.

Enter data at Source

This says that if you want to improve data accuracy of your computerized system, you must ensure that the data is entered or captured where it originates, or at the place where it is first known, or by the person who makes the decision leading to the generation of that data to be entered.

If the data is not captured at source, it needs to be communicated to the persons entering the data. This is prone to errors of transcription, errors due to wrong coding, and also delays or omissions in communicating the change. This can lead to disastrous results.

The first two problems stated above (Data transcription errors and Incompleteness of data) can be minimized by moving data capture closer to the source, i.e., the decision maker:


Let us take the example of Employee team transfers as one type of employee transactions as the maximum volumes of transactions were on account of team transfers.  The IT folks should find out where and how the data originates. It was found that the Team Managers decide to transfer employees from one team to another for some business reasons as we shall see. Then the data capture should be done right there – by the team managers. The question is – do we make the Team managers enter data? No. The answer lies in the next best practice.

Making data capture an integral part of the transfer process

The third problem (Transaction not communicated at all ) cannot still be achieved merely by moving the data capture to source. The third can be eliminated only by making the data capture process an integral part of the transaction which needs to be captured. Now this is a little complex to do.

Let us take the example of team transfer transactions. The transfer should not happen unless the data capture is done. The trick is to make the data capture an integral part of the transfer process. By making it an integral part of the process, what I mean is that we need to provide such a tool which is essential for executing the transfer process and also captures the data. That is, the process cannot be completed unless the tool is used. To make the tool such integral part of the process which the decision maker does not skip to use in executing the transfer process, we must make the tool such that it helps the decision maker in the decision making process and in completing the process. You can hook the decision maker to the tool only if he finds it useful in his decision making itself. If the tool aids in decision making, the decision maker will certainly use it and data capture becomes a by-product of the process rather than an overhead.

To create such a tool, the systems analyst needs to dig deeper,which is what very few systems analysts do. Most of the analysts hear out what the user tells them and document the process without asking why and how they do what they do. The analyst needs to study how the decision is made, what data is required for decision making. He needs to see why the need to transfer arises and how it is executed. The team managers  need to transfer the team members on considerations like team performance and individual performance to balance team efficiencies. They may also need this on account of external factors like resignations, new joinees, and need to transfer some members to new businesses due to company growth. 

Having studied this, the analyst can provide a tool so that it aids him to do his duty and decision making by actually providing him all the data that he needs to make these decisions. For instance, the team leader needs to know individual and team performance, past history of employees, his skills, team resignations, etc. Can we create a tool where the team leader gets team members listed in buckets, and the team member can drag and drop names to reorganize the teams. He will have all the necessary information on fingertips that he needs to decide who should be transferred, and tools to do what if analysis to see what is the impact on team performance if team members are moved. At the end of his analysis, he will finalize the team structures and submit, and all the necessary transfers request are automatically posted into the HRMS system. It may go for approval and on approval update the corresponding employee data. There can be preferably a future effective date for transfers, so that the data is all ready and approved before the due date, and on the due date it gets automatically updated into the HRMS system. There can be no delays in data entry, no chances of any errors as the Team leader would have spent time analyzing and rechecking his decisions.

So the tricky job of making data capture an integral part of the process is achieved indirectly – not by forcing him to capture data, but by luring him to a tool which helps him to make decisions and without which he would not like to do the transfer. While making decisions, he has actually already entered the data, so there is no need of a separate data capture process which can be missed out.

What are the benefits in this process?

  1. As stated before, there can be no errors in transcription as there is no data communication and transcription.
  2. The chances of data not communicated or entered are completely eliminated as the team manager cannot perform the transfers unless he uses the new tool provided. In fact he now would not do the transfers without using the tool as it aids him in the decision making process and helps him optimize his transfers itself.

My Articles on Computers/ IT Management

Please see my articles on InfoTech Management at

%d bloggers like this: