Skip to main content

Tag: Business Analysis


Contribution as a Form of Professional Development

As practitioners of change, we are probably all acutely aware that we need to continually develop. There is always more to learn, and there are countless ways of learning it. The fact that you are reading this article now, on a business analysis website, shows that you are interested in your professional development—and kudos to you for doing so! After all, it is those that develop and keep up to date that will thrive in an increasingly competitive environment.


However, professional development is often seen as a consumption-based activity. Ask a typical BA what development activities they have undertaken recently, and they’ll likely respond by telling you about articles they’ve read, training they’ve been on, webinars they’ve watched and so forth. All of these are fantastic ways of hearing different perspectives, and it is great that there are so many cost-effective (and free) options out there.


From Consumption to Competence (Through Practice)

Yet consumption alone rarely enhances a skill. I could ‘consume’ (read) a book about how to fly a passenger jet, yet you probably wouldn’t trust me to fly one if that’s the only experience I had. In fact, even if I’d been on a one-day course and we’d done some group-work simulating flying, you’d probably argue that isn’t enough. And of course you’d be right, pilots (presumably) need lots of time in the simulator, and hours flying generally, before they are qualified to fly a commercial airliner.


Although you or I are unlikely to be racing to the cockpit of an Airbus A380 any time soon, it’s likely that we will need to learn new skills, techniques and concepts. The broader point here is that just reading about them, or watching a YouTube video about them isn’t enough. Actually using them is crucial. This is where the ‘rubber meets the road’, where even more learning happens, as the technique or concept is put into practice within a particular context. It’s often the case that some adaptations are necessary—a technique that works just fine in the classroom may need some finessing to work in the real world. And that’s just fine, deliberate and selective adaptations to the nuances of the world are precisely what we should do as analysts.




From Competence to Contribution

It’s often been said that if you want to really test your knowledge of something, try and explain it to others. There is a strong element of truth in this, as anyone who has ever created a presentation or training course will tell you! Putting together an article or presentation tends to highlight any gaps in thinking, and it’s an opportunity for reflection.

This is where contribution to the BA community can become part of a deliberate professional development strategy. Perhaps there’s a technique that you’ve mastered: that would be a fantastic topic for a ‘skills exchange’ session with your colleagues. Perhaps that would involve a short presentation and a Q&A. Your colleagues would learn about the technique, within the context of your organization and by creating the presentation (and responding to the Q&A) you’d likely learn more too.  A real win/win.

It’s possible to go even further. While we may be members of a Community of Practice within our organizations, we could also consider ourselves to be members of a global Community of Practice of interested BAs. You and I are connected via this article and this website. Others are connected through social media networks such as LinkedIn.


This provides us with the opportunity to write, blog, create videos and share experiences with people outside of our organizations too. Of course, it’s crucial not to share anything confidential or commercially sensitive, but sharing ‘how to write a user story really well’ or ‘how I used use cases to clarify complex requirements’ is unlikely to be controversial! It also has the advantage that it helps us all to connect with other interested BAs around the world. Hitting the ‘publish’ button can be scary, but the act of creating something is hugely worthwhile, and others will benefit from it.

Incidentally, if you’re reading this thinking “I’m too inexperienced to write or create anything” or “I don’t have anything worth writing about”, in my experience you are probably doing yourself a disservice. BAs tend to be somewhat modest, and everyone has an interesting professional story to tell!


Take a Blended Approach

Community contribution can be part of a blended professional development plan. Alongside consumption and practice, it can be a great way of reflecting, while also sharing experiences and building BA networks.  The nature of the blend will vary depending on practitioner, but considering the options is key.

And if you do decide to create and share something, be sure to connect with me on LinkedIn and let me know about it!


Beware Indecision Inertia: The Importance Of The “Do Nothing” Option

Organizational change can be hard. People get into routines, and convincing people to adapt the way that they work can be difficult. This is a seemingly human trait: think about how hard it can be to adapt when an icon or menu option moves in a new version of Windows. We have probably all taken a while to adapt to things like this, occasionally wishing that we could reinstate the older version of the software that we are so used to. If even a simple change like this can cause initial confusion and frustration, no wonder a larger change such as an office move or process change can be challenging.

