Tuesday, April 28, 2009

Project Manager or a Technical Leader

Does a project manager need to be a technical person? This debate has been going on for years and probably decades. There are thousands of excellent blog and forum postings, mostly by project managers. The general opinion is that project managers do not need domain knowledge as good project managers are capable of acquiring whatever it takes, inclusive of domain knowledge.

Contrarily, most employers insist on domain knowledge, without which it is almost impossible to get jobs these days. Project managers feel that is tragic and being a project manager myself (irrespective of the job profile) I agree with them. However, we must try and look at the whole issue from the perspective of top management in order to have a better understanding.

About a decade back, when I was working for an advertising agency, I was assigned the task of screening candidates for the selection of sales representatives. It was kind of a situation where supply exceeded demand a thousand times. Therefore, the screening was expected to be very thorough. Though freshers had not been instructed not to apply, there was little chance that we would have selected a fresher. I personally felt bad for them but not as bad as I would feel seeing experienced people, who generally have families to support, jobless. Nevertheless, I took great care avoiding my feelings influence my decisions.

After interviewing a candidate, who was brilliant but not experienced, I asked him if he had any questions. He had one, and that was, "If a fresher does not even get a job how can he gain experience?"


I replied, "If freshers do not get jobs then where do these experienced people come from? The fact is that freshers do get jobs but at places where they can accommodate freshers. So far we have not taken any decision on selection of any candidate or otherwise. However, if we can accommodate freshers, the most deserving ones will be offered jobs." What I told him was a fact. If a post can be filled in by an employee with the least pay scale (fresher) who would want to hire an experienced person and pay several times more. On the other hand, if the salary is fixed, who would not want to hire a person who can deliver most?

The bottom line is that like every kind of buyer, an employer tries to strike the best deal. This is the reason why organizations want project managers with PMP as well as domain excellence. "Java project manager" no more makes me laugh as it has become a norm. It has been widely and happily accepted through out. I won't be surprised if PMI introduces credentials like PMP-IT and PMP-Construction, etc in near future and PMP-Java and PMP-dotnet slightly later. After all, as shopkeepers they need to keep on their shelves what they expect customers to come looking for.

If I were to choose between two project managers who were equally good at project management but one had domain knowledge, I would definitely choose the one with the domain knowledge. Most ideally I would rate all the candidates on the basis of their project management skills and I would consider domain knowledge if the best candidates tie. Would you not do the same?

Coming back to the example cited above, what is the harm trying to choose a project manager with domain knowledge from the ones who would score 10 in project management skills? I don't see an issue with that. However, the problem is when a good technical person is assigned the role of project manager without gauging his managerial and leadership qualities. More than often technical people find impossible to step out of their technical mindset in to the world of business.

Top level managers and executives are "why people", they are concerned with why a project, why a task, why the business and why this project manager, etc. On the other hand technical people are "how people". They are concerned with how to do it, how to write this piece of code, how to build this piece of hardware and so on. In a balanced organization why people and how people keep a check on each other, correct each other and complement each other. When a how person is put in the place of why person, he is most likely to fail keeping check on and correct how people as he is basically one of them. He also fails to adjust in his role of why person because he cannot stop thinking how and he does not know how to think why.

Managers assure but they do not ensure. They have their teams to ensure. On the other hand technical people seldom assure, they ensure. One of the most important jobs that a manager does is delegate. Technical people would any day prefer to do it all by themselves. Both these approaches are very important for the respective role but they can be damaging if interchanged. If the manager finds it difficult to delegate, the team will go nowhere.

Managers are good at looking at the bigger picture while technical people can see the finer details more clearly. Just as they say "A product for everybody is a product for nobody," I think a person who can see every level of granularity from the top most to the bottom most level can actually see nothing.

People with technical aptitude are no less or no more than people with managerial aptitude. They are just different. A manager is not made up of what a programmer is and vice-versa.

