The last proposal went in 16:45; Actually, we tried to squeeze in yet a later version since we discovered some issues with the document, but at that time the proposal system experienced close to DOS due to researchers all over Europe with the same idea as us. So, the second-best version is the one that evaluators will see. Not that it matters a lot, but of course I would have liked to get the better version in. This was the one I coordinated myself, in technology enhanced learning. I also helped the other guys a bit, but those proposals where "finished" a bit earlier, so the better versions will be presented for evaluators.
As this was the first time I coordinated such a STREP proposal, I learned quite a lot. The most important thing I learned by coordinating was that you should never coordinate unless you also have a close colleague interested in the proposal and taking ownership of some of the work. In particular during the last 4–5 days I used so much time on communication (telco's, phone calls, IM-chat, email) that I got too little time to actually write. During these days it would have been a lot better, and the proposal could have improved a lot, if I have had someone "at the end of the table" taking care of all that came out of my discussions. Of course, I had several other people working on the proposal together with me, and a few of them long hours just as me. However, it's never the same as being together in one room. And of course, only a Simula-employee can fill Simula's role in the proposal.
I learned several other things too. Some of the things I learned will probably never be posted online. But most of the things I learned are general and applicable to any project, so I will try to make a write up such that others can draw on the experiences. I will however try to not just repeat what others have said, so I will think through it before I write.
On the practical, technical side, I ended up using the following stack of tools:
- For writing: The document was set in LaTeX, so I had to pull out the text-editor stuff;
- Textmate: become the work horse on this project - because it is easy to keep several files open in separate tabs, and jump back and forth. Decent support for LaTeX macros and search/replace (but not perfect).
- VIM: as always, because it's my favourite - in particular when working in a single file. I can get whatever LaTeX support I want because I know how to write macros. And vi is excellent when it comes to regexp work.
- Texpad: a quite new TeX-editor for OS X, available in the App Store. Compiles and view pdf in the tool, can handle several files (and still view them as a single file), decent navigation support. I ended up using this most in the beginning when the outline of the project was created. Later on, when we where editing collaboratively all over Europe I couldn't trust the tool. Maybe I was wrong, but I wasn't sure it updated dynamically when someone else updated a file, and I was afraid of overwriting other people.
- Some of my co-writers was on Windows-systems and not familiar with LaTeX. For the future, I will need to find a nice editor that's freely available, or at a low cost; which will handle file encoding correct (had some issues with strange characters in some files), and which also feel familiar for someone coming from a Word-world. Ideally, this should be an editor where they also can drop images in, and have the \includegraphics statements generated for them, etc. Not sure what to use, but maybe texpad will be available for Windows in the future?
- Collaborative editing: We used a Dropbox-folder to synchronise files between all participants. In order to not have everyone running the latex commands all the time in the same dropbox-folder, I set up a bash-script that every other minute run latex on the files, using "latexmk -f -pdf" in order to not choke on errors, and also create a pdf. This was a really nice balance, and somethings most people seems to like. Die-hard *nix'ers would have prefered svn or git or some other collaborative version-control, while others maybe would have just went with sending files by email as default. I think Dropbox with a script at one end doing the LaTeX-compile is a nice balance that is simple to relate to, and easy for everyone to understand.
- Creating Gantt-chart is a big deal for a EU-proposal, because you need to understand the timeline of your project, and define Milestones and so on. What I realise was that it is really hard to find a program that works well. My first choice was OmniPlan, because it is supposed to be good. It probably is, but only when you have specific people you want to plan the project for, on a by-hour basis. What I needed was to plan related to unspecified person-months, in such a way that 12 months are 1 year, and not some 1500 work-hours or something. OmniPlan turned out to be a mess really. Through the App Store I found SG Project Pro, which did almost all I wanted. The only stupid thing with that tool is that it is very hard to get an image (pdf) output that can be used as graphics in a proposal. I ended up using Print (after defining a custom - big - paper size in order to fit the chart on one page), and then open pdf in Preview, and saving pdf from there. Unfortunately, it was not possible to use undefined project-start and just Month or Quarter markers in the chart, so I had to open the pdf in Illustrator to fix this. It worked, but far from project. Ideally, the Gantt should have been coupled to a database representation of the project, where also budget could have been generated from - I will probably need to make something my self in order to get it right...
- PERT chart is something else needed for a proposal. This was new to me, but I saw that at least Microsoft project (maybe also OmniPlan?) can generate those. Anyway, I just made them on the work-package level, and used Keynote/Powerpoint to do it. Again, this works, but the better option will be to keep all the data in a database, and generate a skeleton or even a nice finished version from the database - which will be in agreement with the Gantt and the Budget. If I create this tool in the future, the tool should have an option of creating PERT on the task or work-package level.
- Budget: That was Excel, unfortunately. The good thing was that I got a nice template from Pera, but totally decoupled from the Gantt and PERT charts. All this should come from one database... Anyway, Excel kind of works and is easy to use for everyone. Just pay attention to formulas if you extend with more rows and/or columns!
- If I create this database thing, I will also add auto-generation of latex code for the important and mandatory tables for work packages, effort, deliverables, milestones, and work package descriptions. Now, I had to sync everything manually by hand - which is not fun. That time could have been better spent on writing important text.
- As mentioned already, the document was set with latex - pdflatex to be exact, with Sorbonne font in 11pt, and with some occasional Verlag. It just look much better that way.
- Finally, some work on citations is required should I do this again (which I probably will). Handling bibtex for those not familiar with it is not easy. I had a look at Mendeley with an idea of collaboratively using Mendeley to collect all references, and then export bibtex from there. But when I searched for some of the things we needed to cite, and found that they where not present in Mendeley, so we would have needed to add them manually, I skipped that idea. However, in the document we submitted there was a lot of citations marked ? because there were some errors in the bib-file. So, this is an area where work is needed.
Until then; take care!
