What's My Name Again?

Monthly Sales Revenue Generation... no

Monthly Sales Group Rev Production... no

Sales Revenue Performance by Month... no

Sales Revenue by Month for Overview... maybe... yes, that one was it.

Speaking from experience, trying to document vital business information when it all is named with generic operational mumbo-jumbo will slowly cause your brain cells to rebel against you throughout the day. If you haven't given in to their demands by the end of the day, your brain could retaliate by making you forget vital information like your name, favorite color, or the air speed velocity of an unladen swallow.

Concerns for your own health aside, the business is put at risk when vital documents or business processes are not identified correctly. Loss of documentation can lead to costs for replacing it, failed process attempts, legal actions, and bad requirements for projects.

To prevent that from occurring, a system to easily identify information correctly is needed. In the strictest form, the information you are working with should have unique ID's (not like the ones at the beginning of the post though). If you use requirements management tool like Caliber, then your entries should be given unique IDs. If not you will have to come up with some system yourself.

A combination of letters and numbers work well to prevent ID overlap. I tend to favor a 2 to 3 letter prefix that is some sort of abbreviation for the information such as 'RO' for report object or 'IPD' for InfoPath Document. This will help add much needed meaning to an identifier without having so many words to say so in the first place. It also serves as a code that is easier for machine side recognition if applicable to your project.

Now we have our lovely hybrid id. What do we name our document? Some people like to use summaries (which unfortunately, in my opinion, are informative mostly based on how you see things.) I try to use a generic name that describes the overall purpose of the doc such as 'Sales Dashboard' or 'Customer Credit Registration'. Those types of names will most likely be commonly accompanied with dates relevant to the creation of the document. Try to append the date in a manner that is friendly to alphabetical sorts (i.e. 2009-08-26).

Now the part that some of us will not like (I am looking in your general direction agile extremists), write down in a list that all these documents exist. Descriptions, owners, and change management rules for these documents will prove invaluable later. While other BA's are telling stories about how this one employee quit 4 years ago and the sales process is relying on a SQL database running off of an old laptop that person setup which they are now trying to bypass, you will be quickly identifying which documents need to be migrated to the new system and being confident you got all the relevant organization's buy-in.

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?

Creating Accurate Time Estimates

I recently joined a new project where I will be working as the person responsible for the developing and creating the requirements and documentation on a major development effort. As the person on the hook for a significant portion of work, I need to provide accurate time estimates for my portions of the project. I was concerned about providing accurate time estimates on a new project in a new environment. I am also very aware that deadlines are important and know that if I am unable to accurately estimate my deliveries, I will quickly lose credibility with the rest of the team. Underestimating my deadlines might also put other team members relying on my work at risk of missing their deadlines.

My concerns had me thinking that perhaps others might be in a similar situation. After a bit of research and analysis of my own process I compiled the following list of questions and suggestions to help when making time estimates.

1. How accurate do your time estimates need to be?
   If an estimate needs to be very accurate, it is usually a good idea to take a longer period of time to consider and analyze the answer. It is not unreasonable to ask someone who is looking for a timeline for some “think time” in order to provide an accurate answer. However, when not immediately responding, it is a good idea to communicate a reasonable target for when you will have the estimates finished, even if it’s only 15 minutes of extra think time.


2. How well do you fully understand the project/tasks that you are being asked to estimate?
   If a problem is complex, or if you do not completely understand all of the tasks you need to finish, it will be difficult to make accurate time estimates. Getting as much clarification as you can is necessary. Discussing the details of what you have been asked to accomplish with the person making the request might also provide them insight into the complexity of the request and your work process.


3. How long has a task of this type taken to accomplish in the past?
   It is a good idea to maintain a personal log of tasks and an ongoing list of recorded time spent performing a task. I simply use an excel spreadsheet to record tasks I have finished on my projects and update it when I have a few moments at the end of the day or week. Having a realistic idea of the amount of time I spend on my tasks helps me to accurately predict future projects/tasks.


4. Are there any assumptions, conditions or constraints which might affect your time estimate?
   It is impossible to predict in advance every detail of a project with certainty. It will be important to note your assumptions and constraints when you provide your time estimates to communicate your issues clearly. These could all be considered risks to the accuracy of your time estimate and should continue to be monitored as you begin the tasks/project.


5. Do you need to add any wiggle room?
   You should consider adding contingency time if there is a lot of uncertainty about the tasks or many risks associated with your estimate. By increasing time to the estimate appropriately because a project is new and unfamiliar as a way to prevent underestimating your efforts.


