The CapTech slogan, prominently displayed at the top of our webpages and on our business cards, is “Others Talk, We Listen”.  That motto quite accurately describes how we are successful, and we strive to produce solutions that work for our clients.  What are the client’s pain points?  What do clients actually need, and what are they really asking for? 

What if a customer is having difficulty conveying information?  Have you ever been at a loss for how to extract requirements or other information from a Business User?  Have you ever felt that every question yielded a vague or “YES”/“NO” answer?  Here are three easy phrases to prod your customers to supply more information in an easy to use, non-threatening way.

A big focus during the first couple of days at the conference has been on Business Analysis Centers of Excellence (COE).  There have been a number of sessions where the speaker has shared their experiences with setting up and maintaining a COE.  There is a desire among BAs at an organization to have a community where the analysts can share ideas, create standards, develop best practices and document templates, and learn about what it takes to be a better BA.  There were some instances where management iniated the creation of the COE, but in most cases it started as a grassroots effort among the BAs in the organization.  

The purpose of a COE is to setup processes, controls and templates for the business analysis community within an organization to follow.  More and more companies are realizing the necessity for this and are looking for ways to implement it.  There are a few important things I learned during the conference about setting up and managing a COE.

Today was the first full day of the Building Business Capability Conference.  This is the 2nd year of the conference and first that I have attended.  The conference is made up of 4 tracks

• Business Analysis Forum
• Business Process Forum
• Business Rules Forum
• Business Architecture Summit

I am mainly focused on the BA forum.  My goal is to take some things back to CapTech that can be used to increase the effectiveness of our BSA practice and also understand more what are some of the pain points in the industry and what can be done to relieve them.  I attended five sessions today and took something away from each.

1.

I’m a data modeler, so I enjoyed Jonathon Geiger’s recent article entitled “Why Does Data Modeling Take So Long”.  But why does he say it like it’s a bad thing?

Mr. Geiger’s bottom line is exactly right: “Most of the time spent developing data models is consumed developing or clarifying the requirements and business rules and ensuring that the data structure can be populated by the existing data sources." On the projects he describes, no one took time before modeling to determine available data sources and identify business entities of interest, relationships among them, and attributes that describe them before database design started, so the data modeler had to do it.

As a BSA, most of what we do on a day-to-day basis ends up in a deliverable that is consumed by others.  Whether it is a business requirements document, feasibility study, use case diagram, or process model the goal is to produce something that can be easily understood by those who look at it.  This level of consistency is not that hard on a small project where there may only be one or two BSAs.  The challenge increases within large projects/programs where there may be dozens of BSAs.  This challenge also exists for corporations where multiple projects are going on at once in the same line of business and they all have dependencies on each other.  One of the underlying competencies of a business analyst is to be able to communicate to a wide audience in a way that is easily understandable.  While it is important that each individual BSA has this skill there are things that an organization can do to help the BSA produce the best work possible.

One of the things I’ve learned the hard way is to include a checklist of data-specific criteria in your Data Requirements document. 

We have all heard the question come in from a developer asking about formatting of numeric values.  “How many decimal places?” or “Does this value have a leading dollar sign?” The Data Requirements section of most Requirements Documents lists the name, description, data type and other characteristics of specific data elements.  It defines whether each data element is a character (and its length) or numeric, and whether NULL’s are allowed. 

An often overlooked piece of the requirements gathering and documenting portion of a project is assuming that everyone understands the assumptions.  Almost every project document includes a list of assumptions.  Problems arise when the assumptions are not clear or when some are left off of the document.  

Recently my friend Mark Hudson posted about the inappropriateness of the term “sprint” for an agile project phase, preferring the cycling term “interval.” That post really struck a chord with me.

As IT consultants, we often find ourselves aligned to (read: paid by) either business or IT, but to implement successful technology solutions we have to work in concert with both business and IT stakeholders. We have to avoid the mistakes that follow from putting IT at the center of the universe to the detriment of the business users. IT supports business, and we always have to work with that at the forefront of our minds. Below are a few tips that I've found that are helpful in putting the needs of the business first.

1. No IT project is ever and end to itself

The Business Analysis Body of Knowledge (BABOK) which is the current documented standard for Business Analysts lists the following techniques as ways to elicit requirements from stakeholders.

• Brainstorming
• Document Analysis
• Focus Groups
• Interface Analysis
• Interviews
• Observation
• Prototyping
• Requirements Workshops
• Survey/Questionnaire

In this post I am going to focus on Document Analysis and how it can be a useful step in your requirements gathering efforts.  Blog posts in the future will touch on some of the other techniques.