16 Questions Project Managers Should Ask Before Starting a Project

It can be daunting—that moment when you find out you’re in line for a new project. No matter how big or small it is, there are a lot of things to take care of before your team gets going. In this article, I’ll explore what needs to go into those first few days before (and right after) the project kicks off.

This will not cover self-evident questions like “Who is the client?”, “What do they do?”, or “How long is the project?”. Instead, you’ll see granular things aiming to get to the heart of the client’s business objectives and the project goals. This article is meant to provide these questions as a guide for the process you should go through to arm yourself for whatever is about to come your way.

Let’s get started.

From Sales Lead to Project Manager

Once the client has signed on the dotted line, you’ll need to hit the ground running. A structured business development to project management handoff is a great way to facilitate a quick and effective start.

Make this handoff a priority, and come prepared with some of the following questions:

How did we win it?

It matters how we got the business—maybe one of your colleagues has a relationship with someone on the client side that you need to be mindful of. Maybe they read one of your company’s articles or social posts. Maybe they just Googled you.

Whatever it is, knowing how the engagement began will let you know how much time to spend familiarizing the client with your agency’s way of doing things.

Do we know who our main point of contact is?

We should always have a main Project Manager on the client side we’re regularly corresponding with. Take a quick look on LinkedIn or the client’s website for their bio. If they’ve had some digital experience, it’s likely you won’t be spending as much time setting expectations for a successful project.

Additionally, ask for an organizational chart when you get the chance. We recently had a client come in and talk about their entire company structure, from its parent brand down to its subsidiaries. It was immensely helpful for stakeholder management and controlling the feedback loop.

Is the launch (or project end date) based on something specific and/or set in stone?

Sometimes, clients are carefully planning this engagement to prepare for a major event—a conference, an IPO, acquisition, or something else. This will let you know how flexible the launch or the project completion date can be, if needed.

What’s the account growth potential?

Knowing whether a client is actively looking for an ongoing partnership, as Viget always is, or just a one-off execution given budget or timing constraints will let you know whether you should be actively identifying opportunities for future collaboration—but without losing sight of the current project.

This should be done strategically and in conjunction with your Account Manager or sales lead.

What should the business development and project management split look like?

There can be some blurred roles across agencies between Project Managers, Account Managers, Product Managers, Sales, or anything else related to client management.

At Viget, we have pretty distinct lines between Project Managers, who handle the day-to-day execution, and Digital Strategists, who manage the account from a high level and own future business development efforts. This is not always the case, so it’s good practice to hash out what the split between those roles will be.

On a related note, once you have eliminated any ambiguity, some key questions related to account management are a good next step. Is a quarterly client call for discussing budget and additional engagements appropriate? How about regular retrospectives to evaluate project health and client satisfaction? Should there be a weekly internal discussion to collaborate on future task orders, burn rate, and timeline?

Clarifying these responsibilities and touchpoints, and putting care into strategizing around them, will pay dividends down the road.

Is there anything unique about the billing structure or resourcing?

If your company sticks to one billing structure, there probably won’t be any surprises. But sometimes client requirements can call for something atypical. The more you know about this, the earlier you can spot red flags in your burndown.

Some more internal considerations you might need to address at some point in the project include:

• Are team members going to transition on or off the project?
• Are there opportunities for interns, apprentices, or new hires to shadow?
• How involved in the day-to-day should the Account Manager be?

What’s the client’s level of digital expertise?

A client who has had experience with digital agencies or works in the tech space themselves knows how these types of projects go. Almost always, that makes collaboration and communication more efficient, which is great for the end product.

If they don’t have that experience, use the sales lead's initial conversations to suss out how knowledgeable the client is about the process of digital work.

The client will certainly be the subject matter experts, but it’s not their responsibility to know the difference between an index page and a detail page, understand the nuances between product and graphic design, or be aware of the latest accessibility practices. That’s yours—but it’s also part of your job to help them understand it. And that needs to start from day one.

How responsive has the client been so far?

You can generally get a good idea of how responsive a client is going to be in the first couple weeks. The answer to this will inform how early and often you’ll have to set expectations for approval cycles, and to convey the risks if the client goes dark.

Are there any particular areas they have prioritized or will pay close attention to?

There’s a huge range of things this can mean. Some areas that come up fairly regularly for our clients include:

• Accessibility
• Support for older devices and browsers
• Performance
• Ease-of-use for content editors
• Security

Different clients have different priorities and resources. A company that’s going to open up their new website to lots of content editors will be interested in having an intuitive and flexible CMS. If an organization receives federal funding, that means meeting WCAG standards is paramount. Knowing this in advance allows you to allocate the appropriate resources to that area.

Are there any preliminary requirements we’ve gathered?

Requirements gathering is tough. Be thorough and pick the business development person’s brain for anything they may have heard.

