Throughout the years, I have worked on a wide variety of projects. Some, such as class assignments, have taken days to plan and execute. Others, such as my Masters in Biology thesis project, have taken years.
So what have I learned about project planning?
- The first thing is to plan for the planning. This concept isn’t my own and came from Roger Tomlinson’s famous book, “Thinking About GIS: Geographic information system planning for managers“. For context, Tomlinson is the inventor of GIS in its earliest form and is often referred to as the “father of GIS”. I had the honour of meeting Mr. Tomlinson before his passing in 2014. The concept he put forward of plan for the planning boils down to the fact that every project requires some degree of planification and that this process takes time. He argued that this time is just as valuable, if not more so, then the time spent working on the project itself. A poorly planned project will most likely provide negative results, and could prove to take far more time, money, and energy than was initially believed. However, if one takes the proper amount of time to plan things out, then they are likelier to stay within their target time frame and budget. I have found that taking the time to plan out a project at the very beginning saves headaches in the long run. Anecdotally, this also feels exponentially so as a project gets bigger and bigger.
- Another important part of planning a project is staying organized. This may sound simple, but can involve many elements. I like to learn through examples, so I will attempt to practice what I preach. As Data Analyst, I was responsible for training students/professors/researchers who needed to use the Postal Code Conversion File (PCCF). The PCCF is essentially a massive database of all the postal codes that were ever created (approximately 1.6 million records) and how these all relate (geographically) to various Statistics Canada census geographies (e.g. census divisions, census tracts, etc). So a researcher who is interested in certain postal codes and would like to supplement their data with census data would need the PCCF to be able to do this effectively. I would be the one to meet with them, go over their project details, evaluate if they needed to use the PCCF (or perhaps some other resource), and if so, train them on how to use it for their needs. This was a process that could vary based on the request, but generally had many of the same steps (e.g. assessing the suitability of the project, creating a subset of the PCCF, removing duplicates, etc). To be as efficient as possible in handling these requests, I found that keeping all my data files (e.g. SPSS code), assessments, and metadata well organized was hugely beneficial. Sometimes a month would pass between requests, and it would only take a few minutes to access all the necessary files to become re-familiarized with the process and assist a new user expeditiously.
- The third point is that everyone working on a project have established roles and clear communication channels with one another. Group projects were common in my work as Data Analyst as well as my school work during my MIS. When a group works well together, supports one another, and has clearly established roles and communication channels, things are wonderful. However, I have worked on many projects where this was not the case, and invariably, certain team members will end up doing much more than others. Sometimes the situation may call for this, as varying skill sets may dictate that certain individuals be called upon to do more than others. However, often this imbalance is a result of not having established clear roles at the outset. When laying out a project and coming up with a series of deliverables, there should also be one or more individuals that are tied to these deliverables. This makes those individuals responsible for those parts of the project, and is much more effective than simply laying out a list of tasks with no real idea of who will work on them or how these will get done. It is also important to establish clear communication channels between members of the team, whether this be through email, Slack, planned/unplanned face-to-face meetings, etc. Knowing who/how to get in touch with those you need to communicate with when you have questions is vital. I have seen many projects be slowed to a crawl or entirely derailed because someone on the team couldn’t accomplish their task as a result of a breakdown in communication. Notably, this can also occur with communications to sources outside of the group (e.g. when contacting government agency to obtain data), but this is often out of your control.Examples of group projects I have done as Data Analyst include:
Reference
- Tomlinson, R. (2013). Thinking about GIS: Geographic information system planning for managers (Fifth ed.).