Category: Business Analysis
Dad jokes…. why we love them

Those of us are accomplished at dad jokes are accustomed to the rolling eyes, face palms and sneers that are the stock response to our creations from those who have neither the wit or the will to understand.  “Cruel and unusual punishment” they moan.  “Puns are the lowest form of humour” they cry.

But wait, there’s more.  Let’s have a closer look at the dad joke.

‘Normal’ jokes are malicious.  The basis of ‘normal’ comedy is mocking someone’s misfortune or perceived weakness, thereby diminishing them.  This recognition is nothing new, millennia ago it was propounded by Aristotle that comedy focused on personal “weaknesses and foibles”.  ‘Normal’ jokes rely on and reinforce stereotypes and prejudice.  Behind the laughter there is cruelty, and it’s personal.

Dad jokes are benign.  Their basis is exploring words and meanings and ideas and how they play nicely together.  Dad jokes celebrate collaboration and creativity.  Behind the laughter is delight.  Which is why it appears in silhouette.

Dad jokers are special people (and they don’t have to be dads) who have the skill and ability to appreciate context, to interrogate and comprehend language, ideas and meanings, to recognise and interpret patterns and trends and explore the ways in which all these things can be recombined into something new and then deliver it, all in an instant.  It’s more than an art, it’s chemistry or, more likely, alchemy.  It’s Mohammed Ali in ballet shoes and a wizard’s cloak.  These people walk amongst us.

I contend therefore that because all these marvellous qualities express themselves in the form of dad jokes, that makes dad jokes an excellent predictor of someone’s ability to think differently, to derive profound insights and imagine innovative responses to satisfy business needs.  To add value.  Who wouldn’t want someone like that in their enterprise?

So, if you’re prospecting for talent, think a bit different and ask a question like “what gives you delight?”.  If the answer is something like “dinner with friends” then demur politely and move on.  If, on the other hand, the answer is “de switch on de wall” you know you’ve got a live one.  Play your cards right and add a dad joker to your pack because, like Parmesan, they’re the gratest.

How to be influential with senior clients/stakeholders – Part 1 (A BA’s perspective)

Stakeholder management is one of the important aspects of business analysis. In this blog, I want to share my learning on how to be influential with senior clients/stakeholders as a business analyst. I usually follow the “Five Ws and One H” format, which forms the basis of “Problem Solving”, but have modified these questions to fit the topic.

  1. Who is a senior stakeholder?

Stakeholders are people, groups, vendors or organisation who participate in the projects and have different levels of involvement and interests. They also are likely to be impacted because of the project. Senior stakeholders are those who possess the highest authority in the project environment.

  1. Where to find them?

Stakeholders can be in the office, on the field, in the factory or anywhere else. When a business analyst is assigned to the project, he /she needs to identify the stakeholders and conduct stakeholder analysis. The BA has to use multiple ways to find them.

Get the list of stakeholders involved in the project from the manager or supervisor. Talk with people to find the decision-making authorities, executives, third parties and end users. Also in IT projects, there are instances where the software systems interact with other software systems and hence it becomes necessary to find who owns these and check if they are impacted by the new initiative.

A simple method to capture this information is via Stakeholder Analysis Matrix. This matrix should contain all the required details about stakeholders involved in the project. It helps in identifying senior stakeholders and estimating their levels of interest based on how it would impact them. That will in turn help to prepare before interacting with them.



  1. When to influence the senior stakeholders?

Influencing stakeholders from all levels (junior till senior) is an ongoing activity, which starts from day one of the project. Early start to this activity is always beneficial to the project.

  1. Why is it needed to influence them?

Business analysis is a critical part of a software project. In complex projects with diverse stakeholders, their different motivations might affect the delivery of the project. The BA needs to quickly resolve all types of issues and lead the way. The BA also has to keep them interested. However BAs don’t have any formal authority. Hence they must be influential enough to exercise that power informally.

  1. How to be influential with senior stakeholders?

Now to successfully influence the senior stakeholders, I follow the below techniques:

  • Communication techniques

Get to know how they want to be communicated. Some might prefer one to one meetings, emails or even phone calls. Understand which method would help. Prior to your interactions, do the homework, anticipate how the discussion is going to be and be prepared. Listen to them, take notes, analyse, be clear in communication and show willingness to act upon the points communicated by them. Ensure that desired response is received at the end from the stakeholders.

  • Focus on high-level details and avoid technical jargons

Senior stakeholders might not understand or be interested in technical details involved in the project. It is always good to give them the high level details and if they require more details then provide them. Focus on knowledge and facts.

  • Be confident and trustworthy

