The Site is under Reconstruction

I apologize for any inconvenience, but I think you'll enjoy the new site.

Business Analyst Mastery Podcast is Back On the Air

In this episode of the Business Analyst Mastery podcast I’ll talk about:

-  5 Step Outline to Better Presentations
-  A great tool for doing UI wireframes

NOTE: There is some noticeable sound quality difference between the newer and older recorded parts of this podcast.  I’m hoping the newest version of Audacity that I am using will help make the sound quality more consistent.

Be Prepared for Stakeholder Interviews

In this Episode of the Business Analyst Mastery podcast I’ll talk about:

• A comment about one of my Business Analyst articles at modernanalyst.com
• Stakeholder Interviews

Download thisBusiness Analyst Mastery Podcast Episode

More Questions Than Answers in the Beginning

In this Episode of the Business Analyst Mastery podcast I’ll talk about:

• BA World Denver
• 6 More Entry Level Business Analyst Skills

Download the Episode Here

In the first episode of the Business Analyst Mastery podcast we talk about:

• What to expect from this podcast
• 5 Entry Level Business Analyst Skills

Download the Episode Here

The great intro and outro music provided by Noise Media.  You learn more about their great music HERE

Shoveling Snow is like Business Analysis

Most of you probably don’t know (or necessarily care) that I live and work in the panhandle of Texas.  However, the panhandle area just got hit with a pretty good blizzard requiring me to shovel my driveway.  I say “pretty good blizzard” because I grew up in North Dakota, and what passes for a blizzard and shuts down businesses and schools in Texas is just a minor inconvenience in North Dakota.  I digress. As I was shoveling, a thought struck me that shoveling snow was a very good analog to performing Business Analysis.

The Right Tool for the Job

One thing about shoveling is that you need to use the right tool for the job.  You can not use any old shovel.  If you try to use a normal flat bladed shovel like you would use in soil, you will be shoveling for a long, long time.  There is a reason snow shovels are wider and hold more material.  More importantly, depending on the type of snow on the ground, you may need different snow shovels.  For instance, a plastic shovel works well on powdery or even wet snow, but it is almost useless for breaking up the icy layer underneath.  A metal shovel works best for those icy layers.

The right tool for the job holds true in Business Analysis as well.  A class diagram will likely be jibberish to the end user.  A Use Case Scenario and Use Case Diagram is a better tool for non-technical types.  Also, a System Requirements Specification is the wrong tool to put in front of the Executive Sponsor.  You will be better off with a shorter, more global tool like a Vision Document.  You may or may not use the tools described, but you should be conscious of the tool you apply to the situation.

Scope is Important

In general, it’s a good idea to get agreement on the scope of the project.  If your friend asks you to come help him/her shovel, you may ask what you are shoveling.  If he/she says a Walmart parking lot, you may either want to decline or find a snow plow.  If you are shoveling a driveway, like I was, it’s a good to have a general idea where the driveway ends and the grass begins.  If you don’t know, you could end up driving the shovel into the grass causing unnecessary damage to your lawn or sprinkler heads.

Again, in Business Analysis, scope is important.  If the scope of the project is too broad, you may have to find ways to narrow it or split it into multiple projects delivered in iterative fashion.  If the scope is narrow enough, you may still want to clarify boundaries to ensure you will be able to stay on track.

You Have Your Choice of Methods

There are two basic methods for tackling the job of shoveling snow.  First, you can wait until it stops snowing, and shovel all the accumulated snow.  Second, you can shovel frequently while it is still snowing so that the accumulation of snow never gets very big.

The two methods mentioned for shoveling translate pretty well to Business Analysis requirements gathering methodologies.  First, you can take waterfall type approach and accumulate all the requirements into a document and consider them complete.  Second, you can take a more iterative or agile approach by gathering those requirements you need at this time, and you can gather more requirements at a later time as needed.

NOTE: For those Business Analysts that have never had to shovel snow, consider yourself lucky.  If the analogy eludes you because of your great fortune, I apologize.

