Studio 2 – Project management (Extended)


In my older blog discussing the methods of the scrum/agile method i did, i didnt mention how our team used them in our project. So this blog will discuss how i used them in the West End Festival Project.

The project plan was to be completed in a few days after we received the project. We allocated people to do their part of the project plan and the QA agents were to look over it and complete their role as QA for the project plan. When tasks were allocated, some of the team members did half of the work they were assigned and assigned themself to do (leaving out the big works for the QA managers to assess and complete for them, which was irritatingly annoying) leading to a lately done project plan.


When we were planning for sprints and doing sprints all together we recorded them on the backlog for the plan. We did this so that everybody could understand what was happening and how it was happening. We prioritized tasks and split up the group for bigger projects like posters and logo. Within the first week, we had to finish a lot of stuff as we had a deadline, but we managed to do it because of how we executed it.

We did our logo first up, because the logo is what sets the style of the whole festival. The collateral had templates made while the logo was being made. The templates were mockups to get overall ideas. This was done because we wanted to waste no time and continue the project with haste; but after that the logo set the style and we finished the collateral and mockups.

The tasks were made each week (sprints for first week were made first week, then second week the tasks were made after that).

aaaaaaa aa aa a  aa.jpg


The project management was mixed between Kim and I (which made everything ordered and not a hierarchy). I believe that having two was a lot better, especially since we were split up into two from the beginning group 1, group 2.

Now you may be thinking this is a break of the Fayol’s principles of management: unity of command. This may not work in some environments or in some cases, but I did research of how it should work before starting (as we were split up into two from the beginning which create a power commandment issue). An interesting an in depth list of how a double project management project can and would work can be found here from the blog post from blogger ‘Eight to Late’

  • Develop a good rapport with your counterpart: As I’ve written about elsewhere, communication is the basis of good project management. It is easier (and a lot more fun) to communicate with someone you like and get along with. Hence this is number one in my list: get to know your counterpart, socially if possible. Building a rapport (even better, a friendship) will help ease the inevitable tensions that crop up when the project is underway.
  • Divide all responsibilities: This is almost as important;  responsibilities must be completely partitioned between the two PMs. This means:
    • all responsibilities are assigned to a PM  – i.e. no unassigned responsibilities and,
    • no overlap – i.e.  each responsibility assigned to one PM only (never both!).
    Note that this point addresses the apparent violation of principle of the unity of command
  • Help each other: Yes, despite what I’ve said in point two, you will occasionally need to help each other. This could, for instance, be by helping out with hard tasks or covering for your counterpart while she’s away. Remember, you never know when you’ll need help yourself. So, offer assistance, if only for selfish reasons!
  •  …but don’t tread on each other’s toes: After all is said and done, you and your counterpart are individuals. Respect that by not barging into each others territory. There’s a difference between offering help and interfering – though, some people seem to find it hard to make this distinction.  As an example,  don’t  offer unsolicited advice (unlike me!), unless you’re sure it will be taken in the right spirit.
  • Make joint presentations at sponsor meetings: You and your counterpart are a  leadership team. Giving joint presentations to sponsors reinforces the notion that both of you are jointly responsible for the project.

With having one project manager i found that the team doesn’t actually listen a lot of the time. The 2 groups had a project manager each before we started the project.

The project manager in the other group was supposed to be another team member, but I’m sure Kim met it a lot better than the other member. Then when we were all together, it was the two of us so there would be no power involvement and we were all equally right with our own opinions which worked in harmony (this is what we all talked about doing from the start, having two when together).

If it wasn’t like that it would feel like going back to the primitive age where there is a hierarchy of power.  That is something you don’t want.

We both helped each other out with issues and things we may have missed out on or forgot about, like the task sheet; where we would write the tasks and when we sent these to Harmonie. Everybody makes mistakes, and that’s why having two people in a sort of same state of management can counteract that issue a bit and correct issues they may have forgotten about.


Scrum Meetings

We were to arrange scrum meetings at the start of each class. We just basically talked about what we did the day before, and how we were going to achieve the next result (which is what the meetings are for). We did this a lot more in the first week as we wanted to check up a lot to see whether we were finishing the stuff we were assigned, and for QA purposes. We wanted to keep in track too so we continually updated the sprint backlog along with this.

The scrum meetings didn’t occur as they were Supposed to, we didn’t stand up or announce the scrum meetings, as in “this is the scrum meeting of the week. We will now discuss it.” We went to class and talked about our work and what we did, so it was a more comfortable meeting instead of a 5 minute talk standing up. The meetings spread out every day, and online the meetings were the same. We discussed what we were working on and what we will be working on. This was also a great example of the QA and we were to keep on track with the backlog and tasks regularly with this.


We have a tasks sheet which we would fill out each time we finished a product. The date of finish and when we sent to harmonie. The review of our sprints were held online and offline (person). This was done during our milestones and it helped us get a better understanding and make the product better as it develops. We had to make sure everything fits with the style guide, so we have these sessions along with the QA of everybody to make sure that it is all correct. This entails the quality to perfection. We made sure to create mockups for each design we had, so that we don’t waste all of our valuable time. The first week of designing was like this, there were multiple mockups made to speed up everything and make it fit correctly. The mockups helped us create faster and made it easier for QA and seeing how everything looked printed as well. (mockups as in digital mockups and product mockups)




With our products, we held small meetings online to see whether or not we had problems with the data or with the designs, then we would either contact Harmonie, or narelle if the issue pursued further. If any design had issues, we would discuss and try and meet the deadline and refer to the risk management chart!



Two project managers, one project. (2008). Eight to Late. Retrieved 2 May 2016, from

Multiple project management (2016). Retrieved 2 May 2016, from



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s