Wednesday, April 16, 2008

Week 5 - Record

In group collaboration communication is vital, the records kept of any communication is even more important. Our group’s primary form of record keeping was initially in the form of emails. This was fine in the beginning as the discussion was small enough to keep track of who said what when and it was an immediate form of record with a set chronology. Fortunately Matt discovered Base Camp which improved our records as we now had a method of recording who said what as well as what’s left to do and when it needs to be done by.

A major flaw in our group’s record keeping is the lack of formal minutes during face to face meetings. When an issue is discussed such as job delegation it was recorded individually in our own way, either typing directly into a document or writing in our books. Unless either of these methods are stored with some logical structure then the records are just about useless.




In a wider scope record keeping record of every dialogue related to the project between team members the client is important as it is needed for the progression of the project and potentially for legal defence. While it is important to record what progress has been made, one could argue it is almost more important to record what is yet left to be done, especially in a top-down approach of task distribution which leaves a lot of smaller tasks.

Other methods of record keeping can include general work logs to record which changes were made and when, as well as time sheets since we all like to get paid for the time with spent working. Change logs are perhaps the most important record for both architects and general computer users due to the unreliability of computers and the opportunity of mistakes being made whilst working on a file. Some authoring suites such as Dreamweaver offer built in modules which record who worked on what file when called Check In/Check Out which also provides protection from two people working on the same file at once.

Once a project has been completed in the developer’s eyes, it must be shown to the client that all of the outcomes outlined in the brief have been accomplished. In my own design work I tend to have email dialogues which are a mini brief with a set of outcomes to be achieved. When it comes time to bill the client, I also include a copy of my timesheet as well as a list of what I have been working on in order to reassure the client that they aren’t paying me for wasting time which so far has been successful with no qualms or financial disagreement.

No comments: