Review at the first half of the Project

Project Initialization and Planning

In a long lasting project I would normally take a whole week of time to think about the project objectives, to define them by following the S.M.A.R.T principle, to weight those objectives, to create several SWOT analyses to identify the project’s and team member limits, to prepare a stakeholder chart, to build up a plan to identify and conquer possible risk and so on.

But this phase was dominated by its time constrains due to the First Pitch and its deliverables deadline. There were only two days left to create the game concept and the presentation, at the beginning. And therefore, we began to work directly. This led to an exhausting amount of working hours because we didn’t follow an established plan with prioritized objectives. But the results were remarkable good. It also demonstrated the extraordinarily high team performance under bad circumstances: Even while being over-worked each team member worked objective oriented and the stress level didn’t result into interpersonal trouble. It also exposed the product of working without Project Managing (PM), overall.

After reviewing those two days, I decided to interrupt the actual work and introduced some PM techniques to improve our workflow. At first, we talked a little about the project objectives, which were defined somehow by the modules syllabus and the team member expectations. But I skipped to dive more deeply into them, because I had some other KPIs in mind to control this project.

Milestone

With the help of our detailed game concept we established our milestones, roughly:

  • First Playable Prototype until Christmas that is defined as a “minimalistic approach as fast as possible (prove-of-concept)”. Its purpose is to give everyone something playable in hand in case they want to go on with the project over the Christmas period on their own. It is also the first shareable picture, the idea in motion, for everyone to develop a corporate vision on the final game.
  • Alpha Release (17.01.2018) is defined as: “All of the CORE game elements are included, as fast as possible”. This release is the first one that is playable by play-testers to gather more resources for our designer to balance the game. It also will demonstrate strongly what we will be capable of until the end of the project and it will be the last time to redirect the project course in a strong manner.
  • Intermediate Presentation (17.01.2018)
  • Beta Release (31.01.2018) will be about: “ALL game elements are included in desired quality. No additional features will be added after this milestone”. This is the major step to the final product. This release will include everything we planned to have in the game. After this deadline there will be no more time to add any features. Its purpose is to indicate the interaction between those and to discover potential issues.
  • Final Release (15.02.2018) is “a polished version of the Beta Release”. This last two weeks is the time to clean everything up, to include the last missing bits and bytes and to apply last changes to balance the systems.
  • Final Presentation (15.02.2018)

Kanban Board (hacknplan.com)

The final step was to introduce a simple way to log our work. The web portal “Hack’n’Plan” was the tool of choice: It is easy to use and especially not overloaded with distracting things. We spent a whole day to generate working task on the portal and estimated the amount of working hours. Those estimations and the reached quality of the milestones are my main KPIs to monitor and to control the project. There was nothing left, so we could begin with the project’s work.

My own objective was to be as minimalistic as possible with the amount of attention the project management needed to save up time for myself to work on the project as a programmer. Until now, it tend to work out that way.

 

First Meeting after Christmas (Monitor and Control)

On Wednesday the 3rd of January we had our first meeting after Christmas. I thought a lot of the project and the amount of work we will have to do, checked my KPIs and compare those on reachability. I discovered an unbalance between the amount of planned work and the amount of hours available to each artist. The process of discovering this imbalance in each individual task and to get a solution for those took a lot of effort and adjustment to the project plan. We discussed about dropping features but decided to simplify some of the tasks and move others to the beta milestone. It is still a risky plan but doable. The most important thing is, that every team member now knows the risk, is aware of the workload for the upcoming days and decided actively to follow that plan instead of cutting more stuff out of the final product. For myself, this is a very critical step, because right now, we haven’t spent a lot of time in the questionable features and redirecting the project course right now would be only a task of shifting around words on paper. In the future, the price increases significantly, because work will become worthless. We will find out if it was a good decision…