Problem personalities among project managers

Original author: Neil Green
  • Transfer


It may seem strange to someone unfamiliar with software development that a project has both a product manager and a project manager . The difference is that the first is responsible for determining the product, and the second is responsible for the state of the project and reporting to the interested parties, if the date of delivery is at risk.

Project managers tend to strive to ensure predictability of terms by standardizing and adhering to the cyclical nature of processes. These processes focus on status reporting to track progress. It is generally accepted that the more closely you monitor the processes, the more predictable the project schedule will be, and the higher the likelihood that the project will be delivered on time.

The curse of the project manager - the quality of the estimates of the time they receive from the team. These estimates may vary wildly. As a rule, they differ from person to person, and daily updates may be required. Such a whirlwind in the assessments may ultimately make it impossible to determine the deadlines for the project, but a firm date is expected from the manager. When these deadlines are finally skipped, the manager must find a way to explain why the deadlines are missed, without making the staff members directly responsible for the missed deadline. Lack of diplomacy in this area often leads employees to blame the project manager for “throwing them under the train,” regardless of the accuracy of their previous assessments.

The following are problematic identities among project managers:


Meeting Scheduler


The project manager, who believes that all the problems of the project are caused by a lack of communication and coordination, and the solution will be an abundant number of meetings.

  • May mutate to statistics
  • Dangerous in conjunction with a patent type product manager.
  • Probability of correction: high
  • Project Hazard: Low

Problem


In theory, people gather at meetings to discuss options and make decisions. In fact, this rarely happens. The meeting planner is not aware of this phenomenon and is trying to schedule meetings as often as possible, with as many people as possible. He sincerely believes that this will improve collaboration in the team: the idea that there is not enough communication for the project’s success is firmly reinforced in his mind.

A manager of this type exacerbates the three main problems inherent in the overwhelming majority of meetings:

  1. As a rule, the selection of participants is bad, with the result that some listen to information that they are not interested in, and express opinions on issues that do not concern them.
  2. The organization of meetings is also usually bad, which often leads to chaotic debates unrelated to the purpose of the meeting, which in turn does not lead to any practical conclusions.
  3. Projects are completed not at meetings, but at workplaces. If you drive employees to meetings instead of work, they spend valuable time.

Decision


The meeting planner does not pose a serious threat to the project, because employees usually do not attend meetings that harm their productivity. Therefore, the work continues, despite the regular meetings.

Such a project manager can be fixed with a simple instruction:

  1. Classify all types of meetings that they usually convene: status reports, project reviews, scheduling, etc.
  2. Determine what results (if any) of these meetings can be achieved by other means, for example, by e-mail, tracking tools, informal conversations.
  3. For mandatory meetings, determine how often they should go and who should attend.
  4. Schedule meetings in chunks to avoid multiple employee distractions due to context switching.
  5. Leave a few days of the week free from meetings.
  6. Free several weeks from meetings (they will love you for it).
  7. Plan each meeting at least a week before it starts with a published agenda and any materials you need to consider before the meeting.
  8. At the beginning of the meeting, review the agenda, meeting objectives and contribute to achieving these goals.
  9. Finish the meeting right away: do not continue it if the original goal is reached.

Meetings are required to complete a project, but the main thing is:

  1. Make every meeting as effective as possible.
  2. Minimize the negative impact on performance.

As soon as the meeting planner understands this, his behavior will immediately change for the better.

Statistics


A project manager who is only involved in creating lists and checking items, regardless of their content.


Problem


Completion of any project requires two mandatory steps:

  1. Make a to-do list.
  2. Mark items from the list that are made.

The project manager of the statistical type came to the conclusion that the maintenance of this list represents the entirety of his official duties. He is not concerned about what is on the list. Only by the fact that there are items in it and that they are checked at a predictable rate. The statistician does not evaluate or suggest any critical approach to what the items in the list are, but instead relies on others, telling them the content of the item and the deadline.

