Good Bye...Good Wishes

This post is the last post for the time being. It may be the last post ever. I do not know. I may even start to post in this series again. I would like to thank you for visiting this page and wish you all the best, always and ever !

Project Managers with BPO service provider

I have really no idea of what exactly a PM in a BPO or KPO would be doing. Whatever I write here is pure speculation and some intelligent guess work. I think, a PM with a BPO would be a team manager who has margin, delivery as well as people responsibilities. The technical aspect would be quite less. The focus would be on processes. Thus, in a scale of 1 to 10 in the following parameters: Technical Knowledge, Process orientation, Team management, Cost management and Project management, the typical PM in a BPO would have the following ratings:

Technical Knowledge:    3

Process Orientation:    8

Team management:        8

Cost management:        8

Project management:     8

This concludes the series of the posts on different types of Project Managers.

Project Managers with IT product development

The PMs with product development companies would have mostly similar skill sets as the ones in IT service providers. But I think there are some slight differences. The differences would be in the fact that though the IT product development PMs work as per a budget, they are not margin driven. So, though they would be bothered about the cost of the project, they would not be fanatical about the margin. Infact, they would not care so much for the financial metrics of a margin. They would however be fanatical about the quality of work and deadlines as with PMs in other organizations. The difference would also come from the type of the organization for which the product development is happening. For example, in companies like Microsoft, I guess, the products are very huge and it calls for high specializations among the roles. Here the project managers are mostly called Program manager (specific to Microsoft) and their role is mostly coordination and facilitation. However, in smaller product development startup, the project manager may be required to do technical review and face the customers as well.

Thus, in a scale of 1 to 10 in the following parameters: Technical Knowledge, Process orientation, Team management, Cost management and Project management, the typical PM in an IT product set-up would have the following ratings:

Technical Knowledge: 7

Process Orientation: 7

Team management: 8 

Cost management: 6 

Project management: 8

Project Managers with IT service provider - Part II

People related responsibilities include building and nurturing the team, looking into individual career and growth issues and knowledge building and retention. This is one aspect which is absent for a project manager in an end user organization where s/he may be working purely as a vendor manager. Working with a fairly large team reporting into you also calls for a person who has good people skills and knows internal team dynamics.

Delivery related responsibilities include planning and executing the project such that execution happens seamlessly the delivery is smooth. May be some other time I will post a bog on this alone.

Margin related responsibilities include containing the cost of the project for which the project manager should be aware of the cost being incurred and be vigilant enough to identify and bill change requests for any out of scope work that is to be done. This is very critical in fixed bid projects. IT service provider companies are very finicky about costs and idle time. Idle time is watched for like a hawk and no one wants a non-billable resource in their team.

The PM also has to interact with the various other departments in his company like the staffing or sourcing or HR team as it may be called, so as to get resources for his project when required. The PM has to interact with finance team to raise invoice for the work delivered and has to track the payment of the same. These responsibilities may not be there in all companies and may sometimes be shared with the supervisor of the project manager (called the delivery manager).

So, the PM has to be a facilitator and motivator, and a very good leader so that s/he can lead the team members with clarity. 

Thus, in a scale of 1 to 10 in the following parameters: Technical Knowledge, Process orientation, Team management, Cost management and Project management, the typical PM in an IT service set-up would have the following ratings:

Technical Knowledge:    5

Process Orientation:    8

Team management:        8

Cost management:        8

Project management:     8

Project Managers with IT service provider

The project managers with IT service providers are again a different lot. They mostly are home grown in the company, coming up the ranks of the programmers, team leads, project leads and then become the project manager. They typically lead the project teams and are responsible and accountable for the delivery of the project. Apart from this, they may or may not be responsible for the technical architecture (some companies are very strict on this that the project manager has to be technically competent) and for the requirements part. So we see a lot of overlap between a tech architect and a Business analyst role with that of a Pm for a smaller project. For larger projects, the roles may be distinctly different. My personal opinion is that for a project manager in an IT services company, technology is not as important as the process. Therefore, the must-have skill for a PM here would be very good process knowledge and drive for processes and getting things done in general.

Apart from the process and technical side of the delivery, the most of project managers with IT service providers have two other basic responsibilities:

a)                People related

b)                Delivery related

c)                Margin related

Project Manager in an end user organization