Business Analysts: Racing to Nowhere?

The Race to Nowhere?

The question mark was on purpose.  I’m wondering what all the effort is for.  You know what I’m talking about: all the training, writing, conferences, blogging, mentoring…………………….

Why are we doing it?  It really feels like a race to nowhere.  We spend an inordinate amount of time educating ourselves to improve our professional standing.  Where does it take us in our careers?  Right now, I don’t think it takes us very far.  I believe there are a few reasons for this:

1. The Business Analyst Profession is Young
2. Lack of Adequate Corporate Business Analyst Training
3. Failure to Set BAs Loose on the Company

The Business Analyst Profession is Young

I’m not talking about the term Business Analyst.  I’m talking about the Profession.  The profession of the Business Analyst is one that is not yet recognized by most companies.  In a recent post, I was pretty harsh on the idea of Certifications, but if you could get past the somewhat nasty tone of the post, I noted that I’m a fan of what the IIBA is doing.  It is my opinion that the IIBA is doing more than anyone else to further the notion that the Business Analyst is a Professional position.

Unfortunately, most companies are only concerned with the Role of the Business Analyst.  Companies see the BA as a Role to be filled not a Professional to be nurtured.

Lack of Adequate Corporate Business Analyst Training

Every day as I wander the highways and byways of the Internet, I come across yet another Business Analyst who has had to learn it all on their own.  The lack of training may be related the previous point, but I think there are a couple other reasons that companies fail to provide adequate business analyst training.

The first reason is cost.  Many of the BA training programs are expensive.  As companies have been scaling back costs in an uncertain economy, they certainly are not going to spend THOUSANDS of dollars on training.  The second reason is time.  Having mentors produce internal training is good, but mentors need time to create the training, give the training, and respond to questions about the training.  However, the mentors (senior level BAs) are usually the ones handling the most sensitive or visible projects within the organization.  They just don’t have the time.

If there is no dedication to training, where do BAs go in their careers?  Nowhere fast.

Failure to Set BAs Loose on the Company

Right now businesses everywhere know that they have Business Analysts that can provide solutions to complex problems for their customers and provide real value.  However, Executives and Management, everywhere, FAIL to set those same BAs loose within their own companies.  It always makes me wonder if the Executive management is scared of what these masters of problem solving will uncover.  I don’t think so.

The problem is the silo’d nature of business.  If there is a problem with Marketing, let the Marketing manager figure it out.  If there is a problem with Operations, let the Operations manager figure it out.  Companies just don’t see Business Analysts as a shared resource.  If they did, there would be more companies hiring Business Architects out there.

Moving Down the BA Path

There isn’t much we can do about time.  Good things will happen for the Business Analyst, they have happened, as time goes on.  In the mean time, it’s important that Business Analysts demand more structured training from their companies.  In addition, the IIBA should continue their efforts to ensure that Business Analysts are recognized as the Professionals that they truly are.

Certificates are for Children

Certificates Are For Children

What is a certification really worth?  Children get them for good school attendance or winning a race.  Yet, numerous college institutions, and other organizations, are passing Business Analyst Certifications off as though they are equal, in some way, to the degrees they confer upon graduates.

When asked whether someone should complete their college degree or get a BA Certification instead, I recently posted the following on LinkedIn:

I think completing your degree will give you the most “bang-for-your-buck”. Here are a few reasons I feel this way:

1. You already have significant experience as a BA. Right now, the CBAP is not as widely recognized or required by employers as, say, the PMP. A quick search for CBAP on the major job boards will validate this.
2. A degree provides you more options if you find you cannot advance, specifically if your company does not have a career track beyond Senior BA.
3. In my opinion, many of the Certification programs offered are way overpriced. You can acquire additional BA knowledge cheaper online or through books. This works best when you find a mentor or two that you can have direct your knowledge seeking efforts.

