Two points of view... They are both right!

In reflecting on the work we collaborated upon, which was an experience for the first time for many of the students, I was very keen to not take charge nor try to control the group's objectives, aims and working structure.   This would have been very easy for me to do, having been in management and in particular Project management roles for most of my working life.

I thought it best therefore for the students in our team to go through this collaborative learning excercise for themselves, whilst for me, to give them full encouraging support, but not to take over, nor run the project which I would naturally do.  Had I done so, I think the learning experience of the students would almost certainly have suffered, as it's possible, in fact highly probable, that the aims, objectives, formats and other project start-up criteria would have been formally established early (as would be usual, even in a small, but fully managed project of this type). It was very hard for me to keep very quiet and not automatically produce a work break-down structure, product and sub-product lists, bill of materials, task assessment plans, task & event timescales, milestone and go-no-go gates, even at a minimum, a gannt chart / task assessment etc.

Whilst it has been hard for me not take control,  I am glad that I was able to justifiably remove myself from (what I would consider as the mid-stage assement phase at prototype completion) during the last week (Week 3 from a total of 4). as I was simply uncontactable during that week's pre-booked vacation.

This meant that, in my opinion when I returned, the students have had a chance to of learned so much more by finding out the pitfalls for themselves, what worked, what doesn't / didn't work, who or what is reliable, who/ what is not, (i.e. group dynamics, general collaboration rules) and so on.

This may all sound a little patronising or 'smart' from me, but as I say, having been a project manager in many different sorts of business over the last 25 years, it was important (and even though it was hard for me to bite my tongue, see some failures looming and allow them to materialize), to let the team experience the reality of what it`s like to collaborate, see what would be needed to be done, (to individually take responsibility in a collaborative way etc), rather than simply providing them with a pre-defined formal operating framework and hence provide all the answers without learning from the experience.

So, from a more practical point of view, there have been many lessons learned by the group which as an observer in a sense,  I will suggest a few here to summarize conclude;

1. Set the goals and aims of the project in a start up or kick off meeting,  when it is essential that all the stakeholders, which means the person (or persons) providing the breif; the people responsible for the design, production and technical capabilities, together with someone who can represent the end user (or customer, or viewer or reader etc. It doesn't need to be an actual customer or reader or user, but someone who is as well informed about that group at least). * This didnt really happen.  
2. Agree all of the requirements and record any representations or special requests. Consider and agree collaboratively if they are achievable within the resources (cost, time, quality) constraints.
     Try to come out of that first meeting with as much agreement as possible, over the format, tasks needed, people responsibilities for what and when and so on.
3.  Try and establish very basic risk management and contingencies. i.e. ask 'what if this or that, goes wrong / isnt done or whatever, to cover the immidiate possibilities.   
4. A rough plan with timescales and milestones should be able to be created from all of this and it's important to make sure it is in writing as soon as possible and distributed to the whole team.
   
   All this might sound like overkill, but if you adopt these simple first steps, there is less likely-hood for things to go wrong later. It also means people know what is expected from them, and by when, and this stops (or at least reduces)  people from going off and doing their own thing.
5. If necessary, appoint a suitable project manager (someone from the team who will document the above), and who'll be the central point of contact for control.
6. if the project is big enough, write a project charter document!  What the aims are, how you will work together, when you will regularly meet at compulsory breifing meetings, how you will communicate, (i.e by what means). This should be the backbone document to further planning as it stops the team from loosing site of the goals and objectives.
7. Make sure a prototype can be completed well in advance of production.  It is vital that when this is agreed, and the final prototype should be formally accepted by the whole group, (obviously, it can change, but again this must be managed in good time), then a total CHANGE FREEZE is put into place to stop any further development.  Production can then start properly, with less likelyhood of wastage, failure or late delivery.

Like I suggested earlier, these might seem like overkill steps, but should, in the very least, be considered. - You don`t have to implement every suggestion or step, but in reality, in a real project for production, especially in a commercial setting, or when arranging an exhibition (or any other event which is going to cost money) there can in fact be a whole lot more steps, depending on the aims, size and effects (or repercussion)  of the project, and this is often a full time job for a project manager.  

Anyway, I hope this post is useful for my peer students. I also really do hope that one massive lesson learned, (and it always is in a collaborative project), is that everyone has very unique skills, we all work differently to one another, its really fun and interesting to find out 'who' is suited to doing 'what' specific roles; where they excel and where they prefer not to do certain tasks.  It's always important to make sure people don't try to take on too much too, as whilst they mean well, and want to be heros, it can be extremely stressful for them at times and can even lead to fallings out, if timescale deadlines are missed and so on.

Co - labor -ation...  We are all (working) in it together and we must look after each other (share the load equally).

---------------

On a lighter note, I also found whilst doing some other research for the Contemporary Art in Context - theoretical  studies, this interesting snippet from around 2007 (I think, judging by Mr Paxman's hair colour and style, it was of this period).
It is a classical situation when two people have very specific beliefs (in reality, these could be almost anything, like football teams or favourite restaurants etc), and poopr Jeremy was trying to arbitrate between two contemporary artists.

Jeremy Paxman with two contemporary artists