The Optimal Moment to Bring in a Project Manager

Project managers: have you had the experience of being brought into a project too late?

Maybe everyone else on the project team has already been informed about the project and begun work, and someone finally thought to contact you “so somebody can keep track of things.”

Or maybe you’ve overheard about a project that still nobody has thought to involve you in, and you feel like you’re watching a train speed down the tracks, likely headed for a crash or some major issues if you don’t chase it down and get a handle on the controls.

We know in these moments that something has gone wrong. We feel ignored and underappreciated or, even if we set our personal feelings aside, we weren’t given the opportunity to provide as much professional value to the project as we could have.

It’s less common, but have you ever been brought into a project too early? Usually this is less frustrating because it’s nice to be included, and I personally always love more context on the projects I’m leading. But at the same time, if you’re busy—and you probably are—you might feel like you’re spinning your wheels trying to keep track of ideas that haven’t been solidified into decisions. If you’re in enough early project meetings like this, you might start to feel like there are more valuable things you could be doing with your time.

While it would be nice if our companies always knew exactly the right time to involve us in projects, it is likely up to us—either on our own or in partnership with our PMOs—to teach them. If you’re in this position, read on! My goal in this blog is to give you language to describe how projects develop, and to describe the shifts that indicate NOW is the optimal time for a project manager to be brought in.

How do projects develop?

All projects, whatever internal language or processes your company may use, need to proceed through these very basic phases:

1. Ideation

Before a project exists, there’s a process by which people discuss what might be done, or if anything needs to be done at all. Sometimes this is part of a formal organizational cycle: “We have these company goals for the year; what projects might we undertake to meet them?” Sometimes it is very informal: somebody has an idea out of the blue that is generally in line with an organizational strategy, and they start talking about it with the relevant leaders, the relevant subject matter experts, or maybe just the people right around them.

But eventually the seed of a project idea makes its way to the appropriate person to own or sponsor it, and that person continues the ideation process of what might be done until…

2. Decisions

…decisions are made about what will be done. Sometimes decisions happen quickly and only a few decisions are needed to establish a project. Sometimes what a company decides to try to achieve is complex and many decisions are required. Regardless, here are a few keys to the successful completion of this stage:

• These are decisions about the outcomes or deliverables of the project, not about how the project will proceed. What will we do or make? What—as PMI would say—product, service, or result will we set out to achieve?
• It is important that the correct people in the correct roles are the ones making the decisions about whether we will do something and what that is, and also that the correct people have the opportunity for input. If the wrong people try to make decisions about a given project, chances are the right people will find out about it later and have something to say about it, if not significantly change or cancel the project. (If you happen to be involved at this stage, a good RACI chart can help you speak up about getting the right people at the table.)

You might equate this with the idea of a project being “chartered.” Some companies have a formal chartering process with a charter document and rounds of review and approval. By contrast, the only charter some projects get is an email or a verbal direction from someone in authority saying, “Please do this thing.” But if the person has the authority to approve this type of project, and the authority to commit company resources to make it happen, then the project has been chartered.

More colloquially, the project is exiting this stage when the right person or people say, “We are going to do something, and here is basically what it should look like when we’re finished.”

3. Planning

During the planning stage of a project, you take the vision for the project that came out of the decision stage, and you figure out how that vision will be achieved. What steps are needed? What people? What materials? How long will it take? What risks should be considered and planned for?

Whereas in the decision stage, the product, service, or result was planned, in this planning stage, the project to create that product, service, or result is planned. The decision phase is about what. The planning stage is about how.

4. Execution

This is the stage where the team starts the actual work of the project (which will create the desired product, service, or result). Tasks were decided and ordered during the planning stage; now those tasks begin to happen. Pivots from the plan may happen along the way, but the point is that our result is now coming into existence.

Note: if you’re familiar with the five PMI “process groups” of initiating, planning, executing, monitoring and controlling, and closing, popularized by several editions of the PMBOK® Guide, I’m not throwing those by the wayside and giving you a different set of terminology just for fun. I also find those helpful! But I describe the progression of a project the way I do above because I find it a bit easier for the non-project-managers you’ll be discussing this issue with to relate to, and a bit more relevant to identifying when a project manager needs to get involved. So without further ado…

When should a project manager be brought in?

Here is my basic, core answer to this question: with respect to the stages I describe above, a project manager should be brought in after decisions have been made about what we’re doing (after stage 2), but before we begin planning how we’ll do it (before stage 3).

The reason it’s best to bring us in after stage 2 is that project managers typically don’t have the authority to decide what projects our companies will take on.

But more importantly, the reason it’s best to bring us in before stage 3 is because guiding a team through a planning process is one of the strongest forms of value we provide to our companies in our role. This is our core expertise. If somebody else with less expertise leads or begins the planning process, the quality of the plan is likely to be lower—and therefore the chances of project success are likely to be lower.