If you are more business oriented, I would suggest a Bachelors in Information Systems or other Business degree. If you are very technical, I would recommend a Computer Science degree. If you are hoping for further advancement, I would recommend the MBA which can lead to higher management levels.

Worthless BA Certification Exceptions

There can be exceptions.  The Project Management Professional (PMP) certification offered by the Project Management Institute (PMI) is a fine example.  The PMP is a certification recognized across all industries and backed by a mature organization with a history of steady improvement.  Employers across the globe demand PMP certification as a basic requirement.  The closest thing Business Analysts have is the International Institute of Business Analysis (IIBA).  However, the IIBA is not yet mature enough to engender the same sort of recognition as the PMI.  Don’t get me wrong, the IIBA will become what the PMI is, but that is going to take years.

Experience and Training – NOT a Piece of Paper

A quick search of the job boards proves that current employers are searching for people with particular experience and training.  You would be better off plunking down $6,000 on a SAP or Business Objects training course than a Business Analyst Certification.  That doesn’t mean you shouldn’t pay for training.  On the contrary, you should purchase training, but you can do it much more cheaply by taking online Business Analyst training courses and buying books.  If you do decide to get the certificate anyway, just make sure you are doing it to get the training to develop experience and NOT just for the piece of paper.

Example: Simple UML Activity Diagram

Mistake #4 – No Activity Diagram

I will admit that this mistake usually only occurs in Use Case documentation that is complex. By complex, I mean that there are a number of alternate flows in the Use Case scenario.  If you have a very simple Use Case with a Basic Flow and one simple alternate flow, then you can probably skip the Activity diagram.

However, if you have more than two alternate flows, the logic is probably complex enough that you would provide a benfit to the reader by including the Activity diagram.

Benefits of Activity Diagrams

Much like the Use Case diagram, the Activity diagram provides an easy to read visual depiction of text contained in the document.  This can be presented either before or after the reader has actually read the textual description.  Specifically in the case of a complex Use Case scenario, the Activity diagram will provide the read with a way to visualize all the logical flow.  You can imagine how hard it is to keep all the logical flow of events intact when you are reading several pages of a Use Case scenario.

In addition, software developers generally think in terms of logical associations, and they generally prefer the Activity diagram over all the text in the Use Case scenario.  If the developer requires clarification, they can refer to the detail contained in the Use Case scenario.

You should be including Activity diagrams in your Use Case documentation to improve the readability of your documentation.  Remember, the point of writing a Use Case document is to provide clear, unambiguous description of the functional requirements of the system being developed.

Mistake #3 – Improper Associations Between Use Cases

There are three associations between Use Cases according to the UML v2.2 Superstructure:

1. Generalization
2. Extend
3. Include

All three are considered “Directed Relationships”.  This means that the direction of the relationship arrow has meaning in UML.  The most common mistake in using these relationships in Use Case diagrams is usually when the Business Analyst draws the relationship in the wrong direction.  Utilize the information below to make sure you don’t create improper relationships between use cases:

Use Case Generalization Relationship

Proper form of Use Case Generalization Relationship

Generalization is a way to depict the notion that there are general types of Use Cases (example: Perform ATM Transaction) and specific versions of that Use Case (example: Withdraw, Transfer Funds, Deposit Funds) that inherit the properties of the general type.  The Generalization association is shown a solid line with an open arrowhead (or hollow triangle) that goes from the specific type of actor ending with the arrowhead pointing at the general type of actor.

Use Case Extend Relationship

Proper form of a Use Case Extend Relationship

This relationship specifies that the behavior of a use case (Login) may be extended by the behavior of another, usually supplementary, use case (Register for Online Banking).  So you can think of this as Register for Online Banking extends Login.  The normal functionality of Login implies that the user has the appropriate Login information.  If the user does not have the Login information, Register for Online Banking extends Login by allowing the person to Register for Login information.

