Project Management Processes

We all know that having a solid foundation is a great way to start building something fantastic. 

All projects have to start somewhere and I am really interested in making sure we have a process that makes things easy for us in the long run. 

Why is process so important?

Well, think of it this way. If you want to run a mile but every 0.20 miles you have to backtrack for some weird reason and start 0.5 miles back to where you were ; it’s going to take you super long to finish the mile! But if you are running normally, and you don’t back track for weird reasons, you can finish the mile more efficiently, with less headache and its less painful! 

Starting a project off incorrectly, having information slip through the cracks, not having vital project team members present and not having their voices asking the right questions, often makes a project more of a hassle. Rather than waste time, and get more stressed out, I would like to make sure we are following our process properly. Less wasted time means more time for fun game research for us!

Below is the process that I’ve created, iterated with the team and polished until it is what you see now!

I’ve outlined the steps below. 

1. Initial communication. Someone contacts GRID interested in our services. We make sure to document them.
2. ACTION- Depending on what they’re asking for we send the correct intake form after communicating with them. CRM is generated to mark down their interest and create a profile for them. First client meeting is also scheduled.
3. Team – Before the client meeting, quick chat with the team to share intake. See who wants to be at the client meeting. This can be to see if the design teams wants to ask questions or get a feel for the possible project from the client directly.
4. Planning-Check current bandwidth of the team. Do we have the space to accommodate a new project right now? Make sure to have a good understanding before client meeting.
5. Client- First meeting with the client to discuss basic ideas of project. Discuss deadlines, basics of funding/budgets. Tell client we will take this and decide whether or not we can take this project on.
6. Team- Internal Meeting. Brainstorm, mission alignment assessment, grid soapbox.
   1. Is this something we want to do? Can we do this? What are the risks? Whats on our plate? Can we partner with someone on this? If we do want to take this on ideas are thrown and settled. Storyboards and design doc are tasked and worked on after this. Try to estimate how long this project would take.
   2. Create scoping document, and lead takes charge for design. Storyboards and design document are created
7. Client meeting – Pitch or ditch. We pitch the ideas that would fill the need of the client. We give our estimate on how long it would take. Need definite deadlines with this project by this point in time from the client side. Budget also needs to be discussed. First draft storyboards and draft of design document are presented
8. Team Meeting -Internal chat. We decide to formally take this project on.
9. Planning – SOW, deadlines, content deadlines, budget and everything laid out. Support needs to be outlined. Who owns what, ownership of assets. Client signs and we are a go! Production START!

This might seem like a lengthy process but each step was carefully created to make sure we are following something that works for our team. In the past, when things have gone wrong, I’ve noticed that something was broken or overlooked in these critical steps. 

Speaking of critical steps, here is what the team follows when doing a sprint. I team up with the project lead to make sure we are regularly meeting and adhering to our process. 

My job is to make sure we are starting off on the best possible foot, by adhering to the process we outlined, making sure that everyone understands what step we are on and giving everyone the option to chime in with concerns and questions. By involving the designers and developers early on, we are able to identify key risks and contingencies based on their understanding of their craft. 

The next section cover the every important intake form I created to get everything we typically look for down in a document. 

With a name like that, our clients loving putting in the work to help us help them out. 

At GRID we typically work with faculty, departments and staff to create learning objective focused content. Meaning, we create a game to serve an educational goal. 

But there is a disconnect we need to work with here. Communication is the corner stone of understanding. 

How can we create a product without understanding the needs of the client? How can we better understand the clients? We ask  A LOT of questions. Sometimes though, asking all these questions in a meeting can stretch the meeting to be a few hours long. 

As the PM, I want make sure we are given the best footing we can to take on a project. We only have so many hours to work, process and create.

That’s where the lovely Help Us Help You comes in. We outline specific design questions we typically either ask or want to know in order to start thinking about creative solutions. 

The standard outline for the document is : an intro, some examples of past work and the following questions :

I found that having these questions outlined, makes our clients take their request more seriously. We want to know that the clients have really thought this out and have specific goals in mind. Again the goal is to make client meetings more efficient. 

As a student worker, I noted down the important questions we typically asked to get everything down so that we can start working on a scoping document, then a design doc and storyboards. 

Having all of these really important questions down also allows the team to chime in with client specific questions for the actual client meeting follow up. 

We’re able to weed out premature projects, ill funded projects, out of scope projects. This document ended up saving us tons of meeting time! 

We also have a few variations depending on the service the client is coming to us with. Either a virtual world, game project or an event project. 

The Statement of Work is the culmination of all the hard work setting up a project. It lists out the boundaries of a project, defines the scope, defines the problems and solutions offered, outlines the deadlines for content and the proposed timelines of the project. 

A lot of that work in completed together as a team. I make sure to create a feasible timeline once our scoping document is created. I typically create the scope of a project after meeting with clients and discussing our options with the team. It typically serves as the voice and concerns of the team. 

The timelines are typically created within realistic and feasible goals, based on what the client wants, and based on what we can do within those deadlines. 

