How to manage software projects

Managing projects is an art. An art with many different interpretations, and you can spend a lot of time learning about it.

You can find lots of books about this subject on Amazon and tons of different “takes” on the Web.

There is no definitive answer on what makes a good project management strategy, but in this post I want to introduce you my take of how to manage a software project.

A quick way to start.

When you have to start a project, the first thing you do is you start planning. You don’t start by writing code.

Writing code might be one week after your start planning, or longer.

You first have a phase of requirements analysis, as I explained in module 3 of this bootcamp, in the first week.

I would recommend you to use a project management tool. There are tons of them.

I would use a tool like Notion or a mind map like MindNode.

In a team environment, the planning phase is a collaboration effort and tools that enable collaboration are great. Like Basecamp for example.

Meetings and talking with each other to define what you are going to build, and to define an initial roadmap.

There is no way the initial roadmap will be the final roadmap.

This is because in the beginning you just ignore too many things.

You are doing your best work to create something with a lot of uncertainty.

Any plan you come up with is just guessing.

This is why the Agile movement grew so quickly. You can read books like The Art of Agile Development, Running Lean, Lean Startup and many more to find lots of interesting information on the topic.

Another great book, especially oriented towards software, is Getting Real, which you can read for free on https://basecamp.com/gettingreal

My suggestion is to first identify an MVP, a Minimum Viable Product. This is by definition the smallest product you can create that will solve the problem you have.

There’s a lot of things to discuss about identifying the right problem to solve, and the right product to build, but I assume you are doing a product for a client that commissioned it to you.

Clearly set boundaries and stick to those essential features that make the core of the application. Iteration towards the first MVP should be fast to give you a quick feedback with the client.

Get the first version out there as soon as you can, because that’s when the real learning starts to happen.

From there, you will continuously iterate to change the product until you make it right.

The larger the team, the bigger the problems and the more experienced the project manager needs to be, and this is why project management is not something you’ll do as your first job out there, and might only be your responsibility after years of working as a developer.

At some point, you outgrow development as in “writing code” and you’ll start taking on more responsibility, and that’s when you might switch to project management.

It’s a common path, although not a path you are forced to grow into, but one that usually also provides status and financial benefits.