In the past 1 year, I've been increasingly taking part in conducting events, and through each of these events, I've been learning from the teams, my experiences, and mistakes as well. Now I seem to have a pretty good idea on what makes an event great, both to the audience, and the organisers.
What prompted this article?¶
The most recent event I had helped organising for is UniCon '26, and it was a runaway success despite issues propping up left and right. While the topic of issues I'm putting to rest, the way the event was handled, even though I might be a little against some of the decisions, ensured that the event wasn't let down by the issues. This prompted me to think about the previous events I had helped organise for, and I began to see parallels, both in terms of issues and rapid decision making, without which the event could've spiralled down.
So, where do you begin?¶
The first step has always been to have a good idea of what the event must be. Early decisions like outcomes, spending, hospitality, key logging and operation workflows, must be clearly set and worked around.
All this is tied together by communication. And communication, is always key. It defines if the event succeeds or not. Often times, lack of communication and random decision making only lead to more confusion.
This should technically conclude this blog, but I'd rather go in depth, drawing from my experiences to make it a point.
Outcomes of an event¶
Typically, atleast in my university, you have to submit a whole list of documents/drafts long before the event is even given the green light. These include:- - Event description - Proposed Budget and spending - Sponsorships/earnings - Venue requirements
There is some leeway, atleast in terms of sponsorships, but in general, these must pass the approval of the Dean of Student Affairs. While a long and tedious process, this helps establish two things: i. What the event is about, and ii. What are the deliverables of the event.
Post approval, domain based committees are formed, and the event is now in the works.
Domain Committees, Teams, and Cross Talk¶
Domain based committees is too long to type. So I will call them domains instead. Now, it isn't necessarily true that every event must have domains, but the work is always domain specific. What changes is if there are people assigned to domains specifically. Some clubs out here employ a domain free, interest based team formation. This allows for avoiding fragmentation that domain groups form. Unironically, it also means that it's harder to find people actually "interested" to do leg work for an event. It is also significantly harder on the core, or the "leads" of the event. This is why larger events almost always tend towards domain specific teams.
The issue of fragmentation in a Domains based division is a very common one. It is almost inalienable to any event. But in order to get this properly, we must first understand what kind of domains an event's Organising Committee would be split into. Note that this is not a strict list, some of these would be split into more domains or clubbed into the same depending on the OC's needs:- - Design - Operations and Logistics - Marketing and Promotion - Hospitality - Finance and Sponsorships - Tech and Mentors
We shall go into detail as to what each of these Domains would be doing, and then identify the crux of the issue.
Design Domain¶
The Design Domain is usually the one that begins work the earliest. They're responsible for everything that technically showcases the event, from when it begins to when it ends. This includes posters, logos, stickers, banners, social media posts, and any other promotional materials where the event's name has to be shown. They usually work with a pre set requirement lists, and they need time for iteration and finalising designs. A lot of it. Their output is then used everywhere in the event, by multiple other domains.
Operations and Logistics Domain¶
The Operations and Logistics Domain is responsible for everything that is required to make the event happen. This includes venue booking, venue setup, purchase of items, crowd control, and what ever else would be required in place for the event. All the required permissions an letters are handled by them, including printing, getting stuff done, etc.
So what will they be needing? A Huge checklist with minor changes once in a while.
Marketing and Promotion Domain¶
The Marketing and Promotion Domain is responsible for getting the event accross to the public. They are needed to get the event a decent audience. If the designs are the face, the Marketing is the voice behind the event. In order to market the event, the marketing team often requires the gist of the event, including what it's about, it's timings, any guests/speakers and any perks arranged for the audience.
Hospitality Domain¶
The Hospitality Domain is responsible for ensuring that the audience and guests have a good time at the event. This means ensuring that the event goes smooth and the audience is comfortable and entertained, as well as catering to the needs of guests and speakers.
Finance and Sponsorships Domain¶
The Finance and Sposnsorships Domain aims to fund the spending of the event, including reimbursements and making a profit. Any and all purchases and money spent must be approved and tracked by the Finance Domain.
Tech and Mentors Domain¶
The Tech and Mentors Domain is responsible for the technical aspects of the event. This includes the website, the app, the speakers, the mentors, and any other technical aspects of the event.
The Crux of the Issue¶
Once you begin to understand each of the domains' responsibilities, you begin to see that a lot of them are pretty intertwined. For example, the Marketing Domain has to work with the Design Domain to get the word out, and the Operations Domain has to work with the Finance Domain for budgeting and purchases. These are just overviews. Depending on the venues, requirements and approvals, the deliverables will change.
This means that domains are supposed to work together. This is usually where domain heads are appointed, who communicate between each other for all the requirements. But this, from my experience is a very bad solution.
I was once the Finance Domain Head for an event, and the groups were pretty fragmented. We were basically asking ourselves to trust one person to give us all the information about a domain's proceedings into the Domain Head group, and then each one of those domain head must then communicate to the rest of their teams. In my case, the communication was pretty bad, and that meant for a lot of the time, I didn't really know what the status was. I couldn't know if purchases were made, if the requirements align with our projections, if approvals had come, etc. This made it very hard to plan and assign funds.
What did we do then?¶
So we devised an alternate strategy: people from my domain were assigned to work with a few people from the other domain. As in, they had to keep in touch with 1-2 people from Ops, another person in marketing, Design, etc. This allowed for a lot more context for our domain team. This also meant that our Domain had a significantly higher level of understanding of what was happening with respect to the planning and execution of the event in comparision. All this, along with a planned out, structured approach to dealing with tasks (we used Linear, a task tracker that was very sophisticated) meant that I was able to have a lot of information in hand.
As they say, "Information is Key". This let me stay on top of a lot of the things, and subsequently the rest of the domain leads as well, allowing us to manage the event waaaay better than we had initially thought we could be.
This is to not mean that I came up with this solution. The other domain leads employed some very neat tricks that worked up their sleeve as well, which I shall highlight here:-
-
The Design Domain started work early and used a set palette. They also were directly in touch with the Marketing domain, and crucially offloaded one thing to the other domains: Venue planning and design.
-
The Marketing Domain started off brilliantly by aligning the blasts with what the Tech Domain had planned. They also came to the finance domain, verifying with respect to the goodies, and made a good trade off early on. They took total control on posters, giving us an estimate of requirements very early on.
-
The Operations Domain pipelined the Letter of Requests and approvals, since most of the signatures were required in the same order. They also had frequent updates from the person running arond to get the approvals done, allowing for others to pick up from where they'd have left off.
Great. So what else did I learn?¶
Unlike the previous event I mentioned, there was one where I volunteered for sponsorships, marketing and tech. This time, I was closed off from a lot of details, but was given just the right amount of information to get my work done. This was mildly frustrating, especially when it came to the tech domain, because having details helped plan better. Nevertheless, it worked out very well, and the event was a runaway success.
I, however, disagree with such a way to run an event, especially when it's college run. Before I list my gripes, I will first list the advantages it will bring:- - Privacy of information, especially with respect to event work being outsourced - Lesser questions with decisions made - More autonomy for the heads - Faster, more streamlined decision making
So why do I think it's not the best way? For one simple reason: It's a college event. I'd rather have my team working and learning about the specifics as we go. I value suggestions more than absolute autocracy, even if it makes things go slower.
Conclusion, I guess?¶
This has essentially become a very high level overview of what an event organising committee does. I am forever grateful for the opportunities I have been given by my seniors, helping me learn to the point where I can now write this post. :D