by Desert Beagle

Project Lead

Now available on Steam for free!

Malediction is a third-person puzzle platformer that gives the player the ability to control space and time! Play as Morgan, a wizard with more ambition than sense, whose experiments often get him into trouble. A cloning spell has backfired, allowing his duplicates to run off with most of his powers, and he must now chase them down and defeat them in order to regain his magic abilities. Players will manipulate their environment with telekinesis and time in order to solve obstacles put before them by the dastardly clones.

Desert Beagle is a team of 16 talented developers working together to make Malediction a reality. My development director and I managed their efforts using scrum methodology, organizing objectives into two week sprints to meet milestones set forth by the faculty. Tasks were tracked using Jira, which helped us evaluate the team's progress and adjust taskings for following sprints. To ensure the team was never caught flatfooted, my leads and I evaluated all significant risks, ranking their severity and likelihood, and came up with contingency plans should the worst come to pass. This proved invaluable when unforeseeable personal circumstances came up among some of the devs, as no time was wasted adjusting to production shortfalls.

It's been a learning experience for me coordinating three teams from three different fields (programmers, producers, and artists), each of which have their own vocabulary and expectations that can lead to miscommunication. Getting engaged with the team, such as doing weekly one on ones with each member, has not only taught me about these differences, but has helped keep the game vision clear to the team and made it that everyone feels their concerns are being addressed.

Project Schedule

When presenting to the stakeholders at milestones, having a clear schedule with all the work you plan to do is a good way to show you're on top of it. This is a high-level gantt chart of Malediction's first seven milestones, from January to August, and is based on the dev team's estimates.


Tasks are listed in chronological order and color-coded by team or event. For the sake of readability, dependency lines weren't drawn, but are easily added with Excel's shape tools. To the left is a pivot table, showing the breakdown of tasks by team and the number of days estimated for completion. 

Risk analysis chart for February. Click to magnify.

Risk Analysis

It is rare that a project goes along without a hitch, which is why risk analysis is incredibly important. For Malediction, the team and I evaluated project risks on two scales: how likely is a complication to occur, and how much of an impact will it have if it does?


Each scale had a value from 1 to 5 (1 being on the harmless end), and the resulting risk was the factor of both scale values combined.  This had the benefit of clustering the lower values together, making it easier to evaluate the significance of high risk tasks due to numerical separation. Additionally, each risk was assigned a type, based on the most likely point of failure.

Rather than coming up with fallbacks for every possible risk, I determined it was worth the time savings on meetings to only plan for failures above the midpoint (valued 9 or higher). Anything lower would either be very unlikely to happen, or a nice-to-have that had minimal long-term impact. If possible, methods to mitigate the risk to ensure completion were added.

©2020 by Jaime Tous