How I Manage My Projects: A Step-By-Step Guide
Tags: productivity, management, tutorial, programming
Published: 2023-09-16 23:19:26

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:

![List of feature requirements](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2j666sg9osieub88dsq6.png)

- **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? 

![List of non-functional requirements](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z5s177bk1zsfx25bu7d9.png)

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](https://adr.github.io/) come in. These are documents that clarify the reasoning behind decisions made. 

![Architectural decision record](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rs8k2f0sb4k756jxd5wk.png)

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.

![List of tasks with risk and estimated time](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/foe2gv2lqoimsb0tpqj7.png)

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: 
 
![Project schedule](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p96mhqyhyxcnpzr8bixt.png)

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](https://trello.com) 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?

![Kanban board](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uo2v000cwyatnw551ox6.png)

## 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.

![List of tasks completed in toggl](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vryoawde96rhg3jwi7kl.png)

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!_

![List of tasks with estimated time and risk](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/okobmwlsjjz9jgumysvf.png)

## 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:

![Schedule with how long it took for the project to be completed](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xorlot6rod4u2kx1ssxb.png)

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_ :heart: finishing projects on time :stuck_out_tongue_winking_eye:

## Working examples

Repositories: [Express app] (https://github.com/freddyhm/MyRepoStats), [Django app](https://github.com/freddyhm/my-repo-stats-python)
Documents for the projects: [Notion notebook](https://serious-swordtail-48f.notion.site/Exploration-Projects-4e410d0987ff4fed860ed9f5517d38eb?pvs=4)
Deployed Apps: https://my-repo-stats.fly.dev/, https://my-repo-stats-python.fly.dev/

_Cover photo by [Dan Burton]("https://unsplash.com/@dan__burton?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText") on [Unsplash]("https://unsplash.com/photos/l6jWD4AZIf0?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText")_