Be confident and show interest at all times and in all situations. There might be instances where stakeholder might come up to you and ask you for information. Hence keep your data handy. Senior people appreciate if you provide counter arguments, differ in opinions or are frank to tell that you do not have sufficient knowledge to answer right away. It makes them believe that you mean what you say. Provide evidence as to why your approach is better one if asked. Keep communications channels open, listen to what they say and be transparent. Always keep them informed on the status of the project, risks in the project, deadlines and results. This way it helps them to trust you.

  • Deliver commitments

Take responsibility of the project and stick to what has been committed. Show results to prove your competence. This shows that you care about the stakeholders and care about delivering project successfully.

  1. What are the benefits of being influential?
  • Benefits to the stakeholders: At the end of the project, stakeholders are satisfied and their requirements are implemented. They get what they need, have positive experience with project delivery and they get business value in terms of results.
  • Benefits to the business analyst: Benefits are on both personal and professional ends. It helps BA to perform better and it boosts confidence, builds credibility and leadership qualities. Further helps in professional success by creating positive relationship with the stakeholders and in creating brand value.


Finally, I would say that influencing senior people would require a planned approach and but keeping in mind “Keep it Simple and Sincere” principle doesn’t make this look so difficult.


Supriya Joshi BioSupriya has recently joined IMA as a business analyst. She is an IT professional with more than 7 years of experience and has worked on banking, automobile and healthcare domain projects. She has worked with diverse stakeholders from several countries and demonstrated good business analysis skills. She possesses good analytical, problem solving, and communication skills; always strives to deliver quality products. She likes travelling and exploring new places, cooking and spending time with family.

Think before you Agile..


What follows are my personal experiences and thoughts based on a recent contract role that I did as a Project Manager of an Agile project.

Agile has been a buzz word for quite some time now and I think it’s safe to say that it’s caught on as a fashion statement as far as project methodologies go. Nowadays most of the job adverts ask for agile experience, which I assume is a direct indicator of most projects wanting to go the agile way. I have attended an interview where the hiring manager, looking at my profile said something like ‘I feel outdated and have been thinking of going agile with my project’ which in fact was a multi-year network upgrade project, one of the last projects in the world I would think of making Agile.

My project was a long term (2 years) development project and the project team involved 7 squads working on a fortnightly sprint based development model. We followed Agile ritualistically. We breathed agile so to speak. Where I stand now, I believe that agile, in its purest form, may not be appropriate for most of the long running (multi-year) projects around.

Here are some tips I’ve picked up in my experience to-date.

Agile Must Haves:


However you try to coat it, Agile depends heavily on making documentation lean and on demand. This has some detrimental impacts in the long run. If you have a project running for a long duration, or a project which is done and dusted but the go live is delayed and the team had to be dismembered and re-convened (with different set of contractors) later . Nobody would have a clear end to end view of the architecture, requirements, design implemented, standards used etc. Thus the need to focus on the long term, even when the sprints are of 2 weekly duration. Figure out what are the documents that an operation team would require to maintain the application, or a new set of contractors would need if they were to re-engineer the solution for whatever reason. System appreciation document, Requirements document, Requirements Traceability documents to list a few. Effort needs to be set apart and planned for documentation during each iteration or at regular intervals say every 4th iteration.

User Stories:

There is an argument that user stories provide traceability in agile projects. But I haven’t found that effective. User stories would be sliced pieces of bits and pieces of functionality which are created to fit into the effort available in a sprint doable by a developer, testable by a tester. But no group of user stories would clearly depict the requirements in a clear and understandable manner in the long run. Hence go for a tool like JAMA for putting in requirements. You need to establish a clear heirarchy of functional requirements and a process as to how and under what sub requirement would a user story of a particular type and function be added. Establish the skeletal process upfront before you write your first user story. We got into a mess as the skeletal structure and the processes were not set upfront and each Scrum Master who came on board went their own way in documenting requirements.


Refactoring is the next topic that needs attention. The need to get going with the next set of requirements, along with the need to be agile and deliver at very short intervals leads to a lot of disjointed coding practices and deviations from the initial design architecture standards. More often than not you would tend to cut corners to ensure we deliver the requirements on time for the iteration. There is an unavoidable need to have a refactoring sprint planned regularly. If it could be afforded, you could have a separate squad consisting of the architect and a developer working together who pick up what has gone into the previous iteration. This squad then reviews, corrects and refactors code where required regularly. Another idea is that it can be a sprint planned for all/some of the squads every 2 months or so where they spend (say) 1 week of their time in refactoring and tidying up what has already gone in. In the second model it is imperative that some watchdog like the architect or a senior developer keep a note of what are the corners that were cut, deviations that were done, either in consultation with or whatever is found through reviews.

Work/life Balance

Agile gives a real good work life balance for employees. It’s perfect from a developer or a tester’s perspective. You commit to what you can do and go ahead do that.

