There are three important letters that you add to your name when you finish your Ph.D. But there are two other letters that are also important to researchers as they begin their careers: P.I. The Principal Investigator is the person in charge of a research project and it signifies the next step in your career, where a funding agency has selected your research proposal, using a panel of your peers in most cases, as worthy of gaining a substantial amount of external support. It is basically a sign that other people (you know, people who aren’t trying to help you graduate) think that your work is important and interesting. It’s a really good thing and the first time you become a P.I. is an important career milestone.
A proposal I wrote almost a year ago got funded over the summer and I am now a P.I. It’s a three-year project that, in brief, is looking at the feasibility of using students’ speech to determine how well they are collaborating together when working on interactive collaborative computer tasks. We are partnering with the speech technology experts in another department at SRI to do this work and the project itself is a big collaboration between education researchers and speech researchers. The project (Speech-Based Learning Analytics for Collaboration) will lay the groundwork for lots of future work and could potentially be applicable in lots of areas, not just our initial context (which is middle school mathematics).
It’s kind of crazy that the first proposal I submitted in this role gets funded, but I definitely didn’t do this alone and I am very lucky that my institution has a huge support network and process in place to help people get their projects funded. But that doesn’t mean that the road was easy. In this particular case it definitely was not. But it was a learning experience and I think our proposal process/ordeal illustrates a lot of things that eventually made it successful. So, below I discuss parts of the process of this proposal, especially the feedback and changes we made along the way and how those really helped it get funded.
Language and Communication
Anytime you are writing something for someone else to read you need to think about how to communicate your ideas to that person or people. That particular audience. I wrote about this in my earlier piece on how to write a good proposal. But, in many cases, you will also be writing and planning/designing with someone else, a collaborator, and you and that collaborator might not always share the same language. This was the case for this proposal and it proved to be a big obstacle in our early planning phases and writing phase of the proposal process. As mentioned above, we are collaborating with some speech technology folks at SRI and they come from an entirely different field of study and have different ways of doing studies and talking about their work that would not always be appropriate for an education proposal. But we needed to find common ground on what was a mutually beneficial research plan and also a common language on how to communicate this plan to a panel of education researchers.
It was not easy. We went through a lot of drafts and lots of discussions before both sides finally agreed that we were on the same page. It took a lot longer than I thought it would and ate up a bunch of time in our proposal writing process. So, the earlier that you can define terms and find a common vision for your team, the easier it will be. You need to set aside time specifically to do this, especially when working with new partners or people from a different area of expertise.
I cannot emphasize this enough. You need to have someone (or, best case a few someones) who are not familiar with your proposal to read it through and give you really honest feedback. You want them to pretend that they are reviewing it on a panel (so it’s best to have people do this who have been on these panels before) and just be brutally honest about where the flaws are. Because there will be flaws. There will be a lot of them. It is unavoidable, especially with the short time frame that most proposals are written in. And you need to sit down with these someones and go through their feedback and decide what to listen to, what to ignore, and what you can actually change.
In this case of this proposal, there was a lot of really good feedback we received at this point. But we had waited too long to do the review and didn’t really have the time to make all of the changes that they suggested. And some of them were major changes. Because we had waited until the last minute to do this review we were left with a decision: make some minor changes and submit it and hope for the best or make the major changes and submit it to a different program or wait until the next submission date. Luckily for us there was another program with a similar focus with a due date a couple weeks after this one and it made perfect sense to submit it there instead. This would not normally be the case, so you should definitely not wait as long as we did to do this review unless you’re ok with waiting six months to a year to be able to submit. [You will notice that I did not suggest just submitting and hoping for the best with what you know is a subpar proposal because seriously the review panel will see this right away and it’s not going to get funded.]
I will be totally honest. I felt like a big failure at this stage. We had invested a lot of time and resources into making this a great proposal and it just wasn’t there yet and still needed some major tweaks in order to be competitive. And I wasn’t sure that we could do it. I felt like I had let the team down and that I should’ve seen these problems beforehand. And yes, it was partly or mostly my fault that we were behind schedule. We should have done the review sooner.
It was hard to work through this feeling of failure, but I think seeing it as a learning process helped me process everything in my head and pull everyone back together to finish it.
We decided to make the major changes. And believe me, they were major changes. We kept a lot of the text in the 15 page proposal, but moved most of it around and cut out a couple pages. We reworked the research questions significantly and reframed the background section a bit. We tightened the research plan and added more details to the analysis section. The research questions were really where it changed most visibly, even though the research design and analysis did not change at all. We needed to rethink how we were presenting the questions, how the questions releated to each other, and how they connected the background to the research design. We needed to focus them and make them specific and achievable. We changed a lot of language in the proposal to clarify the different pieces of it and how the pieces fit together to achieve a common objective (and not two or three different objectives by two different research groups). [I heard later from the program officer that the research questions were especially good on this proposal and he was not surprised to learn that we had iterated on them quite a bit.] The hardest thing was not making the actual changes, but in making the decision that we should. There was a certain amount of trust involved, in trusting our internal reviewers that they were right and in trusting ourselves that we could implement the changes in a timely manner.
I still think it’s kind of strange that the best news you can hear as a researcher is that ‘we have questions for you’. The funding agency (NSF in this case) asks you a bunch of questions about your proposal if they are interested in funding it. You then work super fast to answer the questions, submit them to the program officer, and a few weeks (or, months, really) later you have your acceptance.
And then the real work begins.