The greatest concern for such a manager is that his work can be performed by project management software. Thus, it becomes unnecessary. Often, statistics are given to lead projects in such a program, and he very carefully keeps information up to date. The project itself may be in ruins, the team may release a completely wrong product with a delay of months and of poor quality, but as long as everything is properly documented, the statistician sees no problems.

Fortunately, if the statistician only keeps lists and deletes items, he does not cause any harm to the project, if you do not take into account his lack of information about the true state of affairs. The main problem is that a statistician can quickly mutate into something much worse.

Decision


Statistics are hard to correct because his attention to detail is deeply rooted in nature, quite possibly from childhood. If someone considers lists to be important, he will not suddenly change his thinking after your words. In addition, lists are really important, but they are only a map, not a landscape. This confusing paradox of lists that are important, but not paramount, especially makes it difficult to correct statistics.

The key skill that is not enough statistics - the skill of working with people. The manager interacts with the list rather than with people. Invite them to talk to people in person about what they are doing and why, and not just ask for a list of items. However, in the event of a poor performance, the statistician may slip into micromanagement (see uncertain manager).

Finally, ask to write a summary of one paragraph about the status of the project, and not to show the result in the form of a list of items. This will make them more holistically present the project.

Deluded


The manager is so disconnected from the realities of the project that it gives false information to the interested parties.

  • May mutate into optimist or pessimist
  • Dangerous in combination with an optimistic developer
  • Probability of correction: high
  • Danger for the project: very high

Problem


The main responsibility of the manager is to report on the status of the project. This is called “setting expectations”, and “meeting expectations” is the measure by which the success of a project is determined. A good project manager sets expectations based on a combination of quantitative and qualitative data, as well as his own professional experience. On the other hand, the erring manager relies solely on his instincts.

Below are key phrases that allow you to recognize a project manager in the clouds:

  • "I have a bad feeling".
  • “I don’t think we will be in time by this deadline.”
  • "I think everything will be fine with us."
  • "I do not see any problems."
  • "This decision confuses me."

Pay attention to the use of "I" and "we" - these are good markers, that the manager's perception is based on subjective impressions, and not on the collected and analyzed data.

It is important to note the difference between a misguided manager, a pessimist and an optimist :

  • A pessimist , based on his interpretation of quantitative and qualitative information, believes that the project will fail.
  • An optimist , based on his interpretation of quantitative and qualitative information, believes that the project will be successful.
  • A deluded manager only on his own feelings creates an opinion about the success or failure of the project, which is completely untrue.

This is one of the few personalities that can independently destroy the whole project. If such a manager often meets with interested parties, then vigilance should be increased, because the following can happen:

  1. The manager tells the authorities that everything is lost, the project will never go into production, as a result of which the project is canceled.
  2. The manager says that everything is in order and everything will be on time, as a result of which the authorities will be even more disappointed if they are late, which will lead to the cancellation of the project.

Decision


Fortunately, such a manager can be fixed in two steps:

  1. Ask him why he feels what he feels.
  2. Show him the quantitative and qualitative data that contradicts his instincts.

Why ask to formulate what he feels? This will help him to understand that judgment is based not on something material, but on a subjective assessment, that is, on feelings. It is vital that he come to this conclusion on his own - no need to say that he has bad instincts. Keep asking “Why do you think so?” Until you reach a breakthrough.

As soon as it came to the manager, show him hard facts about the project. For example, if he says “Product quality is no good”, imagine a graph showing a steady decline in the number of bugs over the past few months. If he says “We will be ready on time,” provide a list of incomplete tasks and the usual time to complete the tasks, which proves the opposite. At this stage, it should be just a matter for the mind and logic of the manager to prevail. If he remains in illusions, repeat the process as many times as necessary.

Pessimist


A manager who confidently speaks of the failure of the project, and it can not be convinced of the opposite.

  • May mutate into deluded
  • Dangerous in combination with alarmist type tester
  • Probability of correction: no
  • Danger to the project: extremely high