Since Extend is also a directed relationship, it is important to note that the extending use case (Register for Online Banking) is the source and the extended Use Case (Login) is the destination for the association arrow.  The association is shown as a dashed line with an open arrow head going from the source to the destination, highlighted with the keyword <<extend>>.

Use Case Include Relationship

Proper form of a Use Case Include Relationship

Include is a directed relationship between two Use Cases, implying that the behavior of the included Use Case (Card Identification) is inserted into the behavior of the including Use Case (Withdraw from ATM).  The included Use Case is not optional.  It’s behavior must be performed within the including Use Case.  You can think of it in this manner: Withdraw from ATM (source) includes Card Identification (destination).   The association is shown as a dashed line with an open arrow head going from the source to the destination, highlighted with the keyword <<include>>.

Valid UML Association Between Actors

Mistake #2 – Improper Actor Associations

There is ONE association between actors in use case diagrams: Generalization.  Generalization is a way to depict the notion that there are general types of actors (example: System Administrator) and specific versions of that general type of actor (example: Disaster Recovery Administrator or Database Administrator) that inherit the properties of the general type.  The Generalization association is shown a solid line with an open arrowhead (or hollow triangle) that goes from the specific type of actor ending with the arrowhead pointing at the general type of actor.

Actor Association in Use Case Diagrams

According to the UML 2.2 Superstructure document: “An actor can only have associations to use cases, components, and classes.”   So you may be asking how can an actor have an association to another actor.  Great question.

The answer lies deep in the bowels of the UML 2.2 Superstructure document, and the answer itself is a form of Generalization.  You see, the Actor is a specific type of Classifier in UML 2.2.    Since it is a Classifier, UML 2.2 Superstructure says: “A classifier is a type and can own generalizations, thereby making it possible to define generalization relationships to other classifiers.”   So the specific type of Classifier that is Actor inherits the properties of the more generalized Classifier in UML, allowing for the Generalization association.

Painful, isn’t it.

UML is a Language

So you may be asking: “Why is this important for a Business Analyst?”

My answer comes in two parts:

1. UML is a language.  Like any language, if it is not written correctly, it is at best comical or worse; meaningless.
2. Business Analysts that utilize UML, and Use Case Diagrams specifically, should not produce meaningless documentation.

Keep this common mistake in mind when you create your Use Case documentation.  Better yet, utilize one of the many tools out there that will enforce the UML syntax rules to prevent you from drawing meaningless diagrams.

Even simple Use Case Diagrams should be documented

Mistake #1 – No Use Case Diagram

You should always include a Use Case diagram regardless of how simple it is.   There are two main reasons for this:

1. Provides a sense of scope to the reader

First, it gives a clear picture to the reader showing the scope of the documentation following.  For example – if the ready sees a single actor and single use case in the diagram, they can expect a rather short document, unlike a diagram with 3 actors and 8 use cases which would indicate a rather lengthy document.

2. Simple Use Case diagrams can be combined into a Use Case Model

Second, by providing a diagram in every Use Case document, it makes it much easier for an architect or Senior Business Analyst to reconstruct the system by piecing together all the diagrams into a viable Use Case Model.  This becomes more important if you are developing a large system with a lot of decomposition at various levels of abstraction.  This also becomes important if you are trying to make changes to and existing system that does not already have a Use Case Model.   By injecting these diagrams into documentation, a full or nearly complete model can be constructed over time.

Post your thoughts:  Do you always document the Use Case Diagram?

Don't make these 4 common Use Case doc mistakes!!

We are all in a hurry to get the docs in front of customers and developers to keep those business wheels turning.   In our rush, we can often forget that there a number of different individuals with different roles that will read our documents.  Business Analysts should be cautious of these 4 common mistakes when creating Use Case documentation:

Mistake #1 – No Use Case Diagram

Mistake #2 – No Activity Diagram

Mistake #3 – Improper Associations between Actors

Mistake #4 – Improper Associations between Use Cases

Although I originally planned on discussing each of these mistakes in this post, I soon realized that each of them deserves it’s own post.   Take a look at each Mistake, and review each of them to make sure you are not making these mistakes yourself.

