The slick salesman, the carpetbagger, the guy who knows it all—these are the traits that consultants despise in their colleagues.
TechRepublic’s IT Consultant audience advised managers to avoid the puffed-up, self-congratulatory project management (PM) consultant with too much talk and not enough action. These inept swindlers swarm around ready-to-hire managers and, with each sales pitch, sweeten the pot with talk of expert skill sets and the latest technology.
The boastful talk that makes their solutions sound great in the beginning can sting when managers are left with problems the consultant didn’t solve.
If you want to avoid being the “prideful consultant,” check out the warning signs provided by one TechRepublic member.
Thanks for sending your advice
Advice for this article was collected through a TechRepublic contest. The winners were rewarded with either $25 or a TechRepublic coffee mug. We’ll offer a second helping of advice for hiring consultants next week. Thanks to all members who submitted tips. Keep contributing to TechRepublic!
Recognizing a prideful consultant
Dan Schwee, a consultant with plaNet Consulting in Omaha, NE, told us about five qualities he avoids when hiring a project manager—all of which may signal a burgeoning superiority complex. Here are Dan’s five warning signs of a consultant you don’t want to be.
Number one: Consultants who don’t need to understand the technology
Some PM consultants do not feel a need to understand the technology of the project. These project managers focus on comparing actual task completions to schedules, yet don’t help to truly solving issues.
“They just act as an alarm and throw problems back to developers,” Schwee said. “A low-level clerk could accomplish this. A good project manager watches the schedules, hours, and costs but knows enough about the technology and the people and procedures to facilitate adjustments to keep the project going smoothly.”
Number two: Consultants who won’t use certain PM tools
Consultants should be flexible in their use of project management tools. The project manager needs to help the development team to accomplish its goals, and since every project and team is different, the manager must determine which tool will gather project status information in the most effective fashion.
He or she should make that decision based on the needs of the development team and the business requirements of the project, Schwee said. “There is no one-size-fits-all solution.”
Number three: Consultants who emphasize “manager,” not “project”
Some PM consultants believe they are “superior” to the development team. The best project managers realize that they are part of a team that focuses on schedules, due dates, elapsed time, costs, specification changes, and changing client needs.
“If the project manager does their job, the developers can spend their time on the more technical issues,” Schwee said. “A project manager that puts the emphasis on ‘manager’ rather than ‘project’ has missed the entire point of their role, and the developers will have to overcome them to get the job done.”
Number four: The wishy-washy consultant
Project management requires a consultant with some backbone. Wishy-washy consultants can’t make the tough decisions and leave their clients and their team lacking leadership. By example, Schwee said, a PM consultant should be able to remove a member of the team in order to move the project forward, if necessary.
“Assuming that reasonable alternatives have been explored and this is the best overall solution, the project manager needs to remove the person, or request their removal by business management.”
Number five: The consultant whose time is more valuable than yours
Continuing the theme of team spirit, Schwee warns that managers shouldn’t spend any time on an inconsiderate PM consultant.
“Don’t even consider [hiring] a project manager that is not punctual and considerate of other team members’ time,” he said. “I look for project managers that are excellent communicators, truly value the time and efforts of the development team, and understand the project’s business environment.”
How does Dan’s advice stack up?