I’ve recently wrapped up a freelance client website using Trello for project management.
I’ve wasted hours on projects in the past due to a lack of organization, processes, and general good practices. So this time I wanted to sharpen my project management skills in a way that would be replicable for my future self.
My perspective is particularly honed because I’ve worked for many years as a small business operator. I had to source contract and agency work before getting into web development myself.
The premise of this kind of one-man-shop project management comes from Brett at DesignJoy:
Below are some lessons learned after I implemented this over the course of a few weeks.
- Organization is key
- Time restraints are tricky
- Deliver on time
- Define the scope
- Define the process
- Test, test…and keep testing
- Polish is important
- Results matter most
- Previews are good
- Let the client lead when possible
Organization is Key
Prior to Trello, I was doing a combination of email, texts, and Google chat. That’s fine when you’re starting out and have one client at a time. But having one place where all communication about a single project lives saves time and effort.
Clarity on the order of events was incredibly helpful too. I set up lists where different tasks would live:
- Directions, assets, and general information in the first column
- Task queue in second column
- Active work in third column
- Work ready for client review in fourth column
- Approved work in the fifth column
It’s a very simple but effective setup that allows for asynchronous communication (I have had zero phone calls so far) and a clearly defined pipeline for requests/work/review.
I grant the client full access to the Trello Board and they’re able to rearrange the queue such that the work that needs to happen first gets put at the top.
From there, I grab the top item, and work on one thing at a time in active work. This is valuable for the client to see what I’m working on. And, bonus – it’s incredibly helpful for people like me who are easily distracted from one task by wanting to go do another one “real quick”.
Time Restraints are Tricky
Hot take: don’t set time restraints unless you have to. Often I resist the urge to add a note about timing for delivery. It’s common to do this when talking to people, but unless I’m asked for a scope of delivery, I leave this off.
This allows me room to expand on design work, try out different implementations for coding, and not be crunched on non-time sensitive items.
Deadlines are just tricky. A lot of times you have to move them after you set them. And a lot of times they’re arbitrary to begin with. I avoid them unless I have no other choice.
That said, if you’re not disciplined enough to put in the hours without them…you may need to have a few. 😂
Deliver on Time
It’s unlikely that you’ll have zero time restraints, though. Otherwise, the project may drift on in perpetuity. And then, caught in its numbing undertow, you’ll turn around in 6 months only to realize how little you’ve progressed and how much anxiety lingers under the surface as a result of a lack of closure.
You don’t want this. 🚫
So, when you do have a deadline, deliver before it. Give yourself some room so that you can likely deliver ahead of schedule, and at the very least deliver on time.
Define the Project’s Scope
What are we building? What are the guardrails? Is it a marketing page? Is it an ecommerce site? Will it require skills beyond my knowledge? There are many questions like these to answer up front.
Starting out, it’s easy to want to say yes to any and everything. And in most cases, go for it! There were a couple things in my last project that I had to research and figure out mid-stream.
But, try insofar as is possible to define the scope up front so that you can structure your project well and have a good idea of what it will take to get from start to finish.
Your client may or may not know their own scope. You will be a very helpful resource for them throughout the process, especially if they are not technically proficient.
Define Your Process
This is where Trello really helped me with some of my natural weak spots. Organizing the board and setting it up to be as simple as possible for both of us really paid off as we worked together.
At the onset, I built a template card with instructions. This both defined the process for me, and gave a reference for my client.
The process of working on tasks throughout the project was extremely straightforward and left little room for confusion. On tasks where explanation was needed, screenshots, notes, and checklists were available to box up issues into containers.
Test, Test, and Test Again
You can never test enough, and there will likely be things that slip through anyway. At least that’s been my experience! Always test on mobile devices and not just the Chrome Dev Tools.
I broke some image gallery functionality and didn’t realize it until client sent screenshots from his cell phone.
Not ideal! 😅🤦♂️
Polish is Important
Get the meta tags and favicon stuff right. Depending on the platform you’re developing on, this may be done for you, but just make sure you’ve taken care of it before launch. It’s easy to overlook things like this.
If you’re doing these yourself, I found some helpful tools to generate and test them:
Results Matter Most
I overrode some Bootstrap 5 CSS in my main.css. I tweaked an npm package. Your client doesn’t care what you do, or about the perfect best practices. Results matter most.
Don’t break stuff, but that aside, you may bend some rules to simplify things if you need to.
Your client wants you to do awesome. Concern yourself with the best way to get them the results they desire.
Previews are Good
Clients are not always technically savvy. Descriptions, screenshots, and so on are often insufficient for them to grasp and approve what you’re working on. Be able to send them a working preview build when possible.
I developed this project using GitHub for my codebase and Netlify for deployment. Deploy previews are a built in feature at Netlify, and you can share URLs based on pull/merge request numbers. That way, if there is a working site up and running, the client can preview changes separately.
Let the Client Lead when Possible
Hold your feelings and opinions loosely. This is their project, not yours. It’s easy to get that backwards.
But the client is in charge and knows what they want even if they don’t know how to get there or even how to describe it.
Part of our job as developers is coaxing that out of them by using the tools we are proficient with. Communication, organization, and teamwork are equally or more important than our technical toolkit.
As a freelancer, we are valuable assets to their business and should be pointing toward serving them well during the course of all our work.
Let them lead when possible.
Make suggestions when asked or when it’s necessary.
But be helpful above all.
Empathy 😊 is the name of the game.
Master this and the coding will often be the easy part.
Thanks for Reading 👊
I hope this has been helpful for you!
Come say hey 👋 over on Twitter: https://twitter.com/EamonnCottrell