It’s perfect in all the other ways that we all know about like, being able to cater to the customers immediate needs, providing a working software at regular intervals which the customer can look and feel and modify his requirements accordingly to.

Agile keeps the enthusiasm level up there or thereabouts always. It is great to have frequent sense of achievement, release of pressure, re planning and re estimation, recharging of batteries.

A Physical Agile Board:

Always have a physical agile board unless you have a big and wide screen monitor/smart board which is life like. The sense of physically moving tasks from one stage to another cannot be replaced.

Have a ‘graveyard’ where you would move the completed tasks and stories. If possible get different squads to use different colours or may be different colours for different types of tasks (one for dev and one for Test maybe) this would help to create some nice and creative patterns on the graveyard which through a time-lapse video would make us all proud as a work of art and provide an ongoing sense of achievement.



Agile Pitfalls:


Agile is for teams involving good to expert level developers and testers. New members must be drafted in gradually, and drafted in only when then they are very close to 100% ramped up. New team members or those who are not well versed with the technology in-use, liquidate the effectiveness of agile methodology. When such a member joins, for quite a few iterations at least the team’s velocity estimates go low and so does the productivity. Agile teams are like bullet trains. You can’t attach a cargo van at the end of it and expect it to run at the same pace. It can be very detrimental. This is one of the reasons I feel, why agile is not good for a long running project where you, more often than not, would have churn and developers and testers move in and out frequently or in organizations where resources are pulled into different projects or operational activities at various times.

In an agile project the timeline OR the scope can remain constant. Both cannot. Due to the inherent nature of agile, scope gets swapped in and out, functionality requirements keep changing everything moves around between iterations.

Stakeholder Management:

Ensure that you engage and educate the stakeholders on what they are getting into. It so happened in one of my projects that towards the end of the project, (mainly due to some internal politics between the concerned departments within the company) the agility and its rules were forgotten and the business put a wooden foot forward saying the scope is non-negotiable and so is the time-to-market. Hence all the remaining scope in the backlog became indispensable. This same backlog was always thought of as a priority list (as it should be) which would be tackled in the right order and it would be the product owners responsibility too to ensure that he gets the most important features in the time remaining till the project go live. So now we had a situation where the product owner who was all agile and happy to add in and chop off requirements as he wished suddenly went backstage and there we had the business director standing on top of us with a ‘my way or highway’ attitude.

Agile Non-Negotiables:

What the above scenario teaches me is that even though we run an agile project, do 2 things. Educate / coach your stakeholders on how agile works and what it means, with respect to overall scope and timelines. Secondly, keep yourselves covered by always probing and getting as much requirements (even at a high level) listed upfront, high level planning poker done for all the requirements , add your buffers and keep the forecast with respect to scope also highlighted in your weekly reports. What I mean is, if there was a new chunk of work that came in to the backlog which suddenly became priority for the product owner, show clearly by means of trend graphs how the overall scope has increased and how that impacts timelines if all the requirements were to be completed.

You might say “we all do that!” Yes but still ensure that every week the view of how the overall picture looks with regards to scope is provided to all stakeholders. The product owner shouldn’t be able to shrug off the accountability of getting what is required in the time that is allocated.

Particular mention needs to be made of some product owners who, on seeing that the velocity of the squad is really good, tries to get it in more thrills and frills wherein that high velocity should be used to tackle the important features first and then return to the thrills if time permits. Keep a tab on the prioritization thought process of your product owner at all times.

Squad Management:

When you have multiple agile squads, each runs with a different velocity of course as each squad has a different way of story pointing and different levels of productivity too. Thus, when preparing project plans you need to ensure that you take a reasonable and probable average velocity into account. If you are starting a new project with new squads who haven’t been together before then all you can do is a reasonable guess I believe. But ensure that you do a most likely, worst case, best case analysis and provide forecasts accordingly.

Agile Pitfalls: The next bit, though a bit sensitive to talk about is worth the mention. Agile teams can grow to be very sentimental and moody. They need to be nurtured with care and love. At times all that care and love can create a monster. They become a collective unit and conspire to put blockers where there are workarounds, give out considerably higher story points than is appropriate, can decide to delay a few activities so that the stretch goal needn’t be brought in to the current iteration even though there is spare time available, give out higher story points and ensure that there is enough buffer to compensate for less than 100% effort. All this can happen even when teams aren’t facing new challenges regularly. So one way of tackling this is to do a close monitoring of the work that each member is doing, even at the risk of going against one of the concepts of Agile which is to have full belief in the team and its capabilities. You could do this being less conspicuous by catching up with team members offline and not in a formal team meeting environment or at her or his desk. You might even want to swap team members without affecting the structure too much at the same time. This reduces chances of such behavioural patterns developing.


Other things to consider.



We once had a security hackathon which was basically a 2 hour period wherein all the developers and testers attached the application and tried to crack into secure data. It did bring out quite a few security vulnerabilities, which are part of the often forgotten and often non-written non-functional requirements. This is a highly recommended practice.

Getting the squads together to engage in some agile games is another way of making it fun at work while indulging in some team building activities. You’ll get a truckload of games online which you could try out for your squads. Most of my team really liked whenever we had them.



Backlog is very volatile bucket so how do you actually depict anything meaningful to the stakeholders on how and when would something be done. A visual representation of what feature was developed when we had what we called a Sprint pipeline plot. Which was an excel sheet which showed blocks of work that would be covered by each squad and around when.

Also consider how useful this would be in a situation where you have 5+ squads (like we had 7) and you have a year-long project to run. Scope might keep getting added to a particular module and might get culled in some others, but with this sort of visibility you can easily look at options on how you could rejig and make everything fit more like a jigsaw puzzle. It would be much easier discussion with senior stakeholders too, in order to explain how agile you are and how confident you still are in meeting the project goals.


Screen Shot 2016-08-11 at 11.41.50 AM
We did an EVM (Earned Value Management) plot. Keeping in mind various aspects like the most likely, worst case and best case average velocity of the sum of all squads.Financial management

The total scope that we had to cover in terms of story points. This was based on the initial very high level planning poker where we got the total number of story points that needed to be covered. Here again we did a best and worst case. It’s imperative that we do a reality check a few times through the project to revalidate the total number of story points that forms the scope. Please ensure that when you do this exercise you do take into account time that needs to be spent on stuff other than development, testing and deployment, I can think of research work, tech spikes, maybe a cloud deployment etc. which may not be part of a module you work in, may not be part of the discussions and work that you do with the product owner but are necessary for the software to be released. I could write a separate blog on how to prepare EVM graphs for an agile project. That’s an elaborate topic in itself. May be I will do it one of these days and provide some examples on how to go about it.


By: Nikhil Prabhakar 

Nikhil is a project manager who has recently joined IMA who comes with a management background in Applications development, Service Delivery, Transformations and Transitions and has worked with a diverse set of customers across the globe.
He has just been promoted from ‘forever wanting to write about his experiences’ to ‘having his first blog published’. Nikhil is an avid soccer fan and is’nt shy in proclaiming his support for Arsenal FC

How to Utilise your Time on the Bench

Screen Shot 2016-03-29 at 10.59.45 AMBy Saira Cheema.  Saira makes her blogging debut today for IMA, please make her feel welcome…Saira, a rather new entry in IMA, is a Business Analyst and a nerd in disguise. Books, current affairs, cricket and sarcasm are her go to areas of interest. Other than being awkward, she loves writing, reading fiction and watching gruesome TV shows.


We all know that for any Business Analyst, the time at the bench can be hard. (For those not aware of the term, “bench” or “Beach” is a commonly used term for Consultants who are in-between or yet to be allocated to projects but still employed by a Professional Services company) You have been working non-stop at a client’s site for months and as soon as you are back at the bench, you start wondering, “What do I do now?”.  It can be difficult to find the best way to utilise your time,  I have had that struggle, which is why I wanted to share my experience. It has not only been a way to fill my time but for me, therapeutic as well.

1. Blog about it:
Being a Business Analyst, you get to work with different clients with diverse work environments and you always get to learn something new. Among the BAs I had the privilege of working with, there is so much to learn which you end up sharing over coffee or the weekly lunch but it is never written down or made part of the bigger conversation. So when you are on the bench with some time on your hands, sharing your experience should be the first thing you do.
How do I share my experience, you ask? Company blog is the best way to become part of the mainstream conversation. The starting point for writing a blog is always difficult but once you overcome your fear, writing is the best way to de-stress. All you have to do is gather your thoughts and create a blog-post. It doesn’t necessarily have to be about your experience at a particular client. It can also be a generic post about the skills you utilised or the new ones you acquired.

2. Catch up on what you missed:
Time on the bench is not the time to slack or go rusty. It is the best time to invest in acquiring new skills. While I was working on the client site quite recently, I missed out on many company events but I also missed out on some of the training sessions conducted.
How did I catch up? I dug out the material on the Intranet and went through the sessions. If I didn’t understand some of the newer concepts, folks on the World Wide Web were always there to help. This is also a good time to go back to the basics and re-evaluate your skills with spending some time reading on what you already know. Open BABOK or do a training on PRINCE2.

