Should You Hire a Consultant to be Your Project Manager?
Wednesday, July 16th, 2008Answer: Maybe.
Consider hiring a consultant to be your project manager when:
- there are no obvious candidates within your organization
- your organization is “tight” on resources and you don’t want to overload staff personnel
- you want an independent third party to be your project leader
Don’t discount the value of having somebody outside your company run the engagement. On numerous occasions over the past fifteen years, clients have said to me, “Would you go talk to Person X? He will listen to you.” Or, “You and I say the same thing but because we are paying you the high hourly rate, they listen to what you say.” Another nice side benefit to having outsiders come in is that we don’t have to care about company politics. We do our job, get paid, and go home. Sometimes an internal project manager is stuck running the project in a manner not totally to his liking because of the realities of his particular organization. In other words, he wants to keep his job.
How large should the team be? What is the optimal size for a software acquisition team? My preference is five to seven people. That usually covers all the functional areas of most organizations and allows for the meetings where everybody can be heard but that do not go on too long. As number of participants grows, so does the length of time to conduct a meeting, particularly if the meeting is poorly run.
I was hired to manage a software acquisition project for a large East Coast property management firm a few years back. The leaders asked for volunteers to serve on the evaluation team and they got eighteen responses, fifteen from the same functional area). All eighteen people ended up serving on the selection team. It was big-time overkill, and it made conducting the planning meetings and the subsequent vendor demonstrations very difficult. There were reasons why my client did it—over my objections. The ultimate selection was not “better” because the selection team was this large.
At what level of the organizational chart should the team members reside?
They should be in the middle, neither frontline staffers nor the executives. We want people who know the organization and are used to working.
Everybody tends to know who these folks are; they are the ones doing all the work! Ambitious types who want to serve just so they can say they served should be avoided. These guys will not work and will make the others angry and resentful as they have to pick up the slack of a noncontributing team member. Having said this, I have had people on all places of the org chart be successful on a team. They have to want to work, though; that’s the key characteristic.
What is the motivation level of possible team members? Do they want to serve… are they TOO eager to serve? What I am talking about here is bias and/or ambition. We don’t want people who are bucking to select a certain vendor because they worked with the package in advance or because they want to advance in the organization by the kudos that might be granted by being a part of a terrific software choice. (By the way, that goes two ways.) A vendor that was great for one company might not be the best match for another. Steering committee members, be cautious of somebody who wants to be on the team too much.
You want reluctant warriors.