A situation

Let us assume a scenario where the manager is not aware of the team member’s background and is not assigning appropriate work. This is causing some dissonance.

Facts:

* The manager is new in the team

* The team members are also new

* People have not had the chance to find out about the strengths of each other

* The manager has to get the things done quickly and correctly

The issue revolves around formation of a new team when the team members are not sure about each other and are all the while trying to gauge and judge each other's capability. Ideally, the manager should take time out to learn about his team members. In the real world of looming deadlines and burgeoning costs, the manager may be a little slow in reacting to people issues while trying to douse the fire in other areas of the project. May be the manager has some pre-conceived notions or assumptions in his mind about his team members. May be there is lack of time to plan the project properly. This may be the reason for assigning any type of work to the associate.

There seems to be an obvious lack of communication between both of them. The simple way to go about this is by having an open discussion with the manager and setting proper expectation. It is not only a person as a manager who sets expectations for team members, but the associate also should be setting expectation for his manager. 

My suggestion would be first to keep doing the work whatever is being assigned so that the project does not get impacted. If there is a concern on the skill of the associate, he should discuss it with the manager and give him alternatives such as asking for more time for deliverables or sharing the work with someone who has the knowledge and skills. The team member should clearly tell the manager that he is not enjoying the kind of work that is given but would still be willing to do the same for the sake of the project. This would help the manager gain some confidence on the team member and then the team member should try to project his skills and strengths and his area of liking on which he wants to work. The team member should tell the manager how much he would like to be part of the new project and how he can add value over there. Giving a couple of suggestions and ideas will show the manager the team member’s interest in the project and may be he will think of putting the team member in the project.

I think open communication and expectation setting is the key here.

While at offshore, when the team member is reporting to his own manager, an open discussion is easy. The same may not be possible when reporting to a manager from the client. In this scenario, the team member should take his offshore manager into confidence and tell his pain areas to him and also tell how he plans to approach the client manager. After taking the buy-in from the offshore manager, he should proceed to talk to the client manager.

An individual’s quality of deliverables are important in letting the manager know how dedicated you are to the project. But unless someone tells where his interests are, another person will never know.

How to handle client complaints

This is a good thing I learnt from a colleague. It is how to handle client complaints. This is known as the LEARN model – Listen, Empathize, Apologize, React, Notify. Whenever a client complains on any issue, one needs to listen to the same patiently. Then one needs to empathize with the client and apologize for the inconvenience caused. The complain may or may not be a real cause for worry. There may or may not be a real issue out there. But because of the fact that the client has complained, one needs to apologize. Then one needs to come back and analyze what has to be done. This is the react part. Once the action is taken, one has to notify the client on what action has been taken.

Difficult client?

We all have heard expressions like a difficult client, tough client etc. What does the term actually mean? I see lot of discussion going on around this. Here is my understanding of the same:

Any client is one who is very demanding in terms of quality of work and very stringent on the cost part and very rigid on the deadlines and who is not willing to give any leeway on any matter can be termed as a difficult client. It will be difficult to keep such client happy. Typically, such client may not be willing consider factual evidence and keep unreasonable expectation from the vendor. Normally, the client will raise a big hue and cry for something that goes wrong in the project. A demanding client asks for good quality at his own price while sticking to pre-defined schedule. When a demanding client is not willing to listen or negotiate, he becomes a difficult client.

The way to deal with such client is to set proper expectation with them. More than technical skills, it is the people skills which help us handle difficult clients.

The GQM Method

This is again another find from Google. I learnt about the GQM – Goal Question Metric method. This is a method to identify metrics for a process/system/organization. The idea is to start with what is the Goal of the process and then ask questions related to how to know if the goal is achieved. From these questions, one needs to drill down to the metrics. This is a top down approach to software measurement. There is a lot of material on the GQM available on the internet. This simple thing has also been elevated to the status of another management tool like Six Sigma or a TQM with rigorous prescriptive steps and different process phases, project plan, etc which do no more than put off a practitioner like me. Anyway, if you need more details on the GQM method, it can be found here and here.

More thoughts on development metrics

Each of the phase of software development has some deliverables and invariably all of the deliverables undergo reviews. They may be a walkthrough in which a group runs through the document or may be one-on-one review done by an experiences team member or a tech expert. All of our development and testing projects have the reviews built into their schedule. The review comments are logged and acted upon. So a review efficiency metrics should be easily be created. These are called differently in different organizations. Sometimes they are called phase yield. Sometimes phase review efficiency. But the gist of all of them is mostly the same, i.e. to see how good was the work product and how efficient was the review. This is used to figure out metrics such as review efficiency or PCE - Phase Containment Efficiency!

I have seen some project teams meticulously maintaining the review logs. And then there have been some teams which do not maintain these logs and manage to get away with it. Also for teams which do maintain the review logs, do they need to log each and every minor comment into the log? Sometimes, the reviewers ask questions to know more details about the design. Will that qualify as a review comment? Moreover, when the there are to and fro comments from the author and reviewer on the same topic, do we need to track each of the comments as separate review remarks or club them under a single remark. These are the practical difficulties which come up while implementing the review log system. But more complex is the scenario, which I have seen in my experience, is that, when there are multiple reviewers (who belong to the client’s department), and some of them are very thorough and give a sea of comments and some are very superficial and give very few review comments, if we use the no of review comments as a leading metric for gauging the quality of work product, it may not portray the correct picture!