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