Should a company hire only Business Analysts?  Of course not.

Can a company be comprised, almost completely, of  BAs? Absolutely, and it should.

Nearly all of the companies I have worked for have had Business Analysts.  Very few of the BAs had formal training.  In fact, most were Domain Experts that naturally fell into the Business Analyst role with their ability to define the system requirements.

What is a Business Analyst, really?

The BABOK® v2.0 describes the Business Analyst as:

“A business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysis practitioners include not only people with the job title of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design.”

Read that paragraph once more, just in case you missed all those people who could possibly perform the Business Analyst role.   I’ll bet if you work in a software company, that list comprises a good number of your employees.

How to Train an Entire Company?

There are X things you need to train a group of diverse individuals:

1. Short training sessions – You can’t have the whole company stop what they are doing to sit through several days worth of training.  Look for courses that are short enough to digest easily in one sitting.
2. Online – It’s best if these courses are online and available to the employees at any hour, day or night.  The easier it is for them to do the training, the greater the satisfaction.
3. Targeted course material – The courses should target only what the employee needs to learn the material.  For example: a developer doesn’t need to learn how to run a Focus Group or create a SWOT Analysis, but they do need to understand UML diagrams and Use Cases.
4. Immediate implementation – Training is useless until implemented.  Make sure the employee is able to implement their training immediately.  They need to hone the skills that they just learned.

The Results

Providing formal Business Analyst training will ensure that each and every employee trained in Business Analysis will be able to provide solutions needed for the organization to reach it’s strategic goals.  Additionally, Business Analyst training across the organization will foster better communication flow.

I need to start by saying that the BABOK® Guide v2.0 is a step in the right direction towards making the Business Analyst role as powerful and prevalent as the Project Manager role.  With that disclaimer out of the way, there are 4 things you should know about the BABOK® v2.0 before purchasing it:

1. Cost
2. Knowledge Areas
3. Techniques
4. Bibliography

The Cost

This is one of the best things about the BABOK® v2.0.  As of this posting, you can download a pdf copy for $29.95 USD (members of the IIBA get a copy for free).  Compare this to the $65.95 USD price of the PMBOK® 4th Edition (PMBOK = Project Management Body of Knowledge for those of you that might not have ever heard of it), and the BABOK® v2.0 sounds like a steal.  However, the PMBOK® has been around much longer and contains 195 more pages, and, in general, is a much more mature and stable guide.

The Knowledge Areas

According to the BABOK® v2.0  “Knowledge areas define what a practitioner of business analysis needs to understand and the tasks a practitioner must be able to perform.”  The Knowledge Areas (heretofore referred to as KAs)  are well detailed in the BABOK® v2.0, and they should be read thoroughly by all levels of Business Analyst.  It is likely that some of the KAs will not be used in your organization which may be a problem if you decide to go for the Certified Business Analyst Professional designation (more on that in a future post).

The Techniques

This is the section that really disappointed me.  Although it is clearly stated that these are “high level overviews”, I still felt that the content describing the various techniques was lacking.  I understand that they could not possibly detail all the 34 listed techniques, but I still felt as though there should have been more.  At the very least, I would like to have seen references to the pertinent entries in the Bibliography that describe the techniques.  This would allow Business Analysts to quickly find the relevant research material to further their education.

The Bibliography

This is a comprehensive and relevant list of material from which Business Analysts can train themselves.  To some (like myself), this list would comprise a dream library of information concerning Business Analysis.  I think the folks at the IIBA did an excellent job on this.  Iit is important that they used recent material from which to base their Body of Knowledge on.  My only regret is that stated above: if only BAs could easily match the techniques with entries in the Bibliography.

Conclusion

Despite my complaints, the BABOK® v2.0 is a must for any practicing Business Analyst and for anyone interested in Business Analysis, regardless of the role they play.  Go out an buy it, learn it and teach it others.