Four Work Styles That Can Harm Your Project (and How to Manage Them)

Four Work Styles That Can Harm Your Project (and How to Manage Them)

Every SAP project team is comprised of human beings with their own distinct characteristics, needs, and agendas. Successful SAP project managers find ways to keep those differences from impeding the progress of the project.
Unfortunately, that’s a skill that is typically gained the hard way, says Rao of Deloitte Consulting.

“When you think about what project managers are taught in order to be certified, none of this is included,” says Rao. “They learn how to manage a project planner, how to work a breakdown structure, and how to schedule and run meetings — but not about the challenges they’re going to have managing the people that are going to be involved in these projects. The best project managers are often those who have gotten some scars from dealing with different kinds of people.”

So how does a project manager prevent differences in personality from devolving into multiple personality disorder?

A good start is to identify the types of work styles on the team, so that you can form a plan to manage each of them successfully.

Work styles are just one component of the personalities of a given project team. Rao uses the pyramid shown in Figure 1 to illustrate the various elements for project managers to consider.

Understanding Problematic Work Styles

Every project team member has a unique style of work, and most are compatible with the success of a project. However, Rao highlights four common work styles that can make life especially difficult for project managers:
Non-leaders
Overachievers
Geeks
Clerks
Understanding these four work styles — and formulating a plan to manage each — will make managing any SAP project easier. (Note that these are not the only common personalities on a project team — they are simply an easy way of grouping characteristics into categories).




Non-Leaders

While the project manager bears the ultimate responsibility for a project’s success, project teams require leadership at multiple levels. Good leadership is also necessary from stakeholders and team leaders.
Unfortunately, non-leaders are too common at every level.

Rao offers the following comparisons to help you distinguish leaders from non-leaders:
Leaders take responsibility for the team’s struggles but credit the team for successes. Non- leaders place blame for struggles and hog credit for successes.
Leaders keep the big picture in mind at all times. Non-leaders get bogged down with trivialities.
Leaders play fair and acknowledge excellent employees. Non-leaders play favorites and are jealous of the success of team members.
Leaders are adept at motivating team members. Non-leaders use fear and punishment as strategic weapons.

Managing non-leaders: Rao cautions project managers to be wary when dealing with non-leaders. Some are intelligent, but lacking in wisdom or maturity — making them especially dangerous to a project. One key for dealing with non-leaders is to create a paper trail of communication to keep a record of all decisions and instructions.
“I think the universal truth of this approach is honesty and integrity, but to some degree it’s also about covering your back,” he says.
However, non-leaders can perform a valuable function on the project team. Rao suggests that many non-leaders are effective devil’s advocates — and can be used to test ideas through argument. Several companies have struggled because their leadership teams were not exposed to different points of view on critical decisions.
“Enlisting those devil’s advocates to find gaps in your solution means you’ve got these non-leaders — who are typically the nay-sayers — actually playing a valuable role in the organization,” says Rao.

Overachievers

Most project managers would likely jump at the chance to bring on board a team full of determined, passionate, and hard-working employees. And they’re right — for the most part. While overachievers are good at using their considerable energy to move a project along, they must be managed carefully.

“Overachievers bring a challenging dynamic into your project team. They can be very quirky,” says Rao.

Because many overachievers are driven to move up the corporate ladder, they often see projects as a means to an end, and are more adept at playing politics than other types of employees.
Overachievers also tend to get a “rush” from completing tasks early or beyond expectation. Just as with drug users, this rush diminishes over time, which in turn leads the overachiever to get restless and seek a new job.

Overachievers are also prone to reckless decision-making and are often uncomfortable with criticism, because they are used to praise only.

Managing overachievers: The primary focus when managing overachievers is to lead through inspiration and not condemnation. Overachievers need to be convinced that the project manager has his or her best interest at heart.

“It’s about realizing where they want to go and helping them get there. You do that by inspiring them and tapping into that energy and creativity to get them to explore ideas for how to make a project better. It’s a re-channeling, if you will, of their strengths. Once they realize we rise and fall with the same tide, they tend to be more productive and valuable to the project,” says Rao.

