The roadblocks were many, but there was a particularly poignant one that was causing sleepless nights for Ramachandra Raghavendar. Years ago, as an offshore Project Manager of a Japanese project, the complete lack of trust from the client’s side appalled him. Language was the major barrier, and communication overheads were significantly increasing the cycle time.

Only detailed diagrammatic visual description of the question, realized Raghavendar, could elicit quick response from the other side, and that in effect would get the trust going. Since the project was a long way off from completion, he formulated a Boolean approach to get things going. He would frame his queries, and his understanding of the requirements with detailed visual descriptions; in a manner that it would require only a Yes or a No from the customer. It reduced the communication overheads, and helped carry the project forward.

Today, thanks to technology and the coming of age of various communication channels, such an approach is no longer required. The trust factor though is as, if not more important in the favorable execution of a project. Accordingly, Raghavendar, now Senior Project Manager, Tavant Technologies, leading projects on mortgage and financial documentation, pays maximum attention to notch up the trust quotient with customers. His pet formula: Decompose Project deliverables into sub deliverables – each sub deliverable producing a visible, measurable output and have early feedback from stakeholders.

“The approach also ensures that all stakeholders are on the same pitch,” he says. Feedback is used to gauge whether what the team is developing is in tune with the client’s requirements. Oftentimes, it is not an application, but a part of the code that is showcased to the client.

“For UI based Applications, one of the visible sub deliverables could be mock-up screens,” he says. Through the screens, the client is informed of the different paths the code could take from that point, and the possible results it could lead to.

In the case of large programs with globally distributed teams, Raghavendar deems it essential for all players to attend these periodic ‘integration meetings’. Typically, in such meetings, after the trust-building effort with the client is over, the component teams connect at a more fundamental level and walkthrough all parameters.

To elucidate their importance, he says, “A mortgage documentation project I was working on, for example, ran into integration challenges, since the team here had coded for the data to be fed in years, and another team had worked on the same to be fed in months.” Had there been a comprehensive run-through of integration parameters, these issues could have been detected upfront. The problem, nevertheless, was rectified in a short span, but the lessons have stayed with Raghavendar since.

“The experience taught me that while it’s important to break up a big project into various sub-parts for simplicity sake, it’s equally important to ensure seamless integration,” he recalls. The way to achieving such integration is a two-pronged approach that constitutes an appropriate team and a sound process.

The key to having a high-performing team, says Raghavendar, is to have a project manger who is conversant with the domain and the technologies involved. He cites an example from not so long back in his career to drive home the point. With the project well into the heavy-duty mode, the tech lead who reported directly to him resigned due to personal reasons. It had taken a good four months to find an apt replacement, and if Raghavendar, then the project in charge, hadn’t known the nitty-gritty of the Application, the project could’ve gone awry.

The experience, incidentally, also highlighted the importance of having the right back-ups in place—people who, in the event of their higher ups quitting, could take charge and steer the project at a micro level.

“It hardly takes a month to gauge the true potential of an Engineer,” he says. The informal interactions give a peek into the engineer’s personality, while the weekly reviews help get a perspective into his performance and abilities.
The review process, incidentally, is one of the strong traits of his management acumen, opines Raghavendar. Taking a cue from APJ Abdul Kalam’s Wings Of Fire where the latter talks about the review process he had put in place in his Space Projects, Raghavendar too has instituted a similar review procedure. “I’m more interested in what might go wrong, and setting that right, and a sound review process helps do just that,” he says.

AM in Team
A classic double blow situation is when a customer wants to change certain specs mid way through a project. It often requires working on the code right from scratch, as also discarding the earlier effort. Since this entire process causes a lot of burnout and frustration among the team-members, Raghavendar goes about educating his reportees, as and when they join him, of the inevitable practice of refurbishment. “That way they have already accepted, in principle, the possibility of reworking on the code,” he notes.

Despite this preparation though, there are times when the client might want the project delivered at a very short notice, and such situations call for ‘ready to go’ teams’. This calls for having conscious effort to raise the bar of the teams on a continuous basis. There are various ways to do this, says Raghavendar, but he swears by the army analogy: A soldier, irrespective of whether he is going for a war in the near future or not, practices regularly. There’s no way he might learn to shoot when in the battlefield. Similarly, engineers have to be battle ready; they can’t afford to learn while working on the project. Therein lies the importance of making them work on pilot projects, and various types at that, to sharpen their skills.

Another way in which he ensures that his team is ready to go is via the competency identification route. Each of the engineers under him are required to identify, within 6 months of joining, their area of core competency, and secondary competency; then they must keep themselves abreast with the latest developments in their niches. Once the competencies of each of the engineers are known, there is considerable ease in drawing up a team when a project comes.

Since a project, at times, might stretch on for several years, transcending various phases such as development and deployment Raghavendar rotates his engineers, keeping in mind their aspirations. Accordingly, somebody who wants to work only on development is moved to another project more suited to his interest once the former goes into the deployment mode.

Despite the rotational nature of the teams, Raghavendar believes in sharing successes with all the contributors. So even though over a year had passed since a team under him had worked on a project, when the same went into production at the end of 2005, he sent a mail to all who had been involved in it, congratulating them on their efforts. Some who had left the company by then actually wrote back to him expressing their delight!