When a potential change is being discussed, there are usually supporters and detractors. It’s important to understand the different perspectives, and work together to understand the best way forward. Yet beneath the overt support and reluctance, there are other subtler things to look out for too.  One is indecision inertia.


What is indecision inertia?

Although you might never have heard the term ‘indecision inertia’, you’ve almost certainly experienced it. Imagine a stakeholder needing to make a key decision, which is pivotal to a particular project progressing. It is a key dependency, and it is going to block progress if the decision is not made. They very reasonably ask for some data or a report in order to make the decision.

It takes some time to assimilate the information provided, but when it is played back to them (with a recommendation) rather than making a decision, they ask for more information. Or they raise a set of new questions, and more investigation is required. On the one hand, this is useful as they are helping to mitigate risks. On the other hand, it sometimes feels like the ‘can is being kicked down the road’.

Put simply: Sometimes the perception is that the least risky thing to do is nothing. In order to build a case for doing something a stakeholder might feel there needs to be watertight evidence and data. Yet, in reality, ‘watertight’ data rarely (if ever) exists. Can you say for certain the benefits that a project will bring? Or how long it’ll take? Or how much it’ll cost? Sure, these things can be estimated, based on a set of assumptions, but any certainty that is provided is entirely illusionary.


Indecision inertia occurs when the path of least resistance is doing nothing even though, when analyzed holistically, that might not be the most appropriate thing to do.

Incidentally, this pattern plays out in personal life too. People sometimes stay in jobs longer than they should (I know I did!) for fear of the ‘risk’ of applying elsewhere. People keep the same old car for too long, even when the maintenance is a nightmare, because it’s the car that they know and love…




The Role Of Holistic Analysis

This is an area where business analysis is crucial.  In many cases ‘doing nothing’ isn’t a cost-free, or risk-free option. Imagine an organization running an older, legacy, packaged IT system that is going into extended support. Soon it’ll be out of support entirely. It’s been extended and customized over the years, and the development team affectionately define it as a ‘bag of spanners’. It works, it’s reasonably reliable (at the moment), and the prospect of spending money to replace it is a hard decision to make.

Yet doing nothing will lead to increasing maintenance costs, risks that it’ll become unmaintainable, and when support eventually expires there won’t be security patches and updates which leads to an even more worrying risk. Just like a beloved old car that is kept too long and breaks down at the worst of all times leaving its passengers stranded, this beloved old IT system might implode, get hacked, or develop other issues at the worst time. And if it’s a core system, every minute it is down is probably costing significant sums…


This is a hypothetical example, but it shows the importance of understanding that doing nothing is an option, and it has costs, benefits and risks associated with it. This is important as it is a way of reframing the decision.  Often a decision is seen as:

  1. Stay as we are (which is safe, and nobody gets sacked for doing nothing)
  2. Do something risky / costly (and put the sponsor’s neck on the line if it goes wrong)


Whereas, the real decision is often

  1. Stay as we are, and things will get progressively worse, riskier and more costly (and action will need to be taken at sometime)
  2. Do something, understanding the risks and costs (but do so at a time of our choosing, rather than when some major risk event forces us to)

This is simplified, but it illustrates the point.



In summary, change is hard, and decision-making is hard. As analysts, we can help decision-makers to make informed decisions. Analyzing and presenting the ‘do nothing’ option can be part of this.


Mastering Business Analysis: 7 Strategies for Effective Internal Best Practices Sharing in Teams

Effective transmission of internal best practices within a business analysis team is crucial for fostering consistency, efficiency, and continuous improvement. As business analysts navigate complex projects and evolving client needs, harnessing collective knowledge and refining methodologies can significantly enhance outcomes. Here are some essential tips and approaches to facilitate this process:

  1. Document and Standardize Processes:

Begin by documenting existing best practices and standardizing processes. This creates a foundation for consistency and clarity within the team. Utilize tools like process maps, checklists, and templates to outline workflows, methodologies, and key deliverables. Ensure these documents are easily accessible and regularly updated as practices evolve.


  1. Establish a Knowledge Sharing Culture:

Promote a culture of knowledge sharing where team members are encouraged to contribute insights and lessons learned. Facilitate regular team meetings, workshops, or brown bag sessions focused on sharing best practices, case studies, and success stories. Encourage open dialogue and feedback to refine practices collaboratively.


  1. Mentorship and Peer Learning:

Implement a mentorship program where experienced analysts mentor junior colleagues. This not only facilitates the transfer of best practices but also promotes professional development and skill enhancement. Encourage peer learning through shadowing opportunities, joint project assignments, and cross-functional collaborations.


  1. Leverage Technology and Tools:

Utilize technology platforms and collaboration tools to facilitate knowledge sharing and practice transmission. Implement a centralized knowledge repository where team members can access resources, templates, case studies, and recorded training sessions. Leverage project management software for task management, progress tracking, and documenting lessons learned.




  1. Conduct Internal Trainings and Workshops:

Organize regular internal trainings and workshops focused on specific aspects of business analysis. Topics can range from requirement elicitation techniques to data analysis methodologies and stakeholder management strategies. Invite external experts or senior leaders to share industry insights and best practices.


  1. Encourage Continuous Learning:

Support ongoing professional development by encouraging team members to pursue certifications such as CBAP or PMI-PBA. Provide access to relevant courses, webinars, conferences, and literature. Foster a learning culture where individuals are empowered to stay updated with industry trends and emerging best practices.


  1. Measure and Improve Effectiveness:

Establish metrics to measure the effectiveness of internal best practices in transmission. Monitor key performance indicators such as project success rates, client satisfaction scores, and team productivity. Solicit feedback from team members through surveys or focus groups to identify areas for improvement.


In conclusion, transmitting internal best practices within a business analysis team requires a strategic approach focused on documentation, culture building, mentorship, technology integration, continuous learning, and performance measurement. By fostering a collaborative environment where knowledge sharing is valued and supported, organizations can enhance their capabilities, deliver superior outcomes, and drive innovation in business analysis practices.


Priming: A Powerful Tool for Business Analysts

Big doors swing on little hinges.” W. Clement Stone


Imagine walking into a store and hearing your favorite song playing in the background. Instinctively, you feel more at ease, more inclined to browse, and perhaps even to buy something. This subtle influence on your behavior is no accident—it is an example of priming at work. Now, picture leveraging this same psychological phenomenon to enhance the effectiveness of business analysis. Welcome to the world of priming, where a well-placed word or image can shape perceptions, drive engagement, and ultimately lead to more successful projects.


Historical Context of Priming


Priming, a concept rooted in psychology, began to gain traction in the 1970s. Researchers like David Meyer and Roger Schvaneveldt conducted seminal experiments demonstrating how exposure to certain stimuli could influence subsequent responses. For instance, people could respond faster to related words (like “doctor” and “nurse”) than to unrelated ones (like “doctor” and “bread”). This discovery highlighted the subconscious ways in which our minds process information, laying the groundwork for priming’s application across various fields, including business analysis. The foundational studies revealed that our brains are wired to create associative networks, meaning that exposure to a particular concept can automatically activate related concepts. This insight has been pivotal in understanding how to strategically use priming in business contexts to shape decision-making, improve stakeholder engagement, and enhance communication strategies.


Real-Life Examples of Priming


Priming has been effectively used in many real-world scenarios. For instance, in retail, stores often play specific types of music to influence customer behavior. A study by North, Hargreaves, and McKendrick (1999) found that playing French music in a wine store increased the sales of French wines, while playing German music boosted the sales of German wines. This subtle priming technique tapped into customers’ associations between the music and the product.