Problem


Most software development projects can be called unsuccessful from some side:

  • Excess budget.
  • Excess deadlines.
  • Lack of all necessary functionality.
  • Performance, stability or scalability issues.
  • A large number of bugs.

In the real world, this can be expected, and sometimes perceived as an inevitable reality. But the pessimist makes such high demands that the project cannot meet, so he announces his failure long before the actual failure of the project.

A pessimist is easily identified by two key characteristics:

  1. He specifically chooses negative metrics about the state of the project to focus on the negative, ignoring or discounting any positive signs.
  2. He is passionate in his speeches, which are often full of emotional drama.

Such a position can convince the authorities that the project is hopeless, and it is really canceled.

Decision


The pessimistic manager cannot be corrected, as he is often unhappy in his personal life, dissatisfied with his job, his career, or the company itself. Thus, its negative has nothing to do with the project itself, but represents a personal problem. The best thing to do is to offer psychological counseling, on which few companies go. This leads to the often inevitable result: the manager either leaves himself or the company dismisses him.

Optimist


The project manager, who convinced himself of the success of the project, regardless of the evidence to the contrary.

  • May mutate into team captain or misguided
  • Dangerous in combination with an optimistic developer
  • Probability of correction: low
  • Danger to the project: extremely high

Problem


As a rule, people like to work with positive people. The lack of an optimistic manager is that his positive outlook makes it difficult to understand the warning signs on the project . Instead of taking measures to eliminate problems, he prefers to ignore these signs, considering them an unhealthy negative, and instead prefer to report only good things. This breeds a culture of complacency or despondency among team members, while the bosses are under the illusion that everything is going well.

In any management position, optimism in the face of adversity is an important advantage. To distinguish an optimistic manager from a bold leader, use the following tests:

  • Does he feel grateful for the bad news?
  • How often does he make unreasonable compliments?
  • Is he always in a good mood, no matter how low the morale of the team?
  • Does he avoid confrontation, even if it is justified?
  • Doesn’t it seem that for him to please others is more important than the success of the project?

An optimistic manager often causes a project to fail because it ignores problems that can lead to failure. The longer the project goes, the worse the effect.

Decision


An optimist is easily confused with a courageous leader, which is why they are rarely identified, and therefore rarely corrected. By the time the optimistic disguise manifests itself, it is often too late, as the project has already failed.

Organizations are keen to promote brave leaders. As a result, an optimistic manager has higher chances of promotion, if he can convince his bosses that the project has failed for reasons beyond their control.

Regardless of the reasons why a manager behaves this way - for personal career growth, not wanting to face an inconvenient truth or simply naively - the damage to a project is the same. The only difference is whether he is promoted or fired.

Team captain


A project manager who focuses on ensuring that all programmers are happy, and not on the success of the project.

  • May mutate into optimist
  • Dangerous in combination with a peacemaker type development manager.
  • Probability of correction: high
  • Project Hazard: Low

Problem


High morale is important for any project: developers are usually more creative and productive when morale is high. When a project goes badly, naturally, the morale drops until the situation improves. At this time, instead of solving the problems of the project, the captain of the team is engaged in improving morale.

The team captain and optimist share a positive attitude, but its manifestation is fundamentally different:

  • The optimist ignores any problems facing the project and misinforms the authorities.
  • The team captain considers the success of the project solely in terms of morale: low morale is an unsuccessful project; high morale - a successful project. He thinks about the interests of customers and authorities later, if he thinks at all.

The team captain is very easy to spot:

  • It comes spontaneously with treats, such as coffee and donuts.
  • He considers it important to negotiate in private with each employee “in order to hear their needs.”
  • As a rule, he likes to talk about personal things, about the life of an employee outside of work (thinking that this may be a source of dissatisfaction).
  • It sends out positive letters, puts up motivators all over the office, and is usually overly positive.
  • It stands for the best office furniture, the best lighting and, as a rule, the best working environment.
  • Violently struggling against poor working conditions, such as lack of career development for employees, an insufficient number of trainings and overtime.
  • Organizes after-hour meetings with the team, not tied to the important stages of the project.
  • Very concerned that all project participants love him.


