Day: June 24, 2020

I’ve decided to cover the basics of project management here. I did not get into any big technical tools but just covered the 3 things you should know before committing to a project.

The 3 things would be defining your goals, understanding your resources, and understanding why projects fail.

I think this is something honestly most people don’t want to think about. It’s far more exciting to just start building out some project and seeing where it takes you then to stop and ask Why you are building. I’m guilty of skipping this step often because just starting a project can be a lot of fun. Figuring out Who you are building for will help you focus a project. I’m going to just for the sake of simplicity break this down into three parts.

Do you want to sell this project? Then focus on what people want to buy. Look at your competition and see why they are successful and why they failed. Tools like SWOT (Strength, Weakness, Opportunities, Threats) can be a quick way to do this, alongside Competitor Analysis.

Is this just a showcase piece? Then focus on what types of strengths this brings to your portfolio. Think about why these pieces are important and who you want to see them. Showcase pieces are really the middle ground between a product for sell (yourself/team/tool/whatever) and doing something to learn. Getting feedback on showcase pieces is a good way to grow.

Are you doing this to learn/have fun? Sometimes being willing to play and learn is the best way to grow. There are two approaches to this I see. One is to follow tutorials, and learn how to think about a project, the other is to try and built it yourself and learn to how to do creative problem-solving. There are benefits to both methods and realizing the value of both methods helps keep you from getting burnt out or stuck.

I think the how is something we often assume, or at least I do. I think being able to take a step back and look over the scope of what I want to achieve is important. Do I want to spend a weekend doing this or the next 5 years? What will I need to get this done? What am I willing to give up to make this happen is also something to consider, if you don’t have a lot of time either scope or cost will have to increase to try and maintain quality for example.

As someone who has hired contractors to work under me before, I can tell you, that triangle is a pain. Balancing my budget, my time and scope can be a huge headache.

Some ways people approach scoping projects is with different mindsets such as Minimum Viable Product (MVP) – a way to create the most basic product necessary for feedback.

Another method becoming more common is creating products with the Minimum Marketable Feature (MMF) mindset, the idea is what is the minimum I need to sell this product.

The difference between MVP and MMF is one (MVP) is focused on prototyping (often for shareholders), the other is focused on being just good enough quality to sell (directly to consumers), so it’s beyond a basic prototype.

These two tools – MVP and MMF are based off of the Agile mindset.

Agile is a project management style of separating tasks and working on them in short sprints then getting feedback. Often these short bursts of work are around 1-4 weeks long but they can be longer or shorter depending on needs. Agile is great for projects with independent components such as one person changing the menus art and another person programming them. Agile doesn’t very work for dependent components though, Waterfall is used then.

Waterfall is very common in art-focused fields where you have to go step by step. If you don’t have a script you can’t design a character, if you don’t have a character you can’t create animations, and every step is dependent on the step before it. It becomes VERY hard to change directions with Waterfall systems, with Agile it is much easier. Neither is wrong, they just serve two different purposes.

In a nutshell if you have a set vision the waterfall method is very likely what you need, if you want feedback from outsiders then agile is better suited.

Because waterfall methods are so vision focused they have a very high failure rate compared to agile projects. Movies flop all the time and it’s important to understand why.

When it comes to creating products design is key. With Waterfall, product design is done in preproduction and does not really change, so the design needs to be really really strong. Agile products can have some weaker designs in the beginning but they have to build up a reasonable design early or else they may suffer technical debt long term.

Technical debt can lead to redoing work, throwing away work and/or poor quality with unfixable bugs or designs. You can avoid or manage technical debt by working on good design practices, such as having good documentation, testing designs (through prototyping and other forms of testing), strong collaboration and refactoring & cleaning up the project as you go.

Some systems that can help with this is source/ version control. Good source control makes it easy to roll back changes if they cause issues which allows for more experimenting & cleaning, it makes collaboration easier, and most have built-in ways to leave documentation of what you have done. Don’t mistake this documentation for proper project design though.

Another tool that really helps is design documents. There are a lot of types of design docs such as Game Design Docs (GDD), Developer style guides, Visual/brand style guides, Model Sheets, business plans among other forms of technical design. These documents help explain what the product is and define the requirements for the product, though in many cases they may be guidelines they are very important if you want to explain (or remember) what makes your product what it is.

Anyway to sum it up..

• Think about who your audience is
• Think about why you are building the project
• Think about what resources you have
• Think about how you will scope the project & when you plan to finish
• Think about where you struggle and what tools/outside resources you can use to overcome that.