Organizations like Citibank, GE Money etc which have IT as a support and enabling function typically have an IT department which employs project managers to execute projects. Most of these organizations follow 2 different models to their IT development approach with some variations to it. The first model is to have in-house development teams lead by project managers. The second approach is to outsource the technical stuff to a vendor which is managed by the project manager. Many organizations also follow a hybrid approach where in they have an in-house IT development shop and also do some out-sourcing.

In most end user organization, the IT project manager is the person responsible mostly for delivery of the project. There is usually a business project manager who controls the purse strings, since all projects are typically initiated by the business and the business funds the project. Typically, once the requirements are finalized by the business, the PM is asked for an effort estimate and schedule. The PM coordinates with the development teams (if in house development exists) or with outsourcing vendors for the effort estimate. When this comes out, the cost for the project is calculated and the budget is decided and approved. Then depending on the IT development model followed by the organization, either the work is done in-house or outsourced.

For an in house development model, mostly the development team reports to the PM for project related issues. The PM acts as the facilitator and motivator for the team, helping the team achieve the project goals within the desired budget. But for an outsourced model, the PM acts as a vendor manager and is mostly required to facilitate the outsourcing company complete the project. But in the second model, most of the delivery risk is assumed by the outsourcing company and the IT PM usually chases up and beats the vendor to complete the work!

In either cases, IT PMs in end user organizations interface with all the different departmental stakeholders for planning and execution of the project. The most important focus of the IT PM is to complete the project in time and under the given budget. Typical IT PMs in end user organizations that prefer outsourcing the development do not have to deal with the human resource angle, profit margins, knowledge sharing and associate growth aspirations. The in-house development center PM has to deal with all the above except worrying about profit margins as IT department is usually treated as a cost center rather than a profit center. IT PM have to grapple with Scope, Effort-Cost & Budget, Project Risks, Infrastructure and most important of all, the Deadline.

Thus, in a scale of 1 to 10 in the following parameters: Technical Knowledge, Process orientation, Team management, Cost management and Project management, the typical PM in an end user set-up would have the following ratings:

Technical Knowledge:    3

Process Orientation:    5

Team management:        5

Cost management:        8

Project management:     8

Types of project managers

The field of project management is very vast. It is applicable to building tunnels, dams, temples, forts to nuclear submarines, power plants, petrochemical complexes to clinical drug trials, molecular research, nanotechnology research, semiconductors etc. Even within the realm of software there can be various types of project managers according to the domain and the organization. Role of a project manager in the IT department of a end user organization (like a bank or a retail chain) is different from a project manager in a IT services company which is different from a IT product development company and is different from that in a BPO/Transition services company. In the subsequent blogs, I will try to put in my thoughts and ideas on this subject.

Innovation at ground level

Continuing on the theme of innovation in the field of software services, we need to understand that the “service” part of the software service industry is the one which would differentiate one organization from another. A software service company can choose to provide a wide variety of services in all possible domain or remain a niche player in one field only. However, the innovative firm will choose to provide its services differently. Innovation in software services has mostly  been on processes and deal oriented. These are structured at a very high level. They dictate how the workers would go about doing their work and how the finances would be structured. IMHO, the junior employee manning the keyboard does not have much say in that. But now there is need to bring innovative solutions to touch each customer/client. This will come only if the lowest level employees, who interact with clients on day-to-day basis are empowered to take decisions, big or small. What is required is to create an unique customer experience which will stay in the mind of the customer, long after the service is done

Software products from India

Some people are of the opinion that we do not have any good, world-class, commonly used software product (like MS Word, Excel, Powerpoint, Autocad) created out of India. I agree to this completely. But then apart from the US, which other country can boast of many commonly used software products? I think only a handful. And that is because, most of the products are standards driven and all standards come out from the US. The US universities do a lot of technical research and create standards. This means that they are the ones who dictate how some new technology is going to work. India has a lot of engineers. But they are not researchers. They do not create new standards. Rather, they study the standards and create software as per the standards. Manpower is our strength. Unless we develop good research facilities which come up with new technologies and standards, it is very difficult to get into the product space.

Yet, some of the Indian companies have developed application oriented products. Case in point I-Flex which has FlexCube product for the banks. Infosys has Finnacle and Polaris has the Intellect product. There are some products in the ERP and CRM domains also. But these are not commonly used products. These are used only by a select few customers. So the product potential of Indian companies is not widely known yet.