For example, on a recent Wordpress build that included a relatively complex calculator feature, we collected a number of hefty documents with very specific equations, results, design states, and more—all up front. The nice part of this project was that it all came from the client, which means all parts had been reconciled with each other. Most often you’ll get a collection of background materials and your team creates requirements for the client to sign off on.

It’s almost always a good idea to have some sort of documentation that specifies creative guidelines, user stories (including edge cases), CMS functionality, and other components relevant to your project. If you dive into this process without first checking if the client already has these, you’ll be wasting valuable time.

From Project Manager to Internal Team

What are your personal goals for the project?

You’re probably going to be spending a lot of time with your team over the duration of the project. Knowing what they’re hoping to get out of the work, and telling them what you’re looking to do, builds empathy and camaraderie.

During an internal kickoff, I recommend setting aside a portion of the time to go around the room and have each team member talk about their goals and what would make this project a success for them professionally.

What risks do you foresee?

Similar to goals, each team member should have an idea of one or two potential risks. This usually comes from experience on a project of a similar type, previous work with the same client, another project eating up too much of their time, obscure technical or creative requirements, or some new industry trend or tool we've decided to use that is relatively unknown.

Identifying risks upfront will make it easier to keep an eye out for red flags and allow you to address and mitigate them early. Oftentimes, I find it’s the same risks over and over, regardless of the project (content migration and stakeholder management being the Big Two™).

How should we communicate? / What tools should we use?

It seems simple, but there are so many ways to communicate with your team nowadays that it becomes crucial to nail down what should happen where—otherwise, you’re bound to lose some important piece of information because it was in a different place than you thought.

For communication, we primarily use Slack, Basecamp, and Google Suite. If you also throw into the mix some project management tool the client asks us to use (Trello, Monday, etc.), things get more complicated. And this doesn’t account for work in places like GitHub, Airtable, Figma, Whimsical, and others.

It’s a lot to keep track of, and you’re probably the one in charge of wrangling it all—you can do yourself a lot of favors by setting and championing a communication process early.

From Project Manager to Client

What problem are we trying to solve with this project?

“Visitors don’t understand what we do” and “Our brand is fractured” are pretty clear problems. But we’ll need to get more specific.

Here’s a great example: “Nest Realty was looking to overhaul their disjointed internal systems to provide their agents and brokers with a custom, all-in-one software solution for managing their business process.”

That’s a clear, understandable, and succinct proposal to solve a (not uncommon) problem of lots of disparate systems creating a fractured digital ecosystem with some technical debt.

This is not necessarily an opportunity to get too in the weeds (that’s the next question). The answer to “What problem are we trying to solve?” should be a “north star” when you start to get caught up in the actual work and lose track of the team’s overarching goal. It’ll happen, and this is a good way to prepare.

What are we delivering?

But actually, what is it? “We’re delivering a website” is not good enough.

Try getting to something like this: “We’re building a Craft CMS to manage product data and other content for BDI Furniture’s main e-comm site. We’re also redesigning and reimplementing the public site in Craft, and writing site copy.”

Notice how this is specific enough to give you a foundation to get to a development plan. There are still plenty of questions that need answering and discussions to have, but with something like this, everyone will go in with a shared understanding of the project.

Here’s another example: “Leverage React Native and ReactJS to create three separate apps, each with its own developer owner, and a single product designer to help tie them all together.”

These clarify the main technical approach (Craft CMS and React Native / React JS) while also hinting at an application (e-comm and public site) and a project vision (a shared design system and a separate developer owners for each product).

And finally...

What does project success look like?

Validations of success for digital products are mostly empirical. For example, we saw great results for our redesign of wcs.org. Our success with this project, measured quantitatively, was clear: The result was “...a new home for a 120-year old organization that led to a 59% increase in donation revenue at the end of the first year. Continued split tests and optimizations drove an additional 23% in end-of-year giving during the second year after launch.”

However, it’s much more challenging to define and set success metrics before a project. Our data team sets baselines from historical information and trends, which we revisit three months after launch.

We find this holds up pretty well. But there is a non-analytics aspect to defining success: what the client thinks of the result.

You can measure user sentiment and perception in a few ways, the most common of which are surveys or interviews. But a bulk of validating success comes qualitatively from the organization you were working with. For a client, it can be arbitrary and differ from person to person. But if you’ve been transparent, clearly defined the business problem(s) and proposed solution, and collaborated regularly with their team, you shouldn’t encounter any disappointment or surprised reactions. This is even more important when you are creating something that isn’t easily measurable (copy, brand strategy, etc.).

Conclusion

The spirit of asking these questions before starting a project is so you know as soon as possible what you’re doing, why you’re doing it, and how you’ll be doing it. As a Project Manager, one of your key responsibilities is to be able to answer these questions—without really even having to think about it.

You should be the one to articulate the vision and the plan, and work to always keep everyone on the same page. If you can make that happen, success will come naturally.