Employers insisting for domain knowledge are actually multiplying the probability of hiring people with wrong skill set. I wonder if they know the cost of hiring a wrong person which some estimate put up to two years of basic salary of the wrong hire in direct costs and much higher when indirect costs are added.

Are they striking the best deal?

I sincerely recommend them to read "Who" by Geoff Smart and Randy Street.

Monday, April 27, 2009

What is project management?

A PMP considers PMBOK his professional Bible. I very much do that too. At the same time I strongly disagree with the very definition of project management in the PMBOK.

The exact words in the PMBOK are as follows:
Project management is the application of knowledge, skills, tools and techniques to project activities to meet the project requirements. Project management is accomplished through the appropriate application and integration of the 42 logically grouped project management processes comprising the 5 process groups.

What does the above statement say? It says application of knowledge, skills, tools and techniques is project management. Is that so? It also says project management is accomplished through appropriate application and integration of whatever. Is that so?

Let us look at an alternate definition.

"Project management is the process of right planning, executing and controlling of the project to achieve project objectives, effectively and efficiently."

Like the general management, project management is all about the effective and efficient utilization of men, material, machines and money to maximize the throughput yield within the parameters of time and quality.

I think PMI needs to relook into their definition of Project Management.

Thursday, April 23, 2009

Living in the fools' paradise

We often say, "Failure does not just happen, it is designed into the system." One of the most important inputs or required inputs for each and every plan in the project is the assumptions. If you don't do a good job managing them, it is very difficult to do things right. You don't even have the requirements complete, leave alone the specifications, until you have not converted most of the assumptions into requirements. That is the importance of assumptions.

I suppose it is needless to say that the easiest way of designing failure into the system is to base it on wild assumptions or to ignore assumptions. It is the assumptions (or call it sky high expectations) that kill hundreds of businesses everyday even before they start, though they realize it much after.

You build a magnificent website with a beautiful UI. You have a wonderful revenue model and you expect millions in first couple of years. Worst of all, your best friends praise your site and the brains behind it. You know everybody around you likes your site. All that turns out to be meaningless when in reality you even fail to make enough money to pay your salaries. Sometimes you don't even make enough to pay for the hosting costs.

The root cause for this failure, most of the times are the wild assumptions, some of which are listed below:

Everything will go as planned

It never goes exactly as planned. Small changes and adjustments need to be made even in the most well thought and well prepared plans. The difference is that wise planners keep the provisions for easy identification and implementation of changes and others, who think they are wise, do not think any changes will be needed as they are sure that everything will go as planned.

There are buyers for everything

We often assume that everything sells if you try. There are buyers for every product and no matter how weird your product is or how exorbitant your price is someone, somewhere will be willing to buy. In reality people are not so dumb. I am glad I belong to the species in which there is hardly anybody so dumb to pay you for whatever you have to offer. People pay either when they see the value or when there is something in the product that their other feelings override the simple logic. For example excitement, love, anger and suspense, etc. Even for taking advantage for these feelings you need to have the right product, available in the right place and at the right time.

For instance, people do not mind paying ten dollars for a rose that would otherwise cost one dollar on the Valentines eve provide it is sold in urban areas, places that are easily accessible, where there is no problem of parking and provide it stays fresh towards the evening when most of the shoppers are going to look for it.

People will somehow find your website

Some people think cyber space is exact replica of real world. They think everybody cannot fit in one place and that is why we are distributed over the planet, over continents, over countries, over states, over cities and over lanes and by lanes. Therefore, wherever you are on earth, as long as there is a road to reach you, someone will reach you. Similarly they think as long as your site is on the internet someone will find you.

In reality nobody turns up of his own. People have to be pulled or at least told that there exists this wonderful site in the world.

People know what you are offering

People around you might but others don't. Some of them might go beyond you index page and try and understand what you are selling, but most of them will just walk away unless your website is sticky enough to hold them back. Therefore, provide as much information as possible in the least possible words.