We stay involved through stage 4 and certainly provide a lot of value then too, keeping things on track and helping to solve problems. But we provide our best value at stage 3 (because we can prevent problems in stage 4!), and it’s the initial point we’re needed.

Waterfall vs. Agile Projects

In a waterfall project, these 4 stages tend to proceed roughly in order, one after another, so this “moment” is relatively easy to spot. In an agile project, these stages are revisited over and over, so which transition from stage 2 to stage 3 is the right one? I’ll answer that in 2 ways:

• The first one. The first time there is any planning, you should be there, because you are the expert at planning.
• When it happens for the project as a whole, regardless of how many iterations of these stages may happen during “sprints” or equivalent increments. Sprints are in some ways, for the purposes of this discussion, all part of execution…though you should be involved in the planning that happens during them because, again, you are the expert at planning.

This isn’t a perfect boundary or moment.

“After stage 2 and before stage 3” sounds like a nice clear line in theory, but often it’s not.

Sometimes it’s genuinely useful to involve a project manager while decisions are being made, though in these cases they serve more as a subject matter expert on process than fulfilling a core job function. Sometimes in an emergency the best people to begin planning are the people who are already there and can keep things moving. (Sometimes. Maybe.)

And sometimes it’s hard to tell exactly when the shift from stage 2 to stage 3 is happening, because there’s overlap. It’s okay, you and your company won’t get it perfect. But you can get it better, more often. Here’s how.

Helping others recognize the optimal moment

Okay, so now you understand the optimal moment for a project manager to be brought in on a project. That’s great, except you’re not usually in the room when this moment happens. So for any of this to be meaningful for you, you need to teach others at your company what this moment is and what it looks like.

If a coworker gives you the time and attention to really understand when to bring in a project manager, please steal my stages and descriptions above, so they understand a project manager’s key role within the flow of a project. Indeed, if you’re having a lot of trouble getting people to bring you in at the right time, you may want to organize a lunch-and-learn to teach this entire framework.

But if that isn’t the right fit for your situation, then keep the deeper understanding in your own mind, and use it as the backdrop for providing nuggets of direction that are easy for others to digest, such as the following:

A brief conversation

Here's are some examples of how I might explain this optimal moment to a project owner or sponsor at my company:

“Feel free to have discussions about what results we’re trying to achieve without me. That’s your domain! But once you’ve decided what those results should be, please pause and check in with me before you start planning how you’ll achieve them—before you start identifying what team members to contact, what tasks need to happen, or what timelines might be realistic. That’s what I’m here to do, and that’s what I’m really good at! If you bring me in before planning starts, I can help get us to your project results as smoothly as possible, with the least hiccups.”

“It’s totally fine to figure out IF we’re doing something or WHAT we’re doing before getting in touch with a PM, as long as I’m involved by the time we’re figuring out HOW we’re doing it, and to set everyone up to proceed with the work” (I actually wrote this in an email this week).

A rule of thumb

Here are some rules of thumb that might capture when the shift from stage 2 to 3 is happening, making it easier for your coworkers to recognize the moment and remember to contact you:

• Contact a PM before asking anyone outside your immediate team to do new work (this one is effective at my company).
• Once you know what we’ll do, let me help figure out how we’ll do it.
• You determine the results we’re after; let me determine the process we’ll use to get them.
• Project managers are the ones who put projects into our tracking software (this might be the right moment at your company, or it might be a bit late, but it will keep people from involving you really late).
• Contact me as soon as the charter is signed.

What if they don’t agree?

What if you try explaining the best moment to bring you in, but the leader you’re talking to doesn’t agree with you—or, to put it plainly, has a different understanding of what your role is/should be? What if they, for example, just think you’re a glorified secretary?

This is a very different issue, and for the purposes of this blog I’ll mostly say this: try to have a moment with yourself where you recognize this is a “them” problem, not a “you” problem. You have a lot of value to offer, and it’s their problem that they don’t see it, or aren’t giving you a chance to show it. Don’t internalize the limits they’re placing on you.

If you have a good relationship with your boss, they should be your first stop with a problem like this. They should be the primary defender of your ability to do your job well and provide your best value to the company.

Otherwise, assuming you plan to stay at this company and this one barrier isn’t part of a larger toxic company culture, keep shining in the areas of the company where you’re supported in doing so. Over time, your successes and the praise of others may be the tidal wave that washes away that person’s resistance—either by personally convincing them, or by other leaders no longer permitting this person to deviate from the processes that are making all the other departments successful.

Commit to educating your coworkers.

I hope you can see that you will make your company more effective, and the experience of project managers at your company more enjoyable, if you have a clear understanding of the optimal moment to bring in a project manager and are ready to teach those around you in situationally-appropriate ways.

You have so much to offer projects in the planning stage. Be your own advocate, so that others will create the space for you to shine.