Note: this is an expansion on a previous article I wrote around kickoff docs.

Project Kickoff!

At this point, you should have a good idea of what your overall goal is. You should have a rough sketch of what your milestones are for the project and what you want to include in each one. You should not have the specific details of the projects worked out yet.

It’s time for a project kickoff.

What is a Project Kickoff?

A project kick-off meeting is the first meeting with the project team and the client of the project where applicable. This meeting is the time to establish common goals and the purpose of the project.

Taken from the Atlassian Project Kickoff reference.

The kickoff meeting is a

• chance to bring all stakeholders together,
• cast a vision for the project that everyone can get behind,
• and an opportunity to make introductions and establish good working relationships.

At this stage, the specific details of the project haven’t been determined, so you should include a discussion on the project scope, timeline, and goals in your meeting agenda. This is also when roles are announced and a communication plan is explained. The kickoff meeting sets the tone for the working relationship among stakeholders for the duration of the project.

Why a Project Kickoff?

A project kickoff sets a clear outline of project goals and milestones.

It’s a celebration of where you’re going as a group. You get your chance to outline what you want to build as a team and why you’re doing it. The how isn’t important at this step - either from a management or engineering side. You’re just trying to let everyone know where you want to end up once the project is complete.

A kickoff generally will be a forcing function to think about timelines.

Have you planned for:

• Design
• Testing
• Customer Sign-off
• Quality Assurance

If not, you can always call that out - we’ll deliver a finalized timeline and design by XXX date, instead of trying to figure out when you’ll deliver before you’ve started. If you’re not being pushed to deliver by a certain date but instead to deliver certain functionality this can be a great way to go.

If you’ve already committed to a delivery date, the kickoff can be a great way to acknowledge that we have to find a way to meet the goal in a certain amount of time. It can act as an immediate forcing function to cut functionality you can’t afford or won’t need.

Finally, a project kickoff can help your team have something to fall back on when things get unorganized. If someone is unsure what to do at any point, the project kickoff docs can be a great reference to refocus everyone.

Roles and Responsibilities

In a project kickoff, you should lay out who’s responsible for various aspects of the project. This is a great opportunity for a manager to provide growth opportunities to folks. You can break up the responsibilities of the project into many small pieces that you dole out to your entire team or have one person be responsible for everything.

Some ways I’ve broken up responsibilities in the past:

• Product Design
• Feature Delivery
• Standups
• Leadership Team Updates
• Internal/External Comms
• Development
• Code Reviews
• Tech Specs, Architectural diagrams
• Tech Spec reviews
• Backlog maintenance, review
• Testing (automation, manual)
• Driving Resolution on technical issues (aka making sure bugs get fixed)

Remember that a role is not the same as a person.

• In some cases, one person can fill multiple roles, such as having a designated emergency contact, a role that adds few additional work hours to a person’s schedule.
• In other cases, multiple people may hold identical roles, as when your project requires multiple software engineers.

Goals and Outcomes

When setting out the goals of your project, you should tie the project into any company wide OKR’s you might have. Most likely the project is tied to a key result or results - those should be stated for the team. There shouldn’t be any surprises about what the deliverables are.

Any deadline driven deliverables should also be called out. If you have hard customer commitments those should be highlighted.

If you’re lucky enough to work on a project with no deadline, you should at least endeavor to provide a rough timeline to give the team your expectations around delivery.

A rough timeline like this has worked for me:

• Design, Research done by Late June
• Development Done by Late July
• Load Testing by End of July
• Medium Confidence in shipping by End of Quarter

The progress you make over the first 2-4 weeks of a project will have a compounding effect on the overall project timeline and risk. Make the most of it.

Working Together

It’s good to highlight how everyone is going to work together, and what to do when you’re not working together as effectively as you could be.

• How often do you plan on meeting?
• Where are you documenting your decisions?
• How much process do you want to put into place?
• How will you review if things are going well outside of the deliverables?
• Where is your backlog of work stored?

A high level example:

Staying in Sync

• When in doubt, jump on a Zoom
• Bring everything back to the development channel
• Daily standups
• Start with minimal process
• Periodic Retros

Executing

• Iterations (2 weeks)
• One planning session per iteration
• Jira is the source of truth, everything should be in there

Next Steps

Once you’ve kicked off the project, what are your next steps? What are the actions you need to take now? Finish the kickoff making sure everyone is empowered to act the moment the meeting ends.

Common next steps:

• Creating a project slack channel for folks to follow along
• Writing & Reviewing a Technical Design document for the 1st milestone by XXX Date