The project management timeline equation

Figuring out how long a project will take is the most complex thing you'll do. It’s the most common question from stakeholders, the biggest concern you'll have about meeting expectations, and probably the thing that'll keep you up at night wondering if you got it right. 

In my many years of shipping projects, I’ve developed an “equation” that helps me explain to partners, executives, and other decision makers how I define and adjust timelines. Developing this understanding with stakeholders provides a framework for discussion that makes it easier to request resources, adjust timelines, and reduce scope when necessary.

Defining your timeline

Determining a timeline requires first defining two elements: requirements and resources. Requirements are the scope and goal of the project—what you're setting out to build. Resources are the tools, person power, and capacity you and your team have to build it.

In a project kick-off process, you, the project owner, and stakeholders will define these elements independently by asking detailed questions, documenting the answers, and ensuring all decision makers and team members are in agreement. Dig into our Project Management Handbook for a step-by-step approach to conducting effective project scoping.

Once you’ve defined your resources and requirements, you can begin to define your timeline using this approach:

Requirements / Resources = Timeline

Here’s how you can think about this. The quantity of resources you have to apply to your requirements will determine how long the project will take to complete. You can adjust either the requirements, resources, or timeline to reflect your organization’s circumstances.

Start by asking: is one or more of the elements of this equation inflexible? For example, if there’s a hard deadline, the timeline will determine what resources you need to meet desired requirements. Or if both the timeline and the resources are fixed, that might determine the scope of the requirements that you're able to build.

A caveat: These rules apply in circumstances where your ultimate decision makers are reasonable. They're interested in preserving project quality and some level of quality of life for the team. They're not interested in shipping a project that folks can't be proud of, just to say that they shipped it. And they're not interested in simply expecting the project team to sacrifice nights, weekends, other projects, etc. to maintain a timeline that's no longer reasonable.

Let's talk through some scenarios on how to use this equation.

The requirements change

Often, when you start a project, you haven't dug into the details of building something enough to understand how significant the requirements are. For example, perhaps you set out to build an integration between your app and another. You think at first that this is a small lift, because you have two engineers available, and the scope of work feels small. You are connecting a few API endpoints to meet the needs that your product manager outlined with one customer story.

In partnership with the engineering lead, you estimate that this is about 4 weeks’ worth of work, which gets an estimate of 2 total weeks with 2 engineers available. You and your team begin building the integration, and as you shift into user testing, you discover that you don’t have the correct endpoint in your code that you need to complete the integration.

In this scenario your requirements have changed, and you realize that either the resources or the timeline will need to change to reflect this new circumstance. You open this conversation with the project owner, and they want to keep the original timeline and meet the increased requirements. That means you'll need to add engineering resources. At this point, a strong project manager should explore all the ways to do this. Can you pause other projects so additional engineers can focus entirely on finishing the additional endpoint? Can you hire a contractor to help supplement the team? Can you borrow an engineer from another department that’s ahead of schedule on their current work?

The PM equation helps you outline to your stakeholders how and why you'll need to increase the resources in proportion to the increased requirements to keep the initial timeline.

The timeline changes

One more scenario: you're the PM for a marketing team working on a new campaign and there's no fixed timeline just yet. The CMO (project stakeholder) has set out some ambitious requirements to address a new audience sector and the team is doing research, conducting a survey, and developing concepts.

Then your CMO finds out about an upcoming conference and decides to debut the new campaign as a leading sponsor. Your team panics—there's not enough time to build a high quality campaign with the folks they have, and no budget to hire a contractor. So the timeline is fixed, and so are the resources. What will need to shift, to ensure you can deliver a high quality product and a happy team, is to reduce the requirements.

Now the PM shifts into facilitating the right adjusted requirements. You work with the team to develop and reduce the scope of what’s delivered with the new tight timeline, and propose this to the CMO. She signs off on asking the marketing team to define a tight pitch and tagline focused on this new audience. They hone in on creating a narrative you deliver in your booth aesthetics and through your in-booth sales team. The CMO decides to save the full outbound campaign for phase two so they can deliver a high quality conference experience. In this scenario, you’ve helped facilitate a high quality outcome, while keeping channels of communication clear among the team and the project stakeholder.

Using the equation to create decision making frameworks

These scenarios outline how you can frame project timelines in a clear equation, which helps keep all members of a project team aligned. It also ensures that project team members aren’t bearing the full brunt of making timelines work when circumstances have changed, which creates more sustainable workflows resulting in less burnt-out teams. This is key for building trust with colleagues, setting clear expectations with your stakeholders, and helping you sleep through the night.