Whew! It’s been a while since I last posted, but now I’m back to it.
In my last post, I mentioned that I wanted to spend some time on what BridgingtheGap.com calls ‘business analysis techniques’. Today’s discussion is about agendas.
Most people think agendas are only for meetings. To be fair, that is mainly what they are used for. But the concept of ‘agenda’ is broader than that. An agenda is simply a list of things to be discussed, considered, done, talked about, completed, etc. Now, it’s important to take note of a few things. The definition for ‘agenda’ does not
- say which items on the list are more important than others
- require more than one person to be privy to the list
- include an explanation of why items are included in the agenda
- place any resource restrictions around the items on the list
What this means is that items on an agenda can be prioritized, secret, and/or unexplained.
Back to agendas and meetings.
Meeting agendas help Business Analysts to manage meetings by informing attendees of what will be discussed during the meeting. For example, if an agenda shows three items, X, Y, and Z, the attendees can extrapolate that there will be little or no discussion of A, B, and C. A, B, and C are not on the meeting’s agenda, and time will not be spent discussing them in that meeting.
In my experience, the use of a meeting agenda is better than not, but the efficacy is limited if additional information is not delivered along with the agenda. Among many other things, people want to know why they have to stop what they are doing to go to a meeting in the first place, what the purpose is, who authorized the meeting, and how long the meeting is going to take. Sometimes, all of this information is not available, or is only given out on a need-to-know basis.
I’ve found it’s best to be as upfront as possible about meeting agendas- even if that means sending a meeting invitation that says “Come to the meeting to tell me where/how I’m wrong”. 🙂