There are many smart, skilled, and talented people in the business and technology groups I worked in and with.  It is my pleasure to have had the opportunity to get to work and learn with you.  I wish you all the very best!

Sincerely,

Stephen

As a professional business analyst and the world’s most active job hunter (I receive over 2,500 recruiter contacts a year), I see all kinds of job “reqs” (requirements, or requisitions).  In today’s IT world, the virtues of technological contribution are highly extolled.  In many circumstances it is deserved and well-earned.  But in too many cases, the IT department is the tail wagging the dog.

Many job requirements for Business Analysts are really reqs for Systems Analysts in disguise.  SA’s (systems analysts) are not BA’s (business analysts).  Now hear me.  SA’s are not BA’s.  Both SA’s and BA’s are valuable to the IT groups and the business units they serve.  Better said, they can be valuable if understood and aligned properly.

What is the difference?

The distinction in my mind is pretty simple.  But due to the confusion on the part of many hiring managers and recruiters, it is worth spending a little time to clarify.  I have put together the little table below to help.

Of course these are just rules of thumb and there might be some variance among scenarios and individuals.  But in general, BAs and SAs have different functional experience and different mindsets.  Same goes for QAs (Quality assurance Analysts).

My advice to the professionals who hire BAs, SAs, and QAs, is understand what your organization’s needs are, and then clearly articulate and represent them.  Having the right person in the right job is important for both effectiveness and efficiency, as well as for job satisfaction.  If improperly implemented, misalignment can bring down morale and increase turnover and errors.  Expecting SAs to create beautiful and articulate documentation could instead produce confusing and incomplete wordage.  And asking a BA to perform detailed data-mapping might cause insanity.

Understand that my contention is not with the Analyst by any means, but instead with the manager who does not know the difference amongst types or does not care enough to accurately call the position what it is.  I mean this sincerely.  In fact on one occasion, though I was hired in as a Business Analyst, my group management decided to staff up with Systems Analysts.  This meant I was no longer a fit, and my contract was not renewed.  Don’t be surprised when I say that I am OK with that; management and I agreed.  My client boss recognized it and proactively provided his advocacy in my getting a position on the business side.

Hats off to all the wonderful Business Analysts, Systems Analysts, Quality Analysts, Programmer Analysts, and other IT Analysts – and to the hiring managers who care enough to put the right person into the right position with a commitment for success.

There are two questions in this article’s title.  The answer to the second one is “definitely maybe”.  The answer to the first will change every time depending upon whom you ask.

After having seen a few of these technical overviews at a particular large national client, I would have to say that they are only marginally beneficial.  The reason I answer this way is because the technical overviews were performed before the an adequate understanding of the basic business functionalities had been laid.

There is “the way it is”, and there is “the way it should be” (or at least the way I think it should be).

What I have seen is this: very smart people with lots of knowledge sharing their screens with dozens of people who know very little about the application being discussed.   These SME’s (subject matter experts) showed and discussed only databases and tables.  There were no process flows; no depiction or discussion of the business process flows or how the users actually use the application.  There was little insight shared about the big picture or why the application even exists.  Things apparently were started and continue to perpetuate under the silent and false assumption that everyone has the same point of reference as the tenured SMEs leading the meeting.  And as is typical with that type of paradigm, those who don’t know what is going on are intimidated into not asking questions out of fear of looking ignorant.  Have you ever seen this before or had it happen to you?

Imagine that you want to know what an application is and what it does, and you want to know how it is used.  So, does starting off with several minutes (or several hours in some cases) of images and talk about database schemas and SQL queries help you?  No, of course not.  And that is exactly why on several occasions new team members have come to me in confidence to voice their concerns about the confusion and void of knowledge around the core applications they are supposed to support.  In the end, I can serve only to assure them that they are not stupid, and that there is indeed a deeper root to the problem – one which, no matter how hard they try, they can never solve unless middle or upper management commits to defeating it.

While these technical overviews might be helpful to people who are already familiar with the application, they do little for the newbies or even for many veterans.  That is my beef.  Many organizations are too busy keeping in motion that they don’t think about direction.  The problem might at first appear to be of a tactical nature.  But it is not.  It is more systemic than that.   The problem is the lack of strategic vision.  There is a lack at the lower levels of the organization because there is a lack of intentional prioritization at the upper levels.  The deeper you analyze, the more undeniably revealed is the truth that at the root is the want for needed leadership.

There, I said it.  When there is a lack of vision within an organization, it is because of the dereliction of that aspect of leadership.  If not dereliction, then neglect.  I do not intend to be harsh.  But instead the reality is harsh that the top leaders of the organization should be well enough in tune with their downlines that they know whether their strategic visions are being disseminated and articulated to the ends of the earth and the ends of their org.  They should have their fingers on the pulse of their organizations.  If they don’t, it is because of ignorance at best, or maybe laziness or something else at worst.  Regardless, it is incompetence in my opinion.

