Studio 3 – Project Management Review

Design, Graphic Design, Project Management

For the project I’ve been working on this trimester (Grinders Coffee House), I have completed all of the deliverables I set out to do from week 1. This was the initial list I came up with:

  • Deliverables:
    • Logo
      • Stamp
    • Signage
      • A frame sign
    • Uniforms
      • T-shirt
    • Packaging
      • Take-away Cup / Cup Sleeve
      • Menu
    • Business Card / Loyalty Card
    • Video Advertisement
    • A1 Poster
    • Social Media pages
    • Icon set
  • Desirables:
    • Packaging
      • Coffee Beans / Cold Press Bottle Label
    • Decor of café & style furniture
    • Signage
      • Storefront Hanging Sign / Window Sticker
    • Website

While I have completed everything on the list, my project management and time management had to be looked at a few times. At the beginning of the project I sat down and came up with a schedule, giving tasks some due dates. Throughout the course of our 13 week trimester, I have had to change the due date for particular deliverables a few times as I had not completed them as I had previously scheduled. For example, I had originally planned to do the filming and editing of the ad in week 9 but due to my planning and organisation (finding a cafe and getting permission to film their, scheduling for when both myself and my cameraman were available, etc.) we didn’t do the filming until week 11/12.

Most times I start a project I just want to get straight into the moodboard research, styles, and concepts and stuff and I kind of skip past the project management step. Therefore, for any future projects I need to put more thought into the planning process. One way I can do this is by thinking through each deliverable a bit more and if there are things I need to set up before each one can be started. I should also think through each item I’m putting on the deliverable list (and desirable list) – is it necessary? does it suit the project? how can it be used? will it benefit the final product? I just need to ask and list out more questions as I think through the task list.

Studio 2 – File Naming Protocols

Design, Graphic Design, Project Management

Hey everyone!

This week has been all about project management and fixing up documents. Oh what fun it has been!!

In this blog post I’m going to talk about naming protocols. This is very important, especially when working on a big project like the West End Festival and we have a lot of different collateral we are working on. Another reason it’s so important is that at the completion of the project we will handover the files to the client and they need to be able to find the correct documents quickly. They don’t want to be searching to find a document that should not be hard to find.

I am discovering that there are a lot of ways you can name files. Firstly I’m just going to list a view of the reasons why it is important to follow some naming conventions:

  • makes it easier and quicker to find what you’re looking for
  • increases productivity
  • all files are identifiable (know what’s in a file without opening it)
  • helps to coordinate and manage shared files
  • can show work history

From some research here are a few naming conventions I thought would be useful for our project include:

  • the name of the collateral, shortened where possible
  • the date, following the protocol YYMMDD, i.e. 160505
  • a version numbering system could be used, i.e. V1.1 (first option), V2.1 (a second option that had a major change), V2.2 (third option with a minor change in it)
  • the underscore key is used between name and date to delimit words
  • capital letters will be used to delimit words

I’ve only discussed a few possible ways to name files but if you need a more extensive guideline for file naming I really suggest you check out Naming Conventions by The University of Edinburgh. They have 13 rules and for each one they have some really good explanations and examples. There are some really good rules that I’m going to try and incorporate in my future projects.

The Stanford University Libraries website had some interesting case studies that highlighted the importance of file naming conventions.

Case study: File naming done bad

Case study: File naming done well

Hope this was helpful for you.

– KH

References

Studio 2 – Project Management

Design, Graphic Design, Project Management

METHODOLOGY – SCRUM

For our final project, marketing for the West End Festival, we are using the scrum project management methodology. I hadn’t used this methodology before so I had to do a bit of research (because I don’t really remember all the details from when we learnt it in Tri 2).

This is what I found out about the Scrum method:

Roles:

  1. Product Owner: this would be the client
  2. Scrum Master: pretty much the team leader
  3. Team: the team of designers working on the project.

Artefacts:

  1. Product Backlog: a complete list of the collateral that’s to be done throughout a project, ordered in priority according to the product owner so that the team is working on the most valuable tasks first.
  2. Sprint Backlog: this is a prioritized list of tasks the team needs to complete during the sprint. Worked out in the Sprint Planning Meeting.
  3. Burndown charts: this is used to show the amount of work remaining in a sprint. It will be an effective way to determine at a glance whether a sprint is on schedule.

