Being a project lead can be challenging. There are so many variables to make everything work out in the end. But it's a rewarding experience if everything is going right. Following a few simple guidelines can set any project up for success.

Understand what success looks like, develop a plan of execution, hold people and yourself accountable, know when to escalate.

"Project" is a vague term. Some projects can take multiple years, with thousands of people involved. Others can get done by two people in a week. And then there is everything in between. No matter what size your project is, the first thing is to know what success means. Begin with the end in mind and work your way backward. It's one of The 7 Habits of Highly Effective People.

The planning starts with clearly defining the scope and success criteria. What is in the scope and what's not. Everyone involved should be on the same page what success means. And what the deadline is. A one-pager document or PRD (product requirements document) are pretty standard practices. You and your team should be able to tell with confidence when the project is complete.

When building software, programmers break it down into smaller components, classes, objects, utilities. Same with managing a project. Break it down into smaller pieces, then take those and break it down again until you end up with tasks. The first step in this process is to create milestones. They should serve as a map of how to complete the project. Each one of them should be a mini-project with a clear deliverable and timeline. By completing milestones successfully and on time, you can be confident everything is under control. And the opposite is true if there are issues with one of the milestones, the entire project is at risk. Use them as your roadmap to get to the big finish line.

Projects don't happen in isolation. There is always a group of people who has skin in the game. Stakeholders are people who work with you on the project like product managers, designers, program managers. In some cases, projects can involve other teams or departments like marketing, business, finance. Identify all the stakeholders and their roles and level of involvement to keep them informed as everything progresses.

All the tasks, including clarifying requirements, delivering assets, and coding should have owners. A task without an owner won't ever get done. It doesn't mean an individual. An owner can be a team or a person as long as there is an agreement. Once the owners are clear, everyone should be accountable for delivering the committed work on time. There are multiple ways to communicate the progress and blockers with the rest of the team: daily standups, weekly check-ins, status reports, to name a few. Choose the cadence that works for the team as long as there are transparency and accountability. Any standing meeting is better than pinging people on Slack regularly to get an update when something is going to get done.

If there are blockers or unexpected complexity, evaluate what impact they may have on the current milestone and overall project. Discuss it with the person who faces the challenge, try to work it out, and agree to escalate it if necessary. Other people can potentially help to resolve the issue. TPMs can help with external dependencies, engineering managers can reallocate resources, and PMs can re-negotiate the scope, timeline, or priorities.

Things happen. Every project has risks, and most of us expect that unexpected things will come up. It's rare for a team to keep building the same software over and over again. There is something new in the mix every time. We face unknown projects, tasks, problems, bugs constantly. It all makes the projects somewhat unpredictable. Despite all that, management will demand some timeline and budget estimates because building software is the means to an end. The ultimate goal of the software is to support or build a business. And business works around budgets and time. We still do our best to estimate the efforts, but we can't say for sure.

There are many ways why things can go sideways. Common pitfalls are increasing scope, implementation complexity, unclear requirements, missing assets, legacy code. Transparency is the key, know when to pull the andon cord and notify the stakeholders and management there is a problem. Escalate cleanly, remember your colleagues have the same goal. When it's all over, everyone will remember how you reacted and how you treated others more than the project outcome.