I work very hard to make sure the developers have their voice heard when creating timelines. 

A recent timeline I created for a project is outlined below. 

Great care is taken to make sure we are creating timelines to avoid a crunch, with time built in for a buffer for errors and unforeseen issues. As outlined above, I provided extra time for things to go wrong and for time for the clients to schedule me in. 

After all of that is outlined I draw up the contract. 

A clean, well written document is amazing. We are able to understand what the project is, who it is for and what we aim to do about it. In this first picture outlined above, we have important, self explaining sections laid out. 

As a PM, having this all laid out properly acts as an insurance for the team. Once a project goes out of scope for some reason, I am able to refer to this document and point that the client signed this document agreeing this this specific scope. Having everything tightly knit really saves in the event of an unruly client. 

SOW part2

Here we have content deadlines. This allows me to keep our clients responsible for providing everything we need to do our work. 

We have a separate section for billing and fees. Since we work with different departments and games are typically expensive to crate, we offer discounts and we explain this here.  

Warranty and support are self explanatory. We aim to offer support to our clients. It differs with each project. 

Lastly, we have our right and ownership. We spell out our intentions, how we store the project and our marketing goals for each project. Again, this servers an insurance for our team. I found it best to have it here and go over it with the client to out them at ease than not and get bitten later on. 

SOW part 3 

The final part is the University legal stuff we are required to put as well as the final parts of ownership. 

Spelling out our intentions leaves less for assumptions to run around so while this might be wordy, I love having it all down to refer to in the future. 

I view this document as a project charter and as our insurance for taking on a large project. 

When a project is in production, how do I keep track of everything that goes on?

We now mainly use Github as a place to store our projects, project tasks and we use these Kanban style boards for our weekly scrum meetings. I make sure our team members are on track and that we report our weekly progress at these meetings. During our scrum meeting, we go through our weekly sprints to make sure we are making progress towards our milestones which culminate to our main features. I understand that our team uses a mix of various types of methodologies but it works for us. 

Below we have a a few different types of boards for one specific project. I typically check in for each board to make sure we are making steady progress. Some boards are maintained by specific leads or developers. Overall, I typically make sure we are following our process, our kanban type boards and that we are making steady process. Below you see three boards for one project. They are maintained by some mix of team members depending on what part of the project we are talking about.  This way, our asset board is not cluttered with development bugs. 

Here we have an old Asana board, which was another software were tried out and ultimately didn’t like. 

Here is a calendar invite for the weekly or biweekly scrum meetings we typically have during development. 

I track each project currently on deck using our Miro Master Project Calendar Show below. I’ve created this calendar and came up with how to update and use this while making decisions of taking on projects and which team members are doing what. This serves as a great visual of WHO is on WHAT project. This also keeps track of vacation times planned and helps me make sure no one is overburdened by being on too many projects at the same time. 

When we are done with a project, we typically have postmortem for each project to define

1. What was this project?
2. What went well
3. What needs improvement
4. And what are our next steps

We typically hold these postmortems to highlight the good along with the bad. Things don’t always go perfectly during a project and now’s our chance to highlight the issues with a spirit of improvement. Mistakes, shortcomings and failures can be seen as uncomfortable topics that target individuals but when structured properly we can learn and grow from them. 

The most important aspect of this postmortems are the rules we outline before each session. We set the stage so that no one takes things personally, no one makes it personal. We are talking in the spirit of OVERALL improvement. We also like to make sure this is a welcome, comfortable place to talk about some issues we might have faced during the project. Making sure everyone is open to listening to all perspectives is a corner stone of the postmortem format. 

Here is an example of a postmortem board. 

Retrospectives are typically for our 2 week sprints and serve to look at the over all health of the team while we are working on our different projects. We use this space as an area to list and highlight wins in the departments. 

We also use this board as a place to talk about difficulties in general that we might have faced over the last 2 weeks. 

The last two sections are for coming back together and talking through some of the issues, escalating reoccurring problems to upper level management and setting up long term goals for the team. 

I typically like to stay up to date with my team members when making sure we are on the same page. I find that finding the time for a quick catch up works best. I am up to date with their progress, I am able to communicate that over to the higher ups and I have a better picture of the status of our department’s output. 

I usually just ping someone to see if they have time during the week for a chat.

Above I have an example of a day for me to catch up with one of my team members. 

We like to start off the week strong. What better way than a early morning meeting to see the progress of the previous weeks work.

GRID all is a higher level view point of all the projects, events, growth, and anything else that the team is working on. We report on the status of projects, any large issues needing to be addressed, scope or timeline issues and if things are proceedings as planned. 

Having the team get together helps plan out all of the important meetings that need to be scheduled through the week. As the PM, I work with project leads to make sure everything is scheduled. 

This is our version of a standup except it’s a bit more formalized. 

We’ve all heard of stand up meetings. But I’ve developed and I’m looking into patenting this new improved type of meeting. 

