Project management: best practices from the trenches

Projects are everywhere in work life, and everything is a project. Yet very few people have had training in project management that would help them be effective. Almost everyone needs to figure things out on their own.

This lack of training leads to situations like all-nighters before a big meeting when you realize you’ve forgotten to do part of the analysis you need for tomorrow, mistrust in the project team because of seemingly unfair division of responsibilities, and project teams spinning wheels for months because of lack of clear buy-in from the project sponsor.

I’ve had two classes of experience in project management. In management consulting, the whole job is structured into formal projects, where each client engagement = project. Projects run anywhere from one to six+ months and generally are staffed with a team of consultants (3-15+ people). You get trained on the job, day in and day out, by your colleagues – partners, project leaders, and more senior consultants – how to run a project effectively. In startups, project management looks less formal (e.g., most of the time, a 40-page deck with a 60-page appendix isn’t required), but my teams and I have found value in applying a structured project management approach, especially in our work on the Business Operations team.

Here are some real examples of projects a BizOps person might be asked to do:

  • Help the customer support team not have 10,000 tickets in backlog
  • Help Product Management figure out how many integrations to build, and which ones
  • Open up our first international office and make it successful
  • Establish a yearly planning process that doesn’t suck

Every one of these projects requires structured thinking, problem solving, stakeholder management, and ultimately getting things done. To help ourselves, we’ve written down a few things to remember at various junctures of a project. I’ve taught these to a broader audience (engineers, product managers, marketers, recruiters), and folks have found these applicable in their contexts as well. I hope these pointers help you in your projects!

Before project start

Think through whether the project is actually needed and needed now. Will it be impactful? This is especially important when the project was started by some other person or function and you’re inheriting it. This is the perfect time to think about it for 30-60 minutes and come to your own conclusion of whether it makes sense, and in what way.

How well does it connect with company and team goals/OKRs? Assuming you have clearly defined company goals, this should be a relatively easy check. Even if company goals aren’t super crisp, it’s a good idea to ask this question to yourself and/or your manager. This type of check has resulted in a few of projects being postponed from my BizOps team’s agenda because it didn’t map to company goals – that was great: it ensured we worked on stuff that mattered to the company.

Be ready to say no to the project at this point! If you said yes to the project…

Write a project plan

  • Required parts to the project plan:
    • The components
      • Core issues and hypotheses
      • Metrics the project will affect, ideally by how much
      • Can the question even be answered deterministically?
        • If yes, lay out how you’ll get there
        • If not, consider cutting down the “formal” approach to solving the problem via modeling and deep thinking, and instead rely on piloting, quick hypothesis validation from inside and outside sources, etc.
      • Clearly laid out deliverables
      • Clearly laid out “end of project” – the more practical, the better
        • E.g., “Sales is trained on new pricing” is better than “Deliver new pricing to Sales leadership”
    • The people
      • Who is the main client? If in doubt, take the nominal client and go up the chain of command until it becomes absurd. Check with the nominal client and your manager that you’ve got the right level nailed
      • Gather intel on the working styles of your main clients
      • Collect the main clients’ expectations from the project
      • Ask your main clients how much they’d like to participate in the project and from what perspective (with examples)
        • “Would you like to be in working sessions or just the three main check-ins?”
        • “At what point do you want to see “the answer” – at 20%, at 50%, at 80% readiness?”
      • Consider the RACI framework – clearly define who will do what
      • If folks from other teams are involved in the project, make sure you have their manager’s commitment of their time and level of involvement for the time during which you want them to participate (i.e., during those particular 3 weeks vs. “in Q2”); make sure your project is in their OKRs if appropriate
    • The process (i.e. how will you answer the question?)
      • Clearly lay out workstreams (separate out different streams) and try to tie back to how each one answers the question
      • Build in a feedback loop so after the thing is implemented you can check in to see what impact it had. Bonus: make your next self-review writing a breeze!
      • Make sure you have a Gantt chart, and that it’s built from deliverables, not activities
        • Have you accounted for holidays and various people’s time off?
        • Have you left a week of buffer for the inevitable unforeseen circumstances?
        • Have you accounted for other work commitments you have during project time?
        • Have you ensured that the timing of what is required in each workstream works with the business cycle (e.g., trying to have a working session with Account Executives in the last week of the quarter probably isn’t going to be possible)?
        • Be sure to make the Gantt chart a ‘living’ document and modify it as the project unfolds and things develop – but keep a copy of the original plan so everyone can later check how things went according to the agreed-upon timeline
      • Are you relying on one type of data (e.g., “the model” you’ll build or “talking to the Sales team”) or are you diversifying your data sources to triangulate better? Possible sources of data:
        • Internal data and its analysis. Example: ARR for all our closed-won deals since the dawn of time
        • Internal interviews
          • Structured conversations with the “client” team
          • Unstructured “brainstorming” sessions with folks in the company who may have intuition on a subject matter
          • Guidance from the company’s leadership
        • Customer interviews or surveys
        • Industry expert and practitioner interviews
        • Communities (e.g., Modern Sales Pros) that you can learn from and ask questions to
        • Published research. Examples: analyst reports, market analysis
        • Competitors’ publicly available data. Examples: S-1s, 10Ks, 10Qs
      • Define formal check-ins with the “steering committee,” get them on the calendar – fewer of these
      • Define formal check-ins with the project team, get them on the calendar – more of these

