I notice when I talk about Business Analysis people often have a very fuzzy idea of what I’m talking about. And the deeper I go into defining the profession from a general perspective, the fuzzier it gets.

That’s why I decided to write down the things I personally do on a day-to-day basis, and I hope this will help build a better picture for the uninitiated. Other BAs might do different things, but usually there a level of similarity, otherwise there would not be a name for the profession.

1. Documentation – Most known and usually most tedious BA activity. The problem I’m trying to avoid with this is to have 5 team members and 3 major stakeholders and amongst them 15 different ideas what we are actually doing. The Business Requirements Specification is a tool for avoiding this, but not the only one and often falls short of achieving the objective.

2. Process Analysis – I don’t do enterprise analysis, at least not on my current position. What I do is more focused – when we change the systems people will change their work process. What I’m trying to describe is how things are done now (the AS-IS point of view) and how the work will be done after the change (the TO-BE process). The purpose here is to demonstrate to the team what the changes we are making will actually achieve. It also visualizes in front of stakeholders in detail what business result they have requested.

3. Requirements Elicitation/Analysis – A key task in my job, this is the description of what system changes we are actually going to make. The task here is to translate the general and unclear requests into detailed description of what is needed and is going to be done. I need to be at least somewhat familiar with the current system designs, since some (actually most) initial requirements are unreasonable and waiting for the developers to tell me that takes too much time.

4. Requirements change management – Extremely unpleasant topic for all involved. Means that me and the stakeholders have forgot something or a stakeholder has simply changed their mind. So we need to reanalyze all the wok done so fore – requirements dependency, project scope and price, requirements documentation and communication. Since most of the team works on many projects at once and we have no constant communication, spreading the new information to everyone is a demanding task.

5. Priorities – All requirements matter but some matter more.  With limited resources at disposal my work includes proposing or making decisions related to what will be developed now, what will wait the next development cycle and what will be done in the bright distant future when the world becomes a perfect place and all our wishes come true.

6. Project Management – I highly value PMs for all they do – organizing meetings, taking hard decisions, negotiating deadlines, monitoring deadlines and so on. Most often, however, I have the dubious privilege to substitute for them. Since as a BA I have clear picture of requirements and keep constant contact with stakeholders I am the usual suspect for filling the role of PM for the project. If you ever need to convince someone it’s important that each project has a PM – let him substitute for a while and he/she will quickly come around. I guess that’s the reason PMs are the strongest supporters of the BA profession – for similar reasons they do our job when we are not around.

That’s all I can thing of on the spot. If you can thing of things you do as a BA (and probably me too, but can’t recall at the moment) feel free to add to the list.

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email.

You may also find these posts interesting:

• The role of the Business Analyst – poll results

More interesting to me were some techniques which I find very efficient but seemingly more rarely used. So I decided to take a closer look on them and to analyze them in more details.

• Following people around (Observation). It happens very often a customer to come to us with their vision about how the new product should look like and what it should do without being able to explain what exactly is the business process running in their company or how it is going to change with the deployment of the new software solution. One of the most effective approaches to study the customer’s business process and the habits and the technical skills of the future end users is just to stay there and observe their daily activities. Observation gives us the ability to see some flaws in their work, some too complex or unnecessary activities that could be eliminated or to get some ideas to improve the process and thus to increase the customer’s profit from implementing the new software solution. It is much better if our business analysts have the ability to the actual work the users do to get a hands-on feel for the real situation.
  Unfortunately, we are often pressed by tight deadlines especially in the analysis phase (which is a big mistake!) and we rarely use this technique for gathering information.
  Sometimes, the customer doesn’t allow us to meet their employees using security arguments. In those cases we should strongly emphasize that this is a risk for the right understanding of the requirements and for the successful release of the project.

• Brainstorming. This is a technique that works well in many cases and the requirements gathering phase is one of them. During a brainstorming session people get free of their inhibitions and are unleash their imagination which generates a huge variance of ideas, some of which could be very effective. Very often the customer is not able to define the requirements of the product just because it has to work in a new environment that still doesn’t exist – a new process that is yet to be defined. The brainstorming is very efficient way to help our customer define for themselves what needs to be done in order the project to be successful.
• Prototyping. It is one of the best methods in the software development business but on the other hand it is one of the most expensive ones. The prototyping is best applicable in projects where the result is something really new and unique and where the quality of the result is more important than the price. The development of software is very specific area and one of its most important traits is that it abstract – you cannot see it and you cannot touch it, especially during the development process. Thus no matter how deep and how long we discuss the requirements with the customer there always will be a significant chance for misunderstanding and in the moment we show them our product they could be unpleasantly surprised. The prototyping protects us from such situations and gives us the ability to show “live” the abilities of the desired product at a very early stage. When the customer “touches” and feels it then they will have a much better idea of whether the product they have ordered is really what they need. And if not – they will have the opportunity to correct their requirements early enough so they can be implemented painlessly.

Of course, these are not the only possible techniques but I find them very useful. Unfortunately, my observations are that they are used very rarely. I would be happy if you share your experience in the requirements gathering process – do you use these techniques and what are the other methods you use?

