Attitude versus Knowledge

In one of my discussion with a project lead, we were debating which is the most important attribute of a team member. The project lead, who was very much bogged down with the knowledge level of the team members was rooting to the fact that knowledge is most important factor when choosing a team member. I begged to differ. My point was that knowledge can be acquired by a person with the right attitude, but a person with requisite knowledge but lacking in attitude can be a nightmare for any project. If a person has the attitude to learn, to work hard and takes his job seriously, he can compensate for the lack of knowledge in the short run, and on account of his being a learner, will be able to catch up the knowledge in the medium run. Of course, the project duration is also a very important factor in this. For shorter duration projects, which are less than 3 months, the team member has to be knowledgeable so that he can hit the ground running. There is no room for anyone to learn in short duration projects. But for longer duration projects, I would rather choose people with the right attitude and train and build their knowledge. This way, the team member also does some value add to his own skillset and the project also benefits.

Project Beginning and Project end

I have observed in many of the projects that there is a lot of management focus while the project begins. But as the project comes towards the end, slowly the focus of the management drifts to other issues and other high priority projects at that point of time.  The highly skilled resources and dynamic project leads are slowly pulled out because of their requirement in other projects which necessitates the second in command to step up into the higher role. There are two sides to this.

For the second in command guy who takes over, there is an opportunity to showcase his skills. Thus he gets the benefit of leading a team. And in the way, the management also discovers some budding talent. But this approach may also lead to disastrous situations if the second in command is not capable enough. Though there is a school of thought that, there should be continuous management support and attention for a project from beginning till end, real work and business life priorities necessitates to make such changes and we have to learn to live with the change!

Celebrating at end of Project

“All work and no play makes John a dull boy”

There should be some kind of celebrations at the end of a project and if it is a large project, then probably at each milestone reached.

I have found team outings/celebrations, apart from creating a sense of feel-good factor among the team members, also help in team bonding. People get to know each other better in an informal non-work related setting. We have had scenarios where given a choice, the team members consider these as part of the hygiene factors to decide whether to be in a team or not. They compare how often their own team has these good times vis-a-vis other teams.

In one of my project which was a maintenance and support type of work, there was no end at all. The project always kept on going.  One request closed, 2 more were open. People never had a break. There was no end. Also you cannot be partying at every request that is closed. Other teams which were involved in regular development work, they used to have the ending rituals as their end was very well defined.  We decided that in order to overcome the issue of not having any ending, we will have parties or outings every two months. This helped in keeping the team morale high and everyone happy.

Another reason to have these informal lunch party/outings is that it is a good way to gather feedback about the project as well as feedback on a personal level also. Everyone benefits!

Perception Management

I had a manager who used to say, “Perceptions are reality unless you change it”. He used to say that if someone perceives you as a poor programmer, even though you yourself might not think so, you remain a poor programmer, unless you proactively do something to change the other person’s perception. And this is not limited only to perceptions regarding people. It is also true for projects!

We had a peculiar situation in one of our projects. The project was running its normal course and as usual towards the end of the project, there were a few loose strings to be tied up here and there. However, that simple issue had somehow got ballooned up in the mind of the client and created the perception that there is a crisis. Escalations were done and after of lot of management attention, everyone realized that it was a non-issue! It was just that the perception of the client was different from what was the ground reality. And the ground reality was that the project was scheduled to meet the target date.

Hence, apart from client expectations management, we need to manage the perceptions of the client also. This will save a lot of time and effort in firefighting for an imaginary fire and convincing the client!

Quality of Human Resources in a Project

Sometime back, I read a blog stating that everything that goes wrong in a project can be traced to a commitment made by someone at some point of time. This is quite true. Let me share one experience with you.

In one of my previous projects, we found that the quality of resources that we are getting to staff the project was of very bad quality. Some resources were taken on board without having in depth technical know-how. This was not very apparent in the initial days of the project. But as the project progressed, there were certain team members whose efficiency was questioned. The project seemed like moving towards failure. Top management stepped in and tried to augment the resources. Experts were called in. After months of late nights and mail fights, somehow the project was completed.

Now, it was time for introspection for what went wrong and what went right. Though people were groping in dark to figure out what went right, everyone was sure of what went wrong – Not having the right people. It was written down and notes circulated and presentations made. The blame game continued. People were crying for the throat of the HR team which had staffed the project. Some were saying that the quality of input deteriorated because the screening was not good. All guns were pointed to the HR folks and their processes. But the trace back does not end here.

The question is why did the project staffing folks get such guys in the project? This can be traced to the discussion which happened between the project manager’s boss and the HR manager. The organization had got a huge project and the manager wanted to complete it within a specific time. The sales folk had committed that they can do it. They had revenue targets to meet. No one really focused if the organization had the required number of resources with correct skills. With the deal sealed and contract signed, the delivery date was fixed. Now a mad scramble begun for resourcing. Rapid action teams went out to scout for talent. They had their targets to meet. So they got whoever knew how to spell the language and asked them to work on the project… and the project was doomed for you know what…