AA Meetings

1. The Tri-Pod Documenting - Part 1 - Meeting Minutes Recently, while working with a large company implementing business analysis, structure, and documentation, I realized that this was not my first rodeo; or even my second, in most of the situations where AA Meetings I am brought in, these companies don't have a good way of tracking meetings or post-meeting follow-ups. If they do have a way to track it is usually buried or unknown - instructions not kept in consistent places; not referenced or taught to new hires; not followed. This realization made me stop and think - Are companies becoming too big too fast that they lose the structure that comes with documentation? Are these companies implementing Agile Programming and equating "agile" with "don't need to document"? When the documentation exists, who is teaching the structure? I see this happening again and again in both large and small companies where I am brought in to fix or implement documentation processes. In this three-part series, I am going to show you how to document projects and processes using inexpensive tools and tricks. With this approach you can guarantee projects are fully fleshed-out, all stakeholders informed and all decisions (critical and not so critical) made so your project will proceed easily from inception through roll-out and implementation - even archiving. "Tri-Pod Documentation" is designed using meeting minutes, action items, and directory structure - the three-legged-stool of how projects are run. When you implement structured meeting minutes those parlay into action items. Once these two are in place, directory structure plays its part in making projects very easy to implement, reference and archive. In this article, we won't be designing the project charter or pulling together the "Inception Desk". I am going to assume you already have that information captured. We will be learning project documentation for the 'meat' of the project; after pulling the trigger. We will be discussing the "who, what, where, how, when, and why", to borrow from the Mickey Mouse Club. AA Meeting Meeting Minutes - the necessary evil of project documentation Many times meeting minutes aren't taken because they are tedious. I know very few people who like to scribe. However, almost everyone I speak with loves the detail that meeting minutes bring - their 'clarity' - it's a great way to make sure issues retain focus. Meeting Minutes can detail the "to-do's" and "by who's" of a project. They convey critical and not-so-critical information to all parties involved; they are a way to track your progress, manage strategic goals, and follow up so you can guarantee you have discussed every item. In any project meeting, minutes are a necessity.