This post is also available in Bulgarian language. 

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email

You may also find these posts interesting:

• Software Project Management Again
• CIO Top 100 Companies For 2008
• Managing Padding in Time Estimates
• Software For Code Reviews For Only $5! A 5-Day Offer
• The Two Types of Programmers

You can download the book from its website – The Software Conspiracy.

Glenn Alleman of Herding Cats points our attention to the Department of Defense version of the Guide to Project Management Body of Knowledge (PMBOK® Guide). It is a better source of knowledge he says and more than this – it is free. In fact it is called “DoD Extension to PMBOK® Guide” and as they say in the preface:

The primary purpose of this document is to identify and describe defense applications of the core project management knowledge areas contained in the PMBOK® Guide, as well as those defense-intensive knowledge areas not contained in the Guide. It is important to understand that this is an extension to the PMBOK® Guide, and is not intended to be a stand-alone document.

Anyway, the document is free to download and I believe it could be useful source of knowledge to the practicing project managers.

And, at the end, a free e-book from one of the greatest software gurus – Ed Yourdon. His book Death March is still in my personal Top 10 list of all time influencing books on software development.

Craig Brown of Better Projects brought the link to the free e-book Just Enough Structured Analysis to my attention. He says:

[Yourdon] over time has migrated from a view that highly structured processes will improve project results to one where he believes the success factors are quality people and in keeping bureaucracy out of the way.

Ed Yourdon is a world class expert on software development and the book is definitely worth reading. He says in the Introduction:

This book is intended for two audiences: first, the person who is new to the field of systems analysis, and, second, the experienced systems analyst who needs to acquaint himself with systems modeling tools and techniques that have evolved over the past decade.

Happy reading!

You may also find these posts interesting:

• Classic Mistakes 2008
• Who Does Money Really Motivate?
• Classic Mistakes Forever!
• Recommended Readings: Project Risk Management
• How do you estimate the project’s budget? A new poll

I wrote a post in Bulgarian about the role of the business analyst in a software development team and I put a poll to survey how the people in the software development business in Bulgaria evaluate it. Now the poll is closed and I am giving you the results.

Question: How do you evaluate the role of the business analyst in your team?
Total votes: 27 (little but I still have few readers).

Answers:

1. Very important role. The BA investigates the customer’s needs and represent them before the team – 14 votes (52%)
2. All roles are equal. The BA is responsible for the functional (requirements) specification, which the developers implement – 6 votes (22%)
3. We don’t need such a person. The developers do the client’s business analysis themselves – 4 votes (15%)
4. What is a “business analyst”? – 3 votes (11%)
5. He just hangs around here and looks silly. He cannot write a simple JavaScript – 0 votes (0%)

How to interpret the results? Obviously, the first thing that has to be noted is the small number of the votes. For me, the main reason is the fact that still very few people visit my blog and most of them weren’t impressed by the poll. I think I will open it again in the future when there will be more visitors to my blog.

Anyway, the good news is that despite the few voters, the results show that the position of the business analyst exists in the software teams nowadays and it is appreciated positively. No matter if considered as very important (answer #1) or considered equal to all the others (answer #2), the business analyst takes his/her well-deserved place in the software team (totally 20 votes for both answers, which gives around 74%)

Answer #5 is rude and represents the vulgar and arrogant attitude of some developers to the surrounding world that doesn’t write code. I am glad that nobody voted for it. It probably means that this attitude was already buried in the past.

Answer #4 is a little silly. How can you be a self-respecting developer and not know what a business analyst is? I put this answer on purpose with the intention to be chosen for fun and to make the poll more colorful. I believe that this was the intention of the three guys who voted for it. And if they really don’t know what this is – keep on reading here – there will be more posts devoted to the job of the BA.

The most interesting answer for me is answer #3. It has a double meaning. There are companies, on one hand, that work on small projects or such that work on products and don’t use project principles at all. In such companies, every developer, having been working long time on the same product and having been communicating with the field experts from the business area being automated, gradually begins to gain exactly that knowledge and experience, which make him or her a business analyst. And if you add the aspiration of the company for more exploitation of its employees we come to a natural merging of the role of the BA with the role of the software developer in one person.

However, there is another interpretation. The team (or the company) could consist only of “great programmers” – people who think they know, understand, and can do everything. It was the ideal of the past socialist society in Bulgaria – so called “multi-dimensionally developed persons” – people who believe that a developer should be skilled in every aspect of the software business and there is no need of a narrow specialization in particular areas like business analysis, project management, testing, user education, etc. The developer can do everything!

I really would like to know what were the reasons to vote for this answer. I hope some of the voters will post a comment about it. And if you have an opinion about the role of the business analyst in your team – please, share it with me. It will be useful.

You may also find these posts interesting:

• My day-to-day work as a Business Analyst
• How Did You Become a Project Manager – Survey Results
• How Can a PM Become a Real Leader?
• The 20 Qualities of the Inspirational Leader
• The 3 Most Important Qualities of a Project Manager