Author(s):
Bob Glushko
glushko@ischool.berkeley.edu
Course: Document Engineering and Information Architecture (INFO 243)
Date: 11 February 2008
Title: Course Project
This assignment kicks off your course project. It describes several deliverables and milestones. You'll get feedback on all of them, but only the last two ones (final report and presentation) are explicitly graded.
The differences between a course project and the other assignments this semester are in continuity and scale. You will have some assignments between mid-February and late April to ensure that you develop some proficiency in all the core Document Engineering skills. Your course project will be in a domain chosen and scoped by YOU, will be done in teams rather than alone, and the separate phases should be more thorough and rigorous than the assignments you do as individuals.
These instructions are necessarily incomplete. Because I don't believe that every project can follow the same cookie-cutter template, it is necessary that we view your project requirements and deliverables as a negotiation. We'll jointly figure out a project that balances my objectives with yours.
I envisioned this course project primarily as a mechanism by which first year I-school students could "incubate" a project that would develop into the MIMS project for their second year. It could also be a way for second year students to add an analysis and modeling dimension to the MIMS project they've already got underway. But doing either of these is not required, and of course these goals don't even apply for students not in the I-School. It is vastly more important that you do a project that interests you and that is tractable.
You can choose just about anything that involves some information and process analysis; this can be a transactional domain like the Sylvia project that produced the course syllabus viewer you use all the time, or it can be in a more narrative/publication domain. It can be an effort to automate and improve some existing processes or it can design entirely new ones. Its overarching purpose is just to give you experience thinking as a Document Engineer.
So what your work products will be depends on your team's goals, but I envision two possibilities that are not necessarily exclusive. One goal might be to develop document and process models with the goal of implementing them as XML schemas, which would be the basis for subsequent implementation of an application prototype (you probably won't have time to do any implementation this semester). An alternative goal would be to develop document and process models with the goal of writing a project plan / business case that discusses the organizational and technological considerations and capabilities that will shape the application's development and deployment.
Put in the language of the Document Engineering book, your project might emphasize Chapter 15 ("Implementing Models in Applications") goals and perspectives or Chapter 16 ("Management and Strategy") ones.
Expected Level of Effort
The course project is worth 40% of your course grade, which makes it equivalent to four assignments in the amount of work (per person) that it should require. You will probably end up doing more work than this, especially if you choose a project tied to a potential or existing MIMS project. The biggest challenge is going to be pick something in which you can do something meaningful in a little less than two months, because many of you will want to be able to package your work for your resume and professional portfolio.
To some extent you will decide what "meaningful progress" is, or put another way, where you want to be in early May when every team declares victory according to its own rules. That's why it is essential that I have a clear negotiated understanding of what you hope to accomplish.
Project Teams
Your team should have either two or three members.
Milestones and Deliverables
STARTING NOW! Look around you in the world, or think about some of the "Document Engineering in the News" stories, to get some inspiration. Are you doing projects in other courses that would be enhanced by more systematic analysis and modeling of the information and processes in the domain? Are there paper forms for some business process that you repeatedly fill out that should be re-engineered and automated? We've read many case studies and you know how to use the D-O-C-U-M-E-N-T checklist to identify promising domains for a project.
before March 12: If you're stuck, come talk to me and we'll brainstorm some ideas and turn something into a project.
Wednesday March 12: Turn in a short project description (1 printed page or so). Describe the motivation or context for your project and a list of project members. Include a partial list of potential document types or information sources (people, articles, whatever) that you expect can provide more detailed requirements. I will give you feedback on your proposal as soon as I can, but not later than the next class (Monday, March 17)
Wednesday March 19: Presentation of your Projects and Working Session. This is the last day of class before spring break. You'll make a 5 minute presentation of your project idea, and we'll spend a few minutes discussing it. This is not intended to be at all formal - a few slides at most; if you find the D-O-C-U-M-E-N-T checklist helpful you can use that to explain what you're interested in.
April 14: Project Status Report 1. Each team will make a brief presentation (probably 5-10 minutes) of its work to date, which might include some prioritized requirements, some review of articles, some initial process models, or interviews with at least one "animate" sources.
At this point you will all have done individual assignments in gathering requirements, identifying information sources, and business process analysis. You should be able to create some modeling artifacts that are appropriate to your project, and these should be presented and turned in as part of your status report.
April 28: Project Status Report 2. Each team will again present the results of some additional document engineering activity appropriate to its negotiated goals. This might be some document analysis and harvesting / consolidation work to identify the semantic components of its models. (By this time you will all have done some of this in an individual assignment.)
May 12: Final Project Presentation
May 16: Each team will turn in its final work products and a summary report that ties them together.