IT Project Manager -- the personality?

In this essay, I attempt to enumerate the qualities that are needed in an IT project manager.

1. A person who asks Q, and keeps asking until he is satisfied.
The most important aspect of the project manager is his insatiable appetite to seek "correct and complete" As to his Qs. Further, the PM should know when he is not satisfied with the As. In that case, he should either put him Q differently, or put his Q to a different (and maybe more-appropriate) person.

2. A person who tells the answers to all stakeholders -- programmers, testers, designers, marketers, customer support engineers, etc.
It is quite natural that the PM thinks that he has all the Qs, and the "correct and complete" As to those Qs. But this may be a myth. And hence, it is important for him to share the Qs, As, and source of those As, to all stakeholders of the project. The PM should give equal importance to everyone contributing to the project, be it a programmer, a tester, or a user-manual writer, or anyone else. This gives everyone a sense of ownership to the project, and may take one's productivity and commitment to an altogether high level.

3. A person who trusts people (by default) and is trustworthy.
A project manager is a leader. He is the CEO of the project, and his ultimate goal is to make the project, and everyone that contributes to the project, as successful as possible. This may happen only when the stakeholders trust him, and he trust them in return. He should be genuinely interested in the success of all, and should resolutely believe that everyone is putting one's best effort for the success of the project.

4. A person who is honest -- if he does not know the A to a Q, he says so; asks for help.
Most often, I find people giving airy-fair As to Qs that they don't understand, lest know the As. A project manager needs to be honest to his ignorance, and acknowledge the same, thereby helping himself to know more. He needs to be wise enough to realize that by acknowledging his mistakes and his ignorance, he will enable himself to learn.

5. A person who is confident, yet doubtful.
He should confident about himself, the project, and his team. But, at the same time, he should be skeptical of the success of the project, about the application of Murphy's Law. The skepticism will help him stay on his toes, and watch out for any impediment.

6. A person who does not "assume" things.
Enough of what personality traits a PM should have, now let's talk about traits that a PM should not have. It is important for a PM not to assume anything, just anything, be it the role that a resource plays in the project, be it the success-criteria, or be it envisaging that everything may go wrong. It is important for him to ask Qs from his people, and ensure that no one is making any assumption either.

IT Project Management -- the vital Qs:

1. What to do? -- what is it that we are trying to achieve? Most often, IT projects are done not to solve a problem. In stead, most often the objective may be to improve the state of affairs, improve productivity, reduce the number of errors, organize the work better to increase throughput and decrease response time, etc. (That makes me wonder my most companies look to hire problem-solvers. My pennyworth - hire engineers that may identify problems.)

2. Who benefits and how? -- once all stakeholders understand what is to be done, the next important (though obvious) Q is to ask for justification of why to do the project. In other words, who are the beneficiaries. This Q is tightly-coupled with the funding requirements of the project. At the end, all is business; the project is done to make more money, and the project costs money. It is important for everyone involved in the project to understand who is the sponsor for the project, and to know how the project will benefit the beneficiaries.

A project has 3 needs; customer, business, and technology. A project manager has to look at meeting all the 3 needs from the project. A project that does not meet all the 3 needs has not been dealt properly, and needs a re-look.

Once we know the beneficiary, the next task should be to find out what does the beneficiary do to be benefitted from the project. It is important for everyone to understand the business of the beneficiaries so as to offer the best value in the project.

3. Who pays, and how much? -- I guess programmers and testers may not be interested in the answer to this Q, but, nonetheless, they should be aware of the importance of this Q.

The project manager is the person who should ask this Q, and understand the answer in depth. The answer to this Q will determine the schedule, the resources, etc. More importantly, the answer will be cardinal when a schedule-slippage happens :-).

4. Does the project fit? -- As earlier stated, there are 3 perspective of a software product; the business, the customer, and the technology. Just because we have a customer ready to pay for work does not mean that we should do that work. We have a bigger responsibility than just making money. For instance, a company that is numero uno if telecom software segment should not develop an investment banking software just because there is a customer ready to pay. This is because this project does not fall in the vision of the company. The disadvantages of doing this project will likely outweigh the advantages.

Similarly, consider a customer approaches this telecom s/w company and asks it to create functionality spec of some Perl scripts that run on some telecom s/w stack. Although this line-of-business is met here, but doing this project does not help the technology needs of the company.

Consider the third case now. There is a customer that is ready to pay for a customized enhancement to a product. The project manager needs to understand that the vision of the company is to create products, and not start producing customized releases that fit just one or two customers. Here, the business perspective is not being met.

A plausible problem with the technology-savvy people is that they believe that technology is only for the good. Right? Wrong. Technology may be bad, if we are blind-folded to ignore its side-effects. Just because someone has a high-tech does not mean that this idea makes business sense. Similarly, just because the CEO wants to introduce a new product does not mean that the product should be introduced. See, we are talking business here, and it is OK for people to be emotional, and follow their egos. But at the end, there has to be a business justification of everything that is done. And for this to happen, we have a team of people who challenge and reason each other's thoughts and actions.

The bottom line is that the project manager should see overall rationale behind doing the work, and he is responsible for ensuring that the project meets all 3 needs.

If it's simple, it ain't necessarily easy.