Such a person seems to be the ideal project manager, but there are two reasons for concern:

  1. All these activities only temporarily increase the morale, which quickly dies away when people remember the realities of the project.
  2. They do not eliminate the fundamental causes of low morals, preferring short-term incentives.

Thus, the captain of the team eventually everyone likes, but does not actually do the work of the project manager.

Decision


The main problem is that the team captain usually does not have much experience as a project manager. Therefore, the solution lies in his training. Fortunately, there is a huge amount of training resources for project managers.

Having provided the manager with the necessary tools, he should be encouraged to identify the root causes of low morale, and then correct them. Taking into account the natural tendency of the team captain to improve the mood of the staff, he will certainly make aggressive attempts to find and correct the root causes of the decline in morality as soon as he realizes what to look for.

At this stage, you get a project manager with a very powerful mixture of motivations: first, he uses morality as a measure of problems in a project, secondly, he finds these problems and corrects them. Since his motivation comes from compassion for one’s neighbor, the problems underlying low morals will be quickly eradicated.

By the way, in their character to be kind to others, it is therefore unlikely to “cure” them of this component, and their “correction” should not imply the elimination of positive parts of character. In the end, if it is possible to raise the level of a project manager, it is difficult to find a better option for such investments than the team captain.

Tyrant


A manager who treats project members with contempt in the name of their motivation to work more.


Problem


Software development projects usually involve many strong personalities, but all should be subordinated to one goal each and focused on project implementation. Therefore, project managers have the authority to lead project participants to ensure project success. The tyrant abuses these powers, using negative reinforcement to achieve results.

While the tyrants may not like, the authorities often believe that their “firm hand” is exactly what is necessary for the success of the project, especially if he is behind the schedule. Threats and punishments actually act as a motivator for many types of personality (see developer of soldier type ), which contributes to the spread of tyrants.

Actual problems with tyrants are hard to detect, but they are incredibly harmful to the project.

  • The most talented and experienced project participants will leave when they feel that they are being mistreated, as it is easy for them to find work in other companies.
  • Employees who cannot easily find another job will remain, so the project will be staffed with people who would otherwise remain unemployed.

The longer the tyrant works, the more dramatic this slow talent drain will be. In the end, as soon as all the competent project participants are expelled, it will be impossible to invite talented and experienced participants to the project, as potential employees will not want to work with an incompetent team (the fact easily emerges during the interview).

It is important to note that the tyrant is usually introduced into the project at the most inappropriate moment: when the project is in trouble. Projects under the threat of failure should discard incompetent team members, while maintaining competent, but the tyrant has a completely opposite effect.

Decision


To correct a tyrant, you need to bring to his consciousness that this behavior adversely affects the project. There are two general approaches for this:

First, provide quantitative data reflecting their project management style:

  • How many valuable employees left the state.
  • Successes in attracting talents.
  • How many features are released.
  • How many bugs are registered.
  • How many missed deadlines.

When comparing this information, time schedules are especially effective.

Secondly, let them know what indicators you expect in the near future. Most likely, they will show irritation and hopelessness, since they do not know how to improve these indicators. But this is an ideal opportunity to offer them advice and training on how to become the best manager. Training should cover the following:

  • How they behave with employees.
  • How they discuss the failures and successes of projects.
  • How to identify and weed out incompetent project participants.
  • How to attract and retain competent participants.

Provided that there is a suitable specialist for such training, then the manager-tyrant can be completely corrected, because the following characteristics are naturally inherent to the person:

  • People don't want to be mean.
  • People like when they are loved.
  • People like to be effective.

The main thing is for the team to adopt a new approach, despite the tyrant's reputation in the past. The problem can be solved very simply, for example, to convene a meeting with the theme "I regret" and "I have changed for the better."

