The key to successful, finished projects

It was a dark and stormy night... Not that you noticed, seeing as you were probably holed up in your home, alone, buying a domain name for your next big idea before it has even materialised. Key point: alone, as in working solo, and not as in a B-rated horror film with a jump scare around the corner.

To get from that domain name, or idea, to an actual project deliverable, you will require:

• A plan; however rough
• Grit; to execute said plan

These are, of course, variable.

We're also assuming you have the resources to execute said plan. If not, tough cookies.

A few things to note

'Art Software is never finished, only abandoned', as the adage from Leonardo Da Vinci doesn't go.

'Finished' or 'complete' anywhere in this post refers to software being in an 'acceptably complete' state. That could be a minimum viable product, or it could be every feature that's on the list - the state will be determined by your criteria.

If you haven't planned a project before, know there is a high likelihood of getting things way off the mark. You may readjust projects quite a bit after working through them. You'll get better at it the more projects you undertake; such is the benefit of developing experience and expertise. Just don't forget to multiply the total time you think it takes by Pi (multiPi? 😇); I jest, but mildly - that is, in fact, a common attitude for better time estimation.

It's easier to think in terms of larger milestones first. You may find milestones shifting the more you break them into tasks while you scope and figure out where the complexity lies.

Lastly, time tracking may be useful for you. Outside of this personal context, it is appropriate to react with abhorrence and distaste, as though you accidentally put soap on your toothbrush instead of toothpaste. Many supervisor-types use it as a way to micromanage or evaluate performance. Never encourage that.

A notier note: leave your comfort zone

If you're learning something new at any level, you're likely using tutorials, documentation, and other informative resources.

Tutorial hell isn't the best place in which to get stuck. People end up doing projects other people have already built forever and that's... Not really anything new. We also stay inside our comfort zone. A few ways to get around this are:

• Do projects you find easier and then add features to them.
• Take more complex projects and break them down into smaller, more manageable tasks.
• Make sure you have ways to get help if you're out of your depth. Learning in a community is usually better for this.
• Add a deadline. A real, tangible deadline, that feels hefty.

The underlying point of a tutorial is to teach you something; not give you a portfolio deliverable. Much like how great artists make a song their own when creating a cover version, you should make projects yours.

How planning changes across different types of projects

Obviously, smaller projects should require less planning. There are different ways to plan, and honestly, you don't really want scope creep happening to your planning. Most work should be done on the actual deliverable. ;)

Smallest projects: you probably have an idea of how this should pan out without much written planning, and you'll mainly want to be aware of creeping feature lists.

Larger projects: these take much longer. Duh. 🤣 As personal projects grow to become larger, they tend to require either expertise or more time dedicated towards learning in lieu of the former.

• Will the project stay just yours?
• How is the workload getting managed?
• What do you need to learn to produce the deliverable?
• What resources would you need?
• If important, how will you avoid scope creep?
• Is there a deadline, for some reason?

Personal side projects, of course, come in variable sizes. The great thing about ownership of the project being yours is you can adjust as you go.

Things will change as you learn new information; embrace this attitude early and adapt your plans as you go. It's okay.

Tailor the project to your needs

Use shortcuts to help you create the final product you want:

• Libraries
• Frameworks
• Programs and services
• Ask experts for advice!

The idea is to not build everything yourself, especially for large projects. Sometimes the point of a personal project is to build it yourself (for your understanding, or whatever), so if that's the point... Have at it!

I have a piece of off-the-cuff advice:

Don't use best practices (sometimes!). I know how that sounds - but sometimes, for practice purposes, you're better off having a working project than not much of a project at all.

A half-baked project will get you further towards your goals than none at all. The preferable solution would be to take a shortcut and use a solution that's already implemented best practices, even if you don't understand them (particularly if there are going to be any security loopholes). Context matters, though; for example, we don't store passwords in plaintext or send them in emails. I hate to say it, but companies exist that do this.

Bend to the brain

Don't forget to account for a realistic cadence when it comes to working on the project. What time do you actually have available every week to work on the project? After full-time work, family obligations, socialising, sleep, commutes, and everything in-between - what's left that's going to be spent on the project?

Our brains are wired differently, and psychology that works for one person may not be suitable for another. Do you need to be able to visualise progress? Can you follow a schedule well ahead of a deadline? If not, how do you need to manage yourself to get there? What do you actually need to get your work done? If something has stopped you in the past, what can you change this time around to help mitigate that?

