This week I’d like to use this space to reflect a bit on the process of creating the Project Plan with my group for our project, and share some insights that I had in particular.
For context, I am generally a very process-driven, procedure-following, and risk-averse person. I like to know what I’m doing before I do it and having a plan for a big task brings me comfort. I like order and structure and clear instructions because they make me feel safe and stable. Knowing this, you can imagine that I’ve been a bit anxious about the prospect of planning an entire quarter-long project with some fairly open ended requirements.
At first, I was extremely intimidated. How in the world could my teammates and I plan this whole thing out? How would we know how many hours to estimate for each task? Sure, some of us have had internships or had made small personal projects before, but none of us has really built a project of this scale from the ground up before.
To get over this anxiety and avoid getting sucked into a downward spiral of stress and uncertainty, there were a few key strategies that really helped me, which I would like to share here.
Communicate!
One of the first things I did to quell my fears was set up a meeting with my group so that we could talk over the requirements and start planning right away. While we generally work asynchronously, we met up with video cameras on for this meeting and I feel it was important that we did so. It helped create a connection between us, and we now had faces to put to names while we chat online. It seems like such a small thing, but I truly believe it helps groups work better together when they have a cameras-on meeting at least every now and then as a reminder that there’s a real person behind the screen.
In this meeting, we did some general brainstorming about the high-level structure of our project, divided the project into a few different key areas and assigned “owners” for them (this made it easier to divide up responsibilities when making the more granular project tasks). We also talked about our strengths and weaknesses which helped in determining who could take the lead on certain tasks, but we also left the door open to anyone who wanted to learn something new by either working with the more experienced team member or agreeing to take on the task with the understanding that it might involve some extra time and effort. After all, we didn’t want to just do the things we already knew how to do! We wanted to learn new things via this project too.
Start Small If You’re Uncertain
At the beginning of the quarter, I was definitely feeling overwhelmed thinking about every little thing that would be needed in order to complete this large project. All the tasks and ideas were bouncing around in my head, unorganized and chaotic. During our meeting, we were able to start charting out the major tasks we would need to accomplish in order to meet the project’s requirements and who would generally be responsible for them. Just having some tasks outlined, not even in too much detail yet, helped me feel less anxious.
After that, we each had a better idea about what areas and technologies we would be focusing on. This allowed each of us to do some research in more targeted areas, build out our tasks in a little more detail, and start throwing some hours estimates on everything. Little by little the project plan came together, and with each revision I felt more confident. This early division of responsibility also allowed each of us to feel like we didn’t have to each figure out EVERY area of the project, and it suddenly became much more approachable.
As we each learned more and spent time on our own thinking about our areas of the project and how they would interconnect, we were each able to add more detailed tasks to our tracking spreadsheet, breaking those overarching tasks into smaller, completely achievable chunks.
This approach of starting from broad tasks and gradually whittling them down was extremely helpful for me to wrap my head around this project and I would recommend it to anyone feeling overwhelmed or lost at the beginning of a large project.
Lean On Past Experience
While I did gain some industry experience as a Software Engineer Intern this summer, the past experience that I leaned on for this stage of the project was actually from an earlier, non-engineering job.
At first I felt a little lost about how to structure and organize an entire project plan in a way that would be helpful and easy to work with for my whole team. We had already agreed that we would use GitHub Issues to track tasks once they were established, but in the meantime we needed some way to start outlining our tasks, a way to add up everyone’s hours, a way to make sure hours were distributed fairly evenly across sprints, etc. It was a lot to keep track of. If we each only tracked our own items, then we would each lose visibility on the larger project as well.
I remembered back to a past job I had at a software company when I was in an administrative position. In this role, I used to work with the Business Development team when they needed help proofreading Implementation Plan proposals, which were large projects where a number of consultants and other teammates would help clients get set up with and trained on the company’s software. I thought back to how these project plans were structured and implemented a similar spreadsheet for my team. Although this meant a little more up-front investment of time to construct and format the spreadsheet, we ended up with an extremely useful tool. It was easy to expand with new tasks as we figured them out, and we were able to track hours, sprint number, and assignees to tasks. When it was all filled out, it made it very easy to filter on a number of aspects like which sprint, what tasks were assigned to a certain person, how many hours were assigned to that person each sprint, etc. With the addition of a few formulas it was super easy to see if someone needed more hours or if someone was assigning themselves too much work in a certain sprint. This would have been a real headache to track manually if we all had to keep adding up, tweaking, and re-adding up our hours.
My point here is that even in situations you haven’t approached before (like a big technical project when your background has been mostly non-technical), you probably have other transferable skills that can help you if you are creative and open to trying!
Check Yourself Before You Wreck Yourself
Overall, I found that the most important thing in the project planning stage was to remind myself that it is completely normal to feel like you have no idea what you’re doing when starting a new project. Instead of getting freaked out by the uncertainty, I reminded myself that it was going to be a great journey to learn new things and practice the more familiar things. This tiny mindset shift helped me keep moving forward through ambiguity and ensured that I left the project planning stage excited and ready to take on a new challenge.
I know everyone has different approaches to working on projects or working in a group, but perhaps this reflection and some parts of these tips might be helpful to others.
Seeya next time!