2. Everyone can think of reasons not to document meetings - everyone takes notes; nothing in this meeting will require follow-up; all decisions are made by the CEO; I hate taking meeting minutes!! I understand - however, meeting minutes are vital in an organization that has to track issues, report to people outside of the meeting, manage contact with vendors and stakeholders, etc. They are formalized documentation of decisions and caveats, and sometimes include clarification. Make meeting minutes useful Making sure action items are getting recorded and retaining focus and follow-up pales in comparison to getting the action items completed - the information accessed and documented; questions answered; action items moved off the 'to-do' list onto the 'all-done' list. In companies I work with often the issue with closing action items is not necessarily the follow-through but the lack of a way to follow through. To follow up on these meetings you need to document what was said, what needs to be done when it needs to be done, and by whom. OK, let me digress for a moment. Some companies have a static view of meeting minutes. It seems that "Meeting Minutes" are a formal process for documenting Board Meetings or Committee Meetings. Well, then, let's say Meeting Summary. (I don't care what you call it, as Nike says - Just do it!) Who will document? If you are fortunate enough to work in a company with multiple Business Analysts (BAs) and Project Managers (PMs) use them. Have a primary BA (the one responsible for the project) and a secondary BA (or PM) in every meeting. The primary BA is the "owner" of that project while the secondary BA is noted as the "scribe". The owner has full responsibility for the project - managing meeting minutes, handling follow-up - the whole she-bang. The scribe has all of the same information (and attends all of the same meetings) with none of the responsibility. The scribe gets to do the meeting minutes!!! - OK they have to do the meeting minutes (I'm not sure it is a fair trade). Primarily you are trying to go for double coverage just in case the project owner is out of the office, away or unavailable, sick, or has won the lottery (... never to return). If you can't manage the double coverage, try to have someone else in the meeting (other than the owner) scribe the minutes (hopefully someone who will be available for all of the project meetings). The Owner should just lead the meeting and attend to the agenda - however, if necessary, the Owner can also scribe. When you set up a meeting to discuss further a software project, (future features, caveats, problems in development) the Owner leads the meeting and the scribe takes notes. I always recommend an Agenda -if only to bullet point what you must discuss. Post-meeting the scribe writes the meeting minutes and then sends the document to the owner for review. As the owner, you edit (if necessary), confirm content and then send out the meeting minutes to all people on the project - not just the people who attended the meeting. All project participants can review, object, or include more items. All participants are now on the same page. As a side note, you should be using a RACI Matrix. This document lists everyone with a 'stake' in the project. A RACI Matrix is intended to identify 'groups' of individuals impacted by the project including Stakeholders, BAs, Developers, Q&A; all interested parties. This, then, becomes your mailing list.

3. On a typical day, I send out meeting minutes with a statement such as "Please review to see if I missed anything and let me know", or add the more stringent "... preferably within 24 hours. Otherwise, the minutes will stand as written. " What should you document? Everything related to the project that has an issue (action item) or a resolution (will/won't be included or needs more research/discussion). How? I am sure many of you already have a format for meeting minutes. If not, feel free to use mine. You can use a little or a lot. Below is the information I expect in my meeting minutes. HEADER - In the header of the meeting minutes, including the Name of the Project, issues to be discussed, Owner of the project, scribe, date, time, who was present as well as who was not present. Project Name is the name of the project. The project name will never change on any of the meeting minutes related to that specific project. The Discussion Topic is what was discussed - in general. This information changes each meeting - even if you discuss updates to the previous meeting - just add "discussion 2". For example, "Registration Implementation Issues" could become "Registration Implementation Issues - discussion 2" or even "Registration Implementation Issues - 2". In the example below we use "Project XYZ" and "Registration Implementation Issues". DISCUSSION GUIDELINES 1. Make the meetings more about the items, not the people - be objective and try to write about the 'spirit' of the discussion - don't document the discussion verbatim. 2. Every discussion topic is a paragraph - even if they are not discussed linearly. Attempt to document all related items into one topic paragraph (or two). There is no need to elaborate on the entire discussion. 3. All action items ("to-do's") are clear, complete sentences - the statements can be read apart from the meeting minutes text. 4. Every action item ("to-do") is numbered sequentially - so everybody can reference each item individually. (Have you ever had to reference a document stating... "Section 1, paragraph 3, item 1.a. states"... It is much simpler to say "number 3 from the Meeting Minutes, 9 am August 16th." 5. Include won't do's - make sure you state specifically what will and will not be included. (I've had multiple experiences with someone coming back at a later date stating "we discussed this in the meeting last week... I thought we were including it... ". So, within the meeting notes, make a note of what will not be included or will not be done).,>,> EXAMPLE NOTATION Paragraphs - About items, not people; Simplified topics Not succinct - John stated that he wanted to make the header wider to accommodate the newer resolution of 1600x1280. Craig disagreed as the research currently states that only 16% of computer users have that resolution - many more have a resolution of 1280x960. However, John

4. stated that Craig's research was based upon ALL internet users and OUR internet users are savvier, therefore they will typically have the higher resolution. We will need this information by August 26th, 2013 so we can incorporate it into the next release. Succinct - A discussion was had to determine screen resolution for header width. Our current customer base should support 1600x1200 dpi as they are internet savvy (more than the typical internet user). We need this information by August 26th, 2013 for inclusion in the next release. Action Items - Clear, complete sentences Unclear - John will research to confirm that 1600x1280 will work. (1600x1280? work for what? due date?) Clear - John will research to confirm that 1600x1280 is the best screen resolution for our users so we can include larger headers on the website. We will need this information by August 26th so we can incorporate it into the next release. Action Items - Numbered sequentially; Include won't do's A discussion was had to determine screen resolution for header width. Our current customer base should support 1600x1200 dpi as they are internet savvy (more than the typical internet user). We need this information by August 26th, 2013 for inclusion in the next release. 1.John will research to confirm that 1600x1280 is the best screen resolution for our users so we can include larger headers on the website. We will need this information by August 26th so we can incorporate it into the next release. We discussed payment options. EFT seems necessary, however, for the initial rollout, we will not be handling check payments online. Checks will be mailed to the Accounting Office. 2.Make sure IT has the information that check payments are not to be included in the initial release. Then pulling your Action Items together is a very easy task, take the numbered Action Item and consolidate them at the bottom of the meeting minutes. The last word - saving the file When you save your meeting minutes name them well. The name should convey the project, topic, date, and time. Something everyone can understand when reviewing a folder in Windows. I would rather have a long name that is descriptive than try to search for a particular discussion using the Windows Search feature. {date} {project name} {discussion topic} {time} works well. 2013 0819 - Project XYZ - Registration Implementation Issues - 9am When you start with the year/month/day your documents sort in chronological order as well. That's it. Meeting minutes, when done correctly, should become something you take and reference throughout the project. They are short simple paragraphs that summarize conversations. They are a way to track discussions and clarify purposes and intent. They are a listing of who, what, and when for each issue that needs tended-to. They are succinct and hold a common purpose (and can be used for the next meeting's agenda). They are shared by all on a project.

5. When done correctly they are the beginning; the initial structure of what needs to be done; what will be done and what WON'T be done. They are the first leg in Tri-Pod Documentation. Next up - Action Items! AA Meetings "Tri-Pod Documentation" is designed using meeting minutes, action items, and directory structure - the three-legged-stool of how projects are run. When you implement structured meeting minutes those parlay into action items. Once these two are in place, directory structure plays its part in making projects very easy to implement, reference and archive.