In late September, while attending the Creative Time Summit, I attended a workshop called
"The Bias Bull-Eyes: Workshopping Oppression Awareness"
Led by Shaista Latif, Pamila Matharu, Esmaa Mohamoud and Lisa Deanne Smith
and introduced myself as a person whose passion is bridging Project Management with Arts. Later on in the workshop, we paired off and I explained to my partner how I use my privilege of understanding boring PM concepts and make them more digestible for artists and creatives - this overarching concept is closely related to code switching.
Side Note: a great example of how code switching is used is explained fantastically by Dave Chapelle
The example I used to explain this was how I replace the term "Work Breakdown Structure", a word many project managers know and love, with "Chunking". The person I was paired with said "Yeah, I see why you call it chunking. [It] sounds more fun than work breakdown structure."
For those who aren't guided by the beloved PMBOK, a work breakdown structure is defined as:
A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.
SNORE.
Translation:
- hierarchical decomposition of the scope of work = take your big project and break it down into smaller pieces
- to accomplish the project objectives = project objectives are S.M.A.R.T. goals, usually intangible. Think more business values like performance improvements, increase in market share, increase in team morale, etc.
- create the required deliverables = deliverables tend to be more tangible, a product or a service for instance. They often have due dates and can be given to a person or a team
Before I even knew what project management was, I was simply breaking down my big goals into step-by-step processed and called it chunking.Now we have fancy smancy terms for it.
Chunking = the hierarchical decomposition of a project
Below is a quick sample of a community event work breakdown structure. Here's a PDF version if the image below.
How does one create a work breakdown structure?
- If you can, find a room with lots of wall space, a big chalkboard/white board
- Gather your entire project team together in one place
- If you invite the entire project team, they are more likely to be dedicated to the project because they are helping with the initial planning stages and feel more attached to the project. They are also able to understand the scope of the project.
- If the project team is just you, ask your friend(s) for help because everyone prioritizes different things. For instance, you may think of your customer, another person may think of finances, another person may think of media, etc.
- Place the project title at the very top of your workspace
- Ask your team members to brainstorm major components for the project (sometimes people will think of sub-components and invite them to write them down anyways and connect them to the major components). In the example above, these are Paperwork, Staff, Event, Promotions & Guests.
- Remind your team that they must think of NOUNS instead of VERBS for the WBS or OUTCOMES instead of ACTIONS. For example, writing "staff" instead of "hire staff"
- Invite your team members to brainstorm sub-components (AKA deliverables) for the project. In the example above, these are everything else under the 4 main components. Invite everyone to work off of other team members' suggestions.
- Take a short break - grab water, use the bathroom, eat a snack
- Sometimes team members think of other deliverables to add to the WBS when they are away. After the break is a great time to add any new ideas to the board.
- Organize the sub-components in the most relevant categories.
- A general rule of thumb is to keep the levels to approximately 3 decompositions (ie. Lvl 1 = staff, Lvl 2 = food & beverage, Lvl 3 = servers)
- It's okay if your deliverables can be categorized into multiple sections, to keep it simple just choose one category
- The lowest delieverables in the WBS are called "work packages". Work packages are usually level 2 deliverables or level 3 delieverables. They are small enough to pass on to a team or person in the project, but large enough that they require action items to be developed to complete.
- Keep in mind the 8/80 rule. A work package should be able to be completed within 8 -80 hours of work, so that ranges between 1 - 10 working days. If it is too little, you should combine it into another deliverable. If it is too big, it should be broken down a bit more
- If you can, sleep on it. More ideas may come up the following day. If you have to get the ball rolling, then start breaking your work packages into action items.