Software Problems - When You Get Stuck

This post discusses the case study Software Is Not Like Making Shoes

Actually it is like making shoes. At least it should be. It is called software engineering, isn't it? And it is definitely not Research and Development. Managing R&D is an entirely different ball game.

If your design team is unable to progress, than 9/10 they are doing it wrong. In engineering, you use elimination method to detect what the problem is. Eliminate the issues that do not pertain to a problem and you have what requires to be addressed.

But more importantly, what is your role as a Project Manager in this situation?

1) It is necessary to set priority. Get involved in the team's effort. You may or may not be a technical person. But ensure that the team understands that you are as much into it as they are.

2) If you are involved in the team's effort, you will notice that their effort, at times, goes off in an tangent. Stop your team to go on their own voyage of discovery when there is a problem to be resolved.

3) Get the team to list the probable cause of errors - as they understand at that point in time. I like to have a white board on which the points are clearly written down. Once the points are listed, periodically - ideally early morning - sit with the team and address progress on those points. You may have to add points.

4) Ensure all members of the team do not address the same point. Use the white board to list responsibilities against each point.

5) Sometimes it is a good idea to stay with the team late into the night, if they are doing so. Apart from bonding, you will also notice how effectively they are working to solve the problem.

6) Realize that monotony and frustration can set in if a problem prolongs. Step in to give breaks as and when you see it happen.

7) Always, always, involve the customer. Hold regular teleconferences and send regular - daily, if agreed to - status reports.

Determining Responsibility

This post discusses the Case Study: Who Is Responsible

I would like to say 7/10 resignations are because of bad immediate boss. But I have no statistics to prove it. When dealing with any situation, seat of the pant estimates or feeling doesn't work. In any case I am not big believer of exit interviews. They are supposed to provide truthful information. The logic being the person who is leaving has no axe to grind and so hopefully will provide you with the true state of affairs in the company, from his/her point of view, in any case. However, there is another factor to be considered: unless the person who is leaving the company is absolutely agitated, s/he would like to leave the company in as pleasant manner as possible. So the first advise is that do not get over exited with what you hear at exit interviews. I am not saying what you hear at exit interviews is incorrect; only that it may not be the whole truth.

And in any case, why wait for the exit interviews to get information. It is necessary to establish processes in the company so that grievances could be aired by employees before it is too late. The HR performs a vital role here.

Coming back to the case study, before calling the Project Manager for discussion, there are a couple of quick checks I would do.

Who are the persons who are submitting their resignations?
How many years of experience do they have?
How recent is this phenomenon of resigning? Did this start fairly recently or has been happening for some time now?
What sort of skill set is going out of the company?
Are they easily replaceable?
Are these resignations really damaging your company?
Where did they stand in the

Next I would also talk to the employees who have not resigned. (This needs to be done keeping the Project Manager in confidence. Inform him that you will talk to some members of his team and that the summary will be shared.)

Why are they still with us?
What changes would they like to see?
What is the impact on them of such resignations?
In their opinion what could change. (Don't put words in their mouth).

I have just listed a few questions of the many you should be asking.

Now that you have enough data sit with your HR and PM to understand the data and come to conclusion. It is bad idea to confront your Project Manager. Always find solutions WITH him/her. Sift through the data to get information. The convert information into actionable steps. Since you and your PM are in a problem solving mode - together - chances are that the PM himself/herself will address his/her behavioural issues. If not, then emphasise the importance of short-term versus long-term goals of the company. Getting a project done on time is short term. Retaining skilled employees is vital for long term.

Finally share the information and actions with all other Project Managers and all employees. This is very important.

Now, what if shove comes to push. You may have to tell the PM to modify behaviour. That is perfectly fine. Provided you have enough data to put it across. Sitting on judgment based on one exit interview is not enough data.

Choose Between Two Corrects

Two members of your technical staff have submitted solutions that are totally different from each other's. Both have their merits. You need to make a decision to choose any one. Both members are hyper-sensitive and would demand a reason for rejecting their solution. But a choice you have to make. What criteria do you apply?

What do you do?

What do you do?