I am currently teaching a course in the Mohawk College and CARA Research Administration Certificate program. As part of this, I’ve been writing essays around each week’s discussion topic, in response to the discussions and reflections by the students. The first of these is on the topic of the driving priority in management of the project.
Imagine you are decorating a room. There is large sofa, and you have some throw pillows decorating it, but it looks a little bare, so you get some more. And some more. And some more. How many is too many? 5? 20? 65? Like cupcakes or party invitations, it is possible to have too much of a good thing. This applies to collaborative teams as well.
A while back, I wrote about deadlines as a necessary part of managing projects, especially research proposals with firm submission dates and times. Having recently completed another mammoth grant application project (fingers crossed – results in a few weeks), I’ve recognized some distinct levels of strength that can help in both recognizing the need for and then establishing the right type and level of deadline.
The first of these is the lightest – the deadline of convenience. This is a loose internal deadline, established to encourage progress but not really tied to any external requirement. The convenience deadline recognizes basic courtesies like evenings, weekends and holidays as being down time, and is associated with the early stages of a proposal project, when many other elements (scope, budget, team) are still evolving. The convenience of this deadline is typically linked to the schedule of the deadline setter – what is best for them in this process – and guided by the overall tenor of the team: how much encouragement versus freedom do they need at this stage.
The next level up is middleweight – the deadline of dependence. Linked to other elements, such as institutional deadlines, anticipated time required for formatting, quotes, or signatures, or other key events like conference presentations or key meetings, these deadlines indicate the dependence of other things on this work (something else needs this to get done before it can proceed), or the dependence of this work on those other things (this project needs that other thing). In proposal development, there are a lot of dependence deadlines. The budget cannot be completed until the proposal body is written. The references cannot be finalized until the writing is done. The summary sections need the main proposal to be finished before thy can be written. (Notice a pattern here?) The signatures cannot be secured until there’s a substantial enough document and a reliable budget number.
This middleweight level is where deadline setting becomes both art and science. These deadlines cascade and link to one another like an elaborate acrobatic act, overlapping and connecting pieces of the project until it all comes together as a completed thing. The reality is much messier than that, of course – more like the assemblage of a multi-course dinner with no recipes. There will be adjustments throughout, to both deadlines and content (scope change), but the goal is still the same: the completion of the project.
In the case of a grant application or project proposal, there is also the heavyweight level – the deadline of consequence. Usually established by external stakeholders, these deadlines are immovable, with the consequence of complete project failure if they are not met: there is no coming back from missing a proposal submission deadline.
Deadlines of consequence can also occur within the project itself. There are sometimes firm, non-negotiable deadlines on things such as internal approvals, hiring opportunities, and vendor quotation expiry dates. Other key dates exist as milestones – fiscal year end, for example – that can become deadlines for spending or reporting. These should not be taken lightly, as there is little to no recourse when these are missed.
True project management would have you build the schedule forwards, determining the estimated time for each task or activity, considering the dependencies and relationships, constructing a critical path, and then calculating the completion date. More often, the reality is that schedule development is best done by looking at that ultimate deadline of consequence (the submission deadline) and working backwards to populate the schedule with dates and associated tasks that are needed.
Thinking about these various levels of deadline can help when considering building deadlines into your project schedule. Where are the deadlines you cannot miss (consequence)? Where should you put the ones that contribute to bringing the project elements together (dependence). And where can you put a few to best support and enable the team and the project to be successful (convenience)? For each deadline on the schedule, make sure you know which kind it is, so that you know how flexible (or not) it is and what else it is connected to. By keeping track of progress and activities against these deadlines, and adjusting as possible throughout, you’ll have the best chance of successful completion within the time available.
Last month, a colleague was up for a new job. After searching for some time, they at last had an interview for a project manager-research administrator-type role with an organization that had never had a position dedicated to that work. The research team had grown sufficiently over the past few years that they were now considering it. My colleague asked for some input, as they were working to “justify” the idea of a dedicated project management position to the team. There was no clear job description yet, so they asked if I “could shed some more light on your day to day as a project manager.” Happy to.
Why have a project manager?
1. It’s required.
2. It makes good business sense.
There is an increasing requirement from institutions and funders for responsible conduct of research (RCR) – both doing it and demonstrating it. The traditional concerns of RCR cover ensuring that work is:
In addition, the efforts required to secure funding for research continue to increase, with ever-challenged public and private funding sources, more competition, and higher standards for awards, as well as the en vogue requirement for matching funding or co-funding of research.
All of these mean that the demands on research leaders extend well beyond the conduct of research to include the ongoing demonstration of responsible conduct, including in areas that are time-consuming and often outside their areas of expertise and interest. With the researcher's time being the most valuable strategic asset of a department or institution, maximizing their time and energy to focus on the science is essential.
While it is important that research leaders and scientists have a good understanding of research management principles, more important is to have resources and infrastructure, in the form of a project manager or research administrator or both, to assist and support them. People in these roles in an organization can both free up the researcher's valuable time and better ensure that the requirements of RCR are being met.
As a research project manager, my day-to-day work is in exactly these roles with the research leaders, enabling their focus on science while maintaining and demonstrating RCR. This includes:
I’ve heard the argument from researchers that spending money on these functions and positions takes money away from research. While that may be true, I refer you to my short list of reasons above. Funders now often require these functions to be performed, and many often require or at least allow some of the funding award to be used for project management personnel. By extension then, these funds are allocated to support the management work, and so research activities are not eligible expenses for them. Regardless, whether you allocate money from the budget for management, or you allocate a valuable research resource like a leader or a research associate, the requirements of RCR must be met, and so it is more efficient and effective to spend those dollars on the specialized resource of a project manager.
It is difficult for less senior researchers to have access to the funds to support these roles. This is where the power of collaboration comes in. Junior researchers can pool their limited resources to engage and share project management and research administration expertise. As their own portfolios grow, so too will the requirement for project management expertise but also their means to be able to support it, resulting in the development of an expanded resource pool for them and their colleagues.
So when asked, “why should we have a project manager or research administrator for our team?”, the answer is, “why wouldn’t you?”
Scenario: you’re writing a proposal, and the funding agency (or client or sponsor) website says that the submission deadline is 5pm EDT Monday 31 August. But your project manager has said that your deadline is noon on Thursday 27 August. What the heck? Why do you have to complete it four days before it’s due? What if you really need the weekend to fine-tune the meat of the proposal? Can’t you give it to them at noon on Monday?
After a dozen or so years of working with scientists on grant applications and proposals, I’ve learned a great deal about the ways they work and their needs for time to make their great science look and sound great on paper. Having tried (and failed) several times to write grants myself, I know there is great art within that science, and so my mission as a project manager remains: enable the best possible science and more of it.
I’ve also learned, and hopefully have demonstrated, that there is method to the madness of setting deadlines for proposal projects. The method aligns with the mission – enabling the science – by making it possible for the proposal to actually be submitted. Which means that the funder deadline is not our deadline.
Deadline is actually a horrible word, when you consider its definition:
deadline (n): 1. A line drawn within or around a prison that a prisoner passes at the risk of being shot. 2. a date or time before which something must be done.
It is no surprise then that deadlines rarely have the feel of incentive. But the modern use of the term seems odd – if I were a prisoner in such a prison, I would be staying as far away from the deadlines a possible, never mind meeting them.
Considering the quadruple constraint (scope-time-cost-quality), it’s also not surprising that deadlines quickly become a thing in projects – and a proposal is a project. Defining those boundaries is essential to planning and managing successfully. However, deadlines can quickly take over as being goal or objectives themselves, when really they are just another milestone – a point in the project to measure progress – only at the deadline milestone, estimate to completion should be zero. Milestones are tools for good project time management, but like any tool they only work well when applied appropriately. Part of using them appropriately is distinguishing between the real and the artificial.
Real deadlines are more often imposed by an external entity, such as the funder, but can also be internal to a department or institution. But, they are only real if they’re also firm – as in, there are real consequences for not meeting them. Real deadlines look like this:
They will also typically have specific scope and quality requirements, too. The above deadline requires that the complete proposal in the correct format with all the required elements is submitted BEFORE the deadline. These are as close to the original definition of deadline as we get in the research management world. Missing a real deadline can be pretty devastating.
Artificial deadlines are usually internal or self-imposed. They are more accurately called milestones, as they are (or should be) established within a timeline to enable all the participants to be able to do what is required to meet the real deadline. Unfortunately, because these are self-determined, they are often seen as more flexible and can be ignored or overruled if one part of the team falls behind schedule.
This is what I refer to as “the peril of the deadline extension”. Teams and leaders can very quickly undermine their plans and put their success at risk by extending internal deadlines. By allowing these internal milestones to be moved or circumvented, the project schedule closest to the real deadline becomes compressed, often to the point where success is now nearly impossible. Scope and quality are sacrificed to time, as the precious “last minute” becomes the last 30-seconds, giving insufficient time to deal with unforeseen hurdles.
There are a myriad of things that have to happen with a proposal to get it submitted, and while some sound trivial, they can be enormously time consuming. Converting a document to PDF should, in theory, take very little time and work the first time you do it. However, as anyone in science can appreciate, things that sound like they should work often don’t work out exactly right the first time (cell lines, anyone?).
There are more complex elements to proposal completion as well, such as: aligning other proposal pieces (budget, team description, management plan) to the aims; confirming references and citations in the proposal are correct (and in the correct order and format; checking page and character limits. Many of these things are done in parallel with the main proposal writing, but they must be re-confirmed prior to submission. Since everything else in the proposal links to the science piece, nothing else can be completed until that is done.
And so the proposal deadline becomes a few days to a week in advance of the funder deadline. The project manager sets this deadline to minimize the risk that the submission will be unsuccessful due some kind of administrative issue. Believe or not, the deadlines and milestones are not set to be maximally inconvenient – they are set to maximize the chances of a successful submission.
There is an intrinsic benefit to these internal milestones as well. Without a boundary for time, teams and writers can sometimes get stuck in analysis paralysis – the project stops moving forward while the team analyses all the possible angles and options. This endless rumination (“we should all go away and think about how best to do this”) will happen without some firm date by which decisions must be made and things completed. By ensuring that necessary decisions get made in a timely manner, all elements of the project can proceed towards completion.
A recent piece that I read brought up some interesting points about deadlines. This author asserts that there are two challenges with deadlines: they force decisions to happen within a given timeframe, sacrificing quality to time and they create a disincentive to revisit a process or project once it’s completed, as people will have “project fatigue” from having worked within a challenging timeline, and be unwilling to look at it again once it’s done. While these challenges are likely when deadlines are arbitrary or poorly planned, well-placed project milestones can encourage LEAN thinking by making time a key element in the project, and they can encourage more thorough risk assessment in project planning and better break-testing and change management processes in project implementation so that returns to the past don’t happen but continuous improvement does.
So deadlines are not the enemy – poor project planning and time management is. Well planned and placed milestones enable projects to be successful by ensuring that the project team keeps track of what they’re doing, where they’re at, and what the true project objectives are. Meeting the deadline is not an objective. Completing the project successfully – the full scope of work to the required quality within the time allowed without breaking the bank – is the goal.
Don’t believe me? Check out what NIH has to say: first-time applications (i.e. not re-submissions) submitted ON the due date are TWO TO FOUR TIMES more likely to ultimately miss the submission deadline than those submitted one week ahead of the deadline.
Who is Robyn?
My career as a research project manager is rewarding, dynamic, challenging, and fun. I'm looking forward to sharing my knowledge and experience in communication, organization, and common sense approaches in research management and leadership, and to enabling others to learn and grow in this exciting career.