Thoughts on Project Management and other stuff that seems boring but worth reading.
Sunday, August 29, 2010
The Halo Effect
To put it simply, the Halo Effect is an action done by a manager wherein he does a sweeping generalization of a person's overall performance based on the merits of a single activity. Another form of the Halo Effect is wherein the a subordinate is evaluated based on the most recent events alone.(Its anti-thesis is the Horns Effect). The Halo Effect is something that MUST (again - MUST) be avoided by managers, both people and project managers, at all times. This is because it skews perception of a person towards the specific activity.
To visualize the topic, lets just say Consultant A just made an amazing presentation that helped seal a deal with a customer. Everybody was happy, most especially Consultant A's manager. Come performance evaluation time, Consultant A was given high ratings amidst the fact that he did not perform as expected in the months preceeding the presentation, and was even frequently absent at the office. Consultant A did not also follow prescribed protocol and set meetings with the customer without the prior approval of his manager.
We all know that managers should be fair and objective when dealing with their subordinates, but the fact of the matter that it is hard to do such a thing if:
1. You don't know your subordinates that much.
2. You have no memory of prior activities and achievements (or failures) for that subordinate.
3. Activities performed by your subordinates are valued (or devalued) inappropriately. (i.e. they are perceived higher or lower than what they are really worth).
Getting caught up in the Halo Effect would also create negative impressions on the manager. He would most likely be viewed as playing favorites, narrow-minded, unfair to the team, or even discriminatory. This is definitely not a situation that managers want to be as it would cause tension and lower the teams morale.
So how do you avoid the Halo Effect? Here are a few tips.
1. Document subordinates performance regularly. - Try writing down both good points and not so good points of the subordinate. Even small but important items need to be noted down. More importantly, do this on a regular basis. By regular, it means more than the frequency of doing performance evaluations. If performance evaluations are done quarterly, write down performance notes monthly (or even weekly if possible). This takes out the impact of the time element wherein we can only recall the most recent event since the events prior to the most recent are properly documented and can be referred to.
2. Establish standards within the team. - One of the things that a subordinate hates to do is to guess what his manager wants and expects from him. It would end up as a hit or miss situation and ultimately frustration on the part of the subordinates. A manager should make the effort to inform his team of what he expects of them. By establishing the standards, it also provides the boundaries of expected behaviours. This also gives the team substantial info on what factors they are being evaluated on.
3. Provide feedback early on. - Do not wait until the actual performance evaluation kicks in to provide feedback. At this point, everything is just after the fact. Both Positive and Negative behaviour should be fed back to the subordinate immediately after an activity has been performed. Not only does this give the best impact, but more importantly because it gives the subordinate the notion that performance is evaluated fairly and directly. Official Performance evaluations are only a summary of what is being done on a regular basis.
Always remember, the purpose of evaluating a subordinate is to ensure that they are performing at their best. This means influencing them towards the right behaviours and against those that are counterproductive to the project and the organization. It is therefore a very important activity that must not be neglected or downplayed by Managers, nor is it an opportunity to get back at people who you personally dislike in your team.
Monday, August 2, 2010
CYA is not the only PM technique
One of the first acronyms I learned as a Project Manager before PERT, CPI, SPI, EV, etc(thanks to my old bald headed boss) was CYA. For the uninitiated in the world of real-life Project Management (as opposed to conceptual PM studies), CYA stands for "Cover Your Ass". Yes, I know it sounds like an awful way of managing projects but it really transcends more than just a self serving activity.
When you "Cover Your Ass", you technically ensure that all project decisions, activities, and concerns end up in the right person. Being in the middle of the project traffic, a PM is very susceptible to having issues land on his lap without the means or authority to resolve such an issue. By the nature of his role, he is always exposed to being the scapegoat when a project goes south.
Truth is, CYA is a good PM technique if used in the right and appropriate manner. However, this should only be done when absolutely necessary and not ALL the time to a point that it becomes habitual.
Project Managers have a level of responsibility. In fact they are responsible for everything that happens in the project, whether they like it or not - and whether they caused it or not. It is imperative that the PM can take the heat when heat is present. Simpy doing a CYA to save one's skin shows a lack of character on the Project Manager. It is also unfair to those whom the buck is passed on to.
Amongst the various types of Managers, it is the Project Manager who has to be the one most exposed to change. A Project Manager is a Change Manager. Because of this, he has to be able to manage the changes that impact people. When people are impacted, sh!t hits the ceiling, and when that happens - the Project Manager is in the middle being hit on all sides.
When you "Cover Your Ass", you technically ensure that all project decisions, activities, and concerns end up in the right person. Being in the middle of the project traffic, a PM is very susceptible to having issues land on his lap without the means or authority to resolve such an issue. By the nature of his role, he is always exposed to being the scapegoat when a project goes south.
Truth is, CYA is a good PM technique if used in the right and appropriate manner. However, this should only be done when absolutely necessary and not ALL the time to a point that it becomes habitual.
Project Managers have a level of responsibility. In fact they are responsible for everything that happens in the project, whether they like it or not - and whether they caused it or not. It is imperative that the PM can take the heat when heat is present. Simpy doing a CYA to save one's skin shows a lack of character on the Project Manager. It is also unfair to those whom the buck is passed on to.
Amongst the various types of Managers, it is the Project Manager who has to be the one most exposed to change. A Project Manager is a Change Manager. Because of this, he has to be able to manage the changes that impact people. When people are impacted, sh!t hits the ceiling, and when that happens - the Project Manager is in the middle being hit on all sides.
Subscribe to:
Posts (Atom)