If you haven't figured out a system that works for you yet, bear in mind this adds to your cognitive load. Please don't feel guilty if you haven't figured out your own brain yet. It can - disappointingly - take years of trial and error. But hey, real self-development is a lifelong endeavour.

There are many questions you could ask yourself; the idea is to cultivate the system by which you operate, instead of just the project, as if it exists in its own void.

Get the project acceptably finished

Yes, yes, we know the old adage - a project is never finished. At best, it enters maintenance mode. Personal projects are regularly 'unfinished', and if this is something you intend to use as a portfolio piece, and the code is public, it's best to leave it in an acceptable state even if archived.

You can choose some qualifiers ahead of time for different versions of the project. What would be the minimum qualifiers to release it, to consider it done, or usable? What's beyond the minimum, and how necessary are they? They don't have to be necessary; you should just be intentional with your choices and have reasons.

Reasons projects fail and how to avoid them

There are a multitude of reasons projects fail, and they're often due to a combination of reasons under the umbrella of terrible project scoping. When it comes to personal projects, you know yourself best (condolences if you don't), so of course you'd need to learn and adjust accordingly. It'll be more difficult to avoid them in the beginning; you can, however, become someone who halts patterns early. That self-awareness will do you better in the long run.

Some reasons for failure:

• Unrealistic expectations
• Not breaking down larger milestones into tasks with enough granularity
• Poor time estimation
• Poor personal time management
• Resources run out
• Choice of tools and software (How familiar are they to you? Are resources plentiful?
• Scope creep
• Poor communication
• Poor health management

Some of these are difficult to avoid without experience. Research and advice will be important for better planning, especially for larger projects. And, more importantly, leave space for things you won't have accounted for, whether that be time, money, effort, or something else. Plan for your worst days, not your best, and you'll probably have better expectations in the long run.

The consequences of these variables failing affect your ability to perform - as a human, not just as a creator. Your physical, mental, and emotional energy will be affected. If that happens (for most newbies,  when), prioritise your health first. Fatigue is easier to handle than burnout, so slow down early. You can always return if you want to.

How to scope

Scoping your project out is easy:

• Step 1: What do you want?
• Step 2: When do you want it by?
• Step 3: ???
• Step 4: Profit

Okay, so while I jest - again - there is some truth to it. Scoping is about defining what will be done, and how:

1. Define your goals and objectives

What are you doing? Why are you doing it? Goals are the higher-level achievable outcomes. Objectives are measurable and intended to help towards a goal.

A clearly defined audience is important, even if that audience is just yourself.

1. Define the project's deliverables

What are the important features and capabilities? What are the goals going to achieve?

1. List out requirements

Requirements may involve resources or timelines. A series of deadlines, for example. Requirements can come from any part of the project - you could have a design requirement. Minimum launch criteria are good to consider here. Termination criteria are also good to consider here; what's required to have met the project's purpose?

Axing criteria is also important - what would be required to end the project prematurely?

1. List constraints and exclusions

What are you going to not do? If there are reasons for this, even better.

1. Break down the deliverables into milestones

...Then break down the milestones into tasks. Keep doing this until you understand the different parts of the project and it looks feasible. Tasks should be actionable and clearly defined.

1. Create a roadmap

Timelines aren't as important for personal projects are juggling multiple personal projects, working better with deadlines, or other specific requirements that involve reasons for deadlines. Finishing a few projects is preferred to many unfinished projects.

If you aren't pressured, deadlines are less important and you can constantly work on the project until you're happy to consider it finished. At the minimum, order your tasks so you have a roadmap; add your time constraints as required.

Organising your projects

Tools!

• Trello
• ClickUp
• Basecamp
• Asana
• Google
• Microsoft Projects
• Whiteboard with Post-it notes
• Paper

If you're working alone, it'd be more effort to adopt a project management methodology than to simply undertake the project. Personally, I would just spin up a board in Trello or ClickUp Kanban-style; if it's a small project, I keep a to-do list inside my project repository instead. Most of the software's extra features are unnecessary for personal projects - you basically just need to be able to construct a roadmap of some sort.

Good luck!

That's it!

Good luck with your project. As always, I'm happy to hear about it, so feel free to share them during my streams on Twitch!

Thanks

Thanks to Adam for proofreading!