I’ve led many projects over my career, and plenty of them were complete disasters. Some of them were disasters in spite of great planning, but the majority of my failures were due to faulty planning. These projects had great engineers with plenty of motivation and talent but failed anyway. However, with each of these failures, I learned something new about project planning. This post explores the following six techniques that I now use in my projects.

1. Stakeholder Identification— Who is going to be affected by this project?
2. Project Success Metrics — How will we measure the business impact?
3. Project Milestones— How do we break the project up into checkpoints?
4. Definition of Done — What does “complete” mean for this project?
5. Gantt Charts— Who is working on what, when, and for how long?
6. Pre-Mortems — What is our most likely cause of failure?

I learned each of these techniques the hard way, and most likely, you need to learn the hard way as well. If you’ve already burnt your fingers on the proverbial stove (i.e., you’ve bombed a project due to poor planning), then one or more of these techniques might be helpful to you. I’ve put all of these (and more) into a project planning template that you are welcome to copy/steal/modify.

Note that I’m not including task management in this list because task creation, assignment, and execution is a very fluid process that is highly dependent on the nature of the work and the engineers involved. In my experience, the best task management system is the one that the team is most interested in using. I highly recommend that you use a system (as opposed to chaos engineering), but that system should be whichever is the path of least resistance to your team.

If this post is helpful, please 👏, subscribe, or hit me up on LinkedIn. I write for the fun of it, but it’s nice to know that someone found value out of it.

1) Stakeholder Identification: avoiding surprises of the worst kind

By identifying the affected parties and their motivations, you reduce the risk of miscommunication or false assumptions

To identify the stakeholders, write down a list of every party that will be affected by the result of your project. It is quite common for project requirements to pass through enough hands to get mutated (like a game of telephone). When in a crucial conversation with someone, a common communication strategy is to repeat what you think you just heard. This is used to reduce miscommunications and improve the chance of a successful outcome. Identifying stakeholders is doing the same thing, but between you and the people who want to receive the final product.

Most engineers are surprised by how many different parties have a stake in the game. Here is a made-up list for a user-facing feature:

• Customers — They are the most important stakeholder.
• Engineering team — They will be responsible for maintaining the feature.
• Platform team — They will be responsible for running the new feature.
• Support team — They will need to respond and route tickets for this feature.
• Design team — Their design will disproportionately affect customer adoption.
• Security team — They are responsible for securing the feature.
• Sales and marketing teams — They need to know how to talk about and sell this feature.
• Leadership team — They are paying your team to deliver features and care that their money is well spent.

For each stakeholder, you need to identify the following.

• Why do they care about this project?
• Do you need their input?
• Do they need to take action based on your output?
• Does this stakeholder matter more than others?

Over my career, I’ve seen many projects fail due to a simple lack of engagement with the correct stakeholders. Sometimes this was because the engineers were missing critical information. Other times it was because they forgot to alert a downstream team about the changes they were making (like the security team).

I can’t stress this step enough — it is vital to identify your stakeholders and what they want.

2) Project Success Metrics: determining how big you plan to win

The first step is to define success.

Ideally, one should be able to see how this project’s success relates to the team’s goals and all the way up to the company goals. Most projects are based on the idea that they will increase revenue, decrease costs, acquire new customers, or improve customer loyalty. Having clarity on how the project is connected to the business goals is essential for understanding priority and impact.

Once you know what success should look and feel like, it’s important to shift into how you will measure that success. Project success metrics are concrete measurements that validate a project thesis. Often, directly measuring revenue is too difficult, and proxy metrics are needed instead. The further your proxy metrics are from revenue, costs, or customers, the more likely you can improve the proxy metric without positively affecting the business.

Use business-impact-centric metrics

Most new engineers tend to take business requirements and turn them into technical requirements. They then write that the goal of their project is to deliver the feature. In the vast majority of cases, delivery of a feature without customer adoption is useless. Take the following two options:

• Option (A): Filtering is added to the Product table.
• Option (B): Filtering options are used by >5% of customer interactions with the Product table.

Think about how much more powerful Option (B) is. In order to come up with the “5%,” you needed to have thought about how useful filtering is to your customer’s workflow. This adds weight and clarity to the project by making it clear “why” the engineers are working on the project. By holding your engineers accountable to outcomes, you give them the freedom to take alternative paths. Maybe instead of focusing on delivering the highest number of filters, they will focus on making the top two filters very easy to discover and apply.

How do you pick the best metrics?

Imagine you are in a team performance evaluation with your boss. You are trying to argue why your team members all deserve a raise. Which is a more compelling argument?