Users know how to use a website

I will not say they don't because most of the users actually do. But they might not know how to use your website if your website is too different. It might be easy, but the moment they find it different they walk away. They do not want to take the trouble of going through the learning curve again and again.

Therefore, while on one hand innovation is the backbone of you website on the other don't try and make you UI too different or complicated.

People don't mind to signup

Their minding to sign up or their not signing up is exponentially proportional to the amount of data that you ask them to fill in the signup form. Therefore, ask them for the data that is really important and leave the rest for later.

People will contact you in case they face problems

"Who cares!" that is the attitude of the customers most of the times? When a customer faces a problem that prevents him for doing something that he intended, he simply closes his browser or goes to another website. If he was really there shopping, he would land up in competitors' websites.

Customers are loyal

Many people believe that they can have loyal customers and loyal customers are all that they would need to keep the sales on the top of S curve. If you are one of them, I would strongly recommend Loyalty Myths by Lerzan Aksoy, Henri Wallard, Timothy Keiningham and Terry Vavra. In actual practice, and particularly on internet, customers are not loyal enough to stick on to your website. Instead they are more inclined to try different stuff often just for a change.

Though it is good to try and hold your existing customers, often it is even better to focus more on new customers. From your old customers some will stay anyway and some will leave anyway, that leaves a small group that you are trying to keep compared to a much bigger group out there that you can attract. It is often even less costly to attract new customers than to keep the old ones glued to you.

That does not mean you should not try to hold you old customers but don't do that at the expense of getting new ones and vice versa.

Saturday, April 18, 2009

The debate between Scrum and PMI

In the words of my ex boss, "This is a chicken and an egg situation." Here the issue is not what came first, but what is better. I fear if we toss a coin to decide that, the coin will defy the law of gravity and refuse to come down.

In 2004 I attended my PMP exam preparation course. It was wonderful and I hold the trainer Mr. Gurudev Randhawa in very high esteem. That course was a turning point in my life. Besides knowing what the project management was all about, the PMBOK (Project management body of knowledge) kind of got embedded into my mind. After the course I could see very deep into the PMBOK but I could see nothing beyond it, or rather outside it. I thought PMBOK was the ultimate and you simply could not fail once you knew PMBOK. (Gosh, how many times did I have to type PMBOK?)

In 2005 I did my Six Sigma Green Belt certification and attended a training course on Six Sigma. Does the history really repeat itself? It did! We were told that Six Sigma was the ultimate that was required for success by any organization. In the four day (32 hour) training program, project management was hardly given two hours. That was a bit strange. A bit hard to digest, but that is what they probably thought so called project management deserved within the all important Six Sigma.

In 2006 I did my PMP. Third time I was told the same. "After PMP you will be in demand, because PMP is blah blah blah!!!" Few questions through in my exam, I knew I was doing everything right and expected around 90%. Probably I had started dreaming that HR of a few top companies were waiting for me right outside the door. The moment I step out they will all pounce on me with their offers. All I had to do was to accept the highest offer. I agree that is a bit exaggerated, but just a bit, just to make it spicy. The advocates of PMP had painted such a rosy picture of "post PMP myself", that I was already feeling on top of the world.

In 2007 I attended another training program titled "Managing program professionally." Probably that was my first step towards PgMP. This time I was sure I would have been able to do what I had not been able to, after my PMP. But looks like time is a wheel and same things have to happen again and again, though with some small differences. The fact is that there was an improvement in my capability, but not so extraordinary.

In 2008, after reading lot and hearing a lot, I gave a try to scrum in my organization. Now this scrum, as the advocates claimed, was expected to do wonders. It did. We produced the same "value adding output" that we did earlier in one third the time. Rework was almost eliminated as the product owner was virtually with the development team throughout the project, in every project. We were also able to effectively take the advantage from the ideas that sprung from everywhere. Probably everybody had collected so many ideas but before this they did not find the right opportunity to speak out.