Activities:

  1. Sprint Planning Meeting: there will be a planning meeting at the start of each sprint to discuss the work to be done. Through email, the product owner and the team determine the highest-priority items on the product backlog. Team members figure out how many items they can commit to and then create a sprint backlog, which is a list of the tasks to complete during the sprint.
  2. Daily scrum: each day during the sprint team members share what they worked on the prior day, will work on today, and identify any impediments. Daily scrums serve to synchronize the work of team members as they discuss the work of the sprint. These meetings should be no more than 15 minutes.
  3. Sprint Review: at the end of a sprint the team presents the work they’ve done. The goal of this meeting is to get feedback from the product owner and any users or other stakeholders who have been invited to the review.
  4. Sprint Retrospective: at the end of each sprint the team reflects on the sprint that is ending and identifies how they can improve in the next sprint.

This is just a good visual of how scrum should work:

Screen Shot 2016-05-06 at 9.20.12 AM

From scrum.org

I’m just going to outline some of the problems we had with this methodology:

  1. We chose scrum but we didn’t really know the correct way to set up all the documentation.
    • We didn’t have a complete list of jobs that we had to do until at least the end of the second sprint but the first meeting we were supposed to have was a meeting to create the product backlog and prioritise each item on the list.
    • For each sprint we were to have a new table outlining what would be worked on that week. We kind of had this at the end of the second sprint but it was not right because it was continually updated as we went instead of having a new sheet for each sprint.
      • So, as you can see all of our documentation was wrong and we have had to fix it all up. This means that we are madly working to fix these and at the same time, finish off collateral and work for other projects. Crazy, busy at the moment. We have since done more research, and with input from our teacher, are on track to getting all our documentation correct.
      • One website mentioned having the tasks for a sprint listed on a whiteboard – I think that would be a good idea for our next project. Just having it written up and visible to all group members would be a really great thing.
  2. We also weren’t having the meetings as we were supposed to be. As I already mentioned we didn’t sit down at the start and write up a prioritised log of each task to be completed. This is a very important meeting to have as it would have allowed us to see what needed to be done from the start and tasks may have been easier to allocate to each team member.
  3. Now, it’s a bit seems hard/wrong/silly (I’m not sure what the right word to use here is…) to talk about how we haven’t been using the methodology in the right way because we have completed all of our tasks and achieved a number of desirables as well. But that doesn’t matter, we did do it wrong. As I thought about it a bit more, it occurred to me that we may have been able to achieve and complete a lot more desirables for the project (if we had done the product backlog at the start, we could have estimated the times for each task, realised some tasks won’t take long at all, brainstormed more collateral we could work on and add them to the list too). We may have also had a lot of fun creating and designing collateral we may not have had a chance to yet.
  4. We chose a project manager but I’m not sure they understood what it meant to be in that role. They should have been the one to make sure we were doing all the correct things as per the methodology but they weren’t. Also, no one else questioned if we should be doing things any different either. I had written the section in the project plan about scrum specifically and I remember saying something once but it kind of got brushed aside and I didn’t broach the subject again. This is definitely something I need to work on.

I had created some of the artefacts but I’d just been doing them wrong. Once we got them right though, I found the artefacts used in the scrum methodology to be really useful. Creating a complete and comprehensive list of all the collateral that needs to be done is a really helpful tool to use. Also, the ability to prioritise tasks within the list is really important. Having a list written up is a really good way to visually be able to see what needs to be done. Creating it as a table in a program like Excel also means it is editable, easily updatable and it makes it super easy to also create the burndown chart. Now the burndown chart is also a really good tool. This is a visual representation of how the whole project is going. This article (Understanding the Scrum Burndown Chart) explains all the ways these charts can look like and what it’s saying about the team.

So what did I learn.

  • It is really important to know each aspect of the methodology (sit down as a group and go through it at the start so everyone is on the same page)
  • Even if it may seem silly, have the required meetings (everyday)
  • Produce the right documentation. This will ensure that we are being as productive as we can be.
  • Personally, I need to be more assertive, especially when I know we aren’t doing things right.

See the reference list for a few of the websites I looked at. If you want a bit more information, they all go into more detail.

References

Cohn, M. Scrum methodology and project management. Retrieved May 5, 2016, from Mountain Goat Software, https://www.mountaingoatsoftware.com/agile/scrum

James, M. (2013, May 9). An empirical framework for learning (not a methodology). Retrieved May 5, 2016, from http://scrummethodology.com

Kocurek, D. (2011). Understanding the Scrum Burndown chart. Retrieved May 5, 2016, from Methods and Tools, http://www.methodsandtools.com/archive/scrumburndown.php

Layton, M. C. (2016). Agile project management: Five elements of a sprint. Retrieved May 5, 2016, from http://www.dummies.com/how-to/content/the-function-of-the-scrum-and-sprint-within-an-agi.html

VersionOne. (2016). What is Scrum project management & Scrum methodology. Retrieved May 5, 2016, from Keyword Page, https://www.versionone.com/scrum-project-management/