Sunday, November 25, 2012
In a recent discussion I was asked if there are a set of competencies, other than a certification, that could define a business analyst. Is there a list of characteristics that will indicate whether a person will make a good business analyst or not? Here is the paraphrase of my answer: For one thing, many of the competencies, such as ability to communicate in both written and verbal formats, do not have finite measurements. Some people communicate better than others and some communicate well in writing, but not verbally. All might be good business analysts, and all might not. I think a list of competencies (abilities, traits, talents, etc.) that a person typically needs to possess to be successful at business analysis would provide a good guideline for all those interested in performing as a business analyst. If a person is honest about their own competencies - where they are above average in performance and where their ability or knowledge is lacking - the person can seek improvement in that area. And that is a good thing. In the end, if you took the winner of the Nobel Prize in Business Analysis and sat them next to an average workaday business analyst, you might not be able to distinguish between them based on a competency list. In fact, the Business Analyst of the Year may not be able to pinpoint what he or she does differently than the average business analyst. The competencies, such as communication, inquisitiveness, empathy, analytical abilities such as critical thinking, visualization, curiosity, system thinking, networking, influence skills, negotiation and mediation skills, and so forth, have become so habitual and part of the prize-winning business analyst that he or she would not be able to describe them. The list of competencies should not be used to distinguish a person as a business analyst or to qualify a person's ability as a business analyst, but to provide a guideline for those in the profession and those who would join the profession as to what they have to work on, to hone, to improve, so that the competencies become inherent, habitual and automatic.
Thursday, November 1, 2012
I spend a few weeks in London in September and October capping a year long project that involved both analysts and production and operations managers. I had assumed over the years that the physical move into production was a project manager's responsibility. The PM was the one working with the production people to ensure a smooth transition into production, usually while the developers, business analysts, QA and users are completing the acceptance testing and getting final sign off of the product. In this particular company which follows ITIL it turns out that there are a number of standard procedures (which I helped initiate many years ago and are now refined into smoothly running processes) that are more business-related than project related. As we worked on various projects and processes I began to realize that the business analyst can actually do a lot during the project to make the transition easier for production. I talk a lot about the business analyst making the transition easier for the users, which does not go away, but there are also tasks the business analyst can do to ease the flow of the application into operations. It turns out that the overall business requirements do not only come from the users and business stakeholders. It is not enough to just make sure the problem is solved and the requirements are met. It’s not enough for a business analyst to ensure the described well enough for the developers to build. The business analyst also needs to work with the production people to make sure that the application moves smoothly into operations. There are requirements from production, for example ITIL standards to meet, that have to be defined as well. While these are not necessarily business requirements, they do affect the business in that they affect the ultimate delivery and use of the application in the operational environment. Since the business analyst is responsible for solving the business problem, the business analyst should be aware of requirements for that solution to go live. The guiding principle is always: if the users (customers, stakeholders) are not using the solution to solve the problem, the problem is still not solved.