Many people in leadership positions believe that vision dissemination should occur only at the top-of-the-enterprise level.  But I disagree.  In addition to your Michael Dells and your Steve Jobs and Your Bill Gates and your other charismatic and iconic-or-not CEOs evangelizing the corporate dream and vision, you should also have department heads and group managers and team leads communicating their smaller parts of the big plan to everyone.  And while there are a lot of excellent leader types in the lower ranks who do their best, it is only when the top organizational leaders consciously, willfully, and purposely promote vision dissemination that everyone can hope to see things clearly.  The more complicated the nature of the business, the more important the need.

So, enough of my ranting.  Let’s talk about you.  Does your company have vision?  Can you see it?  Do your superiors and top managers and executives consciously endeavor to promote that vision to the ends of the org?  What is the best example of vision articulation and promotion that you have seen?

Sometimes this is determined by a lack of resources, such as the redesign for the ecommerce company I worked for last summer. The dev team was up to their ears in other projects, so we in the product management team did our best to capture requirements and develop use cases. And strangely, the executive PM on my most recent project seemed to not even engage the development team until after all the use cases were completed. By the time we started getting feedback, it became clear that a large number of use cases were written for nought, as they were struck off the list due to being basic functionality that was a common component of off-the-shelf software. This along with some other factors, contributed to the project blowing its budget early on.

After creating the initial use case map, the guesswork begins. What is needed? What is desired? What format is preferred? What is extraneous and should be ignored? Are my first 3 use cases good, too detailed, too general? How should I do the next 100?

By getting feedback from the developers and architects who will be consuming the use cases, you can adjust your production to conform to what is needed versus what some manager’s experience was 3 years ago with use cases or what article her former boss read. The sooner the use case writer gets this feedback, the better her use of time, and the more useful her documentation will be.

While use cases are primarily written descriptions of a process, and are quite helpful in many circumstances, their value and desired format is rarely consistent from IT shop to IT shop. Many developers I have worked with prefer diagrammatic process flows. Some want only bullet point requirements statements. Some want wireframes. And some want a mixture of all.

As for me, I really don’t care which documentation format is desired near as much as I want them to tell me which one they want.  Sounds simple, right? Because it is. But many managers and PMs decide to double the pace to compensate for lack of direction. My recommendation?…

Let the Business Analyst meet with development for just 1 hour to discuss what type of documentation they prefer. And don’t just allow him, but empower him and facilitate him in case development says it is “just too busy”.  Buy coffee and doughnuts – or even pizza if absolutely necessary.  Remember, budgets exist outside of the development team, and having such a short, sweet meeting early on can and will save tens of thousands of dollars in precious time.  (By the way, I don’t think I have ever heard a developer tell me he was too busy for free pizza).

My style as a BA has been to go meet and greet as many possible constituents as early as possible on every new project.  This has fostered my high performance – award-winning performance, literally.  But amazingly, more and more I am seeing obstructionism by managers who seem to fear some sort of political backlash if they enable their team to be proactive.

In conclusion, there is lots of “opportunity” to increase effectiveness and efficiency in the development process early on.

Some people think that you have to choose between requirements statements and use cases. My experience says otherwise.

A requirement is a criterion by which something must conform in order to satisfy what is required. Simple enough. And a requirement statement is a form of expressing the requirement. As you might expect, it is just the stating of the requirement in a simple sentence format. The more it fits into a bullet point format, the better.

Contrary to a popular myth that focusing on requirements statements is at odds with using use cases and performing an agile or other type of aggressive development methodology, starting off with requirements statements actually enhances whatever type of methodology you plan to use. That is because they are the foundation for what will be put into the use cases, application visuals, prototypes, and what-have-you. Requirements statements represent what is in the business owner’s mind.

Time and again I have seen an organization (large, famous, global ones) dive right into use cases, experience all sorts of confusion and turmoil on what should be in them and how they should be formatted. I have seen them waste millions and millions of dollars by launching directly into prototyped development. And then in the end (actually the middle which should have been the end), they go back to the basics which is requirements statements.

Like everything else in project development documentation, requirements are to some extent “living”. There should be some sort of approval and change management process. Requiring sign off of requirements statements gets the business owners involved and committed versus letting them be passive and distanced from the project. It is important to understand that gathering requirements statements need not take 6 months as comes to mind for the traditional waterfall development process. In fact, they can be initially drafted in a very short time such as a week or a day. And their approval and changes can be managed via email versus formal review. (Nevertheless, they are real, tangible, and written down!).

With requirements statements in place, working on the to-be process flows and use cases makes sense. They have context and meaning.

For one of my ecommerce clients, Sterling Commerce, I took things back to basics for them and began with requirements statements. Very quickly we were into process flows and use cases. So, how did it turn out? Well, let me answer it this way… The project completed on budget and the product launched on time, and later my client manager told me, “Our development lead loved you – you are the best BA we have ever had!”

Starting with requirements statements does not mean sacrificing your use cases; it means making them better.