Having said so, I still do not recommend anybody to blindly adopt any methodology, not even scrum. At the moment scrum is quite happening and it is not bad at all, but it is slightly risky. Rather I should say it has its own pit falls, like other methodologies. The biggest assumption that we make in scrum is that the programmers are knowledgeable and skilled. How can we even make this assumption when the statistics show that 75% of fresh IT graduates are not even "Industry ready?"

Basically there are four types of people. 1. Intelligent and hard working.2. Intelligent and not hard working.3. Not intelligent and hard working.4. Not intelligent and not hard working.
Most agile methodologies and particularly scrum is bound to fail if there are just a couple of team members from group 4. It has very high chances of failure even if there are a couple of team members from group 2 or 3. In other words, scrum is very likely to succeed only if all the team members are intelligent and hard working. How many such teams have you seen? Such teams can be developed by differentiation and elimination. However, that will have significant negative effect.

In practical situation, no matter how hard we try, we end up having employees with wide range of knowledge, skill sets, aptitude and motivation level, etc. All cannot be on the same level.
Another big issue is expectation level of the customer (sometimes the attitude of the customer). In a typical B-B customer-vendor scenario we come across two types of people who disagree with us. For the sake of confusion avoidance let us call them type A and type B.

Type A people disagree because they have their own valid and logical point of view. They often have a clear teachable point of view (TPOV). While it might be a little discomforting working with type A for a short while, in the long run it is a great opportunity. With them, often in just one or two rounds of discussions a third approach evolves that takes care of everybody's concern. From such people we get to learn.

Type B people disagree because they have to disagree. Disagreement is in their nature. They can never tell you why they are disagreeing. At the most they will tell you they want things their way because they want it. "I think it should be like this," that is what they will say in the beginning and "I still think it should be like this," is what they will tell you after days of screaming, shouting and head banging. Neither in the beginning nor in the end will they be able to tell you why they think so.

Do I need to explain why scrum will miserably fail with type B people? The only way of saving yourself from a heart attack will be to commit suicide.

So far I mentioned only PMBOK approach and scrum. I did that deliberately because that is what the debate has been about. Further I am not saying that PMBOK is a methodology and neither does PMI prescribe any methodology except the mention of waterfall model and spiral model, if I correctly remember. PMBOK is a collection of all the processes recommended by PMI, out of which the ones relevant to the project can be chosen and adopted for results. On the other hand scrum is very much a methodology.

The overall list of methodologies from the two main families is quite long. I do not think any methodology is bad enough not to deserve a place in the respective list. But for the practical situation I feel one size fits all does not work. The proper choice of methodology can be made based on the nature of project, resources available, capabilities of the organization, customer, other environmental factors and circumstances, etc.

In the end I would say, scrum worked for me because none of my projects related to lives of people. Had I been working on medical equipment hardware or software or a banking project, scrum would have probably been the last choice, system development life cycle (SDLC) the first.

P.S: Many websites refer to PMBOK as a methodology. I do not intend to contest anybody. In my blog I write what I know and believe. In legal language one would say, "To the best of my knowledge and belief."

Friday, April 17, 2009

About e-Centric Internet Marketing and Business Blog

There is only one thing that is common in all the business owners and leaders (almost all). That is their desire to succeed. However, desire alone has not made anybody taste success.

Over past few decades, the business landscape has changed so much that if our business leaders of the past were reborn, they would prefer to die again.

In our present age apparently it has become too easy to start a business, and more so a web portal. Most people are under an impression that all they need to do is to hire a part time programmer who would download some php scripts from here and there and shape them up into a website running on a free database, hosted with a service provider for 50$ a year. A start up cost of a few thousand and recurring cost of 50$ a year. On hearing this, anybody who has not tasted the failure already, would jump and say, "It is hardly any money. I spend more than that at Mc. Donald's. Why not give it a try." Thanks to them, they are the people who were responsible for the dotcom boom.

