Achieve the Goal, Don't Just Fulfill the Request.

My team was asked this week if a staff person could be added to our project management software so he could initiate contracts.

We do use our project management software to initiate some contracts, and adding this person to the software so he can use the existing contract request form would be one path to this team’s goal. So I could just do what they ask and move on, and they’d get what they want…kinda sorta.

But this isn’t usually my style. If you’re familiar with Ted Lasso…I’m curious. The team says they want…let’s call him Raúl…added to a software program. But what do they really want? They want a straightforward, repeatable way for Raúl to initiate contracts. And I’m not convinced adding Raúl to our project management software is the best way to give them that in this specific scenario.

I want to know more, such as:

• What isn’t working about the way they’ve initiated contracts in the past, or what improvements are they trying to make, that they’re asking for a change?
• What types of contracts do they typically need to initiate, and how standardized or customized are they?
• Are there any other ways Raúl might make use of our project management software, or would this be the only one?
• Do they realize that requesting a contract in our project management software basically creates a task for…we’ll call him Steve…to create and send that contract in a different software? Do they have permission for Steve to work on their contracts, as he’s in a different department?

Because I can think of alternate ways to meet this team’s goal that might be better depending on their answers, such as:

• I could create a single public-facing request form in our project management software that Raúl could use without needing to learn a new software program.
• We could set Raúl up in the contract software rather than the project management software.

I get straightforward-sounding requests like this all the time. Often they aren’t process-change requests like the above, but project requests: “I need a video.” “Can we order branded mugs?” “We have an ad due to an external magazine by the end of the month.”

My response: “Great! I have questions.”

This is the part of my job as a project manager where I feel most like a therapist. Somebody knows they need something, and they have some idea of what that is, so they start talking to me. I typically respond by scheduling a short meeting “to help me understand what they need,” in which I:

• Ask probing questions about their request that adds detail to their vision or exposes downsides they hadn’t considered, possibly causing their vision to evolve.
• Ask how their request relates to our organizational mission and/or other organizational endeavors happening at the same time, some of which they may not know about.
• Explain the implications of their idea for the people who will be involved in executing it, to ensure the effort/benefit ratio of the idea is worthwhile, and to make sure they understand what the project team will need from them to be successful.

People aren’t necessarily asking me to gently push back on them in this way. But because I approach these conversations with a positive attitude and kind words, requesters are typically willing to go with me on a journey to clarify their goal and consider getting it met in a way that’s more efficient, leads to better or longer-lasting results, or creates less work for others.

Depending on the size and structure of your organization, there may be more formal or less formal ways that ideas are tested and refined before they are implemented. But project managers are typically able to play this role at some level—if not for projects as a whole, then at least for aspects of projects or processes they’re responsible for.

Take the extra step. Be kindly curious. Help your coworkers and stakeholders achieve their true goals—don’t just do what they ask. You have the opportunity to make your organization, its projects, and its decisions better in countless ways in the course of doing your job.