I hit this statement while reading a book, and it rightly left an impression, not because of the choice of words, but because it reveals a misconception. Most of us aren't impressed if they are told that the work at hand is simple. They perceive that if something is simple, it has to be easy. Right? Wrong!

A task by itself is neither easy nor difficult. But yes, it may be simple. And that is defined by the perception. The Indian cricket team winning the world-cup is a simple task, but definitely not easy (bet?). And then this effort is simple from the perspective of the fans in India, but definitely not from the perspective of the guys who play on the field.

If we are told that something is simple, we should quickly set our perspective correctly. And then realize that the task is simple from the perspective of the person saying, not necessarily from ours. Further, if the task is simple, it need not necessarily be easy. It may be difficult to implement, but simple to comprehend :-).

Happy Simplifying!

Failure Stories:

A while back, I browsed through the web-site of a leading IT company, and found a bold-faced column titled "Success Stories", and that made my reflect on why there was not any mention of "Failure Stories". Ahem, and that makes me think that publishing a company's failure-stories may be a very sell able marketing gimmick. However, the necessary and sufficient criterion is that the company should be successful. It is human nature to appreciate failures of hitherto successful people, and the logic is simple: a person learns from his failures, and eventually succeeds. If a person continues to be a failure, it is assumed that he hasn't learned from his failures, and hence his failures have no importance. Man, who says failures don't sell?!

The motivation behind my typing this essay is to make my dear reader realize that most (if not all) corporates do not inspire failures. Now, by failures, I definitely am not alluding to project failures. The idea is to tell employee to think, try out new things, implement their ideas, and if in the process, they fail, then it is all fair.

I think each one of us is capable of creating new stuff, generating new ideas, but most often, we do not take our ideas to the next level of sharing them with people and implementing them into prototypes. Most often, it is because of lack of confidence we have in ourselves. The project managers need to play a role here. We all should be told that failure is just not a bad word, it is good, at least it tells you that someone did something, but didn't get what he set out for. There is nothing called "failure", it is all perspective. If you change the perspective, the failed work became a success by teaching the person what next.

Happy Failing!

Why & How:

These two words define the intellectual level we have, and wish to have. For an improved intellectual quotient in our lives, we need to use these two golden words more often.

I have heard many times seniors motivating us by asking us to ask "good" questions. Who defines which Q is good and which is bad? The important point that most people miss is to motivate people to ask Qs, and not bother about whether a Q is good or bad, whether it is worth being asked or not. However, it becomes the responsibility of the questioner to ensure that he asks the Q at the right forum, more so if he really wants to get the answer, and I am sure most of the genuine questioners want answers to their Qs.

Now, let's look deeper into the significance and difference between these two words. The "How" Q makes us question how a particular thing happens in the world, and thereby takes us to the first step of cognitive power. The "Why" Q makes us question the existing way of doing something. A lesson that I learned long back is to question why something should be done the way it is told to be done. Questions are particularly important when it comes to business, devising new ways of doing business, and not sticking with the tried-and-tested ways. I do not mean that what is established is wrong, but the point is that there may be a better way to do the same thing, a more efficient and effective way. In order to find that way, we need to cultivate the habit of asking Qs, and seeking answers.

Once we inculcate the habit of asking Qs, the next step is (indeed) to ask "good" Qs; Qs that make the listener think about the answer, questions that take us to the next level of cognitive power. We learn this trait by hit-and-trial, by asking more and more Qs, and understanding the basics of effective communication in the process.

Happy Questioning!

Make Mistakes:

Before you read the essay, I request you to reflect on the title "Make Mistakes." I have carefully chosen the title so that it explains the gist of what I wish to enlighten. I will share a part of my life in the last 10 months to bring you to the lesson learned.

I married arguably the best woman in this world in july 2006. At that time, I had the comfort of my own home, a very well-settled life, and a well-paid and appreciated job. After two months into the matrimonial life, I decided to experiment with my career, and therefore my life.

I left my dream-employer Cadence/India to join Barclays Capital/Singapore. I was happy with Cadence, but after 3 years with Cadence, I was realizing some degree of complacency. And I thought that that was the time when I needed to "do something" with my career.

About 8 months in Barclays Capital and Singapore, my career and our (my and my wife's) lives have not shaped up as per our expectations. Not that they have been bad, but they haven't been great either. The silver lining in these 8 months has been some revelations. In retrospection, I don't think I made a mistake per se, primarily because such complex decisions of life are never mistakes.

Now, I will take you to the lesson.

I have resolutely believed in "doing" things, in "taking decisions" in life. Even not taking a decision in life is a decision in itself, and trust me, that is the worst decision. When we don't decide on our lives, someone else or something else does, and that may not be to our advantage. We all are in a business, and that is the business of life. On daily basis, we have to take decisions, some of which may be termed as mistakes.

However, unless we make a mistake, we cannot prepare ourselves for better, or rather more-informed decisions. I associate the term "mistake" with follies that we keep making every day, like not realizing that the pan is hot, before picking it up. When it comes to deciding on important aspects of life, we cannot make a "mistake". This is because we decide based on what all we know, and unless we take "wrong" decisions, we cannot learn to take "better" or more-informed decisions.

The point that I take home is to "take decisions" and maybe in that course, "make mistakes." We all have just one life, and we cannot let it run through our fingers by not taking decisions, and by not making mistakes.

Happy Making Mistakes!