• Option (A): My team delivered four features.
• Option (B): My team delivered a feature that increased revenue by 30%.

Outside of early phase startups, most CEOs are focused on maximizing revenue, minimizing cost, or reducing risk all in service of cashflow and profit maxing. The further your metric is from one of these, the more likely your proxy metric can be increased without achieving one of these business goals. The table below lists some examples that show how a weak proxy metric can be rephrased into a stronger metric that has a better line of sight to the company objectives.

3) Project Milestones: breaking complex problems down to reasonable chunks

Project milestones or checkpoints provide opportunities to pivot/adjust strategies if needed

Project milestones are all about risk reduction. When you start a new project, there are many both known and unknown risks. Maybe the technology you picked isn’t working out in practice. Maybe the business can no longer afford to keep staffing this initiative. If your project is planned as one big chunk, then you are perpetually in a state of partial completion. For the rest of this section, I’m going to go over three different techniques for breaking up projects:

1. Break up projects by confidence checkpoints
2. Break up projects by adoption phases
3. Break up projects by “walk away” points

Break up projects by confidence checkpoint

This technique works best when deploying a new technology in order to minimize the negative impact if the new solution is not better than the old solution. From my experience, it’s too risky to assume that your research or due diligence has been sufficient. Instead, I’ve found it useful to break projects up into the following checkpoints.

1. Research, Proof of Concept, and Prototyping: In this step, the end result is a live demo of the new technology in action that can be shown to stakeholders.
2. Staging: Integrate the technology with the business use case, but ensure that no production environment is affected. This is the final go/no-go moment.
3. Production: Fully merge the technology into the environment.
4. Cleanup and Bug Fixing: Assume that bugs, cleanup, and last-minute feature requests will be necessary to unlock maximum impact.

Break up projects by adoption phase

For projects that involve adding a feature, modeling your checkpoints off of the adoption curve is a useful strategy. This also works for tech debt refactors.

1. Innovators: Build the MVP that is needed for your first one or two customers.
2. Early adopters: Refactor the feature as needed to be more broadly applicable, and onboard the next set of users.
3. Early majority: Complete all the work required to scale your feature to your entire customer base.
4. Late majority: Identify and build the remaining features needed to pull latecomers while planning the deprecation of the old workflows.
5. Laggards: Fully deprecate the old path and forcibly migrate old use cases.

Break up projects by “walk-away” points

This technique is critical for teams/businesses that tend to get interrupted often. The idea is that you assume that you’ll get interrupted eventually, so you break the project up into checkpoints at which you can safely walk away. A good example of this would be, when building a new service, fully implementing each feature before moving on to the next. Instead of delaying tasks like documentation till the end of the project, get those done in parallel with each feature. If you ever need to walk away with only one week of warning, you can easily wrap up where you are and move forward.

Unlike with the other methods of breaking up projects, I can’t really give an example of milestones here, as these are very project-dependent. The main idea, however, is that each checkpoint ends at a point where you can walk away, and the result will still be useful and maintainable.

In my experience, the above strategy is one of the most useful to include and can be combined with the others. There are also additional positive side effects from this technique, including minimizing the time to first deliver something to your customer and reducing the risk of a project mismatch.

4) Definition of Done: Avoiding tripping at the finish line

The last 5% of a project can make or break the whole thing

In my experience, engineers tend to wrap many tasks up into a single “cleanup” task or milestone, but often, the work in that cleanup task is the most vital to ensuring project success. Engineers tend to be so focused on the building of the feature itself, that the smaller details get missed. This is especially true when there is something unexpected that comes up at the end of a project (e.g. bugs discovered by the first real users). Pretty soon the next cycle planning has begun, and these small tasks get lost in the shuffle.

While this isn’t entirely avoidable, one of the best mechanisms for avoiding this problem is to document up the definition of done (popularized by Agile). The definition of done is a process where you document both the functional and nonfunctional requirements to a project, such that it’s clear to everyone what final delivery must look like. Here are some examples:

• Support documentation is written and reviewed by the team, and at least 2 engineers are familiar with the code.
• Marketing is using the new feature as part of outreach.
• Feature is in production for over one week, actively used by customers.
• All critical paths have integration tests, and there exists an end-to-end smoke test.
• All logs and metrics are flowing to their appropriate platform.
• All P0 and P1 bugs filed within the first 2 weeks of delivery are fixed.
• Project retrospective has been held and followup actions are completed.

The definition of done and success metrics are not the same thing.

Success metrics tend to be rigid and unchanging, as they are the desired outcome of the project. It’s often not a good sign if you are changing your definition of success, as it likely means you are shifting focus of the project or diminishing the expected results. This is the opposite for the definition of done which tends to grow in scope as more work is done on the project and the end result is more clear. In most cases, you should make it easy for engineers to add items to the definition but require group collaboration to remove items.

