Well, loyal readers, John Dean didn’t set me off with his recent column (insufficiently fascist, entirely too rational), AND I want to think about what he said before deciding to respond.  This means we can take our discussion about BA and Identity Systems back to the highest level, before we diving for the next drill down (I know, I promised a drill down, AND this is more fun). 

In this case, the highest level issue that comes to mind regarding Identity Systems has to do with “executive sponsorship” for a national consensus on the requirements for such systems.

The ONLY source of executive sponsorship powerful enough for BAs to succeed in Identitying System Requirements are the people themselves, and yet the people (as a whole) rarely rally to a transparent process for the common good, which is exactly what we are proposing.  When the people do rally, the effect is immense.

Let’s face it – half the time, a BA can’t even get quality requirements on projects where the stakes are much smaller than for a National Identity System.  Commonly accepted “project failure” symptoms, such as Failure of user acceptance, Failure to deliver mission critical function, Missed deadlines, Over budget, Poor requirements documentation, Scope creep, etc. sound like Project Management problems to outsiders and executives. 

Most BAs know that these failures are really due to organizational resistance (including stakeholders and IT people) to the BA process.  As the famous joke goes:

Q:  How hard is it to deliver on time and under budget?

A:  It’s easy, how much must I spend by when?

Time and money are very important, but not if the what you are building gets lost in opaque, non-transparent petty politics.  The root problems tend to be deeply human ones, revolving around self respect, conflict avoidance, territoriality, work avoidance, organizational tribalism (silos and secrecy), fear of change, lack of trust and much more. 

To these deeply human issues, let us not forget simple corruption, which is less emotional and more premeditated, and cringes in the light that BA practice can bring.

This suggests the Five Great Challenges to our profession.  These are the issues that will define our profession, and will decide if BA can make a difference.  We believe that we can increase project success and reduce the overwhelming waste and failure rate that is currently an accepted part of the world of projects.  Will everyone else?

Will the society at large empower BAs to operate at the level of professionalism required of (say) accountants (transparency, completeness, accuracy)?

1. Given the importance of the what in a project, will PMI agree that BA must precede projects, and BAs must be at least peers with PMPs, instead of answering to their time and budget needs first?
2. Will the earliest CBAPs actually be a credit to the profession?  Will they generate successes, and word of mouth, to help boost the profession, or will they have the same outcomes as everyone else?
3.  Can the society at large understand the BA process well enough to understand why they want to support it?
4. What, if any, are the rules for public disclosure of private malfeasance?  There are such standards for lawyers, doctors, accountants, etc.  What will ours be?
5. What, if any, are the rules for public disclosure of private malfeasance?  There are such standards for lawyers, doctors, accountants, etc.  What will ours be?

Mere certification cannot resolve these issues, but it is a good start.  If you believe, like I do, that BA must rise in our society, please contact me with your ideas. We must lead, or continue to follow, and I for one am tired of being an armchair quarterback.

Thanks for being my reader, if this inspired you at all, please make a comment, so BA Times can know that we care.

Have fun!

In April, I began a series of articles devoted to helping professionals wade through the sea of available business analysis information currently flooding the marketplace and focus on just the essentials. I like to think of it as Business Analysis Unplugged, my own personal back-to-the-basics world tour. 

April’s article discussed the importance of understanding your organization’s overall business goals, and May’s piece covered how to create a common vocabulary among your project team. This month, for my third in the five-article series, I’d like to discuss something that can often get overlooked in the business analysis process: properly identifying the sources from which you will eventually extract your requirements.

Labeling
When we’re kids, we’re told that labeling people is bad. Well, this is good advice in life, but not necessarily in business analysis. The fact is, properly identifying and affixing your sources to specific categories is essential for planning and successfully extracting requirements. Although there are none that are set in stone, three common categories that I’ve used to label sources on past projects include: Customers, Users and Additional Materials and Experts. In this example, all of your sources would fit into one or more of these three buckets:

Customers
A customer is the person or group, internal or external to your organization, likely to pay for the products and services produced. This category can be further refined to include subcategories such as sponsors and champions, or domestic and international customers. The further you’re able to refine your categories, the better.

Users
A user is the person or group who is ultimately responsible for interacting with the products or services produced. Like customers, there’s definitely room for further refinement here. For example, direct users may touch and manipulate the system on a daily basis, while indirect users may simply request monthly or quarterly reports. Both groups will yield distinctly different requirements.

Additional Materials and Experts
This category is more than just a fancy name for Other. It could include additional individuals or groups with influence on the project, such as third-party vendors and subject-matter experts. It’s also important to note that your sources don’t necessarily even have to be humans. And no, I’m not talking about robots-at least not yet. There are many non-human sources that would fit into this category that you can leverage when extracting requirements. These could include existing systems, both hardware and software, or existing documentation, such as governance documents, previously captured business architectures, training manuals and service agreements. 

A One- or Two-Person Job
In my last article, I encouraged group thinking for the development of a project’s glossary of terms. For labeling and categorizing your sources, I recommend essentially the exact opposite strategy. Like building a glossary, categorizing sources is busy work, but it’s busy work that should be taken on by as few people as possible; I’d recommend just the business analyst and, if he or she is feeling collaborative, the project manager. Too many opinions too early can lead to roadblocks of disagreement and the always dreaded analysis paralysis. 

Within the categories, the business analysts should also identify each source’s role and then the benefits that each source will realize from the completed products or services. The phrase “no stone shall go unturned” applies well here, because eventually everyone on your list-from the daily direct users to the software developer at your partner company to the CEO of your organization-will be affected by what you’re creating. So, start with the big picture, and then become as specific as you can. Inevitably, you’ll find that some of your sources fall into more than one category. This is not a problem, and is to be expected.

Once you’ve created your detailed list of categorized sources, you should share that list with the team for feedback

Is It Worth It?
In our need-it-yesterday business culture, your temptation may be to just start calling and e-mailing your sources and asking them questions about their requirements. But remember, business analysis is about planning, preparation and clarity. By going through the process of labeling and categorizing your sources, you and the project manager will begin to get a clear picture of the scope of your project and the amount of time, money and effort that will be required for successfully eliciting requirements. You’ll also be able to identify the risks involved.  For example, if you find that 60 percent of your sources are located in another country and many of them don’t speak your language, well, you’re going to have some extra work to do.  It’s best to realize that from the beginning as opposed to three months in.

Next Month-Choosing the Best Elicitation Techniques
How’s this for a cliffhanger? Labeling and categorizing your sources is also essential for helping you identify the best techniques to use for requirements elicitation. Of course, this just so happens to be the topic for the next article in this series, which will appear here next month. Until then, remember, the more specific you are in your labeling and categorizing, the more valuable the information you’ll have at your disposal later.