By search term

By author
  • Skills

Five Questions

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.

Benefits of a transition from IT to business analysis

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:

  • Ability to leverage experience: Experience comes as a blessing and a curse if you are an IT developer. As you build your experience, coming up behind you are programmers who are more up-to-date on the latest technologies, who work faster and are willing to work longer. A BA role gives you a chance to leverage the skills you’ve accumulated over the years in a profession that highly values experience and maturity over technical wizardry.
  • Burnout: You spend years getting paid to ‘play’ and enjoy ever-novel technical challenges – when one day you just don’t feel the love anymore. Most developers experience this – as did I. Business Analysis begins to look inviting, in particular because of the next point.
  • Business Analysis is less technically taxing than programming: I expect this to raise hackles, but I have done both and the simple truth is that it is not as technically difficult to write a use case or elaborate a user story as it is to write the code that implements it. There is still novelty, complexity and creativity – but you find it more in the new business areas you are exposed to rather than in technical challenges.
  • Natural evolution: As you work your way up a career on the IT side, you naturally evolve towards a focus on higher-levels of abstraction that move you further from the technical perspective and closer towards the business. The next logical step is Business Analysis – the function that bridges those two worlds.
  • Desire to be in a new/growing profession: When I entered the profession, there were few BAs out there, no BA organization, and no formally recognized role. Like many people in IT development, I was naturally drawn towards areas that were new, where there was a green field to be innovative – and Business Analysis fit the bill. While that is not as much the case now as it was then, the field is still young and growing – and even still in its infancy in many countries.
  • The financial motivator (i.e., money): As you get closer to the side that generates wealth, your pay rate rises accordingly. Generally speaking, ‘business’ BAs make more than ‘IT’ BAs, who make more than technical analysts and programmers. The argument is particularly compelling if you are a programmer working offshore, and the BA jobs you are seeking are located in North America or Europe. (See Job Security below.)
  • Job Security: Programming is increasingly being seen as a commodity service that can be outsourced to the lowest bidder – thanks, in part, to globalization and the easy ability today to source programming resources from across the globe. Business Analysis, on the other hand, requires close contact between the BA and business stakeholders; this typically means that the BA function must be performed locally, and that it will probably remain resistant to off-shoring for the foreseeable future. (The fear of having your job outsourced is not exclusive to North America and Europe, by the way; I’ve heard developers in India express the same fears. There always seems to be a cheaper source of programmers somewhere.)
  • Path to Emigration: I’ve met and trained many developers offshore, whose prime motivation was the opportunity the BA profession provided to work onshore. And it’s worked out well for many of those I’ve met who have made the move.

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.

What are the challenges?

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:

5 questions you should ask yourself, before you start transitioning from IT development into Business Analysis:

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.

Transferable skills

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.

Final words and suggestions

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.

Comments (3)

  • From: Chandrakanth Bendarapu
  • Date: 19. September 2014

Subject: Great article with valuable information

Many thanks for posting this information.
I could clearly correlate myself to be in the transition phase from a developer to BA.
I am working in a German OEM as an interface between the business and vendor with respect to software delivery (meeting the engineering requirements). All these days, i was really confused... Am i doing BA activities? how much do i fit for a BA position with the following activities i perform in my role...

  1. Understanding the business process
  2. Requirements managements,
  3. Negotiations with stakeholders
  4. Bridging the differences between development team and customer's mindset 5. Customer oriented approach of proposing business solutions in sync with development team

This articles makes it clear to me now. Can you help me in showing me a structured approach in enhancing my role and establishing a career as a BA.

Thanks again for making me realize all the above.
Mercedes Benz India.

  • From: Simon Hajjar
  • Date: 15. March 2014

Awesome article. Do you have more information or advice around IT outsourcing, pros and cons etc. I could search on the internet for this and I have but I respect your opinions and advice as you are someone I look up to.

As a BA in IT it can be a struggle to get senior IT management to see the true value of a the BA. I've often been told by peers "you need to get out of IT"

Thank you,


Hi Simon
Thanks for your feedback. Yes, I could summarize my advice on the question of outsourcing by quoting my father-in-law: "Cheap is expensive." Not always, with respect to outsourcing, but often enough to be a concern. In a nutshell, you have to think long-term, - and not focus only on the short-term savings. You should ask yourself if the development is more of a one-time thing or will require continual updates. If you will be making frequent changes, and the outsourcing being considered is to a low bidder offshore, then I would not recommend this option, as there is no stable development team to rely on. You need a team that understands the system well and that is able to make changes and, therefore, you are better off relying either on in-house development, or outsourcing to a company/team that you have (or plan to have) a long-term relationship with.

If we are talking about a simple job without significant updates later, then outsourcing can pay off. You will need to closely supervise and direct the development effort more than you might if you were working with seasoned developers who know your business well, in order to make up for the communication difficulties that arise when developers are offshore, but the savings can make this worthwhile in cases like this. Just know that you'll need to watch over the project very carefully in order to ensure you get what you want.

  • H
Author's profile
Related Articles
Bridging communication gaps with a Feature Tree

How product manager and development team found a common language and understanding

Read Article
The Business Analysis Center of Excellence

How to build a strong foundation for business analysis and requirements engineering inside a company

Read Article
Stable? Fragile? Agile! Attractive but reasonable

New opportunities for requirements engineers & challenges within the organization

Read Article