3. Lend a helping hand:
One thing I have learned with IMA is that being a consultant here is not the same as being a consultant anywhere else. You are always part of the bigger picture like any other permanent employee and you get to know that there is a lot of work going on behind the scenes.
What can you do to help out? Documentation is normally one of the strongest skills a BA has and there are so many internal projects you can lend some help in. Need a case study for the website? Give out your advice on what your experience was and how you helped out in the process. The Administration officer is swamped with work? Help out by setting up company meetings in the office and sending out invites. Account Manager has to give presentation to a client? Give advice on how to make the presentation a perfect blend of sales and technical.

As I said, being on the bench can be boring but it is also the best time for you to learn as you don’t have deadlines to meet or constantly engage with stakeholders. This is your own time and you can get the best out of it by investing in your skills. Go for it!

IMA Melbourne Christmas party circa 2015.

A few weeks back the majority of the Melbourne staff and our partners attended our annual Christmas party. This years venue “The old Melbourne Gaol” (or OMG as some of our people called it) did not disappoint.

For what was a great night, we celebrated the year just finishing, celebrated the anticipation of 2016 which promises to be huge, and some amazing milestones of 3-5 and 10 years service.

Here is a little snapshot (well a few snap shots to be honest) of the evening..

The importance of Stakeholder engagement


Pablo Arias

Pablo is a seasoned professional who is focused on delivering high quality outcomes for his clients. His strength is his ability to quickly develop relationships with stakeholders at all levels to find a way through complex issues. Highly qualified with an MBA and over 14 years’ experience in consulting and project management, Pablo has helped his clients in numerous industries including Education, Health, Defence, Telecomms and Finance achieve their business and project objectives. When he is not immersed in solving his client’s most pressing challenges, Pablo enjoys spending time with his children and cooking a variety of delicious cakes and desserts which makes him valued team member for morning tea. He also doesn’t mind a long drive along the coast every now and again.

Recently, I completed two successful projects which involved delivering new technology to the Classroom – but were they really ‘successful’? The business case was approved, the budget and plan agreed with the sponsors, vendors and resources were engaged and there was enthusiasm from the project team about the innovation that would be delivered to students and staff as a result of this new technology.

As the project progressed through design, procurement and implementation, some key business decisions were required from key stakeholders. Fortnightly meetings were held with the steering committee to present project status, issues, risks and to gain input for the key business decisions. What quickly became evident to our project team was a gap in stakeholder engagement and management. What we really needed was a Change Manager – someone who could articulate the project requirements and business benefits and communicate these with the stakeholders to gain their buy-in.

Fortunately, the project was finally able to secure two additional resources to assist with these important change management activities but they were only engaged towards during the end of the delivery phase of the project. As a result, this meant the business deployment activities were delivered in a less effective manner. For example, although training was planned and organised, attendance and participation was poor due to a lack of awareness of the project and its purpose, objectives and benefits.

Similarly, finding willing participants for the trial period proved to be difficult and resulted in some classrooms with new technology that nobody used.

So back to my original question – would you consider these projects to be successful?

Ultimately – the answer has to be no. The expected business benefits of such technology could not be realised if no-one is using the technology.

So what are the lessons learnt from these project examples? Here are my key take-aways;

  1. Don’t underestimate the importance of change management requirements in any technology project. Secure a Change Manager and ensure they are part of the entire project journey.
  2. Stakeholder communication and engagement is absolutely critical to the success of a project. This requires regular communication with all stakeholder groups throughout the entire project duration in order to take them on the journey as well. They need to become the ‘owners’ of the business benefits.
  3. Identify some willing project ‘champions’ from the business – these are stakeholders who act as ambassadors for the projects, who are willing to trial the technology and greatly assist in raising awareness amongst their peers.
  4. Regularly publish and promote project communications to provide broader stakeholder groups with key messages about the project, its goals and benefits – another key method to raise awareness.
  5. Finally, it is critical to understand the ‘impact’ of technology on current business processes and workflows. Develop strategies to assist business users to embrace the technology including training, help-guides and on-site support.

So can a Project Manager also undertake the role of Change Manager in such projects? Given the right experience and size of the project, I don’t see why not.

I would definitely be keen to hear from other Project Managers and Change Managers who have encountered similar experiences and hear how you managed stakeholder engagement.

Kathy has only recently joined the team here at IMA.  Kathy comes to us as a very experienced Business Analyst, mostly specialising in the Superannuation field.  However, within her 27 years in this industry she has travelled across many area’s including Operations, Investments, Accounting and IT. Kathy experiences within this industry have led her to land in the Business Analyst space, where she is passionate about streamlining and improving business processes. Kathy is a great communicator with strong presentation skills.  These attributes assist to make Kathy a great trainer able to deliver training material clearly. When Kathy isn’t working, she loves to travel with her young family.  Trips overseas and spending time with her family are things she looks forward to.  But when at home, you will find Kath in her kitchen cooking up a storm, another one of her passions