But why this question is asked only relative to the software sector in India? Which other consumer product was invented in India? Was an automobile invented in India? Was a washing machine invented in India or a microwave oven for that matter? No. Today we are capable to manufacture consumer products but none to my knowledge has been invented in India. And most of these inventions came from the US again. This is because they had pumped in money and effort into such research long back and started working on them. Indians have never been big inventors. But we have been very resourceful! So, we pioneered the usage of washing machine for making lassi (example of Indian “Jugaad”).

Innovation in Software Services

There is a lot of noise everywhere on innovation. Even I have jumped into the bandwagon and have been trying my bit to innovate. Most people would agree that if one needs to remain competitive, one needs to innovate. As a person, one needs to do things innovatively, as a team one needs to find ways to work innovatively or design innovative solutions and products and as an organization, it has to have innovative processes. The USA has been the masters or innovation. Tons of patents are filed by the US companies every year. Among Asian countries, China and South Korea have also taken to being innovative and are increasingly filing patents. But in contrast, Indian companies seem to lack a bit in this area. We do not file as many patents every year. This may be going up, but we still fall far behind in this. However, I was pretty surprised to know that Infosys had filed some 60 odd patents till 2007. Tried to do some research on the net but could not gather much information on that. There was some mention of a mobile banking solution which was patented and some patents jointly with their customers. But I guess most of the work would be on process innovation. And with the way Infosys has been growing for the past 3 years in terms of man power, they should patent their hiring process!

But I think, Indian companies are making up for innovation by being resourceful. The Indian concept of “Jugaad”. This comes up while replicating processes and defining new processes. Though you may accuse me of generalizing things, the Indian mind always tries to do the work in the shortest possible way. Hence you can count on us in finding new short-cuts for everything. Everything can be done in this way. But what needs to be seen is how far this resourcefulness can propel the Indian companies in the global arena.

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!

Productivity metrics for development team

We have been thinking of some number based targets for our development team. The idea is to show productivity gains to the client over a period of time. Though there needs to be a lot of thought and brain hacking which has to done before we come up with these kinds of metrics, at present, only 2 metrics come to my mind right away.

We can have a quality metric which can be something like an average no of SIT defects attributed to code/design per total number of SIT test cases. Since we have already collected these data over the past 2 years, over many projects executed under the program, we have some idea of this figure and what we can target to achieve in the future. 

The other obvious metrics which can be given as a target is the defect turnaround time. This figure also is available for the past data and we can give a target value for the development leads for this metrics. But when I think hard, this metric is not fool proof. For example, we can track the total defect closure time from the time a defect was opened till it was finally closed. But the time spent in the various state of the defect in between those 2 end states are not tracked. And who should be responsible for it.  If the development team fixes a defect but testing team just sits on it and whiles away time before retesting it, it will look bad on the development team numbers.

Another fact is that both these metrics are lag indicator of the project quality. Neither is a lead indicator. Ideally, I would like to have some lead indicators which can be used to take preventive/ in course corrective actions.

Estimate Quality Metrics

While doing some Google search on metrics, I have stumbled upon a metrics called Estimate Quality Factor, also known as EQF. Now, as a first guess, I thought that this might have something to do with the confidence on the estimate. I was partly right. Though I was thinking in terms of the effort and how confident was one on the effort, the EQF actually is on the delivery date, i.e. the schedule. It is a really simple idea. One needs to plot the estimated end date for any phase of delivery against the calendar date. For instance, if you estimate that the Tech Spec phase of a project will be completed by say 20^th May, you plot 20^th May in the y-axis with today’s date on x-axis. Similarly, whenever the estimated delivery date changes due to any factor, the next estimated end date is plotted. If there are no changes also, one can just plot the estimated end date with respect to the calendar date on a weekly basis. For example, say next week, we estimate that the Tech Specs will be completed by say 23^rd May. So, we plot that. The idea is to see if all the dates plotted form a kind of straight line parallel to x-axis, which will signify that the deviation from planned delivery date is not much. The more there are ups and downs in the delivery date, means that the EQF was not good. I think that the EQF can also be plotted for the effort estimate also. And an effort estimate with a high confidence will have a line parallel to the x-axis.

If estimates keep changing too often, which is the case mostly, the line will never be parallel to the x-axis. Again, only if there is a process of estimation built into the development process and the estimates are recorded somewhere, pulling out this data on a weekly basis should not be much of a challenge.

