Introduction

http://tkbr.ccsp.sfu.ca/pub607/

The Technology Project comprises three research & development projects running in parallel, one per group. At the end of the term, the three project groups present their work to all.

Rather than scenario-based projects, the Technology Project gives you an open-ended opportunity to engage with one or more real-world technological challenges. The details of this project course change each year, and so there is no pre-existing method or path through the process.

The Technology Project presents a semi-unknown problem space for you to wrestle with and come to terms with on your own. Accordingly, we have a far less structured schedule and the weekly project deliverables are not the clearly-cut building blocks of a defined process. Instead, we are concerned here with pulling order out of chaos, coping with ambiguity, and seeing (clearly) in the fog.

PUB607 Goals

The Technology Project course serves the following goals:

• to provide hands-on experience working with a range of digital technologies representing the state-of-the-art;
• to provide experience working on a decent-sized, structured IT project full of the kind of ambiguities and unknowns that typically characterize such projects;
• to gain an appreciation of documentation-driven project management;
• to provide an environment in which students can experiment with new technologies without serious (business) consequences.

The grade is split 75%/25% between group and individual performance. The individual component of the grade will be partly based on a self-evaluation report. The larger group-evaluation component will be based on the quality of work produced (documentation, planning detail, prototyping, production) as well as general problem-solving, teamwork, and reflection on the process.

Method

1. The backbone of these projects is documentation. This is a fundamental component of good project management, as the documentation that you create acts not only as a formalization of the planning for the project, but also the working blueprint, the report that lives on afterward, and the standard against which any development work can be measured.
2. As with the book and magazine publishing exercises, weekly assignments cascade to culminate in the final project document. Be prepared to review and refine your work, again and again. With each weekly deliverable, you are expected to review and update the material from previous weeks as needed. All written material should be thoroughly copyedited and proofread, as it may be forwarded to faculty and industry guests.
3. Everyone in the group is responsible for the quality of all assignments. This means that everyone should review and have input into all aspects of the work before it is submitted.
4. Unless otherwise stated, all deliverables are due at 9:00AM Mondays (that is, the Monday following the week in question) to make timely feedback possible.
5. The TKBR/pub607 site should be used at every opportunity to gather, share, organize, and deliver project information. Monday morning deliverables, however, should be delivered in print (can be printed from the web).
6. Regularly scheduled meetings with John and/or scheduled guests will be on Fridays in most cases.
7. There need be no secrecy between the groups. Rather, on Wednesdays in PUB802 we will do a short (5-minute) briefing on each of the projects so that everyone is up on what everyone else is doing.
8. If you wish faculty to meet with your group outside of scheduled times, you must make appointments with them.
9. Note that there are no defined team roles in this project. If your team decides that you would like to assign specific roles to individual people, you may do so. You are not required to, however. Your ultimate responsibility is to ensure that the project succeeds and that the work is spread fairly amongst your group. During the first week of the project, you and your teammates should take some time to discuss ground rules and common expectations.