Kathy has only recently joined the team here at IMA. Kathy comes to us as a very experienced Business Analyst, mostly specialising in the Superannuation field. However, within her 27 years in this industry she has travelled across many area’s including Operations, Investments, Accounting and IT.
Kathy experiences within this industry have led her to land in the Business Analyst space, where she is passionate about streamlining and improving business processes.
Kathy is a great communicator with strong presentation skills. These attributes assist to make Kathy a great trainer able to deliver training material clearly.
When Kathy isn’t working, she loves to travel with her young family. Trips overseas and spending time with her family are things she looks forward to. But when at home, you will find Kath in her kitchen cooking up a storm, another one of her passions

The wonderful world of a Business Analyst or a “BA”– sounds cool, huh???

Well it is a pretty cool gig!

For example, when you catch up with old school friends, who you have not seen in a while, and they say “So what do you do for a living these days?” and you very cool and very casually say “Oh I’m a Business Analyst”. They will look impressed right? That’s because we are an impressive bunch!

So What Is It You REALLY Do?

Well that’s generally the next question, because even though our title implies we “analyse business”, it doesn’t give too much away.

Do we keep an eye on the stock exchange and international market movements? No that would be an Investment Analyst

Do we keep an eye on interest rates and its impact on the property market and trends? No that would be a Property Analyst

Do we analyse consumer spending to see where and when consumers are spending their hard earned dollars?? No that would probably be a Retail Analyst

So where does that leave us??? Well a business analyst would work in any and all of the above fields, just not performing those particular roles. As a business analyst, we tend to align ourselves with the business and more closely the operations of the business.

Our role is to understand an operational requirement (the business wants to…) and convert this into reality – we call it a “solution”!

How do we do this?? Well we have the skills required to

  • Understand “business” speak, (yes we speak business!) à know what it is that the business really needs (as opposed to what they may tell you they want)
  • Translate this “business” speak into “technical” speak so a software developer can understand what they need to achieve, if any new development is required as part of the solution
  • Before we head off into full development of the solution, we confirm back to the business that we have understood their requirements (what they want).
  • This can be done via a number of different ways, depending on what the business prefers. But generally a “Business Requirement Document” is written which will explain the total solution, and any peripherals such as reporting or outputs and screen designs
  • Once the business reviews these “requirements” and agree “yes this is what we want” then we are on a winner and we can move forward with the solution

But that is NOT where our story ends – no sir!

Through the development phase, any question or issues that may arise (hopefully these will be few and far between), the business analyst will be the first port of call. They will need to make decisions as to who or how these issues can be resolved.

Once any required development has been completed, it has to be tested (we call it user testing).

Again depending on the organisation’s set up, the business analyst may have written a test plan to test that the solution works as per the requirement document. They may even have to execute the test plan. Otherwise the business analyst will liaise with the test team to write a test plan for the test team to execute.

But wait there is STILL more! Now that the business analyst has designed a solution, tested the solution works, it now time to roll it out and train the masses (the end users).

Training people is an important part of a business analyst’s role. There is no point in developing something, if no one knows how to use it.

In all of the above reading, there is one KEY aspect, which you may have noted. It is the business analyst’s ability to COMMUNICATE.

We COMMUNICATE with the business to help them ACHIVE their goals

We COMMUNICATE with developers and other key stakeholders to help the business ACHIVE their goals

We COMMUNICATE with the end users so they know how to use the solution

See it’s all about COMMUNICATION, and a good business analyst has great communication skills.

So What Have You Done to Become a Business Analyst?

Another popular question and there are a number of ways a person can become a Business Analyst

Some of us can rise through the ranks from Business Operations to Subject Matter Expert (SME) to business analysts

Others may have gone down the path of completing any number of “business analyst” bases courses, studying delivery methodologies such as “Agile” or “Waterfall” or “SCRUM” or others. They learn the art of listening, understanding and communicating.

Sometimes a good business analyst is discovered in the work place when given the opportunity to work on a project. They shine with their ability to simplify a process, or understand a complex issue and help design a solid solution.

So Why Would You Be a BA?

Well in my view being a BA gives you a wide range of activities, which keeps our job diverse and interesting.

Unlike many others, we have touch points in business (incorporating business operations and administration), IT, Accounting, Project Management, Training, Testing. We don’t necessarily “specialise” in any ONE field, but we have good broad knowledge of many fields. This knowledge allows us to pull together other the specialists fields to achieve one common goal (yes this is where the communications come into play again).

Having this diversity means there is never a dull moment. However the best thing is the sense of achievement when you deliver a solution and your client says “Wow! That’s pretty cool!”