Let’s look at what a traditional stand up meeting is defined as. 
A stand-up meeting is a team meeting organized on a daily basis to present a status update to all a development team’s members. This semi-real-time status update raises possible issues and synchronizes efforts to eliminate challenging and time-consuming problems. Stand-up meetings are most common in an Agile development process like scrum, but it can also be extended to any methodology in development.

We already have this incorporated in our daily schedules. Before the pandemic, I asked that we put our daily standup in our slack channel. This helps me not have to chase down people for answers or status checks( I still do but they are now more focused). It also allows for the free flow of information. As a PM, I do not want to be a bottle neck of information. Having this information out in the open allows for others within the department to ask questions and step in to help. I have posted my issues with certain obstacles in the chat in the past and I’ve gotten the help or advice needed. It really helped me feel heard!

Now I have innovated on this classic scrum style meeting with my new Elevated Meeting. Patent pending**

I define an elevated meeting as “an agile development style meeting in which anyone on the team faced with an obstacle  can stand on a desk, or other furniture not typically stood on, and yell about it”.

Now I know that you think this is highly unprofessional and can’t really work well enough for the trouble it brings….but it actually has a 100% success rate. I’m not kidding you. 

This gave everyone participating

• a fun outlet to yell about something frustrating 
• it made everyone laugh a bit, helping with the emotions of facing an issue
• the silliness made everyone smile! Smiles help cure problems
• literally a new way to look at an issue. You are asking for more perspectives without being so formal. Being formal or asking for help sometimes is really difficult. This frames the issues and asking for help in a fun, weird way. 
• makes you feel like you’re not alone, the team is here to support you!

I typically found that after these meetings, we all feel a lot better, a bit closer together and someone usually comes up with a solution due to varying perspectives, or gives an idea out that guides the caller to a solution! It’s magic! You are opening yourself up to the different possibilities. You are open to what can help you. 

I’ve studied psychology in my undergrad, and something about this process just work. I think it’s the community aspect of yelling together at a problem. I have also proposed this to other project managers at Rutgers and they have loved this idea. My teacher for my audited “IT Project Management” course at Rutgers University absolutely loved this idea. 

The rules are that you go to a team mate, ask if they have the time for an elevated meeting, make sure our office neighbors are not there or aren’t doing something important , and then you go to town. 

I like to operate on the principle that “if it’s stupid…but it works…it’s not stupid”. Feel free to ask me about this! I’d love to chat about it! 

You’ve heard of companies having gyms but have you heard of dance breaks? So this is a new way to take a break with your team, get away from the computer that we spend all day on and take a moment to work up a sweat. Not only is exercise for you, it makes you feel good too! 

“When you exercise, your body releases chemicals called endorphins. These endorphins interact with the receptors in your brain that reduce your perception of pain. Endorphins also trigger a positive feeling in the body, similar to that of morphine. In general, stress is related to both external and internal factors. External factors include the physical environment, including your job, your relationships with others, your home, and all the situations, challenges, difficulties, and expectations you’re confronted with on a daily basis. Internal factors determine your body’s ability to respond to, and deal with, the external stress-inducing factors. Internal factors which influence your ability to handle stress include your nutritional status, overall health and fitness levels, emotional well-being, and the amount of sleep and rest you get”. (  https://www.medicinenet.com/stress/article.htm) 

Taking 10 minutes to go for a quick round of dancing with your coworkers might seem a little awkward but for a small team like mine, I found that this is the perfect fit of fun and destressing.  We’re able to take 10, dance and then get a drink of water. Often times I saw that after going for a quick round of dancing, we often bring up things we’re working on. It brings us together as a team, we use this as an informal quick check in and I’ve found that I am able to focus more afterward. 

It’s rooted in science my dear, “Exercising regularly is one of the easiest and most effective ways to reduce the symptoms of ADHD and improve concentration, motivation, memory, and mood. Physical activity immediately boosts the brain’s dopamine, norepinephrine, and serotonin levels—all of which affect focus and attention.” https://tinyurl.com/wtbs28ju) 

As someone who studied to be a doctor all my life, I still love applying different bits of Psychology and Biology to my my life everyday. Learning about the body and how to manipulate it based on science is kinda like hacking your mind and body to feel a bit better. 

I have had my teammates also look forward to our Just Dance sessions. We feel a bit more awake when we do these in the afternoon. I saw that it tends to shake off the post lunch fog that we sometimes fall in. I used to also do marathon running in middle and high school. To get me through the last push of the race, I would think about how nice it’ll be when its over. Sometimes I would think of a delicious meal I would get treated to. Knowing that the end of the day is almost here makes me want to give it my all before clocking out.

Taking your mind off a specific thing you’re working on and coming back to it after being refreshed just works! As creative people, I want to make sure I’m not interrupting flow so we sometimes try to plan out during lunch to take a break around 3 to re-center. 

I also want to highlight the notion of taking care of your employees. I’m fortunate that I was able to implement these breaks and that we are still able to focus and get our work done. Making sure everyone is taken care of and that we all take care of our bodies is also quite nice. 

Above we have the VR/Game room I set up and maintain. I also typically bring my switch in work, for research of course!