In another example, Priming is a powerful tool in political campaigns, frequently used to shape public opinion by consistently emphasizing particular themes or issues. Barack Obama’s “Yes We Can” and “Change We Can Believe In” slogans serve as prime examples of this strategy in action. These slogans were not just catchy phrases; they were meticulously crafted to prime voters to embrace a sense of collective empowerment and the possibility of positive change.


During Obama’s campaign, the repetitive use of these slogans created a cognitive framework that associated his candidacy with optimism, hope, and unity. Every time voters heard “Yes We Can,” they were subtly reminded of the potential for change and progress, fostering a sense of personal involvement and collective action. This emotional resonance was further reinforced through speeches, advertisements, and campaign events that consistently highlighted these themes.

The effectiveness of this priming was evident in the overwhelming support Obama received, particularly from younger voters and minority groups who felt directly addressed and included in his vision. The campaign’s ability to prime these voters to associate Obama’s candidacy with positive change and empowerment played a crucial role in his electoral success.


Personal Anecdote: Priming in Action


In my experience as a business analyst, I have found priming to be an invaluable tool in guiding stakeholders towards beneficial decisions. One notable instance was during a project aimed at selecting a software solution for case and document management.


Having previously worked with a highly effective software that streamlined operations and significantly reduced processing times, I was confident it would be the ideal choice for our current project. However, I knew that simply presenting this software as the best option might not be enough to gain stakeholder buy-in.


To prime the stakeholders, I began by sharing a series of success stories and case studies from other organizations that had successfully implemented this software. In pre-meeting materials, I included testimonials from satisfied users and highlighted measurable improvements in efficiency and accuracy. During our discussions, I subtly referenced these examples, framing our needs in a way that aligned with the strengths of the software.


As a result, when it came time to evaluate potential solutions, the stakeholders were already positively inclined towards the software I had in mind. The decision-making process was smoother, and the eventual adoption of the software led to significant improvements in our case and document management processes.


Applications of Priming in Business Analysis


Having seen how priming can effectively influence stakeholders in a real-world project, we can now explore how this technique can be systematically applied in the realm of business analysis.



The application of priming in business analysis provides a strategic advantage in enhancing stakeholder engagement, improving requirements elicitation, facilitating change management, and ensuring clear communication. By understanding how subtle cues can influence perceptions and decisions, business analysts can effectively guide project outcomes. However, the true power of priming lies in its implementation. To harness this potential, it is essential to employ specific techniques that ensure priming is both subtle and impactful, driving the desired results while maintaining ethical standards.




Implementing Priming Techniques


Now that we understand the applications of priming in business analysis, let us delve into practical strategies for effectively implementing these priming techniques in your projects. To effectively implement priming techniques, business analysts should consider the following steps:




Priming is a subtle yet powerful tool that business analysts can use to enhance their effectiveness in various aspects of their role. By understanding and strategically applying priming techniques, analysts can improve stakeholder engagement, facilitate better requirements elicitation, support change management, and enhance communication. As with any tool, the key to successful priming lies in its thoughtful and ethical application, ensuring that it serves the best interests of the project and its stakeholders. Drawing on historical insights, real-world examples, and personal experiences, business analysts can harness the power of priming to drive project success and foster positive outcomes, ultimately shaping the landscape of business analysis for the better.


A Business Analyst/Project Manager Guide to Untangling the Technical/Process Debt Mess

Usually, there would be a discussion about how only IT Business Analysts encounter technical debt as it is a Code Mess. Regardless of the industry you are working in, it may be something other than a technical debt. Still, when you are working on projects that can contribute to a similar concept or backlogs that were cleared to meet deadlines or immediate requests but weren’t cleared the right way, it is referred to as a process debt. Technical debt is specific to code, but accumulating debt from shortcuts applies to any project. Process debt refers to problems created by rushed or incomplete work outside of coding. Both technical and process debt can hinder future progress and require additional effort to resolve.


Who are the Culprits of Technical/Process Debts?

Truthfully, there isn’t one specific culprit, as fingers should be pointed at the project managers, business analysts, developers, and business stakeholders; hence, there is shared blame. By working together and understanding the long-term costs of technical/process debt, teams can make better decisions about how to build software, products, or projects.


