I’ve previously written about how PMs should ask the question “what if?” as a way to help manage risk on their engagements. Instead of assuming everything will go perfectly as planned, ask “what if?” to imagine what would happen if it didn’t. Then, plan for that scenario instead.
A related question to ask is “why?” I love this foundational PM question because it applies on so many levels. On one level, identifying the rationale for why a process functions the way it does offers opportunities to improve both internal and external workflows. Your team gets better at that elusive dream of self-organizing while also improving the quality of the product that the client receives. On another level, asking why a requirement exists helps the PM map that need against stakeholder demands to verify that the project is meeting the needs of its project constituents. If the team or the client cannot articulate the origin for the requirement, why is it a requirement at all?
Finally, asking “why?” not only helps with business process improvement and organizational alignment, but it also improves your human interactions (if executed correctly.) Before you pooh-pooh this one, in an AI age, interpersonal skills will arguably become the most important part of a PM’s job, if they aren’t already. Asking yourself why a teammate is behaving a certain way or why a client is asking the question they’re asking helps you see beyond the superficial. I can’t tell you how many times a client has asked me to implement a project change without providing the context for their request. I’m sure you can relate! For example, one of my clients wanted to know if we could baseline our project schedule—she’d never requested this before, so instead of blindly complying with the request, I (politely) asked why. I learned that she wanted to track historic hours spent by task so that she could better inform future level of effort estimates. Knowing that this was her true requirement allowed me not only to baseline the schedule but also to structure our accounting process so that team members could more accurately and seamlessly track their work by task. Once we did that, our client had the data she needed to justify giving us additional hours in the next project phase. Had I never asked why, we may not have received that extra work.
Bottom line: asking why may make you feel like an annoying toddler, but don’t be afraid to channel that natural inquisitiveness. If someone tells you to do something—your teammate, your manager, even your client!—and you don’t understand the purpose of the request, ask. You’re the PM for a reason, and you’re getting paid to ask the hard questions, including but not limited to “what if” and “why”. Even if you’re a PM in training and/or new to a project, don’t be afraid to pipe up. At worst, you’re asking someone to repeat what they already know—they may enjoy showing off their expertise, and you’ll take advantage of a learning opportunity. At best, you’ll uncover an issue that those heads down in the project details had inadvertently overlooked.