The Good, the Bad and the Beastly

Reflections for project managers new to research projects, by Dominique Thompson

When the opportunity arose for me to be a project manager on the Beastly Business Project, I jumped at the chance to get involved. The project combined many passions of mine; wildlife, criminology, conservation and law to name a few. I was excited by the opportunity to apply existing project management skills to make a positive difference and the promise of being able to learn more about such interesting subject matter.

I joined the project when it was already mid-flight. The project comprised a tight-knit, high functioning team of 5 researchers at different stages of their career. I was immediately struck by the fantastic team dynamic, how effectively the team collaborated and successfully employed each team member’s strengths. 

Despite my experience of being a technical expert in my own right in previous roles, joining such a knowledgeable, well-established team could have been really daunting. I had never worked on a research project, or with academics. I certainly didn’t have the specialist subject matter knowledge that each of the team possessed about the illegal wildlife trade and the respective species they were researching. The cynical part of me also initially suspected a definite risk that I may drown in a wave of technical academic language not encountered since my days of being a law undergraduate

I was so excited to make a difference. Taking an intentional pause before getting ‘stuck-in’ proved a challenge. I wanted to understand the working styles and strengths of the team, what was working well and any challenges, pain-points or gaps. Having such a birds-eye of the project enabled me to quickly understand where my expertise and time would most add value and where changes of approach may unnecessarily disrupt the team in the months that remained.

Much to the relief of my former undergraduate self, endless debates about paradigm-shifts and dichotomies were distinctly lacking. Instead, communications were enthusiastic, effective, plain-English collaborations. Thought-provoking discussions went hand-in-hand with a supportive, welcoming team culture that valued and encouraged contributions from all team members and truly championed co-creation. The opportunity to get involved wasn’t limited to team events and I found myself discussing intriguing topics with lecturers and researchers from across the globe.

It was clear from the already highly organised project team that imposing rigid or prescriptive project methodologies would only hinder the team in achieving its objectives. Instead, I combined Agile tools and exercises with the principles of excellent service management. This was received really positively by the project team, who were able to effectively prioritise, realistically plan and successfully deliver their key deliverables to the agreed milestones without it negatively impacting the team culture.

10 key takeaways for project managers new to research projects

  1. Passion and participation. It helps if you are passionate about the subject area and naturally want to get involved in the work! Don’t be afraid to voice your inputs where collaboration is welcome. Sometimes a fresh pair of eyes and a different perspective can be just what is needed. 
  2. Principal Investigator (PI). Great leadership shouldn’t be underestimated; it can be the difference between a dynamic team working seamlessly to achieve the same goal(s) and an ineffective team in disharmony. Luckily for me, the PI set the tone for the team dynamics and an amazing project culture at outset.
  3. Psychological safety. Create a culture where all members of the project feel safe to voice their opinions, make mistakes and can be vulnerable. Joining a well-established team can be unsettling for the existing team members too who may fear change, so engagement and adaptability goes a long way.
  4. Plain-english. Effective communication on research projects is key! Communicate clearly, in plain-English, using commonly understood terminology and avoiding acronyms and project jargon. You may be working with non-native speakers, various technical specialists and academics and project acronyms may mean something completely different. 
  5. People. Take the time to understand the culture of the project and each team member’s preferred ways of working, their strengths and challenges. By taking a customer-focused/service management approach you can accommodate preferred ways of working. Constant interruptions of research team members can easily hinder progress on key deliverables like academic papers and articles. Be respectful and ringfence time outside of their agreed focus time for queries.
  6. Prioritisation. What are the most important outcomes/objectives for the project team? It isn’t always about increasing performance/velocity of a team to ensure they deliver. I found the opposite; the team was overstretched. By flexibly undertaking an exercise based on the MoSCoW’ing prioritisation method found in Agile, I helped the team to disregard ‘the noise’ so they were able to focus on delivering the key deliverables. 
  7. Processes. Get to know the key processes that the project relies on. Where can you add value? What is working well and where are the gaps or inefficiencies? Don’t spend time re-inventing/disrupting a well functioning research team in the name of a project methodology when time could be better spent enhancing processes, making efficiencies or addressing gaps through quick-wins. 
  8. Partners. Research funders and partners can have different requirements, objectives and ways of working. Be clear of what research funders require of the project team so that you are confident you can advise the research team accurately. 
  9. Platforms. Don’t forget your tech! Whether you are using Twitter, spreadsheets or web platforms, ensure you are quickly up-to-speed and comfortable with how to use the tools and software that the project has if this is in your remit. Build good rapport with your suppliers and keep track of any platform/software expiry dates. No one wants lost content.  
  10. Perspective. Finally, there is no one-size fits all project methodology for all research projects and teams.
Bear and policy briefs
Policy Briefs