Project management is a key part of academic research. Indeed, it is often put forward as a transferable skill. Although many academics are good at managing projects, my experience suggests many are not aware of the various approaches, resources and terminology used in project management. Thus, although the skill itself is transferable, being able to demonstrate it (say on your CV or in an interview or in a new job) is a much harder task.
In an earlier post I spoke about some of the different approaches to project management in research. The approach I suggest would be best suited to research is agile project management.
At its core, agile project management is iterative. That is, projects are progressed in small and manageable increments. In software development, where this approach was developed, that meant building a small part of the software package, checking that part met user requirements, then moving onto the next. And these parts could be as small as a welcome screen or other start-up page.
To me, this sounds a lot like research. We take small steps each day, reviewing their impact on our overall hypothesis. The hypothesis might change as a result of what we find. But, more likely, how we test our hypothesis will change, rather than the hypothesis itself.
So, if you were to set up a research project and implement an agile or agile-like approach to its management, what would that look like?
In agile, you only document the minimum necessary to get the work done. That would mean your hypothesis, or the hypothesis being tested. It would mean a broad outline of the understanding you would like to have if the work is successful. It would mean knowing what the first step is and how long that might take. For a PhD project, intended to span no more than four years you might have:
- What you intend to research in a few lines.
- What you want to achieve in each year – again a few lines per year.
- What you want to achieve in the next 12 months – limited to a few lines per quarter (3 months) or semester (6 months).
- What you want to achieve in the next three months – again, limited to a few lines per month.
- How you will achieve those things in the next three months.
- The focus of the next month on a week-by-week basis. But still only a line or so per week.
Thus, the whole plan for a PhD project will be about two pages. Of course, it will grow as you do the work. Because you will need to document the methods you use, the findings you make and the implications in the context of the wider literature. Remember, it’s about minimal documentation, not no documentation.
Agile project management
– a useful tool for managing
This is the length of time it between revisiting and revising the documentation. A good length of time for a PhD project is once a month. It does not need to be a long time, but you do need to review all of the documentation to check it is still relevant. And if it is not, like with any plan, change the plan to match your intentions. The review might also coincide with meetings with your collaborators or supervisor(s).
There are also smaller work cycles of a week or a day. These work cycles are built around specific tasks and checking them off. For a PhD project, where there might be minimal collaboration, the daily, and weekly work cycles might be meetings with yourself. Whereas, if the work you do is collaborative, the weekly meetings (and perhaps daily meetings) might include a subset of your collaborators.
Another important part of work within an agile project is that tasks are not dependent on completion of other work unless absolutely necessary. Thus, in the case of a PhD, most people might do their literature review first. But if you know your samples, equipment or subjects will be ready now, but not later, then you might start data collection and then move into the literature review.
In all cases they are fit-for-purpose. So planning meetings coinciding with the work cycle will be longer (e.g. an hour). Whereas weekly or daily meetings will be shorter (five to twenty-five minutes). When your plans are being revised and decisions being made, then the meetings need agenda and minutes – so there’s a record of the decisions made. When the meetings are about allocation of work, then there is less need for meetings. Indeed, in agile the weekly or daily meetings – often called stand-ups –primarily involve moving work tasks from one column to another. These columns are simple categorisations of work. To do – the work we need to do. Doing – the work we are doing. Done – the work we have completed. This is often referred to as a Kanban board. And you’ve probably seen them on windows in offices with sticky-notes. Indeed, if the Kanban board can be used to avoid a meeting, it is.
Progress is tracked daily and weekly (as per the sticky-note idea above, but you can usual electronic versions of the same thing). And then it is updated (documented) monthly. Again, the idea is to do the smallest amount of work necessary to make progress.
Is this valuable?
This approach is intended to be flexible. But that can result in problems. As researchers documentation is essential. Yet, using a project management approach that is deliberately document-light, can cause trouble. It could mean you miss noting key aspects of your work.
Dr Richard Huysmans is the author of Connect the Docs: A Guide to getting industry partners for academics. He has been supporting research portfolios, programs and projects for more than a decade. He knows the theoretical approach to project management as well as the practicalities of academic and research projects. He is a #pracademic. Richard’s strategic approach to collaboration and research translation has been making the impossible possible for more than seven years. His clients appreciate his cut-through approach. He knows the sector and how to turn ideas into reality.
To find out more, call 0412 606 178, email (Richard.email@example.com) or subscribe to the newsletter. He's on LinkedIn (Dr Richard Huysmans), Twitter (@richardhuysmans), Instagram (@drrichardhuysmans), and Facebook (Beyond Your PhD with Dr Richard Huysmans).