5) Gantt Charts: A valuable technique for time estimation

Gantt charts are helpful if your team is struggling with project time estimates.

Every time you deliver your project late, you are just like the plumber who shows up four hours after the appointment time or the couch that arrives six months after you order it. It’s disrespectful.

I’ve led many projects and many engineers, and they almost universally say, “I’m bad at time estimates.” However, this feels like a cop-out. People expect reasonable estimates for most other things in their lives, but engineers somehow want a free pass when it comes to software engineering. Imagine if you went to the doctor, and they told you they had over-scheduled and you’ll need to come back tomorrow.

Excellent project managers are able to ask the right questions that hone rough estimates into a reliable timeline. In my experience, I’ve found Gantt charts to be the most effective visualization of tasks. For those not familiar, a Gantt chart is a visual representation showing tasks as a timeline. The idea is to roughly estimate units of work, and stack them according to what can be done in parallel based on available resources and the nature of the work.

You can organize Gantt charts by engineer…

…or simply by milestone.

Note that this basic visualization uses only a simple table (available in all documentation tools). Many task managers have much better visualizations of Gantt charts. An example is shown in the Asana screenshot below.

Most common failures during task estimation

Task estimation is a skill that needs to be developed like any other. Most engineers tend to get tripped up on the following issues:

• Work breakdown → Engineers may fail to break down projects into incremental milestones and high-level tasks.
• Task dependencies → Engineers may fail to consider task sequencing with regard to dependencies.
• External dependencies → Engineers may fail to get firm commitments from other teams. The result is last-minute escalations and project delays.
• Clean-up tasks → Engineers may get tripped up on the plethora of final tasks necessary to finish a project (i.e., all the tasks that engineers wrap into “we will do that at the end”).

All it usually takes is some light prodding along these lines, and engineers tend to be more than capable of filling in the blanks.

6) Pre-Mortems: Avoiding failure with strategy

Every project should have some form of risk-reduction mechanism, and pre-mortems are a great technique that gets people thinking.

Most engineers are familiar with post-mortems, as we (unfortunately) have all had to attend them. The majority of post-mortems are centered around the failures of a project and our desire to improve upon those failures in the next project. While I agree that teams should conduct post-mortems (regardless of the project outcome), it has often felt like we could have done more to predict the future. This is where pre-mortems come in.

I first learned about pre-mortems in Annie Duke’s How to Decide, and I’ve been using them ever since. A pre-mortem is when you perform a post-mortem before you even start your project. This technique is like a focused version of risk analysis. I use the following two prompts to kick off the conversation:

• Short-term failure: At the end of the cycle, we declare the project a failure. Why?
• Long-term failure: We initially declare that the project was a success, but six months later, we retroactively declare the project a failure. Why?

I split the discussion into two prompts for a reason. When people think about risks for a project, they tend to focus on a failure to deliver and overlook the fact that feature delivery is a weak form of success. Real success comes from customer adoption/acquisition, which often can’t be fully measured until months have passed. By posing these two deliberate prompts, I’ve gotten significantly better insights.

When thinking about risk, it’s important to identify the

• effect — the negative result you are trying to avoid,
• cause — the root of the problem that leads to the negative effect,
• impact — the magnitude of the failure,
• likelihood — the chance of this coming to pass if left unmitigated,
• derisking — one or more approaches to mitigating the issue, and-
• owner — the responsible party for tracking and actioning the mitigation

Below is a sample table that you can use.

Wrap-up

While it is impossible to fully eliminate risk from a project, you certainly increase your chance of success with effective planning. Projects fail because people forget critical steps, don’t talk to the right stakeholders, blunder into avoidable risks, or mishandle task sequencing. By taking the time to mitigate these concerns, you are more likely to fail for unavoidable reasons (which is better than failing for avoidable reasons).

There are many techniques for scoping and derisking projects, but this blog post focused on six of them.

1. Stakeholder Identification — Talking to stakeholders reduces the chance of failure due to a lack of context.
2. Project Success Metrics — Identifying project success metrics grants flexibility in execution.
3. Project Milestones — Creating project milestones reduces risk by identifying pivot points early in the project.
4. Definition of Done — Agreeing on a definition of “done” keeps engineers focused until the job is finished.
5. Gantt Chart — Creating Gantt charts improves project time estimates.
6. Pre-Mortems — Conducting pre-mortems mitigates avoidable risks.

Do you have more techniques? Feel free to hit me up on LinkedIn — I’d be glad to chat.