Get your support network in place. Who can help you on this project beyond the obvious – your manager? This can include your teammates, a contact within the “client” org, and your industry contacts.

Check in with your skillsets. Which skillsets do you think this project will rely heavily on Which of these are you already strong in, which will you need to stretch or develop?

Check in with the company’s internal capabilities and toolsets

  • Which tools and capabilities will this project rely heavily on? E.g., will you require data that is not readily available? Do you need to get someone from Engineering or Analytics on board?
  • Do the capabilities currently exist (if so, who owns them?), or will they need to be developed?
  • Are there any tools that will help in the course of this project that might be really valuable? If so think about if (and how) it makes sense to get access to them.

At project start

Manage stakeholders

  • Get your main ‘client’s” input as early on as humanly possible, after you’ve gotten up to speed on the topic enough to sound somewhat credible
    • Go there with core hypotheses and questions that’ll help you focus on the right kind of work
    • Put your main client and your nominal client in the room and make sure they agree on core things (e.g., what are we optimizing for here? what will be the likely tradeoffs)
  • Consider the soft side of project management: motivation, encouragement, excitement of people around the subject matter. How will you make this happen?
    • Get the broader project group / stakeholder group on board with the WHY, WHAT and HOW of the project + what they’re committing to in terms of cadence, work, etc. Look them in the eye and make sure they understand what’s required of them and are on board to contribute!

Put plans in place early. Think about if you are likely to need to liaise with CSMs to get customer feedback, or Analytics to get particular data, etc.? Give them at least a heads up at the start of the project so that they can plan and prepare to provide you things at the right time. Panicked ‘can you do this today’ asks rarely work out well for anyone!

Watch out for data quality. Assume by default that all internal data is wrong (it’s not, but that’s a good mental state to be in). After you’ve got the data, get somebody who has an intuition about that particular dataset (e.g., for ARR amounts on closed-won deals, get a Sales manager) and pretty please ask them to spot-check it, ideally after you’ve cut it a few ways so they see patterns.

During the project

Stay on track

  • At the beginning of every week, check in on your progress
    • Are things on track compared to your original Gantt chart? If not, what can you or others do to get them back on track?
  • Check in with how you’re generally spending your days and weeks

Ask for help

  • Your goal is to make sure the value gets delivered. That doesn’t mean that you must be the person that delivers every little piece of the value – use your network well!
    • Project team members could actually do work and might want to do it
    • Your manager can help brainstorm content and unblock stuff
    • Your main “client(s)” will have thoughts/opinions/contacts

Communicate with stakeholders

  • Make sure that the right people are clued in and involved in decision making at the right time. The worst thing is coming to the end of a project and someone pointing out that the decision you made 3 weeks ago was the wrong one
    • Weekly status updates and/ or informal check-ins on project process (e.g., water cooler conversations)
    • Plan for sessions with the extended team at key decision points in the project timeline and ensure attendance (or at least reading of the materials!). Do NOT assume that if you sent the email and didn’t hear back people agree to everything you said in it – follow up with key stakeholders until you’re sure they’re on board
    • Just plain ask your stakeholders if they know where the process and the content are and whether you should change anything in how you communicate

After the project end

  • Make sure to formally end the project, hand over all materials, do one last check on metrics. Document what needs to be documented. Hand it over to the “client” in an email with links to documentation
  • At this point, it may be useful to run a project team lookback/postmortem to get closure and collect learnings
  • Separately, this is the right time to get feedback on your work from your key stakeholders – ask your manager to help!
  • Remember to check in after the project to update yourself on progress. Do a project post mortem 1-3 months after to understand:
    • Is the proposed solution actually working? Should we do future work to fix/expand/contribute more here?
    • Has anything come up in implementation that I need to consider for future projects?
    • Is the “client” comfortable with the outcomes of the project and the way that it was run?
    • Have I learned anything in the meantime that could be applicable and shared with “client” or whoever is currently working on the topic?

