The project execution system

Here’s the process that I follow that has been insanely effective over the last few years. There are many principles behind the system, but this post will focus on the practical. Of course, there are also many things that happen before and after the project that set it up for success that I’ll exclude here.

This system was designed to solve for the following factors:

• Stakeholders must have ports to give input and feedback.
• The implementation must match the purpose of the project.
• Ship as fast as possible without sacrificing quality.

The system is simple on it’s surface – essentially a checklist:

1. Make a list of the things all of the things that need to be done (while reviewing the project design document). It’s OK if you miss some items – the actionable items are continually a work in process as you learn more about the project.
2. Take your list of items and group them. Experiment slicing the items in various ways. Settle on groups that are independent of each other and slowly unveil a slice of the project in a methodical manner that makes the product better.
3. For each group, show, with code or otherwise, that the group is possible. The code written at this stage doesn’t need to be perfect, tested, or clean – it will be thrown away. The goal is to light a path that shows HOW to execute the group of tasks. This should happen in the first couple days of the project and there should be NO unknowns about the execution. Remember to add any tasks to the group that may have been originally missed.
4. Make an explicit agreement with the stakeholders about which group represents the core of the project, as well as the priority of the remaining groups. Stakeholders should be focused on groups, not individual tasks, but are welcomed to give advice if they have special knowledge on the topic.
5. Start building from the core, using the spikes as a reference. If an unknown appears, surface it to the stakeholders. Implement the remaining groups in order of their prioritization.