As a business analyst (BA), what would you say during the initial conversation with your project manager (PM)? First, do not assume that the PM knows what to expect from a BA. In fact, this is your opportunity to set expectations and explain your value added to the project.

Tracking project status means comparing where you really are at a particular time against the expectation of what “complete” means for this development cycle.  Monitor the status of just those functional requirements that were committed for the current release, because that’s the set that’s supposed to be 100 percent done before you declare success and ship the release.

In my experience of pursuing the CBAP certification, while there are tangible benefits from the outcome of being certified, there are some very real and very significant benefits generated as a by-product of the certification process itself, even when it was painful and downright frustrating.

Some programmers consider documentation a waste of time (see “Agile programming”), even going so far as to claim it is detrimental to productivity. Instead of getting all the software specifications recorded on paper at the start, they prefer to begin hacking on the program code and keep modifying it until the end-user is satisfied.

Probably the most used facilitation technique in business analysis is brainstorming.  In summary, a group meets with a facilitator and attempts to gather as many ideas as possible to address a problem. The facilitator sets rules at the beginning of the session of which the most important is “no adverse judgment of ideas” during the session.

Many BAs (especially the most experienced ones) should be familiar with processes...  Let us try to reveal, how BA skills are applicable to BPM and which steps a BA should take to transfer their knowledge to a state sufficient to fully enter the BPM sphere.

Now we delve into data modeling, one of the core model types. We choose to start here because data requirements are an important foundation for most information technology projects. If you are a business analyst and not doing data modeling today, you should be able to at least read them to validate requirements against what a data modeler has created and our bias is that business analysts can and should be doing “functional” data modeling.

In the real world, good decision modeling is always a balance between science and art. The science is systematic decomposition of a structure (of data or logic) into a set of smaller structures based on the definitions of successive normal forms. The art, on the other hand, is a general decomposition into a set of smaller structures based on factors not related to detecting and correcting normalization errors.

How often has a customer asked you to write software that is user-friendly, robust, fast, or secure? No one will argue that those are worthy goals that everyone wants in their software products. However, they are terrible requirements. They give you no idea of just what “user-friendly” means, or how to tell if you’ve achieved the desired characteristics that mean “user-friendly” to a particular customer.

I’ve come to the conclusion that most projects produce better results when they have specialized people playing the various roles, rather than trying to be resourceful and wear multiple hats.

Visual models don’t have to be complicated. Unless your organization uses formal UML or BPMN standards, focus on learning to create simple visual models. In this article, we’ll explore 3 simple visual models that a new business analyst should be skilled in creating because they add a lot of value to projects and generally improve your requirements documentation. 

Driving Lessons. We all did it. We all know how that very first one went. It was described to us that the clutch should be engaged, place the car in first gear, release the handbrake, release the clutch and press down on the accelerator… Only for the car lurch forward then stutter and lurch forward again. This process continues several times before the car stalls and comes to a stop.

No matter how thorough a job you do on requirements elicitation, there is no way to be certain that you have found them all. No little green light comes on to announce “You’re done!” You should always plan on new requirements trickling in throughout the project. However, an excessive rate of change of requirements suggests that important requirements were overlooked during elicitation.

As a Business Analysts we work with goals and objectives of our clients or companies in order to deliver business value, but how often do we sit and work on professional goals and objectives? How often do we use the skills that we possess on ourselves and our own professional activities? This year I plan to do exactly that, I have put together four BA resolutions that I believe will make me a better BA.