Document for Success, not Defense

May 22, 2011 | ,

A meeting recap is not a design document. A meeting recap fills an important role in design activities by ensuring that the decisions and actions resulting from a meeting are clear and agreed upon by all involved stakeholders. A meeting recap is a very powerful tool for driving a design to conclusion, but that does not make it a design document.

A meeting recap is one of many “point in time” work products created during a design phase that are not organized as a cohesive design, but in a project management appropriate manner, typically by date. Some other examples of these include project plans and issue logs.

Very frequently, important design information is buried in these auxiliary documents where it is of little or no use to those implementing the design. These auxiliary documents are often referred to during the mid/post implementation “blame assignment” cycle of a project. They are great for defense and useless for success.

You avoid this by ensuring all important facets of the design are captured in an “in scope” design work product. Some methods for keeping this on track are:

  1. Identify the “in scope” design diagrams/documents for all members of the project team. Make sure they are clear that if it isn’t in there, it isn’t part of the design. In spite of the emails, notes, and recordings they might have saved…
  2. Ensure the design diagrams/documents cover only appropriate design content. The danger of #1 is that the in scope design work products become the dump bucket for every scrap of conversation that occurs.
  3. Immediately post process the impact of meetings, issue resolutions, and any other design impacting discussion into the in scope design diagrams/documents. Send the design diagrams/documents out to the stakeholders involved in the meeting and/or issue resolution to confirm you reflected the outcome properly.
  4. Use the design diagrams/documents to frame any discussion. This minimizes the creation of auxiliary documents that need to be processed.

We have plenty more to say on this topic. If you haven’t already, read One Artifact, One Vision or any of our other artifact articles, and contact us if you want to learn!

The following two tabs change content below.

Dan Hughes

Was a principal consultant at Systems Flow, Inc.

Latest posts by Dan Hughes (see all)



Comments

Comments are closed.