Project Management for Software Development

In this term of my course, I have been given a new brief to research and develop a highly intuitive, and interactive web application:

PressUp Group plays host to dozens of live music acts each week. As such they have become a staple to the local music scene. They want to add some structure to gig planning, while providing a place for musicians to get recognised. They imagine an app that behaves like a “linkedin-lite for local music”. Bands can sign up to a profile to upload music, and fill out their gigging experience and CV. Venue owners can book bands from this profile and provide praise to bands who deliver a great show. An additional, bonus feature of this solution would be when a venue has booked-out night, a portal page is available to the public for purchasing tickets for that gig. Bands would then get a proportional cut of the ticket sales, and front of house staff would have a guest-list to fast track some people into the venue.

For 10 weeks I will be learning how to research and design, plan and pitch my product. The following 10 weeks would then be centred on actual coding and construction of this web-app to full functionality and interactivity. In using the Gibbs Reflective Cycle to evaluate the process of working on my last project (Di Mario’s Pizza), time management seemed to have been a recurring issue that either caused undue stress on myself, or impeded the quality of the final project when rushing through certain processes and not leaving sufficient time for iteration. Before embarking on my music app, I would like to spend some time practicing project management techniques to avoid similar, previous bottle-neck effect of workload.

As a visual creative, a Work Breakdown Structure (WBS) is a useful tool for me to visually map out all tasks involved in a project, mapping them out by hierarchy and some linearity. When I was doing the WBS I paid attention to breaking down the tasks in as much detail as I am able to anticipate. I have before, practiced a similar kind of planning exercise, namely in the form of list-making or “to-do” lists. The WBS I found, was far more structured and and organised, and I especially appreciate that it is easy for me to refer to (if pinned up on a desk cork board), due to it’s clear, visual appearance, compartmentalising and displaying all the tasks sequentially, unburdened by too much text. The process of creating the WBS was effective with familiarising myself with a brief and planning ahead- I was for example, able to make arrangements in advance such as finding people to interview. Here is my initial WBS, which I created on Adobe Illustrator (please open image in new tab to zoom in):

WBS for Web App Pitch: PressUp Music Group

The second half of my project planning would be to then create a timeline in the form of a Gantt Chart, of the tasks identified in the WBS. To do this, I have used the online tool, Tom’s Planner (https://www.tomsplanner.com/) (please open image in new tab to zoom in):

Gantt Chart for Web App Pitch: PressUp Music Group (ref: https://www.tomsplanner.com/)

It can be noted here that the chart was made to meet a scheduled presentation week in my course (15 – 19 March 2021). My final submission deadline however is 4 April, leaving me some time to revise, iterate and improve my research and reports, also allowing extra time to tie up any loose ends. While I have tried to list only tasks that would take 4hrs or more (therefore combining blog posts for example) to complete, the time blocks on the calendar are still fairly general, taking one day’s work as one unit (I did this for overall clearer visibility) although each unit wouldn’t equate to 8hrs of work in most tasks- I merely scheduled each task over units of time with a corresponding date/ week.

While I feel that this version of my Gantt Chart is a good start to the project, it can certainly afford more room for flexibility, and to allocate time for iteration of the tasks which is an important practice in UX research. In software development there is a project management methodology called Agile. In Agile, you start with an initial goal and set out the tasks to achieve this goal, along a rough timeline. However, tasks adapt to changing project needs. For example, in my gantt chart, items highlighted purple represent a group of tasks. If each group of tasks is treated as a “mini project” and the timeline accommodates one group taking a longer time time than anticipated to complete and vice versa, Agile perhaps provides flexibility that considers newfound strengths and weaknesses, allowing the project manager to strategise as he/she goes along. This is especially essential when working in a team. While this brief is an individual project, I would like to adopt some Agile methodology in my project management for experience, and revise my WBS and Gantt chart at the scheduled 1 March, allowing me to firstly see the changes that I make to my strategy, and secondly conclude my strengths and weaknesses in software development for future reference.