There are so many tutorials on how to build stuff, but much less on how to actually manage what you're building - whether that's a quick weekend day hack or a month long project.
That's a shame because I find that having a solid project management system in place can be a real game-changer.
It kickstarts your ideas, keeps you aligned with your goals, and lets you stay laser-focused during development.
So, here's what's been working for me over the past five years."
Step 1: Requirements
I kick things off with a simple spec sheet:
- What's the goal: What's the project's main goal or purpose?
- Why build this: Why is it important to undertake this project? Understanding the underlying motivation helps shape the project's scope
- Requirements: what are the critical features to consider the first version complete?
- Phases: what is the essential work for each iteration? I try to keep the first as ridiculously small as possible to build momentum quickly
- Mockup: what does this look like? The goal is to get an idea of what the project should look like. On bigger projects it can also help guide the backend work (e.g. what type of data do we need, format, etc.)
Step 2: Architectural Documents
Once I know what needs to be built, I'll outline what kind of architecture can satisfy those requirements as efficiently as possible.
This is where I'll look at non-functional requirements and carefully think about the scope.
What is critical? What can wait? What's the bare minimum?
I do this early on because it'll determine the pieces I need to build the project before I write a single line of code.
Essentially, it lets me code with an uncluttered mind knowing that the big questions are partly answered.
After narrowing down how the system should behave, I'll think about the technology that I can use.
That's where Architectural Decision Records come in. These are documents that clarify the reasoning behind decisions made.
This step might feel like it'll just slow down the process for little gain, but I found the outcome to actually be the opposite.
Without this crucial planning step, I find projects tend to easily derail and can stretch from weeks to months. It's even worse on solo work where you have little accountability.
The power of these docs to clarify thought and keep focus is huge!
Step 3: Feature breakdown & Estimates
Almost all projects I've seen break down their features into tasks - this is nothing new. The part I find extremely useful is estimating time and risk.
For each task, I'll write down how long I think it'll take and how risky the task is.
I define risk here as how probable it is that the task goes over the time I estimated.
I add up the hours and that's my best estimate. I'll multiply it (usually by a factor of 2) and I have my worst estimate.
This serves a few purposes: it helps create an estimate that is bounded (best, worst), and helps prioritize what to work on.
Step 4: Scheduling
Equipped with an estimate in hours and days, the next step is to simply add it to a schedule.
I find this is important because it makes the deadline real in my head. It also keeps me regularly checking mentally if a task fits within the given timeframe.
I keep this page open throughout my development:
Now we know what we're building, how we're building it initially, and how long it's going to take.
Next, we need to visualize the work.
Step 5: Visualizing work
I like using a Kanban style board (Trello has been my go to for its simplicity) that has the following:
- Backlog: tasks that pop into my head while working
- To Do: tasks I outlined in Step 3 or pull from the backlog based on priority
- Doing: what I'm currently working on
- Done: what's done (useful for review at the end of project)
Here's my productivity secret sauce, on every task title I add the following::
- Est.: the estimated time for the task
- RT: the real time it took to complete
- Tag 'Ahead' or 'Behind': is the real time below or above the estimated time?
Step 6: Tracking the work
Right before I start working, I start my timer and place it in a separate screen so it's always in the corner of my eye.
Seeing the time pass helps my mind remember that time is a precious resource, even if it may feel like there's plenty of it.
Once the task is done, and this part is super important as well, I'll update the task's 'RT' on the board and set its tag to 'Ahead' or 'Behind'.
Updating tasks as I complete them gives me instant feedback on how much time is left for the project.
That type of awareness ultimately guides future tasks: can I afford to go deeper in this area? should I leave this task for the next phase? etc.
NOTE: All of the previous steps wouldn't amount to much if it wasn't for this step. Tracking how long each task takes might seem like a lot of context switching, but the cost is minimal compared to the gain in awareness!
Step 7: Retrospective
Once the feature is complete, I'll update the schedule with the real time it took for the project to be completed:
In keeping with the spirit of agile, this is where a mini retrospective takes place: what went well, what could be improved for the next feature, what were the biggest time sinks, etc.
Were all those steps really necessary?
Well no, nothing is really necessary.
But that question should be rephrased to:
"Is finishing the project as efficiently as possible really necessary?"
If the answer is yes, then these steps go a long way ensuring projects finish on time.
And I don't know about you, but I really ❤️ finishing projects on time 😜
Working examples
Repositories: Express app, Django app
Documents for the projects: Notion notebook
Deployed Apps: https://my-repo-stats.fly.dev/, https://my-repo-stats-python.fly.dev/
Cover photo by Dan Burton on Unsplash
Top comments (0)