How to Keep Projects on Track

I begin this piece with a caveat that the below advice is hard-won through experience (e.g. I have not always followed these guidelines), not something you can always put into practice, and not completely my original design. As with many frameworks, creating and following one is more important than what you include within. But here's the process I strive to keep with every client. It's more about the mechanics of keeping a project running well, that how you actually manage the project (as that is very dependent on what work you're doing).

1) Kickoff properly. An absolutely mandatory introductory meeting with as many people who will be involved in the project as possible. As a contractor, I strongly advocate for everyone who is ultimately involved up until the final decision. If that means the CEO, get them on the call (if possible). It's important that everyone know each party's responsibilities and that the collective aligns on goals, KPIs, and timeline. Now is the time to question any aspect of the project that feels misaligned to those goals or may detract from the core mission.

2) Assign the project manager. If you're blessed enough to have a dedicated project manager - the person responsible for making sure everything runs smoothly - congratulations. If you don't, someone will have to moonlight in that (oftentimes thankless) job. They set and enforce the project rules, solidify timelines, and generally ensure the project finishes on time. They need to command respect from everyone and often have difficult conversations.

3) Assign roles. Everyone on the project team needs a role (but it's more likely they'll have multiple roles). Have a foundational document somewhere prominent that identifies and details each person on the project and their role(s). When multiple people share a role, you need to drill down into the specifics and who is responsible for what. Decide whether they truly share joint responsibility or whether one manages the other.

4) Set and simplify the tech stack. So much time is expended on wasted activity, like - searching an inbox when the communique you need is in Slack or Asana. Is the folder in Teams or Google Drive? Unless the client has established absolute discipline about technology, you may have different people in different departments that prefer different solutions (not to mention the preferences of the vendors and agencies).

5) Cement the approval chain. For this, you begin at the end. Who has the final approval? And then work backwards, whose else needs input in the decision-making process. If you're the client, it helps you to minimize the number of cooks in the kitchen. If you're the supplier, you need to know how many times you'll have to address edits. This is also where you have a last chance to change the scope if you originally priced it out under different assumptions.

6) Ten-day check-in on process. Far too often unmoored projects continue as is because it's hard to get off the treadmill. But get off you must if the treadmill is not working as it should. Lest you get hurt (okay, enough of the treadmill metaphor). It doesn't have to be call, and it doesn't have to originate from the supplier (though it normally does).

7) Mandatory debrief. I know most clients want to immediately move on to their next hundred deliverables and responsibilities. And you, as the provider, want to focus on your other clients. Or maybe you think you know everything Even if the project went awry and you know (and the clients know) they will be looking elsewhere for future work. It's sucks, I know. But you must demand the debrief.

As positioned above, this is just one type of process you can use. But it requires transparency, clear guidelines, and open dialogue to succeed. I am quite certain it is far, far better than the alternative. Anything else you would add? Let me know in the comments!