Starting a New Project Is Harder Than You Think (Specific Checklist Included)
How to successfully run a project & mistakes I've made
Take your most pessimistic estimate of how long a new project will take.
Double it
Double it again
You’re probably halfway there
—my dad’s rule of thumb
Starting a new project with other people is harder than it looks.
Not because the work is complex, but because there is no map yet. No spec. No shared picture of what “done” means. Just a loose goal and a group of smart1, already-busy people expected to move in the same direction.
At the end of every project, you’re going to look back and realize if you started again you could have done it in 1/3rd the time—thats normal!
If you’re someone who likes clear rules, sharp edges, and known targets, this stage can feel hard, difficult, and deeply wrong.
Engineers, analysts, and operators often struggle here—not from lack of skill, but from lack of structure. When the ground is soft, it’s hard to know where to step.
If you just want the checklist, jump here or click the PDF version below:
Copiable Deck Format
Template google drive directory
I know this feeling because that’s how my brain works too.
For a long time, I thought good project managers and consultants were doing something vague.
From the outside, their work looked fluffy. I’ve mocked PMO offices before.
Too many check-ins2. Too many docs. Too much talk.
I was wrong. I have been before (see below).
Why I Changed My Mind About Performance vs. Brand Marketing
For the first years of my marketing career, I believed that the numbers were all that mattered.
When project work is done well, you barely notice it. The rough spots have already been smoothed.
Files are where you expect them to be. Decisions don’t vanish. People know what’s expected, even when the goal is still taking shape. Progress feels steady, almost calm.
When it’s done poorly, everything drags. People go quiet. Work stalls for reasons no one can quite name. The project doesn’t fail loudly. It just fades until one day you give up.
This is the guide I wish I’d had the first few times I led something new.
It’s written for smart, capable people who hate fuzzy project edges and would much rather have a spec—but don’t.
Here’s the part that matters most:
You will learn by doing.
You don’t need to grasp every step before you start.
Trust the process. Follow it anyway.3
Think of this as a stand-in map. A set of rails you can run on while the shape of the work comes into focus. The rules may feel strict at first. That’s on purpose. Clear rules lower the load on your mind when everything else is still unclear. Loose rules are great when everyone knows norms.
These steps are built for async work, where gaps and silence can quietly break a project. They also work in person, with a much lighter touch.
If you follow them as written—even when they feel heavier than needed—you’ll give your project something rare at the start: solid ground.
Step 0: Pre-Work
What You Must Decide Before Involving Other People
Decide That You Are the Lead
If you are starting this project, you are the lead.
Take a moment to realize that no one will be checking in on you day-to-day. You’re responsible for self-motivation and management.
This is not a democracy. You will ask for advice and you should change your mind when better ideas appear—but decisions land with you.
Unclear leadership creates more friction than firm leadership ever will.
Decide the Defaults
Decide, in advance:
Where files will live
How people will communicate
How calls will work
Where decisions will be recorded
These choices do not need to be perfect. They need to exist.
Undecided defaults invite interpretations. This will be a problem later.
Decide How Suggestions Will Come In
People will have opinions. Many will be useful.
Decide:
Where suggestions go
When you will review them
How decisions will be made
For example:
“Tooling suggestions via email. I won’t decide this live.”
This keeps meetings focused and protects shared time.
Decide What “Participation” Means
Be clear with yourself about what it takes to be involved.
Does participation require being on a team? Owning work? Showing up? Writing things down?
You don’t need to publish this yet. You do need to know it.
Once these decisions are made, stop thinking and start acting.
The next step is to make these rules visible—by behaving more formally than feels natural when other people enter the system.
Step 1: Act More Formal Than Feels Necessary
“Moving parts in rubbing contact require lubrication to avoid excessive wear. Honorifics and formal politeness provide lubrication where people rub together.
― Robert Heinlein, Time Enough for Love (1973)
Formality is not friction. It’s the opposite. It keeps things moving smoothly.
Once other people are involved, your job changes.
You are no longer just thinking through a problem.
You are shaping a shared space where work can happen without constant negotiation. In that space, informality is not neutral. It creates gaps. Gaps create confusion. Confusion slows everything down.4
So start more formal than feels natural.
This will feel stiff at first. That’s fine. Early formality does not lock you into rigid process forever. It gives you a stable floor while the work is still taking shape.
Decide Once, Then Write It Down
Every choice you’ve already made needs to be stated plainly.
Not hinted at. Not implied. Written.
This includes:
Where files live
How people communicate
How decisions are recorded
What tools are in use
What happens when someone joins late
If it isn’t written, it doesn’t exist.
Recording decisions is a key hack for making sure you’re always learning.
People will not infer your system. They will assume there isn’t one.
Remove Choice Wherever You Can
Choice feels empowering. Early on, it’s mostly a tax.
If you allow multiple tools, people will pick their favorites. If you allow multiple ways of working, people will follow habits from past jobs. None of this is malicious. It’s just human.
Your goal is not to optimize for preference. It’s to optimize for shared motion.
That means:
One file system
One default chat channel
One place decisions get summarized
You can always loosen later. Tight first. Loose later.
Write Procedures for the Parts You Understand
You do not need to document the whole project. You only need to document what you already know how to do.
If you know how meeting notes should be written, write it down.
If you know how files should be named, write it down.
If you know how decisions should be logged, write it down.
Short is fine. Rough is fine. Incomplete is fine.
What matters is that someone who joins later can orient themselves without needing a private walkthrough.
That is one of the quiet tests of good structure.
Assume No One Was in the Meeting
In async work, meetings are a convenience—not a source of truth.
Any decision that matters needs to live outside the call. If someone misses a meeting, they should still be able to catch up without shame or guesswork.
This isn’t about accountability. It’s about respect.
People are busy. People have day jobs. Your system should not punish them for that.
Expect This to Feel Excessive
At this stage, people may not say much. That doesn’t mean they aren’t reading. It doesn’t mean they don’t care.
Formality often feels louder to the person creating it than to the people receiving it. You are laying track ahead of the train. The smooth ride comes later.
Trust that this work is doing something, even when it feels quiet.
Formality is not about control.
It’s about clearing the path.
Once the structure is in place, you’re ready for the next step: setting the tools themselves so there is exactly one way to work.
Step 2: Pre-Decide the Tools (No Exceptions)
There’s one thing better than perfect…standard.
Every tool choice carries habits, expectations, and hidden costs. When tools are left undecided, people fill the gap with whatever they already know. That’s how a project quietly fractures before it ever picks up speed.
Your job here is simple: decide once, then remove the question.
Pick One Place for Files
There must be exactly one place where files live.
Not “mostly.” Not “unless it’s easier.” One place.
For work projects, this usually means whatever your company already uses. Don’t fight that battle unless you have to. Familiar tools lower the bar to entry.
For personal or volunteer work, pick a free option that everyone can access without setup pain.
Once chosen:
Create the shared drive yourself
Set the top-level folder structure
Share access before kickoff
Do not wait for agreement. Do not ask for preferences. File sprawl is far harder to clean up later than it is to prevent.
Use a Clear, Boring Folder Structure
See the example drive for a specific template
Your folder structure is doing more work than you think.
It tells people what matters.
It tells them where to put things.
It tells new arrivals how serious this project is.
Use a structure that:
Is shallow
Is obvious
Leaves room to grow
This is not about elegance. It’s about orientation. If someone can’t guess where a file belongs, the structure is too clever.
Once it’s set, don’t casually change it. Stability builds trust.
Choose One Default Communication Channel
Pick one place where day-to-day conversation happens.
This is the channel people should check if they want to stay in the loop. Everything else is secondary.
Be explicit about:
What belongs in this channel
What does not
Where decisions will be summarized
Also be clear about expectations:
People are not required to respond to every message
Silence does not mean disapproval
Reading is often enough
This matters more than the tool itself. Clear norms reduce social strain.
Decide How Calls Will Work
Calls are useful. They are also easy to misuse.
Decide up front:
What tool you’ll use for calls
When a call is appropriate
What happens after every call
The rule should be simple:
No call produces new information that isn’t written down and shared.
Meeting notes don’t need to be long. They do need to exist.
Lock the Stack (For Now)
Once these choices are made, freeze them.
This does not mean the tools are perfect. It means they are good enough to move forward. Tool churn kills momentum and invites endless side debates.
If you plan to revisit tooling later, say so. Also say when and how. Until then, the stack is closed.
If someone asks to change tools, you already have an answer:
“Send me the suggestion. I won’t decide this live.”
That’s not being rigid. That’s protecting shared time.
Good projects don’t start with the best tools.
They start with shared ones.
Once the tools are set, you’re ready to bring people together and make the project real.
STEP 3: Run a Formal Kickoff (Yes, With a Deck)
The kickoff is not a status meeting.
It is the moment where a loose idea turns into a shared effort. If you skip it—or keep it casual—you’re asking people to infer rules, roles, and priorities that you haven’t stated.
Don’t do that.
Run a formal kickoff. Bring a deck. Even if it feels like overkill.
It can be 2 slides, but it structures a meeting in an important way to gather trust and set expectations implicitly.
The Kickoff Is Mandatory
No work starts before the kickoff.
Not research. Not side tasks. Not “just poking around.” The kickoff is the line between thinking and doing.
This isn’t about ceremony. It’s about alignment. People deserve to know what they’re stepping into before they start contributing.
What the Deck Must Cover
Your deck does not need to be polished. It does need to be clear.
At a minimum, include:
What this project is
What it is not
Any expected digital norms (e.g. cameras on)
Why it exists now
How success will be judged (even if roughly)
Where files live
How people should communicate
Where decisions will be written down
You are not selling. You are setting expectations.
If something feels obvious to you, say it anyway. Obvious rules are still rules.
Assign Roles and Teams Live
This part is not optional.
During the kickoff, assign:
Roles
Teams
Owners
Do it live. Write it down as you go. Share the doc before the meeting ends.
Here is the rule you should say out loud:
To stay involved, you must be on a team.
This does not mean people can’t help outside their team. It means there is no such thing as a vague participant. Loose involvement turns into drift. Drift turns into disengagement.
This is a mistake I’ve made more than once. Every time, it cost the project.
Make Participation Concrete
People want to help. They just don’t want to guess how.
Be clear about:
What each team owns
How work will be tracked
What “good progress” looks like in the first few weeks
Early clarity beats early perfection.
Leave Time for Questions—Then Close
At the end of the kickoff, leave room for questions. Answer what you can. Write down what you can’t.
Then close decisively.
Say what happens next:
When the next update will be
Where follow-up questions should go
What people should do first
End the meeting with forward motion.
STEP 4: Overcommunicate (More Than Feels Comfortable)
Once work begins, your instincts may push you to go quiet.
You don’t want to distract people. You don’t want to spam. You don’t want to narrate thoughts that aren’t fully formed yet.
Resist that urge.
In a new project, silence creates more confusion than noise.
Share What You’re Thinking Early
You do not need to wait until ideas are finished.
Share:
What you’re leaning toward
What you’re unsure about
What tradeoffs you’re weighing
This is not about asking permission. It’s about giving context.
When people understand your thinking, they’re far less likely to feel blindsided if something changes later.
Repeat Yourself on Purpose
It will feel strange to say the same thing more than once.
Do it anyway.
In async work, people read at different times. They skim. They miss things. Repetition is how shared understanding forms.
If something matters, it should appear in:
A message
A doc
A summary
That’s not redundancy. That’s reinforcement.
Do Not Expect Responses
Here’s a rule that removes a lot of stress:
Messages can be useful even if no one replies.
People are busy. They may read and move on. They may save it for later. That doesn’t mean the message wasn’t helpful.
If you tie your sense of progress to visible responses, you’ll stop communicating too early.
Assume your words are landing, even when it’s quiet.
Plant Seeds Before You Pivot
If you think a change might be coming, say so.
Early signals matter. They give people time to adjust. They also invite better ideas before things harden.
A simple “I’m thinking about changing X because of Y” goes a long way.
Most frustration comes from sudden shifts that feel unexplained. Overcommunication prevents that.
Summarize Decisions Clearly
Whenever a decision is made, summarize it in the agreed place.
Keep it short:
What was decided
Why
What happens next
This is not bureaucracy. It’s memory.
People should never have to guess whether something is settled.
Overcommunication feels awkward because it’s one-way at first.
Later, when the project holds together under pressure, it will feel obvious in hindsight.
A good kickoff does not solve the project.
It gives everyone the same starting line.
Once teams and roles are set, your next job is to keep momentum without burning people out—which means learning how to communicate more than feels natural.
STEP 5: Reward and Celebrate Good Work (Publicly and Often)
Early in a project, people are taking a risk.
They’re spending time on something new. They’re working without a clear finish line. They’re exposing half-formed ideas in front of others. That takes effort and a bit of nerve.
If that effort goes unnoticed, people pull back. Not out of spite—out of self-preservation.
Your job is to make sure that doesn’t happen.
Praise Progress, Not Just Outcomes
In the early days, outcomes are rare. Progress is not.
Look for:
Someone who documented something unprompted
Someone who tried an approach that didn’t work
Someone who helped another team without being asked
Someone who closed a loop others forgot about
These are the behaviors you want more of.
If you wait until the project is “successful” to celebrate, you’ll be celebrating alone.
Make Praise Public
Private thanks are good. Public recognition is better.
Public praise does three things at once:
It rewards the person who did the work
It shows others what good looks like
It signals that effort is seen
This does not need to be grand. A short message in the main channel is enough.
Be specific. Vague praise fades quickly.
Create a Simple Ritual
Rituals remove guesswork.
One easy option is a recurring highlight:
“Team Member of the Week”
“This Week’s Shout-Out”
“Good Work Worth Calling Out”
Pin it. Send it on a schedule. Keep it light.
The goal is not competition. The goal is momentum.
Reward Experimentation
New projects need trying, not just finishing.
If someone tests an idea and reports back—even if it fails—that is success at this stage. Say so.
People will stop experimenting if failure feels invisible or risky. You want the opposite.
Assume People Need More Encouragement Than You Think
Most capable people underestimate how much positive signal others need.
You may feel like you’re being obvious. You aren’t.
Err on the side of saying it out loud.
Recognition is one of the cheapest tools you have.
It pays off faster than almost anything else.
Once people feel seen, they’re more willing to ask questions—which brings us to the next step.
STEP 6: Have Standing Office Hours (Lower the Cost of Asking for Help)
Here’s a quiet truth about new projects:
Asking for help has a cost.
Even when you say, “Just reach out,” people hesitate. They don’t want to interrupt. They don’t want to look unprepared. They don’t want to take more time than they need.
That friction is enough to keep small questions unasked. Small questions turn into wrong assumptions. Wrong assumptions compound.
You can fix this.
Do Not Rely on Ad-Hoc Requests
If people have to:
Schedule time
Write a careful message
Explain why they need help
many of them simply won’t.
This is not a motivation problem. It’s a friction problem.
Everyone is very well aware of friction in business until it comes to your own backyard.
Set Predictable Office Hours
Create recurring, visible time where you are available by default.
For example:
“I’ll be on this call every Monday, Wednesday, and Friday from 2–4pm.”
“I’ll be in this room during this window.”
No agenda. No obligation. Drop in or don’t.
The key is that the time exists whether or not anyone shows up.
Make It Clear What Office Hours Are For
Say this out loud:
This is for quick questions, half-formed thoughts, and things you’re not sure are worth a meeting.
Office hours are not status updates. They are casual questions that might need more exploration.
Watch for Patterns
Office hours are not just for answering questions. They are for listening.
If you hear the same confusion more than once, that’s a signal:
Something wasn’t documented
An assumption wasn’t shared
A rule wasn’t as clear as you thought
When that happens, fix the system—not the person.
Write it down. Share it once. Save everyone time.
Treat Empty Office Hours as Success
Some weeks, no one will show up.
That doesn’t mean the time was wasted. It means things are working, or people didn’t need you right then.
Keep the hours anyway. Consistency builds trust over time.
Office hours turn silent friction into visible feedback.
Once you’ve given people a low-cost way to ask questions, you can close the loop properly at the end of the work.
STEP 7: Run an After-Action Review (Close the Loop)
When the work slows down or ends, there’s a strong urge to move on.
Resist it.
Without a deliberate pause, lessons evaporate. People carry quiet frustrations into the next project. Small wins go unmarked. The system never improves.
An after-action review fixes that.
Make the Review Explicit
Do not let reflection happen “informally.”
Schedule a meeting. Invite the people who mattered:
Core team members
Key stakeholders
Anyone who had to live with the results
This signals that learning is part of the work, not an afterthought.
Keep the Agenda Simple
You don’t need a long deck or a formal report. You need honesty.
Structure the conversation around three questions:
What went well?
What didn’t?
What should we try differently next time?
Write the answers down as they’re said. This is shared memory, not private notes.
Include Stakeholders on Purpose
Stakeholders often see things the team doesn’t.
They notice friction at handoffs. They feel the cost of delays. They see where expectations drifted. Their input makes the next project smoother—if you invite it.
Focus on Systems, Not People
If something went wrong, ask:
What allowed this to happen?
Where was the gap?
What rule or structure would have helped?
Avoid blame. Blame feels satisfying for about five minutes and fixes nothing.
Good reviews change systems. Bad reviews assign fault.
End With Action
Before the meeting ends, capture:
One or two things you will keep
One or two things you will change
These become starting points, not just notes.
Share the summary. Close the loop.
I hope you chose your team well.
Still sometimes true. Don’t mistake my acknowledgement here as a carte blanche for shoddy project management
This is one of the classic reasons that consultants are chosen for business transformation roles—we’ve done project initiation innumerable times vs the average employee. It’s a skill to learn. It’s not suggesting consultants are smarter than you, but rather they have a more specific set of skills aligned to that project.
The informal tech culture was primarily created by two forces:
Technical people were extremely competent in a narrow domain. Because you could assume someone that knew how to manage computes was competent, you could relax some of the rules.
You could also assume that they would be frequenting the same cultures (forums, websites, in person meetups) and so could speak the same language.The urge to boast about how incredible the gains from technology were. Even if there weren’t formal structures around tech in business, the gains were so massive that the social inefficiencies could be ignored.
Now that tech use in business is table stakes and the quality of the average tech employee is lower than 20 years ago (you can’t massively increase the number of people getting into a field without lowering standards), neither of these two are really true.
Tech bros of the 2010s, I’m sorry but that culture is never coming back.