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.