Is Technical/Process Debt in itself a bad thing?

In some situations, technical debts can be a strategic decision to get a product or a feature out the door as quickly as possible. This might be because of need, deadlines, unclear or evolving project requirements, or even resource shortages. In this scenario, it might not be a bad thing in itself, but the key is to be aware of whatever debt accumulates and ensure a strategy to pay it down eventually. It becomes bad when it isn’t fixed and becomes the norm.


Another question would be, what is the role of Business Analysts and Project Managers in the Debt Den?

We exist as a bridge between business needs and technical realities. Why, as a bridge, most of us do not write the codes, but the individuals who do are part of our key stakeholders. We must keep them on track to slash the technical debt to its bare minimum until it is non-existent. By acknowledging that everyone can contribute to a project’s “debt,” teams can work together to prioritize quality and avoid shortcuts that create problems later.



What are some reasons for a quick fix that could lead to the accumulation of technical/process debts?

Deadlines (Realistic/Unrealistic): This is usually the primary cause of debts. Truthfully, some of these deadlines may be unrealistic, and some might even be realistic. Still, before deadlines are fixed for every task in a project, business analysts must have estimated the effort required for every feature/product/process. This estimation should have considered the complexity of such a task, possible roadblocks, stakeholders’ expectations, and risks. If this estimation isn’t done appropriately, unrealistic timelines or deadlines might be created. Another focus would be a dependence on Speed versus quality. In an ideal world with realistic deadlines and processes, there would be no need to cut corners; however, cutting corners is almost unavoidable when the pressure is on delivery by a specific date. In code writing, developers should have ample time to write clean, well-documented code that’s easy to understand and modify. But under pressure, corners are cut. Code becomes spaghetti-like, with functionality prioritized over readability and maintainability. This makes fixing bugs and adding new features later much more complex and time-consuming.


Proper time estimation and setting realistic deadlines, allocate buffer time in project schedules to account for unforeseen issues or delays, allocate dedicated technical/process debt cleanup sprints, or integrate small improvements into regular development cycles and existing business processes.


Unclear or evolving project requirements: If the requirements are ambiguous or not well-defined, this could lead to technical debts. The business analyst’s role is to ensure the requirements are clearly identified, verified, validated, and accurately prioritized based on business value and user needs (other prioritization criteria exist). Potential relationships and dependencies are also expected to be accurately identified. When this is correctly done, it ensures that the project scope is clear and the project direction is visible to all.


A proactive requirement-gathering system is recommended where early and frequent stakeholder involvement exists in the project/software development lifecycle. Different elicitation techniques can be used, but regardless of which technique is used, there must be a comprehensive understanding of needs and expectations. Also, remember that features or requests must be based on business value/user need/impact, not sentiments.


Absence of code/process reviews: This would serve as a quality check to ensure that inefficiencies and errors do not exist. Code reviews act as a safety net, catching bugs and potential issues before they become significant problems. Inexperienced developers are more likely to make mistakes that can introduce bugs into the codebase. Also, if processes aren’t documented or reviewed, they can be applied inconsistently across the team. This can lead to confusion, errors, and wasted time.


Code reviews by senior developers can catch these errors early on, preventing them from becoming more significant problems and leading to a cleaner, more maintainable codebase. This reduces bugs, improves performance, and makes future development more straightforward. For processes, reviews provide a structured way to identify bottlenecks, redundancies, and areas for improvement within workflows. This allows teams to address these issues and streamline processes.

It is essential to state that Code/Process reviews should be seen as a learning opportunity, not a blame game. A positive and collaborative review environment encourages open communication and helps team members feel comfortable asking questions.



Technical and process debt doesn’t have to be a burden. By equipping yourselves with the right tools and strategies, you, as BAs and PMs, can become champions of clean code and efficient processes. You can expose these debts, develop a plan, and work together to build a robust and sustainable foundation for your projects. Remember, a little planning today can save a lot of headaches tomorrow –  so go ahead and untangle that debt mess!