How to plan a large/complex project

When you are given a large project to plan and/or architect a solution for how do you approach it? How do you take an idea and plan it out for the team to build?

• Do you immediately jump into coding?

• Do you start writing Jira tickets?

• Do you start with paper sketches and diagrams?

Before I start doing any coding or diagraming, I always like to start with asking a million questions. Things like:

• Who are we building this for?

• Are there any technical limitations?

• What is our product appetite?

• What does success for this project look like?

• Do we have a product requirements doc?

• Do we have an outline I should follow for writing the technical spec?

• Do we have any performance SLAs we need to meet?

• What are we purposely not solving during this project (eg. non goals)?

Technical Speccing

Once you’ve gained a deeper understanding of the project through those questions, you’ll want to take your product requirements doc and start fleshing out a technical spec doc.

Here is a template I’ve shared before to give you a helpful outline to follow. Working through each section in that outline will really helps you think through the problem and make sure we don’t miss anything.

Technical specs are awesome because they help you:

• Identify design issues before coding starts

• Give other devs a chance to catch missing scope

• Provide knowledge sharing and documentation

• Achieve design consensus around the technical plan

Creating a detailed project plan

Once you’ve worked through the technical spec sections around background, goals, non-goals, risks, complications, etc – it’s time to flesh out the Project Plan – how exactly will we build this new product or feature.

There are many ways to flesh out a technical plan, but I like to keep it focused around features and user stories. I take each feature and start thinking through how I would build it.

Again I start with asking myself and others a lot of questions:

• What existing frameworks, systems, and in-house existing technologies can I reuse to build this?

• Are there any new major technologies / libraries we’ll need to use to pull off this feature? (Eg. A new library with a vendor contract, or a document database instead of a relational db?)

• What kind of APIs will I need to pull this off? Will they all be internal, or also external?

• What kind of auth will we use for the APIs?

• Do I need any new databases or db tables for this feature?

• What kind of tech debt will we need to tackle in order to work on this project?

On the frontend, there are different questions and requirements we need to think through.

• Will the designs require us to create any new components?

• What kind of pages / tools will we be making?

• Is there anything with complex state management we’ll need to tackle?

• Are we clear on what APIs we’ll be using, and aligned on their interface?

• Is this any internal tool, or external public facing tool?

• What kind of load should we expect? Will we need a CDN to host our app and/or assets?

You’ll want to document the answers to these questions in your technical spec.

• List out all the APIs and the agreed up structure

• List out new databases or tables you’ll be adding

• List out a new components you’ll be building

• List out any new frameworks or technologies you’ll be using

• etc.

The technical spec should be a living project plan that the entire team can go to as the source of truth for how the project will be built, and what the focus/scope is.

Developing systems design / code flow diagrams

One thing that can really help other engineers understand your project plan is to create diagrams that show how all the different parts of your system connect together.

If you are building a system for sending an email, you’ll want to show the code flow of how an email would actually be sent.

You can start out with a high level of detail, and then continue to flesh out the diagram as you start coding and building the project.

I love using tools like Draw.io, Miro.com, Lucid.app, or excalidraw.com to flesh out diagrams.

Organizing around milestones and tickets

Before you jump into coding, it’s really important to break down a larger project into smaller milestones and tasks. Breaking a complex problem down helps you:

• Make sense of a complex problem

• Develop accurate estimates

• Gain momentum while building

• Rally the team around priorities

As a general rule, anything over 2 wks in length should be broken up into milestones.

Once you have your milestones agreed on, you can take each of those milestones and break them down into features / user stories.

Next, break down each of those user stories into tasks for frontend and backend.

Finally, you will input these tasks into your project management software with a clear summary and acceptance criteria.

Each task should be fleshed out throughly enough so that anyone could pick up the task and have enough context to complete it.

What does this look like in practice?

I recently had to plan out a large and complex project involving: authorization, custom user roles, user groups, document sharing and more 😅

• I started writing a technical spec, which quickly turned into 30+ pages

• I divided the larger project into 7 smaller projects

• I broke down each of those smaller projects into features

• I created stories for of those features

• I added a rough estimate on each of those stories

I then worked backward to build up a project estimate:

• Added up all the story points ✔️

• Grouped all the features into milestones ✔️

• Put date estimates on each of those milestones ✔️

• Loaded up our sprint with the first set of stories ✔️

What started as an overwhelmingly large project.

Turned into something we could reason about and plan 🤝

- - - - - - - - - - - - - - - - - - - - - - - - - - - -

Was this helpful? How do you approach planning a large project?

I’d love to hear any stories or tips you have.

Until next week 👇🏼

Catch me daily on LinkedIn and Twitter, where I talk about everything software engineering, startups, and growing in your engineering soft skills.