6. Are there any other elements to the project/tasks that should be included in your time estimate?
   One area I consistently forget when creating estimates is the amount of extra time I have to spend doing administrative tasks like organizing meetings, sending emails, or organizing documents. At times, these types of activities are not always predictable, but understanding how much of your work might be effected by other project duties is important. There is a small amount of extra administrative work in most tasks, and adding that into your work estimate will help your estimating efforts.

When I employ these methods they have lead me to more accurate time predictions that have also greatly reduced my anxiety over creating self imposed deadlines that are unrealistic. As I also have an intrinsic desire to please the person asking for my time, using some standard processes in producing my time estimates has lead me to win/win situations for both my project and myself.

Your Requirements Best Practices Are Not Your Reality

To begin with an analogy: I have a friend that can be unreliable sometimes and show up late when we have plans to meet. This is especially difficult to manage when we are meeting to see a movie – if she shows up 30 minutes late, then the movie date is off because the show has already started by the time she gets there. She’s a great person to be around, just difficult to manage at times. We agree that we need to meet 15-30 minutes before the show time (best practices), yet something happens and she shows up after the movie starts.

If our plan to see a movie was instead a project for which I was the requirements expert and she was the project lead, then the concept of showing up 15-30 minutes before show time would be a recognized best practice. So what to do when an acknowledged best practice conflicts with what the project lead wants (the right to show up late in the case of the movie example)? The lead wants the benefit of the best practice (seeing the movie), but things happen or constraints are in place that create a situation where this cannot be done.

What I should do (Best Practices) ≠ What I’m going to do (Reality)

The first step I take in these situations is to first fully understand the project lead’s reasons for not being able to apply the best practice. From the movie example: perhaps my friend is taking college classes at night, and they end right before the movie meeting time. In that case, we could just meet for a later movie, or wait until the weekend. Can the lead and I find a “movie time” that works for everyone where we can still apply the best practices?

In the very rare case that the project lead is simply in disagreement with the use of the best practices, then I determine if it is something worth arguing for. How will the project be affected if we do not apply the best practices in question? If the impact is minimal or can be easily negated and/or managed, then it makes sense to apply the practice that the project lead is requesting. If the impact is too great to ignore, then I work to convince the lead to trust me and let me demonstrate the benefits of applying the best practice.

By the end of the project, we are laughing and munching on the last of the popcorn together as we exit the theater.

Bridging The Gap: Best Practices In Translation For Business Analysts

Requirements analysts often play the role of translator. They listen to, understand, and document the needs of system users in the users’ natural language and they present the users’ needs to system designers and developers in a more formalized ‘language’ made up of models and other artifacts. It is critically important to project success for the analyst to communicate effectively with both audiences.

Most analysts do this without really thinking much about it or examining the process and the best analysts do it quite well. But translation is actually a complex undertaking and it’s worth spending some time on it to understand what is really going on and exploring for ways to improve the process and the results.

Know The Requirements Process

The simple description of the translation process involves just two steps: Decoding the source content and re-encoding the meaning of the content in the target language. A more in-depth look at these two steps reveals some significant complexity. Translating from one ‘natural’ or spoken language to another requires that the translator understand the syntax, grammar, and nuances of both the source and target language. This is a much more involved process than simply taking one word at a time from the source and finding the equivalent word in the target.

For requirements analysts the task has a further challenge in that the target must be precise and rigorous while the source will usually contain vague and indistinct literary constructs that are normal in the everyday use of a spoken or written natural language.

Know The Language Of Your Target Audience

I could not find any research on translation specific to the work of requirements analysts, but there is a fair amount of evidence that deep knowledge of the target language is more important for a translator’s success than expert level fluency in the source language. The research suggests that while perhaps coding experience is not necessary, it is important for RAs to have extensive knowledge of the models used in requirements specification and this knowledge should be from the perspective of the consumers of the specification, designers, developers, testers, etc.

Research and best practices from the translation business also suggest that the draft translation should be reviewed by a second translator with deep knowledge of the source language.

Many software requirements analysts do have a background in software design and development but many come from other disciplines as well.

The ideal situation may be for the requirements specification to be first drafted by an analyst with deep knowledge and background in software design and development and then reviewed by an analyst with deep knowledge and background in the business. Not every project team will have access to the ideal mix of analysts but if your project does it may be worth a try.