Now coming to the part where I need to decide if this metric will be of use to any one? I am sure that we will not be able to get a parallel line to x-axis in real life projects since almost all the projects will have change requests coming up in the course of the project, which will change the estimate effort and may be the end dates also. Only in a scenario where there are no change requests, we can probably use this metric to prove the quality of estimates.

Instead of doing all these stuff, a simple metric like the effort variance should be able to tell me how good the estimate was.

Thoughts on measuring productivity

Now that we need to raise the bar, how do we do it? We really need to show some improvement in our process and pass the benefits back to the customer. This thing was there for sometime in my mind on how we actually measure the productivity of the project team and then benchmark it and try to improve further upon that. Now I need to qualify that my project teams consists of development and testing teams. We know that there are some metrics like test case executed per hour which can be used as a testing team productivity metric. Agree though that all of them are not without bias. For instance, some test cases may be very simple and straight forward to test which means more of similar types can be executed in a period of time while some may be pretty complicated ones, requiring specific scenarios to be created and data to be available to test, which in turn will take longer time to set-up and test. But when we are talking about a testing team’s productivity, we can assume that there will be both types of cases and finally at the end of the project we come up with an average test execution productivity figure. Comparing the same across various projects tested over a period of time will give us a fair indication of how the testing team is performing. With a defect tracking and time tracking mechanism that we have in place, we are now able to pull out these figures from those systems and are now working on the benchmarking part for testing teams.

But now the difficult part that I have been grappling with. How do we measure the development team’s productivity? One measure of this may be LOC. But this is not a unbiased one and in maintenance and enhancement type of projects, this actually doesnot mean much, coz most of the development time is spent in analyzing and modifying the existing code, rather than creating new programs. Also, the defect fixing turnaround time can be a measure, but this will be only for the SIT support phase. I am still to figure out some productivity metric for developers for the Analysis phase, Design Phase and Coding phase.

Raising the bar

As part of my regular job, I keep interacting with our clients. I have been fortunate enough to work closely with some people from the client organization and learn how they think an IT service provider should work. In the engagement that we are in, we have pretty established processes for most of the things and the delivery record has by far been quite impressive. However, the manager from the clients’ side feels that apart from consistent delivery, the vendor should also do something more. So, the other day, I asked what more can we do to keep them happy. He asked me what kind of investment you are making in the engagement. This set me thinking. We have in fact not done any worthwhile investment apart from seeing to it that the engagement runs smoothly. He was in a way correct. There can be various kinds of investments to get a better ROI from the engagement. For example, we could provide them a consultant from say our Delivery Quality Assurance wing, who can study our processes and propose improvement. The consultant can even study their processes and give recommendations. 

It is the value we bring to the table which matters. When the client was not happy with their earlier vendor, they came to us and we have proved them our mettle with our fine delivery mechanism and technical thoroughness. After 2 years into the engagement, the client has now got used to the fact that deliveries will be smooth. So now the bar has to be raised.

Quantifying value add by a PM

I was discussing the issue of value addition with my delivery manager. My point was while someone is managing a project, his / her main objective is to successfully complete the project with the minimum amount of issues. So at the end of the day, if one asks the PM, what is the value you have added to the project, the PM can say that I did this and I did that to mitigate this or that risk, I handled this situation in this way and finally the project was completed with minimum issues. But then, can the same be quantified? To this, my delivery manager asked me, what the biggest risk in any project is. As per him, the biggest risk is in loosing the customer, loosing the revenue stream that is established. So if you do anything that will keep the revenue stream intact and keep growing it, that is the value add. Everyone’s contribution may or may not be measurable in dollar terms. Sometimes, what the client pays can be considered to be a measure of the value add; but them it is a great leveler. The client doesnot pay as per individual ability or value add. It is a negotiated amount for a minimum general set of abilities. Even if you do a value add, the client doesnot pay you extra. So, it is very difficult to put a dollar value to it. I agreed to it. Also, another point is that the client appreciates someone when that person really contributes. And though a PM may be handling a team, he can many times act as an individual contributor and add value. Also, in the overall sense, if the team delivers the project successfully, the PM gets his / her share of appreciation. However, this cannot again be quantified. May be some one should come up with a frame work for the value add done by a PM.