The Deployment Project: Defining the Deliverables

I had the kickoff meeting yesterday with my multi-disciplinary team working on the Deployment project. As project leader, one of the first things I have tried to do is define the deliverables we will create as a result of this project. By the way, this is no small task, we have been wrestling with this as a UX department for some time now.

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."

Part of the preparation I did for the deliverables exercise was to review IBM's recommended design artifacts (from a couple of IBM sources), some of my own work on use cases, and the artifacts from a process ISS adopted about four years ago--Rapid Contextual Design. This background gave the team a box of tools so to speak to choose from.

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 Deployment Guide will actually describe current state. This allows us to address a present gap in user documentation (I'm all about early wins that the internal client will value) while letting us hitch-hike on the user analysis and use case work the Information Developers will do as part of developing this document. It will also establish the infrastructure and information architecture that will support the future design.

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.