Troubleshoot the process

  • Mantra: to get to value for the business, process is as important as is “the answer” to the project. In fact, to get to “the answer” that sticks, you’ve got to have solid process. Approach project process design as a mini-project in itself – give it actual thought and check in with its effectiveness as you go!
  • Get people to do stuff they said they’d do
    • Try to understand the motivations of the person/group: is your stuff helping them in visible ways? do they realize it? what’s going on with them/what’s important to them so you can explain how your stuff will fit with their priorities?
    • Follow up with written notes via email from every meeting, clearly stating action items people took on (and make sure that people realize they’re taking them on). Remind them in a reasonable timeframe ahead of the next check-in that they’ve taken on the action item and inquire if that’s still happening
    • If the action item will take non-trivial time/effort, make sure the person taking it on can fit it into their OKRs (ideally it will already be in there because you foresaw that this would need to happen!)
    • Escalate if needed!
  • Get the meeting cadence right
    • Think through cadences for different style meetings at the beginning of the project. Often, this will mean “steering committee” meetings on longer cadence and “project team” meetings on shorter cadence. Get them on the calendar immediately – it’s always easier to cancel/move a meeting than to set up a new one
    • Actively consider having steering committee meetings twice or three times during the project. Most likely, you do need them even if you don’t think you do! Steering committees are important because they are an excellent chance to get all stakeholders to discover the answer together, to kick its tires and to agree to it. On larger projects, bringing people along with you is critical (vs. going into a corner, doing a bunch of work and then presenting the final result and hoping people will magically agree)
  • Get meeting productivity up
    • Presend material with 2 days notice
      • Have a clear agenda for the meeting when sending out the preread so people can prepare mentally: “This is a decision meeting. We want to come out of it with decisions on topics X and Y” or “This is a methodology vetting meeting. We want to come out of it with agreement on these finer points of methodology.”
      • Clearly ask people to read through it while keeping questions X and Y in mind
    • At meeting start, don’t assume people have read and/or understood the preread. Walk through agenda and desired outcomes for the meeting. Don’t speed through it. This is not “logistics” – it’s a vital part of the meeting. Look people in the eye and make sure you’ve got them on board
  • Get buy-in from busy people
    • Insist that you need focused time (can be async, or may need to be in person) – work with EAs, trade horses on schedules, just get it done
    • Provide context on why it’s important to have the meeting on this timeline
  • Keep excitement and productivity level of project team up
    • Work on creating an atmosphere of psychological safety
    • Vary your style during meetings, meeting length/location/purpose
    • Find new ways to remind people why they’re doing this work
    • Bring in new facts (“Wanna hear something cool?..”) that are at least somewhat relevant to the topic
    • Are certain team members under water with other work? Can other folks step in to help?
    • Celebrate successes – large and small! Find ways to dish out praise in public and private forums
  • Get the “client” to become a true champion
    • Before taking on the project, ensure that the “client” wants the project done, understands what it will do for them, agrees to doing work / dedicating team resources to it. Otherwise, refuse the project or find another sponsor
    • “Make something people want” – deliver something useful to the “client” in a manner that’s value-additive to them
  • Get stakeholders to agree
    • Clarify the structure and tradeoffs there are for this decision – as the person who’s closest to the topic, you’re uniquely positioned to do this well. This is a great time to let your problem structuring skills shine
    • Have a point of view and share it constructively; you don’t have to hold it back!
    • If agreement seems far away right now, agree on the process to get to an agreement, then follow that process

Meta behaviors to lean on

  • Have empathy for the person/people you’re interacting with. Put yourself in their shoes: are they prepared for the interaction? Do they know why they are in the room with you? Are they able to pay attention to the content?
  • As a project manager, it’s your job to deliver results. It is not your job to do all the work yourself
  • Assume the person/people you’re talking to about the project don’t have the context. This applies to people you’ve talked to about the project in the past. Provide context at every opportunity/meeting/email. Context includes a brief summary of why we’re doing this project, how it connects to company goals, what the expected result of it is, and where we are in the process
  • Communicate progress and “the answer” updates consistently and frequently to the core project team and sponsors to bring people along with you
  • Just ask the stakeholder/client/anyone about how they’d like to participate, what they think, whether they’re happy with the level/frequency of updates

I hope you’ve found some useful approaches and tips in here. Have more concrete questions? Ask them in the comments!

Thanks go to James Wood who has originally co-developed this content with me

Leave a Reply

Close Menu