As preparation, I established a team Wiki in our Lotus Connections site. The thing to remember about a Wiki is "Build it and they will ho-hum." So you really need to hold meetings periodically where the Wiki is the visual tool. So I used the Wiki to collect my own thoughts, provide background info, and to present a table of the recommended deliverables. I then opened it up in edit mode during the meeting so we could incorporate team thoughts in real time. BTW, that is a trick I have learned from two colleagues who use it well (Miranda Bennett and Christie Davis), that is, use the work product and edit it in real time during the meeting. Two advantages come from this:
- You don't need to take detailed notes and then write them up after the meeting (not to mention the additional task of implementing them)
- You get immediate feedback about the change, as in, "Oh no, that's not what I meant."
At any rate, we have decided that we will produce the following artifacts as our design package:
- User roles and profiles
- Use case diagram
- Use cases
- Product vision (a visual/narrative representation of design ideas that emerge from our user interviews, interpretation sessions, and affinity analysis that are part of our Rapid Contextual Design process)
- Conceptual wire frames
- Scenarios (like use cases but more contextual and UI-specific)
- Deployment Guide
- Service Requirements Document (SRD)
The Service Requirements Document is a new deliverable we have not done before and one that was suggested during the kickoff meeting. (We have product requirement documents, but it has been my experience over several companies that PRDs come from product marketing and lack a user experience focus.) Since we have developers on the team, we can collectively define a document that puts our research and conceptual design recommendations into a format that can be easily consumed by those who must develop the design. We have long wrestled with how much detail should a design document have and how much leeway should the developers have as they work in "rubber meets the road" land. This aspect of the project could become the most exciting for me.
An interesting outcome of the meeting was the decision to remove the Due Date column from the project plan. Huh? I've argued for that for a long time--See my blog You Can't Handle the Truth. But as soon as I was made the project manager for this, wham, I was thinking dates. Part of the problem--as it was pointed out to me--was that the deliverbles would happen iteratively, for example, some use cases early, others later, etc. The other problem is that we are largely in discovery mode and must be open to follow the data when and where it takes us.
OK, no dates.
Instead, as we identify activities, I am assigning an owner and asking that person to start maintaining the Wiki page(s) that tracks activities and progress for that activity. We'll see how that goes.
