How/when to delegate?
When Eisenhower went to Moscow (he didn't)
If there's one thing that is hard to learn that would be delegating. Doing everything within the next 2 minutes is relatively easy, such as scheduling tasks (when you think about it it is a type of procrastination). But delegating... damn, that's hard.
Recently, I realized a funny correlation. Both the Eisenhower Matrix and the MoSCoW method are four-step, so maybe one method can complement the other one.
Let's start by reminding us what these methods are about.
The Eisenhower Matrix is about deciding when to do something: now, at a scheduled time, by delegating it to someone else, or by abandoning it.
The MoSCoW method is helpful when you need to determine the importance of a task. Here, you categorize tasks as Must-Haves, Should-Haves, Could-Haves, or Won't-Haves.
When you write them in two columns next to each other you can see easily what I saw recently.
A Won't Have would be a task to be discarded. And clearly a must-have is something you should do now (or close to now). But what about the other two? The Eisenhower Matrix can be read in both directions, so we have to decide.
Is Should-Have a task to be delegated and a Could-Have to be scheduled? Or is it the opposite?
We're all game-makers, so let's tackle the problem in terms of game-making.
MUST-HAVE tasks would be all the game features and mechanics that are crucial to making an MVP/prototype/vertical slice. The most important game mechanics without which the game would not have the right to exist.
WON'T HAVE tasks were a problem for me, because not being a serious businessman I don't consider any tasks to be Won't Haves1. But let's say they won't be abandoned. Just added it in a later patch if nothing more important is needed at the moment. They're not needed on Day 1. It's hard to tell which is which. It reminds me of an anecdote from the time the first Psychonauts were developed, and Tim Schafer asked the team to implement some idle animation for Raz. Everyone was skeptical because so many things were still to be implemented, and bugs to be fixed - long story short gamers remembered that idle animation. So, be wary, that not every WON'T HAVE is to be abandoned 😉
Left with the remaining two options. To resolve the dilemma let's think about what tasks you delegate. Story? Art? Music? Code? Marketing?
At the moment that planning is done, you will be occupied with the MUST HAVEs. So my suggestion would be to consider tasks to be delegated as SHOULD HAVEs, as it would be best to delegate them as soon as possible. All of them are important, that's why when you'll be doing the MUSTs, someone can be doing the SHOULDs.
Once your MUSTs are done, you will either verify the status of the SHOULDs or go straight to the COULDs., which at this point are features and game mechanics to be implemented after the MUSTs (or to keep the terms clear: scheduled after the prototype).
Would that work? It might, prioritisation is very important in every project, and so is delegation. Unless you're a genius doing all these things alone, not sure if I'm capable of suggesting any solutions for you, then 😁 Dividing your work into phases is the way, believe me, because that's how you eat an elephant - one chunk at a time!
although the fact that I removed W from the equation only for the method to not sound like the capital of a war-mongering nation might've been of influence 😉