Development – A Factory model

The Development phase is treated as a factory model which may be more appropriate for large-scale projects than for individual courses. The team management section could be a separate text, and while the graphics section should add a paragraph on 3D modelers, it’s a practical and useful overview. The scheduling section should include usage of Gantt charts.

The most thorough aspect of the chapter was on post-project activities which are often ignored:

  • post mortem debriefing
  • deployment
  • recommendations
  • training
  • documentation
  • summative evaluation
  • client evaluation
  • project cost analysis
Advertisements

Demonstration phase

A transition between Design and Develop/Deliver, this phase is often incorporated directly into a single iterative unit release methodology. The optional deliveries were very helpful:

  • treatment
  • scenarios
  • templates (content as well as layout/technical)
  • requirements spec (especially useful for software)
  • storyboards
  • scripts
  • prototypes

Practical suggestions are prevalent:

  • media asset lists
  • reading levels
  • translations
  • reviewer training

The storyboard form could have been demonstrated as a template–with the navigation (top) annotated as a common element.

Design – Flowchart & Content

The most helpful part of the entire chapter–since the bulk of it detailing the design document was covered in detail in our previous ID course–was the explicit linking of 4 deliverables to this phase:

  1. Kickoff meeting
  2. Design document
  3. Flowchart
  4. Content document

Our SME’s usually provide all the content; our role is to guide their development of aligned interaction opportunities and assessments.

The design document covered at a high level all of the elements in this key document. What I most appreciated were the sections on the flowchart and content document; the case which used the latter to help clients realize missing questions was very powerful. The flowchart topic could use expansion to present alternatives and rapid models.

Define – Project Proposal

The risk factors, although not explicitly grouped as external (client-side) or internal (production team), were very thorough: i especially appreciated the recommendation to use an MOU for intra-institutional work. The section on proposal research included the most critical “Why” question (we usually add, “Why aren’t you d0ing this yourself?”). The sample project profile was extremely detailed; we tend to focus on (a) interaction and assignment development for academic courses, or (b) the format and nature of the content for classroom self-paced training modules. The best question we’ve found for visual and interface design is to ask the client to show us her favorite web sites and tell us why.

Audience, outcomes, and delivery issues were treated only briefly (covered elsewhere); the schedule section was extremely helpful, although I would have appreciated a discussion of critical path in the schedule (especially in light of our programmers regularly underestimating their effrort by 30-100%). The budget reminder to account for marketing and product management was excellent; we use the estimate by labor (resource) for internal planning and tracking–and the estimate by deliverable for the client.

Collaboration

At UTTC, we use a smaller version of the production team described: the project manager is usually the instructional designer; we (often) use one graphics/multimedia/usability developer; we (usually) use one programmer (Flash AS and/or JavaScript); we seldom (but would like to) use an HTML/layout/documentation assistant. While we always follow the decision-making trail as recommended, we usually try to solve problems by asking questions and developing alternatives collaboratively with the client.

I especially enjoyed the practical suggestions of limiting meeting attendance, sending review materials 5 days (major) and 3 days (minor) in advance, and requiring agendas and meeting summaries. However, the real value of the chapter was in the delineation of visioning tools, although we usually reserve the 5th tool for the post-contract phase:

  1. brainstorming
  2. examples (exterior and prior work)
  3. user scenarios
  4. goal scenarios
  5. prototypes

The recommendation to provide reviewer guidance is well-taken; I usually use a modification of the schedule organized by date rather than task:

Date AISD team activity TPTL activity
w/o 2-16 Send project proposal for approval Review and approve project proposal; answer questions raised in proposal

The rest of the client, document management (version control, backup), and etiquette suggestions were helpful and could constitute an entire book.

Practitioner

Liu, Min et.al. Challenges of Being an Instructional Designer for New Media Development: A View from the Practitioners. Journal of Research on Computing in Education: 11.3 (2002). 195-219.

Because the primary audience for the article appears to new instructional designers, there was little new information I found personally applicable. However, the delineation of responsibilities was clear and helpful:

  • Client
  • SME (often the client)
  • Project
  • Team

The list of top challenges, especially “Working with a client” (which might take all three of the top spots) and balancing ID and PM roles, was right on the mark. In terms of hiring, the attributes and advice seemed accurate if somewhat generic. For our organization, we have found that design of and experience with a variety of media alternatives to be the most effective “measurable” skill (we review the Web portfolios of all potential designers). We look first for communication and problem-solving competencies because we can teach technical skills, and instructional design and project management experience is offered in both coursework to our designers and in authentic trenches.

ID/Project Management

Mc Daniel, K. and Liu, M. A Study of project management techniques for developing interactive multimedia programs: A practitioner’s perspective. Journal of Research on Computing in Education: 29.1 (1996). 29-48.

The mesh of ID and project management brought a refreshing practicality, and I especially appreciated the additions from Gentry on adoption (all of her supporting processes are essentially PM skills). Greet’s model didn’t add much; it seemed merely a merge of Dick & Carey with Gentry. However, the proposed 5 components were perfectly clear.

I was surprised not to see a discussion of Gantt charts and critical path in the Team Assembly and Management section. In the section on Evaluation, Marketing and Support, I have successfully used the conceptual differences between project management (the team) and project ownership (the client) to effect this critical transfer. If ongoing support is in the business model as a continuing revenue stream, it should be provided on a T&M basis.
The ID models seemed overly complex and somewhat idiosyncratic. However, the common desire for evaluation and revision is more easily accomplished with networked products (especially using agile and rapid prototyping) than with previous static delivery mechanisms.

As far as responsibilities, the following are key in my experience:

  • Keep big picture (outcome) in mind
  • Motivate team
  • Meet deadlines and budget
  • Free members from day to day
  • Break & sequence projects into manageable tasks
  • Use appropriate personnel (bring members along through smaller projects to develop independent decision-making)

However, my experience cautions that meetings should not necessarily “involve as many key players as needed.” Smaller teams may be more successful at problem-solving (see post on 2-player teams outperforming 4-player teams in online PBL). Also, while open communication channels are always essential, the project lifecycle I have found successful has 4 phases:

  1. Brainstorming – everyone talks, all ideas entertained
  2. Defining – everyone offers dependencies, tasks and times negotiated
  3. Monitoring – often, only key players present/talk
  4. Celebrating – offsite if possible, documentation review and lessons learned