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.
It happens to everyone. You’ll be in a meeting or working on a project, and someone will say something that, to you, sounds like a criticism of your work, or of you specifically. Perhaps it happens in a meeting with a group, looking at a challenge or crisis on the project. Despite your project management work to date, someone says, “we really need to start managing this project.” You think, “wait. What the heck do you think I’ve BEEN doing?”
The feeling can be very distracting. You find after a few minutes that you haven’t been paying attention. You feel a bit flushed, a cross between angry and embarrassed. The conversation has moved on, but you have not – that sentence and those feelings linger beyond the meeting and the day.
Sometimes, this can lead to or feed into Imposter Syndrome. Most professionals experience this at one time or another, sometimes often: the feeling that, despite all evidence to the contrary – like your career progress, position, recognition, and other success – you really don’t know what you’re doing and it’s just a matter of time till everyone else recognizes it.
This feeling is quite common – I’ve heard from friends and colleagues in all fields and at all levels that, every now and then, they fully expect to be found out and asked to leave. Like being unmasked a party they haven’t been invited to. There is plenty of online guidance about getting past that feeling, but not so much about dealing with a pointed comment.
It’s easy to say, “let it go”, but getting past a back-handed criticism can be difficult, especially if it is out of the blue and, in your own estimation, uncalled for. Here’s a few tips on getting past the feeling, getting to the root of the comment, and getting back to your productive self.
Consider the speaker’s perspective. It’s entirely possible that they were having a bad day, and you just happened to walk into the line of fire. That doesn’t make the comments and impact okay, but it does make it understandable. Who hasn’t had a bad day, or been in a difficult spot, and said something that afterwards they might want to take back. I know I have. When I recognize it, I always try to follow-up and apologize; even if it’s months later, and the other person says they don’t remember it, I do and I feel better for having taken it back.
It’s also possible the person DOESN’T know what you’ve been doing. Research and project managers are often behind-the-scenes people, making things happen and removing barriers such that the project personnel don’t really know what they’re doing, just that things are going well. When a problem or crisis occurs, project management is identified as the solution. Reading it like that, the comment can be seen positively – project management has helped in other areas so maybe it can help here.
It could also be a comment of support. If you’ve been having some challenges within the team implementing project management approaches or getting some team members to follow processes, the comment (especially if from a leader) can be heard as, “if you guys just listened to the project manager, we wouldn’t be in this mess.”
These may seem overly-positive rationalizations, but they are legitimate possibilities when it comes to such a comment.
Get an outside perspective. Discuss it with someone who wasn’t there. Although you’ll just be representing your own perspective, describe the situation and comment to a trusted colleague, coach or mentor. They can listen without judgement, and talk you through the possible whys and wherefores of the instance.
They can also remind of you other better circumstances, that make this negative experience a true anomaly. Is this the first and only negative thing in 3 years of working with this person? Is it isolated to a specific item rather than a generalization of overall performance? Is it based in a misunderstanding?
Look carefully at your own perspective. In any situation of conflict, it is important to consider all perspectives, and to keep the focus on the work rather than on the person or personalities. That includes you. Consider the comment and circumstances and ask: is there any truth at all to it? Is there anything you could be doing differently to ensure that your contributions and challenges are understood? Perhaps you’ve been taking on too much to be able to do your best? Or perhaps you’ve not been making it known just how much you are doing already; to quote Addison DeWitt in All About Eve, “It is just as false not to blow your horn at all as it is to blow it too loudly.”
Consider the venue and context. Be sure that the emphasis and overall message is what you think it is. Perhaps you misheard, or misunderstood. Maybe your own perspective added emphasis or meaning where there wasn’t any.
This is not about blaming yourself, but it is important to be sure you’ve accounted for and owned any contribution that you’ve made to the situation. Take real opportunities to learn and improve, while focusing on your strengths.
Put it all in perspective. Ask yourself if this is a stand-alone comment, or something you’ve heard before. If the latter, see above about your own perspective. More likely, it was an off-hand, one-off comment. If all or most of the feedback to you has been positive, then put this latest in balance with that. Be sure to evaluate the feedback appropriately - don't dismiss it but don't make it mean everything. Keep it in proportion to other feedback as well as your own evaluation of your work and relationships. Think about it, talk about it, learn from it, and then move on.
Be hard on the issue and soft on the person*. This includes being respectful with yourself about a situation, considering the perspectives of others, and giving the issue the attention and concern that are appropriate, which may be very little.
Think carefully before allowing an anomalous comment to drive your behaviour or change your work. If what you’ve been doing to date has been successful, you’ll be chasing the wind if you respond too strongly or quickly to a criticism that was not constructive. Keep your eye on the real goal - the success of the project. Keeping one person happy - even the boss - should not come at the expense of the project or work, because if that fails, then everyone is unhappy. The goal should always be to keep the project on track, be respectful and balanced to everyone (including yourself), and maintaining a balanced perspective.
* I first heard this phrase in ~1997 from one of the VPs where I worked. As best as I can tell, the original expression comes from Dr. Henry Cloud. Jon Mertz elaborates on it further in the context of conflict resolution. The expression is sometimes stated as, "be soft on the people, and hard on the problem."
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.