Managing Difficult Stakeholders
Mansoor is a committed IT professional with more than 5 years of diverse experience in the industry. He brings knowledge and skills developed working directly on complex projects in sectors such as banking, communications and transportation. He is a skilled communicator, adept at solving difficult problems quickly, and is occasionally punny.   He enjoys go-karting, making bad puns and spending time with his wife and two children.

Mansoor is a committed IT professional with more than 5 years of diverse experience in the industry. He brings knowledge and skills developed working directly on complex projects in sectors such as banking, communications and transportation. He is a skilled communicator, adept at solving difficult problems quickly, and is occasionally punny.
He enjoys go-karting, making bad puns and spending time with his wife and two children.

Get out of bed in the morning, and it is likely you will meet people who challenge you. It is an inevitability of human interaction that you will encounter individuals who actively or obliquely oppose you, have differing ideas, methods, and motivations than you, or who simply hold a contrary view.

Some of these people you can and will ignore, others you will engage with, argue with or discuss and share your views with. Stakeholders, especially difficult ones, present a unique challenge in that you must reconcile any number of differences whilst maintaining an ongoing working relationship in order for you to successfully deliver the required outcome.

Difficult stakeholder behaviour not only causes stress and a poor working environment, but given the success of a project will often hinge on a consultant’s ability to overcome this hurdle, effectively managing challenging stakeholders is a crucial skill for any Business Analyst or Project Manager.

Ideally, a difficult stakeholder interaction results in a stakeholder who is your advocate. This is not always achievable, but it is certainly possible; and there are techniques to achieve the best outcome for the circumstances.


Frequently overlooked but extremely effective, reflecting on your actions and behaviour and an as-objective-as-possible analysis of your own contribution to the circumstances is a veteran consultant’s first stop. Acknowledging and apologising for an error you have made can often be all that is required to overcome an obstacle and re-build rapport with your stakeholder. It also demonstrates that you will put the success of the project before your ego.

Acknowledging even a minor issue gives permission to a stakeholder to also acknowledge any of their mistakes, sets a conciliatory tone, and raises the standard of subsequent communications. It is not the easiest technique, but it is often the simplest and most effective.


The key to effective stakeholder management is an understanding of what is motivating their actions and behaviours.

Lacking a clear understanding of why a stakeholder is behaving the way they are can lead to a breakdown of the working relationship. Even worse, the temptation to make negative assumptions about their motivations leads down a rabbit-hole of misunderstanding, miscommunication and usually, project failure.

Understanding a person’s motivations does not involve laying them down on a couch and delving deep into their psyche, but rather developing a clear contextual appreciation of their role within their organisational structure, the nature of their working relationships, and a willingness to set aside personality conflicts to achieve the goals you need to accomplish. The most effective way to understand a stakeholder’s motivations is…


Effectively communicating with a difficult stakeholder means listening far more than speaking. In fact, you should aim to spend 80-90 percent of the time listening rather than speaking. It is essential that you are clear in your mind about the purpose of your interaction and what you are hoping to achieve. Whether your aim is to understand or elicit a requirement, resolve a dispute, clarify objectives, or any other purpose, the key is to be prepared with relevant and incisive questions that will keep focus on the issue at hand.

Difficult stakeholders often feel they have not been heard or understood, and their behaviour reflects this frustration. The behaviour may manifest itself as passive aggression, lack of motivation, poor attitude, disengagement, and sometimes outright opposition. Meeting with and discussing the stakeholders objections can lead to a clearer understanding of their position and motivation. Asking relevant questions demonstrates your interest in their viewpoint and a genuine willingness to understand it.

Aside from direct communication, casual observation of the stakeholder’s interactions with others can often provide valuable contextual understanding of their viewpoint. This does not suggest stalking them in the hallway or eavesdropping on their conversations, but rather where possible and practical, attending their presentations, meetings, and formal & informal workplace interactions.

Effective communication, especially in the early stages of a project can materially alter the outcome, and can potentially make the difference between a project’s success or failure.


Certain people seem to deal with difficult individuals better than others, and their success stems largely from the mindset with which they approach this challenge – they regard it as an opportunity.

Their mindset is to not see the behaviour as a problem, but rather an opportunity to engage and achieve a mutually beneficial result; to convert an opponent into an ally. They recognise that the stakeholder, despite seemingly opposing them, has the same goal – the success of the project.

By simply acknowledging that both parties are on the same side and desire the same outcome, but differ on the way to accomplish it, they change the tone of the dialogue. It can then be easier to examine the differences and evaluate the merits of each view.


My 7-year-old son enjoys dragging his 8-month-old sister down the stairs. He has difficulty understanding why this is not a good idea, mainly because she giggles the whole way down. From his perspective, this is a win-win situation with both parties gaining mutual benefit.