Obsessed with process


The manager is so obsessed with the process that he forgets about his task - to help the project achieve success.

  • May mutate into a tyrant
  • Dangerous in combination with a dictator type product manager.
  • Probability of correction: high
  • Project Hazard: Low

Problem


After completing any training course or reading any management book, each manager risks becoming an obsessive process. This can happen even with the best, so it’s important to be patient when correcting them.

There are two broad categories of processes for which obsession is manifested:

  1. Waterfall obsession
  2. Obsession with agile development (Agile)

Perhaps a course or book called these processes differently, but you can easily put them in the correct category by applying the following test:

  • Obsessed waterfalls believe that all problems can be solved with the help of additional documentation, for example, "from now on, we will write system requirements for each document with business requirements."
  • Obsessed with agile development consider that all problems can be solved with the help of frequent short meetings, for example, “from now on we will organize daily meetings in the morning for no more than 15 minutes”.

The goal of any manager is to deliver the project on time and on budget. The process we use facilitates this. When a project manager becomes obsessed, he can ignore the main goal and instead dwell on the question “Is the process going right?” To the detriment of other official duties.

Decision


Whatever you do, do not try to rob them of the process or challenge it. You are dealing with a religious fanatic rather than a rational person. He convinced himself that his process would "correct" the project. If they think the project is “broken,” and you try to say “it will not help us,” they will simply consider you part of the reason why the project is broken.

Obsessed with the process is easy to fix: just settle for everything he says, gently reminding you that “it takes time to turn a big ship” and “Rome was not built in one day”. The point is to force him to agree to the implementation of a new process through a series of small innovations, rather than a fundamental change. This will allow them to know for themselves which methods are effective and which are not. By gaining this experience, they will learn to adapt the process to the situation on the ground. There is hope that they will understand: the process is a means to an end, and not an end in itself.

Uncertain


A project manager who constantly requests current status from employees, considering it necessary that they focus on their tasks.


Problem


When a manager sits at his desk away from project participants doing the work, he can easily have a sense of his own worthlessness. It makes them do everything necessary to feel needed and useful. For an uncertain manager, the most obvious way to seem productive is to check the current work of employees. This is often achieved using the following methods:

  • Sending emails asking for project status.
  • Schedule meetings to discuss status.
  • Requirement to fill in sheets.
  • The requirement to break loosely stated goals into small tasks.
  • Arranging spontaneous face-to-face meetings to ask team members about their status.

Uncertain manager is widely known by another name: micromanager. His project management practices are interpreted by project team members as any or all of the following:

  • Quibbles
  • Pestering
  • Anxiety
  • Abstraction
  • Interrupt
  • Molestation

Often, employees develop deep indignation at an uncertain project manager, because in their perception:
  • The manager does not trust their time management skills.
  • The manager does not believe their timing.
  • The manager does not understand the need to be alone to solve problems.
  • The manager has nothing to do except to ask and report statuses.

This perception creates a confrontation between the project manager and the developers, suppressing useful communication that the manager could use to correct real problems. Instead of interacting with such a manager for cooperation and cooperation, developers avoid any additional contacts with him, fearing that they will (once again) be asked for status.

Decision


The uncertain manager is so common that such behavior is considered the main working responsibility of the manager. Assuming the inevitable, most developers form a certain threshold, how often they will be asked for their current status. Since the majority have learned to adapt to the constant pursuit of status, an uncertain manager does not present a high risk for the project, although it deprives the team of the possibility of useful communications that could otherwise take place.

Such a manager is born because the team’s performance is not well enough visible to him. Thus, the solution is to locate this manager next to the team. Otherwise, this manager overcomes the desire to directly ask the status of each developer. If they are nearby, the manager can understand the current state of the project, simply by eavesdropping the conversations of the developers among themselves. In this mode, the manager is most effective, since the need to intervene arises from him only when productivity is really difficult.

See also:
Tags:

Also popular now: