Mission Elicitation - Phone Meetings

The site is security restricted, there are subject matter experts in other buildings, and the developers are in another country. Your mission, should you choose to accept it, is to gather the requirements for a gap analysis of your clients software implementation. Your meeting will self destruct in 3 days. You have a phone, a scribe, and a computer to complete your task, good luck.

I have a feeling that most meetings like this fail to meet their real goal, identifying the majority of gaps. A major implementation that requires gaps to be identified often have one big kickoff meeting where you were able to get all the important people to free their schedules. Of course, they couldn't be all in one place, so you have to meet over the phone. This can be disastrous. Not only does everyone over the phone lose context around presentations and discussions, but the people forget who is on either side of the phone. White boarding turns into phone charades. Scribes miss out on who said what. To-Dos are lost in the background noise.

Okay. Take a moment and breath deep. Think of pleasant things, like pre-existing documentation, SMEs that agree on the existing and future business processes, and meeting notes that make sense when you go back to read them.

Relaxed now? Alright, lets make sure we prevent as much of this as possible. There are several steps to mitigate as much trouble as possible. If at all possible, get a tablet pc for the meeting. If that is not going to happen, make sure you have access to a process mapping tool such as Visio. Secondly, make sure you have an online collaboration tool such as Go-To-Meeting, WebEx, or MS Live Meeting. If you don't have one of these tools, get a trial or find an open source (read: free) solution. The ones I mentioned would be ideal since your client will most likely have them already installed which means that there is less of a chance that the first 15 minutes of your meeting will be people discussing which button someone should have clicked instead during the install. Finally, find a scribe. If you do not have someone on your team who can help you, you might have to ask a participant to help you scribe while you try to facilitate and elicit.

Alright, you have your basic tools. First order of business, send out the meeting invite. Don't make this the standard meeting invite you see everywhere else, subject line and no description. Make sure that you include the objective of the meeting and the rough agenda. Step two, make sure everyone is introduced over the phone. Always good to go over who is in attendance and the role they are playing in the meeting. While introducing everyone, it is wise to have the meeting objective and agenda displayed on your projector and online screen sharing tool of choice. Make sure that you are located close to the phone so that you can repeat what was asked or stated and by whom.

While the meeting is going on, be sure to bring up a notepad or word doc on the screen to jot down any action items that come up. Be sure to write down who owns the task and their contact information if you do not already have it. Just having the task title isn't a nice thing to come back to and try to figure out, so add some context. Simply writing down "Get everyone's buy-in" is tempting, but please include the people involved in 'everyone and on what document/process the buy-in is needed on. At the end of each day, send out your notes to all the participants along with the list of to-dos to the owners. You might have to keep track of the to-dos and make sure their owners complete them.

When a white boarding session strikes, pull out your tablet pen or Visio program and start tossing up a copy so that everyone is involved. Much easier than describing which line connects to which box that resembles something more of a rhombus. Doing this will allow for the people over the phone to quickly understand the topic being discussed and add in their knowledge to the debate. True kudos if you are actually able to secure or setup a webcam that will allow you to broadcast the white boarding, removing the lost in translation possibilities.

These are just some basic pointers to holding elicitation meetings over the phone that can save headaches and money for your project. Do you have any phone elicitation pointers or standard operating procedures?

ProductCamp Austin is this weekend!

ProductCamp Austin is just around the corner! It's this Saturday from 9am-3:30pm. I unfortunately am out of town yet again for it, but Tony Chen will be representing Seilevel at it this summer. Hope to hear great stories back from everyone attending!

Do You really Believe in What you Do?

I have a question for all of you BA/ RE/PDM people in the world. Do you really believe in what you do for a living, or is it just a job? My wife needs a new mode of transportation. Her current ride is 12 years old, has more than 240K miles on it and is beginning to require more repair than I’ve got time. So now we’re out looking at all the different vehicle options. I have to say that that I find this very frustrating because she really has no idea of what she wants. We get home from our first shopping trip and she can see that I am obviously put out by all of the "I don't know" answers she gave me while trying to find her a car. She says, “So I guess you don't want to go look again in the morning.”

Ding! The light bulb went off.

I told her we needed to figure out what our requirements were before I set foot on another car lot.

The next morning we set down with pen in hand and I started asking her what was important to her -What her needs were. We created a nice long list of items. Next, we looked at each item on the list to determine what need each of the items addressed. Finally, we prioritized the wants from the needs. We talked about number of passengers, baby seat mounts, fuel efficiency, heated seats, number, size and placement of cup holders, as well as just about anything else you can imagine. I now have a more defined idea of what she needs and what she wants in her next car, but more importantly, so does she. After all of the headache, I wondered why I did not complete the exercise sooner. This is what I do for a living. I help customers define their needs, identify requirements, separate wants from needs and prioritize it all.

If it works everyday for the job, why not use it at home? It’s hard to beat having a job that’s so helpful in so many situations.

When was the last time you found your BA/RE work to be helpful outside of work?

A Product Manager By Any Other Name...Still Writes Requirements

When I was younger, I used to care a great deal about people's titles. Maybe it was my little brain's way of organizing people like I organized my Tinkertoys (teachers go over here, doctors are over here, mommies are in this section...). In any case, I believed that a person's title told you all that you needed to know about him or her. I had grand plans for my own title when I grew up. I decided to be a "Professional." "A professional WHAT?" I'd often get asked, and I'd simply reply, "Oh, I don't know yet -- but whatever it is, I want to be a PROFESSIONAL at it." The work didn't matter, but the title did.

Many people, as I did, place a great deal of emphasis on titles. On the Seilevel message board there are multiple threads discussing the differences between Business Analysts, Requirements Analysts, Product Managers, Project Managers, Systems Analysts, and even humorous entries like Requirementers, Information Vigilantes and 'Shall'icitors. In my career I've held the titles of Program Manager, Requirements Analyst, Manager of Requirements Management (say that three times fast), Business Systems Analyst, and Product Manager. I've done pretty much the same work in all of those jobs. Instead of worrying about what my business card says, I focus on doing my job well.

A recent example shows how other people may not share my perspective. During lunch a few weeks ago, a friend was describing someone he works with. "She's a 'Product Manager,' whatever the heck THAT is," my friend chuckled. But did she do her job well? Did she help build great solutions to difficult problems? I don't know, because my friend "checked out" once he got to her title. To him, the title might have sounded silly, or been unfamiliar, or been tainted by previous experiences with sloppy Product Managers, but it was all he knew of her. By focusing on her title, he had lumped his co-worker (and me, although he didn't know it) in with the rest of the silly or sloppy people he knew.

So what DOES a Product Manager (PDM) do? Product Managers outside IT typically focus on understanding their marketplace and seeing that successful products are developed and released to that marketplace. Within IT, a PDM has a similar role. He or she is responsible for the end user adoption of and satisfaction with a product. The PDM is also responsible for the return on investment of that product.

In IT, a product may be anything from shrink-wrapped software to customized tools created for use within an organization. The PDM defines or identifies the scope of the program, project or release by understanding it in relation to the related business objectives. The PDM elicits, models, defines, documents, reviews and baselines requirements. She or he also manages changes to the requirements, supports and often participates in user acceptance testing, and supports product rollout and adoption activities.

All of these responsibilities help ensure that the product released meets both the business objectives and the users' needs. Given the wide range and financial impacts of a PDM's responsibilities, what does it mean to do that job WELL? To me, the most important aspect of being a great PDM is taking ownership of and pride in your product. If you believe and act as though you will personally make this product a success, you will do a good job as a PDM. If others are getting frustrated with your constant involvement, your probing questions, and your unwavering focus on product success, you're on the right track!

Whether you're a PDM, Business Analyst, Requirements Analyst, or some other flavor of requirements professional, don't let the debate over titles distract you from doing a fantastic job. After all, it's your work that matters, not your title.

How to Prepare for Software Requirements Sessions with Your Users - Tip 4

Our final suggestion on this topic is to Sit With Your Users.

If your users are extremely busy, and the project involves changes to or replacement of an existing solution, then turn the challenge into an advantage. Sit beside the users while they perform their job tasks.

Typically this is a good way to elicit requirements because users cannot always articulate their needs if they are used to completing tasks without thinking about them. This technique will require follow-up meetings with the users after, but then those meetings can be prepared for as above, with intelligent questions based on the observations, thereby shortening the time that users are away from their work.

Let's recap, we've now offered the following suggestions to prepare for requirements sessions with users:

1. Organize Your Time
2. Prepare Your Requirements Models In Advance
3. Prepare Your Elicitation Questions in Advance
4. Sit With Your Users

There are many ways in which requirements analysts can intelligently prepare for requirements sessions with users. Typically a mix of the above suggestions will work well on any project. These tips will help the analyst and users get the most value out of the available time.

By the way, you can download all of these tips in a whitepaper that I've written. Enjoy!

How to Prepare for Requirements Sessions with Your Users - Tip 3

We have now discussed the need to organize your time and prepare models in advance of the sessions.

Today we suggest you Prepare Your Elicitation Questions in Advance

One of the key steps to take prior to a stakeholder meeting is to prepare a list of questions to be asked during the meeting. These questions might be created based upon past experiences or recent meetings with the user. If the analysts know the users, the organization, or the types of issues they face, that knowledge should lead to obvious questions. If the analyst has met with the user already, new questions should be created based upon those original meetings, lessons learned and new issues identified. Also, if drafted models exist, those most certainly should prompt questions.

There are some stock questions that you can use as a guide to requirements gathering sessions. Keep in mind, though, each project will need its own unique questions, and some of these questions are likely not appropriate.

How to Identify Actors for Software Requirements

Here are some suggested questions to ask to identify the actors of the system. These questions are in a guide that we've design to keep on your desk. Download it here.

• Who uses the system?
• Who installs the system?
• Who trains people to use the system?
• Who fixes the system?
• Who starts up the system, who shuts it down?
• Who maintains the system?
• Who creates, updates, deletes information in the system?
• What other systems interface with the system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically at a predetermined time?

How to Identify Use Cases

The following suggested questions can be used to identify the list of use cases or system functionality.

• What functions will the actor want from the system?
• Does the system store information?
• Do the actors need to create, update, or delete information?
• Does the system need to notify an actor about changes in an internal state?
• Are there any external events the system must know about?
• What is the actor’s overall job?
• What problems has the actor had in the past?
• What steps are manual today?

How to Identify Alternative Courses

In order to identify alternative courses or exception paths, these questions should be asked at every step of a use case main course.

• Is there some other action that can be chosen?
• If X does not happen, then what should happen?
• What if the actor cancels an operation (e.g., closes a window)?
• What if the actor provides incomplete information?
• What might go wrong at this step?
• What if part of the system goes down or is unavailable?
• Are there any events (or interrupts) that might occur at any time during the use case?

Are you ready for the last part in our series? It's an oldie, but a goodie!

How to Prepare for Software Requirements Sessions with Your Users - Tip 2

Last time we talked about organizing your time.

Today's suggestion: Prepare Your Requirements Models In Advance

Prepare draft requirements models in advance of the meeting. The reality is that good requirements analysts do in fact know quite a bit about the business processes and requirements. There is a misconception that they should remain unbiased; however, these individuals become experts in the systems they are capturing requirements for and that expertise should be utilized to its full advantage.

As an example, if you are going to cover a topic with a user about how he or she does a task, then you can try to come up with the obvious use cases in advance. You can then take it one step further and actually try to write the header information and normal course for the use cases. Similarly, you may find it valuable to draft state diagrams, where you capture the states and transitions that are obvious and highlight the unknown ones for completion in the meeting. Virtually all requirements models can be pre-drafted if you know a little bit about the business.

In doing these models ahead of time, you will find yourself jotting down lots of questions in the margins, like "What really happens at this step?" or "Should they do X instead of Y?". Even if you throw away the draft model because it was all wrong (which rarely happens), there is still a value from the time investment because you came up with a list of detailed questions. Essentially this is a brainstorming tool for you.

Starting from a blank slate can seem like a daunting task, so once you have draft models, in the meetings with users, you can use these models to work from. Similarly to the authoring experience, reviewing the models will spur questions in the reader’s mind. Therefore they make an excellent tool with which to facilitate a user meeting.

See another great post on how to choose a requirements model.

Come back for part 3 next!

How to Prepare for Requirements Sessions with Your Users - Tip 1

This is the first part of a four part series on how to prepare for software requirement sessions to be most effective with your users' time (and yours!).

Can You Get All of Your Requirements In One Session?

There is general agreement in the software industry that talking to end users to gather requirements is critical to the success of the project. However, a common issue is that users are particularly busy. For example, if an organization decides to add features to a call center application, talking to the call center representatives is critical, but it’s also costly to pull them away from taking calls. In addition, requirements analysts are extremely busy and may have to limit how much time they spend with any one user.

A common issue in gathering requirements is leaving a stakeholder meeting where you missed major requirements because the “next question” to ask did not occur to you at the time. It is unreasonable to think that this will never happen. The reality of software requirements efforts is that they are iterative. In addition, there is quite a bit of critical analysis that must take place, and that analysis cannot always happen immediately in a meeting environment. Whatever the reason, there is certainly a need to get the most out of time spent with the users. So how do you best prepare for meetings with your end users?

Software Requirements Sessions Tip 1: Organize Your Time

Requirements analysts should realize that the software requirements life cycle can be time intensive - including time to analyze, edit, review, and update. The key is to maximize the value from everyone’s time.

Make sure that requirements sessions are well planned, inviting the minimal group of people necessary to get value out of the meeting. The burden of extra time spent should be on the requirements analyst, not the users who are being taken away from their primary jobs. Prepare an agenda and appropriate artifacts prior to the sessions in order to keep the meeting focused on making valuable progress.

In dealing with any super-users who are unable to commit much time, it is important to zero in on specifically what information they must provide. Then allow these users to suggest alternative users to meet with to provide additional information, ensuring them you will allow them to review what the alternative users provided.

Come back soon for part 2!

How do you prepare for a requirements session? I'd love to hear your answer in the comments.

Secret Skills and Qualities of a Great Product Manager

I was giving some thought to what it meant to be a good product manager. There are many good posts written about the typical analysis skills found in a product manager, so I wanted to think a little outside the normal box. Here's what I came up with:

• Thinking on their feet – We spend a lot of time in front of busy users, project managers, and developers, who are smart and know their business well. At times, they are intense. They will ask tough questions of us, and probably even more challenging than that, they will state things that we need to be able to understand quickly and ask questions back intelligently. Too many blank stares, uncomfortable silences, and “uh, I don’t know”s will help us lose your credibility fast.


• Thoughtful – We are interviewers often, and so with that we must be willing to listen and think about what they say. This is different than quick thinking, but rather truly deep thinking. It will require some skills of empathy and understanding when the teams are frustrated. It will require just being someone that cares (and not faking it!).


• Likeable – I hate to say it, but we have to be likeable. We work with so many different people through the course of our work, and we really need these people to want to help us get information from them. People enjoy helping people they like, so be likeable.


• Must like people – Again, we work with so many different people who believe in us, trust us with their products. So complimentary to the last point, we must like the people we are working with. We have to want to talk to them, to tell them how it’s going, to ask them questions – simply put, we must be willing to engage in conversations. While being an introvert is very helpful to the analysis work that must sometimes be done quietly alone, being an introvert all the time will not lead to successful product management.


• Passionate –We have to love things! It sounds silly, but passionate people can feel things, both positive and negative about products around them. We can recognize and engage passion in the users we are working with. It shows itself as excitement, which can be addictive in a group.


• Excellent Reviewer – Not only must we elicit and document requirements, we have to self-review and peer-review the work. Being able to find missing items, or inconsistent requirements across volumes of data is not trivial. There are models and tools to help this, but so far, none of them completely take the thinking out of it. I have found that this is one of the most challenging skills to teach someone to do.