The Approach

It is important for the teams involved with building the complete solution to understand what works and what doesn't so that they can repeat the good and try to correct the bad for future projects. A postmortem is a great way to look back on what has been done on the project shortly after its completion, or sometimes even after moving between project stages, so that the team and management can understand what has been accomplished and how the results were created.

It is very important to have a single mediator during this process. That person makes sure to keep the teams communicating, helps them to bring up is sues, makes sure that the issues are clear, keeps teams or people from attacking each other, and facilitates the meeting.

A separate person needs to take notes. It is helpful if the secretary is just an observer, not one of the people involved in the discussions. By not participating in the discussion itself, the secretary can take notes without the distractions of involvement, making sure to track everything and not putting any personal opinions into the notes.

Database Designer

As you take part in the postmortem process, be sure to include information that would have been helpful for the entire database design but was not available ” especially if this is your first time using the UML to create a collaborative development effort, since you will not get it 100 percent right the first time. Be sure to take part in the entire process; participate more than just when the database design models themselves are discussed. Remember that the entire modeling design process can be used not just for the application development and analysis but also for requirements definition and the development of the database itself. If there is additional information that could have been captured early but was not, include that in the issues list to be accomplished next time. If the use cases, for example, need more de tail as to how the data will be captured (for example, via the Internet, external sources, or just employees ), this can be added to the requirements documentation or even to metadata descriptions captured directly against the use case itself. Are there additional extensions that you as a database designer need to make to the UML to better do your job? Get them on the list as well. Maybe your organization has some special policies or standards that you apply to the database. There can be additional tagged values or stereotypes created and used in that circumstance. Don't forget, this activity should capture both positive and negative items. So include what didn't work and what worked well. You may not be involved directly in the next project, but the next group will benefit from using your knowledge of what you learned and what helped make the project a success.