We’ve all been there. Sitting in a room where the client, a project stakeholder, or your boss is questioning you (perhaps in an angry-ish way) about why the project went terribly wrong. It’s uncomfortable, almost unbearable – and the temptation to blame someone can be almost impossible to ignore – especially because you know whose fault it was. But when you’re the project manager, no matter what happens, if the project goes badly its your fault. The project and the team working on it are your responsibility, and so if there is a problem its your job to handle it (or get help to handle it) before you find yourself in the hot seat.
So what’s a project manager to do when this inevitable situation arises? You have two choices: start making excuses or apologize and start working on a solution.
It makes me cringe when I see PMs selling out members of their teams as they are explaining how the project went off the rails (e.g., the developers were late, a team member called out sick, the designer missed some of the client’s changes). Worse yet is blaming the client (e.g., we got the comments late and didn’t have time to finish everything in time). None of this matters – it is still the PMs fault.
Placing blame and making excuses is the easier choice. It’s much harder to apologize and look for a solution to move on. The upside is that there’s a possibility that the apology itself might diffuse the situation right there. Even if it doesn’t, it pays to get comfortable with the fact that if you’re in charge of the project, with the possible exception of natural disasters, you are responsible for everything bad that might happen. So get ready to shoulder the responsibility and apologize if the worst happens. In the long run this is way better than alienating your team, blaming the client, or giving your boss the impression that you aren’t capable of effectively running a project after all.
Have you ever been a team member working on a project and you start getting hints that the client is asking for something that wasn’t on the list or is above and beyond what you agreed to do? If you’re lucky, right after that the project manager spoke up and said something about it. While it might not be a comfortable conversation to have, talking about the project scope frequently – perhaps even at every single weekly status meeting – can make sure that the project stays on track and ensure that the client won’t be surprised if you have to ask for a change order (aka more money or time) later. Clients tend to be very understanding when you have to discuss cutting features or adding time and/or budget if they’ve been in the loop all along.
So why does it seem like some project managers hesitate to bring it up when changes, requests, or discussions of features start to go out of bounds? I haven’t read any research on the topic, but what I’ve seen with my own eyes is that PMs are afraid to say something because they think the client will be upset and/or won’t like them anymore, that they’ll look like they’re not being flexible, because they didn’t really notice that the client was asking for something that was out of scope or they didn’t think it was that big of a deal, or worst of all they think talking about project scope is not their job. Maybe these are valid reasons for staying quiet (except that last one) – but they don’t negate the fact that managing project scope is 100% the PM’s job and doing this effectively is as key a skill as they come.
So for any PMs that are uncomfortable bringing up the topic of scope, the good news is that the conversation doesn’t have to be formal, awkward, or antagonistic. It doesn’t even have to be definitive. If you think (or someone on your team is telling you that) something being discussed is going out of scope, you can always say “that’s a great idea and we should definitely explore – I will also check into whether it can fit within the current project scope” or “that is something we haven’t discussed before, we’ll regroup as a team and determine what it would take to get that done.” Then you have time to regroup, consult, and determine the impact on the project. Maybe you can counterbalance the new idea by changing something else about the project (removing a feature to make room for the one being added for example) so the final result comes out even. If that doesn’t work, you’ll have time to create a summary of the change and its impact on the project that you can use to determine if it is worth asking for a scope increase. Sometimes it isn’t because the amount is too small or you want to promote good will with the client. But if you really need to ask for an increase, this document can be used to communicate the rationale to the client.
No matter how uncomfortable, there are 2 things way worse than the conversation about scope changes along the way:
- Telling the client that they owe extra money after the extra work has already been worked into the project and it is too late to undo it
- Explaining to your boss why your project lost money because you let the scope get away from you
When planning a project there are lots of options for organizing the tasks. When I think about a project plan I automatically think of the traditional gantt chart with the tasks, sub-tasks, resources, and timeline all incorporated within. In a lot of ways I feel like I need to create this level of detail to make sure I really understand the project, the contingencies, and who will need to work on which pieces when. Without it, I feel like I can’t identify the hurdles as easily either, which can lead to ugly surprises down the road.
But I don’t think that madness should apply to anyone else – not the client, the team, or the stakeholders. While I might show it to them just to let them know we did our homework, I would never ask anyone to try to track the project using a document big enough to wallpaper a room. For everyone else I tend to make a simple milestones list or calendar to show when key points in the project will fall. These tools are much easier to read and can provide all the information the stakeholders need to move forward.
With that said, I know plenty of project managers who never make the detailed project plans and some of them are successful that way. Except for really small projects, I don’t really understand how that works but hey – if it works for them it works for them!
We all know that how we present ourselves makes a difference – if we show up to a job interview looking wrinkled and flustered it will be harder for the interviewer to believe we’re organized and will be a good fit for the organization and the work. But if we arrive dressed neatly and appropriately for the environment, we’ll have a much better chance of getting past that first impression and on to a discussion of the job.
The same is true for the materials we send our clients – when a timeline is overcomplicated, a document is printed in type that’s too small, or the design document is difficult to interpret, we’re sending a message (not a good one) about ourselves. We’ve all been in that meeting where the client is says “I’m having a really hard time following what you’re saying, can you explain again what I’m looking at?”
Not only does this reflect poorly on our skills as PMs, we’re also making the client work harder than they should to do their part, which is never a good thing. On the other hand, if we make our communications clear and our documents easy to read, the client will be thrilled about how easy it is to work with us. That and a decent end product will bring repeat work every time.
As usual, I have way too many goals for one year. It always happens this way – I get excited at the possibility of starting over, doing new things, getting rid of unhealthy habits, and accomplishing more than in any previous year. Like many people, I usually run out of time or motivation before the year is up. So this year I’m trying something new – I’m looking at the possibilities as I would look at a project plan, and putting the most important (and most “foundational”) goals on the critical path. Since I’m prioritizing “health” first, the first critical task on the path is “get more sleep” – at least 7 hours a night. Once I’m doing that consistently I’ll add others. Contrary to the popular belief that a new habit can be formed in 21 days, research presented by James Clear on the Huffington Post says it can take much longer – from 2 to 8 months – and it varies widely according to the habit and the person. I figure I’m a fast habit-former so I’ll give myself 2 months on this first task and start the next critical path task in March. Of course there are concurrent tasks too – like writing more consistently, staying in touch with friends, spending more quality time with the kids, and getting more exercise. I think I’ll be better at all those if I can get more sleep. Only time will tell, but I have high hopes for the critical path method of new year’s resolution management.
Of all the goals you’d like to accomplish this year – which would you put on the critical path?
For all those project managers out there – here’s hoping that everything you’re cooking today comes out perfectly and all at the same time. That everyone who comes over brings just the right thing (e.g., exactly what you asked for), and that you have the perfect number of plates and silverware for all your guests – with some extras off to the side incase of emergency no doubt. 🙂
Enjoy the day with friends and family – Happy Thanksgiving!
Weekly status meetings are a great PM tool. They keep the PM in touch with the client and show commitment to the project because the time is reserved, every week, to discuss the project. The status meetings provide a way to review the project progress, next steps, and assign tasks to the appropriate people. They are also great for reviewing any risks to the project before they become problems that can negatively impact the project. Status meetings for the internal core team can also be useful to make sure project progress is on track. It’s easy to see how this regular communication can facilitate effective project processes, so it does make you wonder when you see project managers canceling these super-important meetings.
Usually before the meeting cancellation arrives you hear something like:
“I talked to the client 3 times this week already so there’s really nothing left to discuss”
“No progress has been made this week because the client has been at a conference so there is nothing new to report on”
“The client still didn’t return feedback on that design document so there is no need to have a meeting to review it”
It might seem logical to cancel the meeting given the reasons above, but this can actually make the situation worse. The project could be at a busy stage or a critical point or going through a crisis, which is why the PM has already been speaking with the client so frequently. That’s a good reason to have a meeting to re-cap on project status. It may be that the project is stalled which is why the PM hasn’t received feedback on a deliverable. This is also a good reason to check in on the project status. Canceling the status meeting takes away the chance to ask the client how to help manage the crises, or figure out how to get back on track after a delay. The very fact that there is no progress to discuss is a good reason to have the meeting. Canceling not only takes away the opportunity to figure out a way to get things turned around or ensure they continue to go smoothly (whichever the case may be), it also takes away accountability for the project since nobody has to show up to discuss it.
It’s only 30 minutes week on the calendar – if there’s nothing to discuss everyone gets 25 of those back while still helping to ensure that the project stays on track.