One of the questions I hear the most from other Project Managers (PM) is how to get their project team members motivated to do the work they have been assigned. A PM usually works in a matrix organization, and that means that the PM’s project team is a mixture of resources across the organization who have their own “day jobs.” So, it is important for the PM to set the proper expectations for the team. That does not mean that the PM should not hold team members accountable. So the fine line that the PM must walk is set even before the PM has resources assigned to the project. However, the question remains: How does the PM get project resources motivated?
Understand the balance needed by the resource
As I mentioned in my previous blog, when a PM has a resource
assigned to the project, the PM must schedule the introduction with the team
and then with the resources. The team meeting should be short and used for introductions.
However, it is the precursor of the meeting for the building of the project
schedule. The PM has to get buy-in from the project team members to commit to
the schedule building meeting. To be clear, this meeting will most likely be
more than an hour long. So, breaking up the meeting into two or three meetings
over a week is strongly recommended. However, if the meetings extend over two
weeks, the members may forget what they committed to, and that must be avoided
at all costs. Once the members commit to the task(s), they must also commit to the
duration of the task. Once that step is completed, putting dates to the task(s)
is next, and this step is the hardest to get commitment from the members. This
should be done in a team meeting, but if the PM has a team member that needs
extra convincing, then a one-on-one meeting is suggested. Once the schedule is
completed, it must be reviewed with the project sponsor and the team members.
Once this is done, the commitment is public and the schedule must be in the
organization's public domain.
There are some PMs who prefer to not place the name of the
resource next to the task. I do not suggest that and am in favor of putting the
resource's name next to their task. That way there is no ambiguity regarding who
is responsible for the task.
Keep the resources informed and ensure there are no surprises
Once the project begins, a weekly status meeting is
recommended. In my blog on how to keep the PM and the project team motivated, http://blog.bennythepm.com/2013/03/how-to-keep-project-manager-and-project.html,
I suggest that a weekly team meeting is necessary, even if there are no
deliverables. This is good for two reasons: one, to keep the project sponsor
informed of the progress of the project, and two, to keep the project team
members involved. If they become uninvolved, the project team members can
become detached from the project. If that happens, it becomes hard for the PM
to get the team members re-involved.
Also, a weekly meeting almost ensures that there are no
surprises to any team member. Sure, there is always the risk that an anomaly
can happen. But a weekly meeting can help the team members identify that risk
and discuss how to mitigate it.
Ensure that the resources know what is expected of them and when the
task is due
Once again, the weekly meeting can help the PM keep the team
focused on the next tasks and who is responsible for them. This is part of the
“no surprises” philosophy that the PM should espouse and encourage among all project
team members as well as the project sponsor.
The "no surprises" philosophy is not one to be
taken lightly by anyone. We all know that the rate of failure in an IT project
is over 75% and the main culprit is lack of communication. The PM has the
authority to ensure good communication and must use that authority throughout
the project. Even in the best-run projects, there will be times when project
team members will have tough moments. The best way a PM can mitigate the
possibility of the project team members becoming, shall we say, irritated with
one another is to communicate often the next steps and the responsible parties.
That way, a PM can develop good team members.
I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine. You may inspire a blog article. I look forward to your comments.
A solidly good topic. I would also add that the communication must periodically extend to the member's line supervisor. If the member is not keeping their supervisor properly informed, then the supervisor may add to the member's workload which could affect motivation.
ReplyDelete