Other strategies for managing overachievers include creating an environment where it is safe to fail and partnering overachievers with team members that have complementary skills.

Geeks

A fixture on just about every project team, geeks are typically analytical problem solvers with an interest in figuring out how everything works. Rao — himself a former Unix programmer and self- professed geek — says the geek work style offers a number of advantages, but can be problematic as well.

“What complicates things is that geeks take an analytical approach and try to over- engineer everything,” he says. “You tend to go down a rat hole with geeks, who may be more interested in the cool technical solution rather than just getting it done and building the basics. Geeks are always trying to figure out how things work, how to break them down, and how to make them better. The challenge is that sometimes this behavior is actually counter-productive to the project.”

For example, a project manager may give a relatively simple assignment to a geek only to receive a far more complex product in return. Rather than reengineer the original assignment, the project manager may simply plug it into the project, which creates increased complexity at future stages.

Managing geeks: The trick to managing geeks is to sell them on the idea that not every issue requires a complex, multi-layered solution.
“You have to understand their nature and get them to work with you to figure out the base functionality you will need to deliver the solution on time,” says Rao. “You have to engage them in that discussion.”

Clerks

Often among the highest-ranking and knowledgeable members on any project team, clerks are typified by their adherence to rules and order. Clerks typically arrive on time, leave on time, and follow all the rules.

The primary issues posed by clerks are a reluctance to accept any kind of change and an inability to conceptually link two non-consecutive steps in a project’s progress. These characteristics occasionally cause clerks to become obstructionists during a project.

“The clerk mentality is very tied into the status quo,” he says. “They are typically the last to adopt new technology and are easily thrown off by changes. They will often say ‘That’s not the way we do things,’ or ‘We’ve always done it this way.’”
Managing clerks: Rao says bringing clerks around on forward- thinking issues is typically an exercise in futility if done too late. A project manager’s best bet is to convince the clerk to participate in the earliest phases of the project, allowing the clerk to create his or her own vision of the solution.

“The project manager has to get them to understand their importance in defining the future state of the system, then minimize their role through change management. Get them to talk about what some of the challenges will be with the new system. Our research has found that people learn best by vocalizing what a change is likely to incorporate,” says Rao.

10 Common Pitfalls of Managing Different Work Styles

While project managers have to be adept at managing each work style and personality individually, project managers make a number of common mistakes when dealing with teams.

Rao points to 10 common errors,

Downplaying training . Too many project managers underestimate the value of training or are afraid that employees will flee to other jobs. The only other option is to hire employees that are too unskilled to work anywhere else, says Rao.
Withholding recognition . Many project managers don’t understand the full contributions of each team member and are therefore reluctant to offer public praise. The solution is to plan goals beforehand with each team member.
Planning too much overtime . Expecting high productivity is admirable, but over scheduling your team leads to burnout. Make sure to keep this in mind when planning your project.
Using management-speak . There are few things as universally reviled by technical teams as corporate buzzwords. Project managers don’t need to speak technology fluently, but avoiding management-speak is a must.
Trying to outsmart the team. A quick way to lose the respect of your team is to pretend you understand concepts that you do not. Project managers who admit ignorance of certain topics gain the trust of their teams.
Acting inconsistently . Team members at all levels have an intuitive sense of fairness, and the project manager who violates that sense loses credibility.
Ignoring the geeks . Project managers from non-technical backgrounds tend to leave the geeks to their own devices. This creates a leadership vacuum that can be difficult to fix later in the process.
Making technical decisions without consulting the project team . The project team likely knows more about the technology than any project manager, according to Rao. Making decisions without consulting the team will cause it to lose faith in your leadership.
Failing to give the team the proper tools . Slow computers and outdated software are annoying and unproductive. Give the team what it needs to succeed.
Forgetting that people are creative workers . Even the employees writing code are engaging in creative problem solving. The entire project team must be freed up to explore creative answers to issues that arise.