The Requirements Engineering Magazine appears quarterly. It is cost free and provides you with up-to-date articles reflecting the activities of the RE and BA community.
Simply sign up for being notified about new issues of the Requirements Engineering Magazine.
You may unregister at any time by sending a mail to email@example.com from the e-mail address which you have registered with.
I was recently speaking to a large group of BAs about some of the lessons learned picked up over my years in the profession. I had a fairly large sample – a few hundred people in person and online – and took the opportunity to ask how many have come to Business Analysis from the IT side. At least two-thirds identified themselves as such. This matched my own conclusions from meeting BAs around the world, at least half of whom have formerly been developers or involved in the technical side in some other way (IT operations, etc.).
This is only one possible path to Business Analysis – others include a transition from business operations – but it is pervasive enough that I think it requires its own focus as there are both benefits and challenges specific to the IT-to-BA transition. It’s also a path I have come to know quite well due to my role as CEO of Noble Inc. – a Business Analysis training and consulting company – and because I have walked that path myself.
This article is for anyone who is personally contemplating that transition, or is in the midst of it. I want to explore why someone would seek this path, what the impediments are and offer some suggestions for how to transition successfully.
The Business Analyst (BA) function is to facilitate communication between the business and the solution provider; it may be a formal, dedicated role or a function played at times by a team member. In my work with my company, I‘ve met many developers around the world who are making the transition to business analysis - and heard many explanations for why they were motivated to take that route. As someone who has successfully navigated the transition, I have also shared many of these motivations: I went from being a programmer who chose the profession because I was being paid to ‘play’ – and who couldn’t care less about business – to being a BA who now runs a business as CEO of a company, and who is comfortable sitting with CEOs and VPs of large corporations, negotiating deals and helping them improve the BA practice in their organizations. From these perspectives, I’ve seen the following reasons for making the transition from IT development to business analysis:
The reasons for moving developers into BA roles vary not only by the individual person but by where they sit within the organization. For example, when I speak with the CEOs and VPs of IT consulting companies and service providers, about developing a BA competency using their existing programmers, the prime motivator I hear is the opportunity it provides to increase revenue from their existing client base by broadening and deepening the services they provide them. On the other hand, I hear a different motivation when speaking with the VPs of IT departments within large organizations: Their expressed goal is to better serve their business customers by doing a better job of going from a business problem to an IT solution.
Here comes the bad news for anyone considering the transition. A great programmer does not necessarily a great BA make. To be excellent at business analysis, you need a package of personality traits that don’t often come together in a single individual: a strong analytical side, coupled with highly advanced interpersonal skills. If you don’t have those ‘soft skills’, no amount of training in business analysis tools will make you a great BA. (The good news, though, is that there are things you can do to develop those areas of your personality that are currently weak, as I’ll describe at the end of this article.) So before you set out to become a BA, ask yourself these questions:
1. Do I have a sincere interest in business (or, can I at least put myself in the shoes of someone who does)?
The transition from IT developer to Business Analyst requires a change in mindset. To be an effective BA, you either have to genuinely care about business issues, or be able to put yourself in the heads of someone who does. It can be a challenge for someone who originally got into IT because of a passion for the abstract logic of programming. Some programmers are lucky enough to be born with both a feel for abstraction and a feel for the practical world of business. Others have to develop it. (I’m of the latter type, but I learned to think like a businessperson when I became one – a suggestion I’ll return to later.)
2. Am I a great communicator/ listener?
To be a successful BA you have to be able to put complex thoughts into terms your audience can understand. It means ditching the technical jargon and learning to use the business vocabulary of your stakeholders. It means being comfortable speaking with anyone from CEO to Customer Service Representative – and being able to adapt your approach to the person you are speaking with. And it means being a receptive listener – able to pick up on both verbal and nonverbal cues. If you are the type of person who loves to hear yourself talk – or whose thoughts tend to wander when others are speaking - the BA profession is not a good fit for you (unless you are prepared to change).
3. Am I a good synthesizer? Am I good at seeing the big picture?
Often, being a BA means being able to absorb a lot of information coming in from many sources and put it all together into a consolidated view. You have to be able to see the big picture – and not be a ‘details only’ person who ‘can’t see the forest for the trees.’
4. Am I a natural leader/self-starter?
As a BA, you will be expected to facilitate and conduct interviews and feedback sessions with stakeholders and developers. It requires someone who is able to get others to follow an agenda, who is able to manage conflict, and who is able to help people move towards a consensus. The BA may not be the ‘team leader’, but the function does require leadership skills and self-motivation.
5. Am I a People Person?
This the most important of the 5 questions. To be good at Business Analysis, you have to have a good rapport with people and be genuinely interested in them and their problems; in other words, you have to be a ‘people person’. Many IT developers whom I’ve met are not. Although agile practices are placing greater emphasis on teamwork and communication, programming is, at its heart, a solitary job: Once the meetings are over and the coding begins - it’s you against the machine. It is not surprising, then, that IT tends to attract people who like to spend a lot of time in their own heads. On the flip side, if you do happen to be an IT professional who has strong interpersonal skills, you possess a combination of personality traits that are not that easy to find - and that, consequently, is highly valued.
One of the services my company provides is pre-evaluation of potential BAs from – typically from a pool of candidates. As part of the process, we put a select group through team exercises, where we can observe them interacting with each other. We are looking for people who demonstrate the traits described above. The following is a direct quote from an evaluation we gave one of these candidates: “a natural team leader, projecting confidence (without displaying arrogance), strong knowledge base and a person whom I would feel very comfortable putting in front of a client.” That pretty well sums up the ideal candidate for a BA role.
If you have the right soft skills, you will find that many of the technical skills you bring over from your IT background are transferable to the BA function – if you can learn to reorient them towards the business. The truth is that many of the techniques used by BAs began as IT techniques. The difference is in timing and context. Whereas you may be familiar with a technique that you’ve used after the requirements have been captured, to design an aspect of the IT system, as a BA, you’ll often use that same technique where it is more useful – during conversations with stakeholders at the front end of a sprint or phase, where you’ll use it for requirements discovery. Skills transferable from IT include:
Deep understanding of the IT perspective.
The essence of the BA function is to facilitate communication between the business and IT. Your background in IT will make it easier for you to understand how developers think, the language they use and the problems they face – and to communicate these to the business side.
Procedural thinking/ analytical mind
Programming requires procedural thinking – the ability to break down a complex action into atomic steps (or conversely, to build a complex action from them). The same talent for analytical thinking is invaluable in the BA role as long as it can be oriented towards the analysis of the business (vs. the technical IT specifications).
Related to this last issue are the actual tools used in both roles. As a BA, I use many of the tools I used to use as a developer – but I use them in a different context. For example, I first encountered decision tables in a development context as input to an automatic code generator. As a BA, I use them upfront during meetings with stakeholders to tease out the operative business rules that lie behind the decisions they know how to make but have difficulty explaining. Similarly, on the IT side, I’ve used Entity Relationship Diagrams (ERDs) and class diagrams to design databases and software classes. I now use them during stakeholder meetings to discover structural business rules and understand business concepts.
Broader application of IT Best Practices
Beyond these specific tools, there is a great opportunity for the former developer to spread best practices, such as agile, that have originated from the development side into the broader business environment where they can have a larger and more effective impact.
If you feel you have the personality traits to become an excellent BA, and have made the decision to make the transition, where do you go next? If you’re currently working as a developer, make your intention known to Human Resources and to management. If you’re working for a large enterprise, the best and most intensive BA training can usually be found on-site – in corporate BA training classes paid for by your employer – or off-site in public classes. You should also begin reading. I’d recommend Software Requirements by Karl Wiegers and anything by Alistair Cockburn. From my own books, I’d recommend working through the case study in UML for the IT Business Analyst (Cengage), as you’ll learn to re-purpose techniques from your technical background in a BA context. As well, become part of the BA community by joining groups such as Modern Analyst’s BA Community Group and other such groups on LinkedIn as well as your local chapter of the IIBA (International Institute of Business Analysis). Seek out a mentor and begin thinking and acting like a BA – by being the one on your team to ask the business questions and volunteer for BA duties. You’ll have an especially open opportunity to do this if you work on a self-organizing agile team.
If you are weak on soft skills such as facilitation and communication, let your manager know that you want to gain experience in those areas by facilitating internal team meetings. It’s a low-risk way to improve your skills and gain confidence. And if you are not naturally a ‘business-oriented person’ consider becoming one – by running your own business. There is no better way for a budding BA to learn to empathize with business stakeholders than to literally walk in their shoes.