This post will be about the different methods of project scheduling used while in Studio 1

Darkest Depths

While working on Darkest Depths our groups scheduling was primarily used for our artist collaborators. This was due to the fact that the design of the board game was a group effort, and we often made changes to the core design as a group and updated the documentation to reflect this. When we did have separate tasks, we used a week by week task list, that had a hierarchy of importance to complete, who was working on the task, and the date it was completed by.

While using this method worked for the work we were doing, it was very bare boned and would become very complicated and convoluted if the project scape was any larger than what it was. If I’m to work on larger projects, then project scheduling needs to be more adaptable.

Snofyr

For Snofyr, we used HackNPlan primarily to allocate tasks. Each task was segmented into a group (eg. playtest 1), with the ability to move milestones into stages of completion and assigning a time limit and a person to the task. It also has the ability to lock tasks out until another is completed, as well as in built commenting and subtasks.

HacknPlan has the ability to work quite well when its various features are enforced properly, however during the development of Snofyr our group only used a fraction of its functionality, using it to schedule chunks of tasks for a single end date.

The main problem we ran into was that tasks weren’t allocated an expected time limit to complete them, resulting in a very long list of tasks were “Planned” but with no end date except the milestone. Because there was no consideration for how long tasks would take, many of the tasks went unfinished, leaving the next milestone with two options: A long list of backlogged tasks; or tasks that would never be completed.

In addition, we failed to allocate users to specific tasks. While this could be forgiven for a 3 person small project, assigning people to a task has a few benefits: If a task must have a person allocated, then the Project Manager is forced to think about the task in terms of how the allocated person could achieve the task and how long they could do it. This would lead to much smaller, achievable task lists, and a lot less of “a bunch of stuff needs to be done sometime before this date”.

In conclusion, I should ensure that whoever is project manager stays on top of the allocating of tasks and timing them, as I believe it will deliver a higher quality game sooner.