Sometimes it is easier to consider things from the other person’s perspective rather than have them see it from yours. So rather than dragging him down the stairs to show him my perspective, I explained that although he has the best of intentions, the potential risks outweigh the perceived benefits.

A willingness to set aside your position on an issue and consider it from a stakeholder’s demonstrates not just a maturity of thought, but also that you are willing to critically assess all perspectives, not just your own.


Getting Your Idea Past Management
Rena Leigh

Rena’ is an experienced Senior Business Analyst with extensive experience across multiple industries. Rena is always open to a chat and is happy to give her opinion on anything.

As a BA and a consultant to business, I have been privileged to be part of the birth and implementation of many concepts and ideas. I’ve also watched many good and valuable ideas die. Some die rapidly, some die slowly.  Usually they die while trying to work their way through the often complex and cumbersome “gates” that companies use to try to weed out more valuable proposals from less valuable ones.

Some people seem to be consistently heard.  Some people are consistently ignored.  Many find their ideas seem to get randomly accepted or rejected and they have no idea why.

I have often spent some of my time within companies mentoring managers and staff on how to get their idea taken seriously.  There is one key principle that I believe is more important than any other when trying to sell one’s idea.

Make sure everyone wins.

I was once mentoring a university student and we talked about the time she brought up a problem to her manager.  This problem had been embedded within the managers department for at least two years before this eager young woman laid it on her manager’s desk and asked for approval to address it.

The manager said no.  My mentee didn’t understand why.  So we talked about how she had approached her manager with the problem, how she presented it and how she presented the proposed solution.

It was clear to me that the solution, as presented, was not a win situation for the manager.  It didn’t take into account the fact that this manager had had an unrecognised and unaddressed major problem in her area for two years…and now was supposed to bring this to the attention of her manager while highlighting the fact that someone else had found it.

This was not going to look good.  In fact, depending on the problem, it might look very bad indeed.

At the end of the day, we are all concerned about our jobs.  We want to be seen as productive, proactive, competent and worth our companies time and money as an investment that will produce returns.  We want to be seen as valuable.  The last thing we want to be seen as is incompetent, stupid or inattentive to our job.

Identifying problems or opportunities is a good thing.  Not many of us are in a position, however, to maximise solving that problem or leveraging off that opportunity by ourselves.  We need a team of people to get it off the ground.  Part of that team need to be the managers above us.  Those difficult people who always seem far to ready to say “no” to us.  But these managers are not our enemies.  They’re part of our team and we need to see them that way.  We need to make a conscious effort to factor into our solution what will help them be part of a winning team.

So…make sure there’s something in it for them.  Don’t try to be a glory hog.  Share the love.  Understand their position.  Recognise that what you’ve found might just be a way to make you both (or all, depending on how many layers you need to go through) look good in the eyes of the company.

Make it a win-win-win.  Win for you, win for the managers who need to approve it, win for the company.  Because if you leave out the middle win, you aren’t likely to get any of the others either.

Jed makes his mark.

2014 saw IMA take a brave and new step in our evolution.  In response to a well written email, a better follow up phone call and a sensational effort on one of our assessment tests, IMA decided to take the plunge and bring on an intern for a semester.  It’s a new thing for us, as we as an organisation traditionally only give our clients experienced professionals to solve their problems.  The timing however, was perfect.

Armed with an attitude worth killing for and an appetite for learning and growth, Jed joined us as an intern to work on our internal systems which were going through an overhaul.

Here is Jed’s account of his time with us

JedMy name is Jed. I worked as a business analyst intern in IMA where I had a wonderful time with colleagues. During my internship, I worked on a “leave application system requirements gathering and refining” project as well as an online timesheet project. It was a very exciting experience to work in the “real world” and make real impact. Raja Vaidyanathan supervised me on the “leave application requirements gathering and refining” project when I started my internship in IMA. He let me take the lead of the project and fully supported me. I feel I have been trusted and motivated to deliver high quality project results. Other colleagues in IMA are also very friendly and supportive with experience from various industries and I learned a lot from them. IMA definitely has a most professional team and provides best workplace environment for its employees.

I improved my communication skills, requirements gathering skills, business analysis skills through this internship and become more confident to work in an Australian workplace.

My time in IMA also consists of several “first time experience”.


  • My first time to work in a consulting firm;
  • My first time to have morning coffee with colleagues;
  • I had my first beer in Australia on IMA’s monthly meeting;
  • I first time had a chocolate that tastes like Chinese herb medicine and I still can’t remember its name;
  • I first time played bowling at IMA’s social club;
  • I will have my first Xmas party in Melbourne;


And more…

Thanks IMA for offering this amazing adventure to me! It is not only about taking challenges and keep improving professional skills but also enriching life experience.

We would like to publicly thank Jed for his time and efforts with us and wish him all the best in his future endeavours