Today will be a big one. We are going to do a post-mortem of the Rapid Reboot project that we have just completed. *Note: about 1000 words into this blog post I came to the realisation that this is going to be colossal if I do the entire post-mortem in a single post, to save you the trouble of having to deal that that much information in one hit I am going to break it up over a few blogs so you can deal with it at a more appropriate pace*
This particular instalment of the project post-mortem will cover Project Management Methodology and its effectiveness, the technical frameworks we utilised within our project and how, as a team, we interpreted our clients brief and delivered an appropriate product to them.
I’ll start by showing you the finished product.
So that was the finished product after 5 or 6 weeks of production, depending on where you count your weeks from (Sunday or Wednesday [when we got the project]). The brief, in brief, was to create a teaser trailer for a hypothetical sequel to an extinct franchise in a particular style. The random generator gave us the choice of Banjo Kazooie or Frogger and in the styles of either a 2D short or environment fly-through video. Our team felt it could best utilise our members strengths by doing an environmental fly-through and we felt that Banjo Kazooie would be more suited to that style and thus our project came into being. We were given a budget of 10 hours work per week per person over the 5 weeks of production to produce the best result we could.
I’m going to start dissecting the project now, from project management to implementation to finished product and reflecting on how successful it was and how I believe it went. I will be including a few notes that will look something like this:
*Note for Studio 2 Facilitators – Information pertains to ANM220.LO##*
This is just to help out the facilitators at my university and point out some important information to them and what it is useful for.
We will kick this off with some talk on the project management used in the completion of this project. This is one of those moments.
*Note for Studio 2 Facilitators – The following information pertains to ANM220.LO15*
Our team used a modified scrum methodology in which we had a weekly set of tasks that needed to be completed and were divided amongst our team. We tried to assign tasks to each member according to each person’s strengths but also people could volunteer to complete tasks if they were interested in trying some work in that area.
For the most part I believe this was an appropriate approach to completing this project, it meant work was spread out across most members of the team throughout the project and also that progress was regularly being made. However being lenient with allowing members who were merely interested in “having a go” at a particular task lead to some tasks being of less than ideal standards. On the flip side of this however, allowing member to have a go is also an excellent way for them to get a taste for that work in an environment where they are surrounded by others with the skills to assist them in learning rapidly. In that aspect I believe that we did the right thing in terms of doing the best by our members but we could have been more strict in terms of quality control to assist the end result of the project.
Utilising this project management methodology we were able to produce work on time and within scope of the brief. On that note it must be noted that at the beginning of the project we had set the bar tremendously high and over-scoped our project. Throughout the production process as we refined and iterated on our designs we realised that we had bitten off more than we can chew and so we cut down and streamlined our production which in turn lead to us being able to deliver a higher quality result on time.
To assist with our project and data management our team implemented and maintained several technical frameworks that were used over the course of the project.
*Note for Studio 2 Facilitators – The following information pertains to ANM220.LO17/14*
Our team decided that having a collaborative team folder hosted by Google Drive was the most efficient means to store the project data whereby everyone had access to the files and were able to contribute to them regardless of where they were at the time. Within this Google Drive folder we had some basic files for easy access and then named folders for each stage of production and various other aspects of the project to help make organising the data more streamlined and efficient. Utilising this structured format to storing our data was key in efficient production of our project as it mean every member had easy access to the project resources they needed.
Additionally our team used the program Slack for the majority of its communication purposes as it is available as both a web browser tab and a smart phone application allowing for it to be used both at home and on the go with the added benefit of notification when someone says something within the team. The only downfall to using this as our primary communication technology was that if the team members missed messages or did not check it regularly then it could be difficult to communicate with them.
Although we did not use a hard and fast file naming convention across the project we made sure to label files according to their purpose (e.g. Renders -> Shot# -> render files) and to maintain the convention of v# at the end of important files to denote the version number. To be fair I think that having a more formal naming convention for files regarding version control would be effective, for the most part a little common sense goes a long way.
It’s all well and good to have a way to manage communication, data and the project in general but it is also important to interpret the project brief as presented by the clients and be able to deliver a suitable product as the result of the project.
*Note for Studio 2 Facilitators – Aforementioned information pertains to ANM220.LO18*
Here is a link to the project brief that we were provided with at the beginning of this project:
“Students are to create a 15-30 second long promotional teaser sequence for a fresh new entry in a beloved old game franchise.”
Our final product (shown at the start of this instalment) that was delivered to the client was 40 seconds in length, although the brief states 15-30 seconds we consulted the client early in the production and were granted some creative leniency regarding the length of the trailer provided the additional time was both essential and enhanced the quality of the product. I believe that our product met the clients brief and was of a satisfying quality level.
I will leave the post-mortem of the Rapid Reboot project there for today (in the interest of maintaining your interest), we will pick it up again next time.
As always, thank you and till next time.
James Day – 1002467