There are hundreds of thousands of people who jump into this, destined failure. Let us call them business owners.

The first surprise these business owners get is when the freelancer they had hired, does not even show up for every two out of three meeting. For next few months they discuss and just discuss when they meet and the business owner keeps looking for the vendor (the freelancer) rest of the time.

After a few months, the business owner decides to hire another freelancer, say another vendor. Obviously the sunk cost does not have to be considered but the business owner also forgets his initial intentions i.e. "It is hardly any money. I spend more than that at Mc. Donald's. Why not give it a try." The new vendor quotes three times the amount that the old vendor had. The business owner still agrees to carry on because by now he has lost the vision already. What he is seeing now are dreams, the dreams that are destined to prove nightmares.

Finally after few more meetings the new vendor starts working on the website. All looks well in first few days. Over their meetings, they laugh together and curse the old vendor together and the business owner leaves no opportunity to let the new vendor know how lucky he was to find him and get rid of the old vendor.

Months pass, several deadlines are missed and relation is no more the same. Now the meetings are for a different reason. The vendor wants more money. The business owner initially does not agree to pay, but his stubbornness is overcome by the thoughts, "After coming so far, I don't want to loose all the time and money that I have invested for a few more thousand."

After paying double the amount than what this vendor had initially quoted and six times the amount that the business owner had initially based his vision on, and after waiting for a year instead of couple of months that he had initially planned, the website is up and running. It is alive and kicking, but with hundreds of bugs. If the customer is lucky, the mischievous guys out there will never try their hands on this site to exploit the vulnerabilities of these downloadable free scripts that are powering this site.

Finally the work is over. The customer is excited. Poor guy does not even apprehend what is to come next. He waits and waits for people to come to his site, but hardly anybody shows up. He tries to create a few fake accounts, some fake postings but nothing works. He starts with requesting and ends up begging his friends to visit his site, but alas everybody is sympathetic to the extent that they offer to help him in various ways, except that nobody visits his site. It is just too boring.

At this stage he consults the son-in-law of his brother's friend who has just passed out from the management school. "What made him an expert?" I can't comment on that.

This new expert comes with another shock, rather shocking term, "Marketing Dollars." It is a great shock because all along the business owner had been thinking that it was just the matter of going live. One user will get 10, 10 will get 100, 100 will get 1000 and so on. He has had been pretty sure that out of a billion internet users out there, even if one tenth of one percent come to his site, we will still have a million users. "After all what is 0.1 %. Why can't he get even 0.1% to his great website that just takes 10 seconds to load a page? A site not ranked in the bottom one percent by Alexa, because it is not even ranked."

Old habits and beliefs are hard to change. The business owner still thinks, "After coming so far, I don't want to loose all the time and money that I have invested for a few more thousand." He is willing to invest more. This time his most trusted person in the world is the newly found expert (somebody's son-in-law). On his advice the business owner agrees to pay for PPC (Pay Per Click) to Google. Not withstanding fact that PPC is a very strong tool to drive high volume and relevant traffic, this unlucky guy gets just blank cartridges instead of live ammunition. The site is bombarded with hits but nobody seems to be interested to venture beyond the landing page. The money, or "Marketing Dollars", just burn and burn and burn. They don't even help keep him warm as they burn in the cyber space.

"Till bankruptcy do we stop?" As long as he can, the business owner keeps pushing his cash eating monster and finally puts a lid on it. In most of the cases, the business owners do not close their misadventure, but simply want to push it under the carpet till they have more money to waste. Finally such projects die and decay under that carpet.

There are very few people who admit the failure earlier in the "website portal failure lifecycle" described above in time and turn to more professional people for help.

The whole idea behind e-Centric Consultancy Services is to become an organization that such business owners can depend on to reinvent, reposition and sell their business to make it highly profitable.

This blog is a part of that effort.