How to manage programming projects when freelancing

avatar

Borislav Hadzhiev

Sun Feb 28 20213 min read

banner

Photo by :DC Snapshots

How to think about and optimize the first 3 stages of project management

This post is about my take on the first 3 stages of project management.

You have to find the best approach for your specific case, if your client doesn't seem to be too confident, maybe you shouldn't spend too much time designing up front, maybe the requirements will change.

At the same time you can't just start coding blindly because moving in the wrong direction is like not moving at all (unless you get paid per hour).

The Requirements #

  • are the initial phase where you talk to the client about the website, the problems they're trying to solve, the business model, ideas, expectations, any domain specific questions you have, etc.

  • should be understood by anybody - they shouldn't include any programming specific terminology

  • could include domain specific terminology - i.e. logistics, law, medical. The programmer should ask any domain specific questions / assumptions. If you don't know what exactly you're building, it probably won't go well. The client maybe knows the domain specifics well, but most of the time they have no clue about programming, so they might have unrealistic expectations. The client is more likely to let you tweak the requirements if they see you're involved / interested in the domain, not just the programming part.

  • are formatted like:

    • As an authenticated user I can add products to my cart.
    • As an admin I can change a user's password.

The Specifications #

  • are the first, dirty iteration of the design phase in my workflow - I've got the client's requirements and I can start thinking in terms of the requirement to implementation option mapping, in terms of pros / cons, based on the tools/constraints I have.

  • are programmer centric notes based on the collected requirements

  • include programmer terminology

  • include some things to think about in the future, in the design phase, considerations, writing down questions, thinking about the constraints you have, i.e.:

    • The application's data model is too complex, and might change - will not use an inflexible db like Dynamodb - should use Postgres instead.
    • This is a consumer facing application where SEO is very important, should use Static / Server rendered pages for the consumer facing routes
    • Technology X would make implementing requirement A easier, because reasons 1, 2, 3.
    • Technology Y is not suitable for implementing requirement B, because reasons 1, 2, 3.
  • is the perfect phase to talk to the client about changing some of their requirements, if you've seen flaws in the way they want things implemented.

Design phase is when #

  • we spend time thinking about architecture, models, software framework options.
  • we think about the solutions for the problems we have written down in the specifications phase, and any that may appear in this phase
  • we think about what our entities are and our models, do we have enough of the access patterns to go with no-sql, if not - go with sql
  • we break down larger problems into smaller ones, spend some time to try and foresee issues
  • we write down any questions that might come up for the client
  • we identify potential solutions for the problems
  • we design the database

End #

This is my personal opinionated approach to the introductory phases of project management, in general I don't want to spend too much time planning in advance, because most of the time the requirements change. However I don't want to jump straight into coding either, because some decisions are very hard to undo as the project progresses - like changing database management system, authentication strategy, etc.

This approach is good for when you go back to a project you haven't worked on for a while - you can get up to speed quickly and don't have to read lots of documentation, that might be outdated. The requirements in the form of intent are most often enough, for example:

  • As a user I can do X, Y, Z
  • As an admin I can do A, B, C
  • I made decision X, because of reasons 1, 2, 3

Join my newsletter

I'll send you 1 email a week with links to all of the articles I've written that week

Buy Me A Coffee