Why questions will lead you to effective project management nirvana

“Any questions?”

The phrase is uttered in millions of offices and conference rooms around the world.

Typically the person who says it is a project lead or manager who has just presented information on how something will be done or what the other people in the room will be expected to do.

If you’ve ever been in a meeting when someone says it, you know the drill:

There’s the awkward pause as people glance around the room and shift uncomfortably in their chairs. Who will be the first person to ask a question? If I ask my question, will I look incompetent for not knowing the answer?

Often the people confident enough to ask questions in a meeting aren’t the people who most need to have a question answered.

Even knowing what questions are okay to ask can have high stakes. If anyone has questions about why a decision is being made...well then. It’s best to keep those questions unasked, since they may be interpreted as undermining a superior’s authority.

If the questions go on too long, the person running the meeting announces that folks can send questions via email, but by the time people get back to their desks, lingering questions or uncertainties may be forgotten as they focus on other things.

“Any questions?” is office code for “our meeting is almost over, so go ahead and mentally check out.”

Unasked questions can lead to disaster

The lack of engagement in meaningful inquiry is a missed opportunity for effective project management. It’s the biggest reason projects fail.

According to Harvard Business School’s Clayton Christensen, 95% of new products fail. And good luck if you’re managing an organizational transformation: while the current statistic is up for debate, long-time experts in the field of change management observe that most organizational change efforts go down the tubes.

Here’s why: when you leave questions as an afterthought to your project management methodology, you’re allowing the status quo to guide your project. You assume you have all the answers because that’s the way things have always been done.

The common adage is “if it ain’t broke, don’t fix it.” The problem is, in society and in business, we often accept broken things as the norm––without question.

Doing something because “that’s the way it’s always been done” is the death of innovation and progress. Maintaining the status quo defeats the purpose of a project dedicated to transformation.

The way project management has always been done

Okay: imagination time. You’re assigned a project that you need other people to help you accomplish.

What do you do?

If you’re like most project managers doing what’s always been done, you follow a linear project methodology. Something that looks like this:

Let’s pretend you’re leading the creation and implementation of a new remote work program (yay!), and you follow the Waterfall methodology (yawn). Here’s what your project leadership would look like using the above methodology:

1. Requirement gathering and documentation

• You ask (or delegate someone to ask) project stakeholders what is required for the new remote work program to be considered a success.
• You report your findings to your team, and document the project scope through phases, milestones, and deadlines.
• You assign tasks according to each members’ role.

2. Design/Implementation/Testing

• Each team works on their portion of the project and passes the work down, assembly line-style, as tasks are completed.

3. Delivery/Deployment

• If the new program meets the original requirements, it's considered a success. If it doesn’t, it's considered a failure.

The problem with project assembly lines: they break down

Okay, so that’s the ideal scenario. It doesn’t take human error, biases, blind spots or physical reality into consideration.

Let’s rewind. Here’s what your project looks like in stark, gritty reality:

1. Requirement gathering and documentation

• You ask the project stakeholders (aka executives and board members) what’s required for the new remote work program to be considered a success. They get back to you with vague answers, or come up with a gigantic list of requirements and an arbitrary deadline. You already feel directionless and overwhelmed.
• You report your findings to your team and pull together a Gantt chart of phases, milestones, and deadlines, based on remote work programs you’ve led in the past. Your team leads push back on the deadlines because they have limited resources/staff, which creates a constant tug-of-war between the requirements you’ve been assigned from above and your team’s ability to deliver from below. 
• You assign tasks with deadlines to each team member, crossing your fingers that no one gets sick or falls behind. (Spoiler alert: People get sick. Tasks go past due. Stress levels rise).

2. Design/Implementation/Testing

• Each team works on their portion of the project and passes the work down, assembly line-style, as tasks are completed. See above spoiler alert.
• You hold random meetings to get everyone on the same page. These are the kind of meetings that end with “any questions?” After the meetings are over and teams get disconnected again, everyone falls off the same page.

3. Delivery/Deployment

• You deliver the new remote work policies and strategy on deadline and according to their requirements. But it’s not something you’re satisfied will deliver the results they’re after.
• When your organization implements the policies, you’re proven correct: your remote employee retention rate is terrible, your department heads constantly complain about the lack of productivity, and the company eliminates the remote work program altogether. 

Can you relate to this scenario?

Notice that the requirement gathering phase is the only portion where questions are a formal part of the process. The traditional methodology assumes all questions should be answered (usually by organizational leadership) before work on the project begins.

Can you see how this makes for a fragile framework that breaks down if unexpected––and inevitable––circumstances come up?

Question-led teams are curious and resilient

What makes a successful team?

If you answered its ability to meet assigned requirements, you’d be incorrect.

A team’s success lies in its ability to sniff out challenges, enthusiastically learn from them, and bounce back with innovative solutions that deliver results.

Treating questions as a meaningful catalyst throughout the project lifecycle can reveal hidden complications that lead your project astray. They can help you predict negative outcomes before they happen. They can illuminate the underestimated skills, experience, and knowledge of every person involved in the project so you can better innovate in response to what’s right for your stakeholders.

Project management nirvana

Can you imagine leading a team where every member takes pride and ownership in their contributions? Where the success of your project is determined by the positive impact it makes rather than the checklist of requirements it meets?

Highly engaged stakeholders and teams aren’t a fairy tale. They do exist. And it’s entirely possible for you to lead your team to transformational success.

How? By adding one missing ingredient to your project management framework: a formal questioning method, known as a Qvest.

Any questions?