I would challenge you on those situations where a client only meets during our meeting. Sometimes that can be an opportunity for the BA to step up and further integrate with the business side to help them define the requirements. We can’t always expect the business to come prepared to work just on requirements, sometimes other discovery or negotiation meetings also play a role in gaining alignment on requirements. Is it possible in these situations to add structure to the client’s decision-making process to help them prepare for more formal requirements meetings?

Laura

1. Review User Integration Requirements
2. Review Web Services
3. Review Historical Data Load

Each one of these items has specific information. I’ve found that details and confirmation of attendees/necessary resources offers a better chance that the meeting will be productive. Another very important step is to get the agenda out in plenty of time, people have their day job to do. Depending on the type of meeting – like a 3 day JAD session – I might allow 2 weeks. For smaller type meetings, I still allow about a week. And then I send a reminder 2 days before the meeting. Outlook is a great tool! Dealing with clients, sometimes they have a PM running the entire project – this entails no support during discovery or requirements sessions – its just the PM and we get no where. Here is the same agenda (small scale) that will likely produce desired results in the first meeting.

Agenda:
Goal: Finalize data requirements, processing requirements and data acquisition requirements for each application. This will be used to document your FRD. Items to Bring: Agreement or SOW (scoping information to remain in scope) and any items prepared for this meeting (like sample fields listles, documented user rules etc)

Attendees: Business Owners, Data Experts (this could be HR, IT etc), End Users (that will be working in the system), decision makers

1. Review User Integration:
a. Define processing rules for your users such as: (provide examples; if I’ve gone through good discovery I’m going to spend some time with specific items we need to define – not to much so its overwhelming).
b. define the data fields that you want extracted out of your HR system: Be sure you engage the proper resources to assist with the data mapping.

2. Review the data acquisition: Web Services have been defined for the exchange of data. (I’ll then list a few items to take to the IT person. Ideally, they will prepare samples to bring to the meeting and/or have their questions prepared).

3. Review Historical Data Import (include the data type they purchased for the import to stay in scope)

a. How are you managing your data today (I provide examples – multiple spreadsheets, access db, a current system. This way we don’t spend time in the requirements meeting talking about manual processes- unless it was necessary to help define business rules)
b.What data elements will be included in your import (I provide some examples of possible data based on the type of import)

The worst projects are those where the client only meets during our meeting, these tend to drag on and on. Most of my clients are working on projects in addition to their regular job and appreciate knowing exactly what they need to do to prepare.

I love this topic so thanks for the collaberation, the basic things are sometimes the most important and we forget. I look forward to more posts.

I would suggest one or two more things in addition to the setting up Context for the meeting.
A solid agenda with each item having allocated time helps to keep the audience focused on discussion and refrain from wander around. Such agenda should be made available prior to the meeting.

During the meeting, Keep asking the feedback or opinions of the users on discussion topics. This way it would help grab their attention and make them think.

At the end of the meeting, facilitator should also give brief summary of what was discussed, what decisons were made and what action items were assigned to whom.

Laura