People ask me what I do for a living. I answer, “I tell people what to do.”
The key to successful projects – and effective project managers! – is communication. What is crystal clear to you is not heard, misunderstood or forgotten by others. Just because you’ve said it once, doesn’t mean anyone remembers hearing it.
You don’t want to communicate too little. Nor do you want to communicate too much. (Though really, it’s hard to have “too much” communication, just as it’s difficult to say “Thank you” too often.) So if you want to make a project succeed, here are a few ways to optimize the process.
Conduct Your Status Meetings
Status meetings should be scheduled weekly – and held! The verbal discussion allows others help in risk mitigation. By the time that risk actually turns into an issue, the team has already discussed the topic. Then you can spend time discussing how to resolve the problem, rather than trying to understand its factors or, worse, placing blame.
Don’t cancel the status meeting even if things are running smoothly. It is okay if the status meeting only lasts for 10 minutes. It’s critical to set a time each week where the team gets together. Once you set up a cadence, it’s easier to bring up risks and concerns when they first come up, rather than waiting until there’s a state of emergency.
Your status report should drive the agenda for the status meeting. The things to discuss should always include:
- Status: the status of the current phase. The owner of the task should provide the status, such as the technical lead explaining where things stand on the design document or the QA lead talking about testing.
- Upcoming dates: Who is on point for the next task? What do they need to get started? Often, no one is thinking ahead past today’s to-do list, so help the team plan for what’s coming next.
- Action/Open Items list: Each action item should have a description, one owner, and a status that includes what happened on which date. This allows everyone to remember (or look up) the history of the issue. However, as project manager, you are the team’s memory, so make sure you record enough details that you can recap the action item.
I know: It’s a pain to keep track of all the action items. Honestly, if it gets done within a few hours and is a small task (such as scheduling a meeting), then there is no point in tracking it on an action items list. You can also store the action item on a shared drive and have the team update it directly. But always remember that the project manager is the owner and should make sure the task is done.
Put It In Writing
Keep meeting notes. Never assume you will remember anything. Whatever is discussed should be documented and distributed for reference. If invitees were unable to attend the meeting, they should still get the notes so they can get or stay up to speed.
The best option is to take notes during the meeting and send them out shortly thereafter – before you get distracted. Generally speaking, notes should be emailed by the end of the day of the meeting. If it’s an end of day meeting, send them no later than the next morning.
Your documentation can be simple. Don’t spend a ton of time on format, unless it’s required by your company. Sending everyone invited to the meeting an email message is the quickest way to distribute the notes, and it is more likely to be read in this world of mobile devices.
Highlight the decisions made. You know those calls where everyone discusses a situation and you finally get everyone to agree on the best course of action? Then, a couple weeks later, someone asks, “Why we are doing this?” If you documented the decision in the meeting notes and added it to the status report (including the why and who), you can quickly reference the decision and who was present. The Who is critical, especially if the person asking “Why?” attended the meeting where the decision was reached.
Don’t Overlook Status Reporting
No, we haven’t discussed this already. Status reports are very different than status meetings.
Status reports are a snapshot of everything going on with the project at any point in time, a high level overview. They cover dates, financials, action items, and an overall scorecard of the project. Send status reports to the project team and to your clients (both internal and external to your company).
Empower your clients
All good project managers know that scope, time, and budget build the triangle of a project. If you want more done, the timeline needs to grow or the budget needs to grow.
While this is a basic tenet of project management, until recently, I kept trying to solve the issue for my clients. I would do all the detailed research, lay out the options, and present the best one to the client. Then I would get frustrated when the client didn’t agree with me.
I have changed how I present the options. I still do the detailed research, but now I give the client at least two options. Even if you see the choice as a no-brainer, still give them a choice. You can include the team’s recommendation, but always empower your client to make the decision. Even if the client asks for a different flavor of one of the options, you’re still closer to a solution by giving them options. Most of what they ask for usually is doable, but you need to outline the “cost.”
I once had a client who wanted to start the project immediately. We scheduled discovery sessions and got the requirements approved within a couple of weeks. When it was time to start development, they decided they wanted the developer onsite, however they did not have his access set up. They had a backup plan (or so they thought) on how he could work on the software until they got his access figured out. However, the backup plan did not work; the developer sat onsite for five days with nothing to do.
At our status meeting, we asked the client if they wanted the developer onsite next week, even though his access was not yet resolved. They said yes. This went on for four weeks. Each week, I asked if the client wanted the developer onsite, each week I documented the decision in the meeting notes, each week I added it to the status report as a risk to budget. Nineteen business days later, when the developer finally got access, I delivered a change request to the client for the 19 days lost. We ended up taking out some scope and signing a change request for additional dollars.
Not all clients work out that smoothly. But if you discuss the situation, document what you discussed and present options for possible resolutions, your projects will run much smoother.
Most of what I discussed here is communication with your clients. However, internal communication is also essential. Always communicate internally first, then with your clients. It’s important for the team to agree with the approach, the issue, and the status – or at least to reach a consensus about what will be communicated – before you start communicating to the client.
When in doubt, take a deep breath and say it again, write it again, and remind people again. Your job as a project manager is to make sure everyone knows what they need to know, when they need to know it. Happy PMing!
