Update: I've wikified this list to make it more useful.
Some notes I've gathered while working on some Very Large Projects™ over the last couple of years. Some of the projects have done some of these things, and some have done few/none of these. Live and learn... I'm just documenting them here so I can refer to something quasi-concrete on the next big-ish project that comes along.
None of these tips are written in stone. They are also not necessary for a project to get done, but these should make things much easier on everyone. YMMV. IANAL. YHBH. Wait. Not the last one...
I'll update the list as I think more about it.
-
Maintain a central repository of files for the project
- avoids 16,326 revisions of Word .doc files being emailed around. Which is the most recent? Are all changes in the latest-modified version? Do I need to keep the previous 16.325 revisions on my drive Just In Case?
- Everyone will be on the same page - no confusion with some people talking about stuff in revision 16,3200, some in the latest revision.
- Word files are definitely not suited to sharing information with a group - use a wiki or CMS or something, but Word .doc files are not the best way to share information, even though everyone might have Word installed (and they may even use it with the project - but .doc is NOT an interchange format).
- If something like Subversion is too geeky, try a shared FTP directory. Just do something to prevent confusion and missing files/data.
- For a simple text/data repository, Wiki Is Your Friend™
-
Have concrete targets/objectives/goals/milestones
- Make sure everyone (organizations and individuals) knows exactly what the plan is.
- Make sure everyone knows about the timeline - what are the "real" deadlines? What are dependencies within the project(s) to meet the deadlines? Avoid "fake" or "internal" deadlines - make sure everyone knows the real dates.
- What are the risks in the project? Where should resources be focussed to prevent failure?
- What is the plan to communicate about the project? Will you be showing it at conferences? If so, pick them well ahead of time and make sure everyone knows about them. Make sure everyone is on the same page so there aren't any last minute "oh, by the way, we're presenting it at X conference tomorrow..." types of surprises.
-
Communicate
- Have regular meetings - they don't have to be face-to-face, they can even be phone calls or IM sessions - but talk regularly to avoid confusion.
- Don't have meetings just to have meetings. That's a bigger waste of time than not having any meetings at all. Meetings should be short, productive, and useful. As soon as they stop being any of these things, they cut into efficiency on the project. Meet when you need to, and only when you need to.
- Share notes from (online and offline) meetings so that there isn't any confusion about what was discussed. Wiki pages are handy for this.
- Make sure everyone on the project has an instant messaging account. It's so much easier on everyone if they can just quickly ping each other for quick questions without drafting emails, or interrupting each other with phone calls, etc... As an added bonus, iChat and Skype accounts function for both text messaging as well as audio conferences (and in the case of iChat, video as well) - very handy for free ad-hoc meetings.
-
Document
- The documentation for the project should include links to the central file repository(ies), timelines/milestones/objectives, meeting notes, etc...
- Documentation should be written both for people new to the project (people come and go - prepare for it), and for existing people who may not have all of the information active in their heads - projects take time, so there should be a backup outboard brain shared by project members
- Iterate
- Avoid monolithic "here it is - it's done" releases. Build early, build often, seek feedback/review/critique throughout the entire project lifespan.
- Make sure the plan/timeline/milestones are still valid as you move along. Stuff happens. Things change. Make sure you're not painting yourself into a corner with outdated plans. If plans change, make sure everyone is on the same page, and document the change (why did it change? what is the new plan? how does the change affect the rest of the project? the timeline? deliverables? etc...)
- Embrace change/risk. If you're not changing the plan at all, you're likely not being responsive. (don't change just for something to do, but don't freak out about it) Also, risk isn't a bad thing. If there was no risk, the project wouldn't be necessary. Risk is where the magic happens, so work with it.