Skip to main content

Tag: Risk


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!


Editing for Success: Applying Hollywood Wisdom to Projects

I’ve long been a believer that a good movie is 90 – 120 minutes long. Sure, there’s the occasional storyline that can keep my attention for longer than that, but generally speaking after a couple of hours I’m getting pretty restless. One of the reasons I rarely go to the movie theater these days is that films seem to be getting longer and longer, and unlike watching at home I can’t press ‘pause’ in the theater!


It turns out that I’m not alone. Celebrated film director Sir Ridley Scott, who directed films including Alien, Gladiator and Blade Runner recently spoke about the ‘bum ache’ (‘butt ache’) factor of films. Too long sitting down and apparently movie-goers will get uncomfortable, and this is something that he takes account of in his editing. A classic case of “less is more”, and a director being empathetic to his audience.


Less Is More

I know virtually nothing about movie production, but I’m guessing that it is probably technically easier to produce and distribute a long film than it was, say, 40 years ago. I gather that in the past films came on multiple spools, all of which had to be physically duplicated and distributed. Apparently since the early 2000s, films have been distributed digitally to theaters. With fewer constraints, you could have a ten hour film if you really wanted it.

Yet being unconstrained isn’t a good thing. I’m guessing few people are lining up to watch the ten hour film “Paint Drying” (which is a real film, but was a protest against the cost of censorship). The fact that it’s possible to do something because a constraint is removed doesn’t mean that it’s actually a good thing to do. Sometimes constraints can foster creativity.


From Hollywood To Projects: Time As A Constraint

I’m guessing that you probably don’t work on Hollywood movies, but there’s a direct parallel with projects here. After all, a Hollywood movie brings together a collection of specialists for a period of time to create a deliverable that will generate benefits for its sponsor… which sounds strongly analogous to a project!

One constraint that you and I probably come up against frequently is time.  There never seems to be enough, and time is always the thing being squeezed. It is easy to become somewhat jaded to this, and either just accept the deadline (but implicitly know that it’ll never be met) or rally against it.

Certainly, calling out unrealistic deadlines is an important thing to do. Yet, in some circumstances an alternative approach is to test the constraint and see how it balances against others.




Let’s imagine that a sponsor has set a deadline of 1st January for the launch of a product or project deliverable. We feel there’s a risk that this is an arbitrary deadline, so we start to tactfully ask “if it was two weeks later, but 10% cheaper, would that be beneficial?”.  If the sponsor says “Absolutely, yes!” then we know that they probably value the budget over a fixed deadline.  Or we might ask “How about we delivered it on that date, but the quality was lower?”. They might answer “No! Absolutely not”, at which point we know quality is paramount. We might ask these types of questions about all sorts of things, including scope, timeframe, deliverables, style of delivery and so on.

What we’re doing here is understanding which are hard constraints that genuinely can’t change (or, there would be a significantly negative impact of breaching) and those that can potentially bend. Not achieving regulatory compliance by a mandated date, where the regulator is strict and there’s a significant fine, might be an example of a hard deadline. It’s better to pay more now, and dedicate more resources to ensure compliance. Other things which appear to be constraints might be more malleable.


Product Management and Business Analysis as Film Editing

Once the hard constraints are identified, it’s tempting to be deflated. Rarely are we dealing with a situation where there’s too much time, resources and budget. Yet another way of looking at this is to think about the movie theater experience… sometimes less is more. Much as an ambitious scriptwriter might have a scene cut because it’s not essential to the story (or the location is too expensive to hire), we can ‘edit’ elements of a project or product in or out.

This probably sounds obvious, I mean scoping and prioritization is crucial. Yet, too often scoping and prioritization are carried out somewhat in isolation. It’s easy to end up with an incoherent set of features, or (worse) to find that only the person who shouts the loudest gets what they want…


If we reframe this as a process of ‘editing’, then we are keeping in mind the coherence and desirability of the product as a whole. Imagine asking twenty people for their favorite ever scenes in movies. Perhaps one mentions a scene from Wargames, another from the Barbie movie, another from Love Actually and so on.  Now imagine making a film out of these ‘best’ scenes… it wouldn’t make any sense.  The same can be true of a product too. If the features aren’t coherent it can become somewhat of a Frankenstein’s monster that is difficult to use and doesn’t really serve any single purpose well.

Another thing about editing is that it involves compromises and making difficult decisions. I’d guess actors probably hate having their biggest scene cut. And script writers probably hate being told they can’t have that on-location scene in Barbados due to budgetary cuts. But, it is the editing that means that the film makes money (achieves its financial outcomes) while also providing an experience that the consumer wants (achieving another of its core purposes).


I suspect this is a balance that we all tread on our projects and products, and bringing it to the fore and making tradeoffs transparently and purposefully can only be a good thing!


Baking Success: Unveiling the Sweet Similarities Between a Small Baking Business and a Business Analyst’s Role

Embarking on my journey as a baker just under two years ago, I have joyfully crafted birthday cakes, engagement cakes, baby shower confections, and more. Recently, I faced a culinary challenge that pushed my skills to new heights. This cake wasn’t just another creation; it was a test of my abilities, filled with many “firsts” that transformed my approach to baking. From applying a white chocolate ganache coat to mastering a full fondant covering, I encountered unexpected hurdles that required constant adaptation.

As I navigated the complexities of this ambitious project, I realized that I was implementing a form of agility in motion. Much like a Business Analyst (BA) adapts to evolving project requirements, I found myself breaking down the cake-making process into smaller, manageable increments. Baking the layers two days in advance and freezing them, preparing the frosting a day ahead, and meticulously crafting fondant toppers became a harmonious dance of preparation and adaptation.

This experience illuminated the surprising parallels between my role as a baker and the responsibilities of a Business Analyst. In both worlds, adaptability is the key ingredient for success, allowing for the seamless integration of unexpected challenges into the creative process. Let’s delve into the sweet symphony of similarities between managing a small baking business and excelling as a Business Analyst.


  • Adaptability is the Key Ingredient:

In the world of baking and business analysis, adaptability is the secret sauce that leads to success. Just as a baker adjusts a recipe based on available ingredients or customer preferences, a BA must be flexible in adapting to changing project requirements, client expectations, and market dynamics. Both roles demand a skillful balance between structure and spontaneity, ensuring the final product meets or exceeds expectations.


  • Customer-Centric Approach:

In both professions, understanding and satisfying the customer’s needs are paramount. Bakers pay close attention to customer preferences, dietary restrictions, and flavor profiles. Similarly, a BA delves deep into understanding the client’s business requirements, ensuring that the solutions provided align with the client’s goals. Both roles involve effective communication and active listening to create a product or solution that leaves the customer delighted.


  • Requirements Gathering as a Recipe:

Much like developing a baking recipe, a Business Analyst must meticulously gather and document requirements. In baking, this involves understanding the desired flavour, texture, and appearance of the final product. In the business world, requirements gathering entails collaborating with stakeholders to determine the functionalities, features, and constraints of a project. Both processes require attention to detail, precision, and a knack for turning abstract ideas into concrete plans.


  • Project Management:

Running a small baking business involves managing resources, timelines, and deliverables – much like a BA managing a project. Both roles require effective project management skills to ensure that everything runs smoothly, from planning and preparation to execution and delivery. Time management, coordination, and the ability to troubleshoot issues are crucial aspects that bridge the gap between these seemingly diverse professions.


  • Continuous Improvement:

In the dynamic worlds of baking and business analysis, there is always room for improvement. Bakers experiment with new recipes, techniques, and ingredients to stay ahead of trends and meet evolving customer tastes. Similarly, BAs must stay informed about industry best practices, emerging technologies, and changing market trends to provide innovative and effective solutions.


  • Understanding Global Trends and Market Dynamics:

In the ever-evolving landscapes of both baking and business analysis, awareness of global trends is paramount. For a baker, staying attuned to culinary trends such as the rise of veganism or the demand for gluten-free options is crucial. Just as a baker adapts recipes to cater to changing dietary preferences, a Business Analyst must be cognizant of market trends and technological advancements. Incorporating global trends into business strategies ensures relevance and competitiveness. The ability to anticipate shifts in consumer preferences aligns closely with a BA’s role in recognizing emerging market demands, enabling both to proactively adjust their approaches for sustained success.




  • Risk Management:

The concept of risk is inherent in both the realms of baking and business analysis. In the baking business, the risk might involve experimenting with a new flavor combination or trying out an innovative baking technique. Similarly, in business analysis, the risks could range from technological uncertainties to unforeseen changes in project scope. Both roles require a keen sense of risk management – identifying potential challenges, developing contingency plans, and mitigating risks to ensure a successful outcome. Whether it’s predicting how a cake batter will rise or foreseeing potential project obstacles, effective risk management is the insurance policy for success in both fields.


  • Visual Thinking:

In the world of baking, the visual appeal is as important as the taste. Creating aesthetically pleasing cakes involves a form of visual thinking, where bakers conceptualize designs, color schemes, and decorations. Similarly, Business Analysts employ visual thinking when crafting process flowcharts, diagrams, and user interface designs. Both professions rely on the ability to translate abstract ideas into tangible visual representations that effectively communicate complex concepts. Whether it’s envisioning an elaborate cake decoration or designing a user-friendly interface, visual thinking is a powerful tool that enhances creativity and clarity in both baking and business analysis.



Despite appearing dissimilar at first glance, both industries align on fundamental concepts such as versatility, prioritizing customers’ needs, meticulousness, and a steadfast dedication towards enhancing one’s performance constantly.


Just as a baker meticulously crafts a cake, considering evolving culinary trends and customer preferences, a Business Analyst navigates the complex landscape of project requirements, global market dynamics, and technological shifts. The parallels are striking – both professions demand a delicate balance between structure and spontaneity, transforming challenges into opportunities and setbacks into stepping stones.

The recipe for success transcends the boundaries of specific industries. The amalgamation of these skills – adaptability, customer-centricity, attention to detail, continuous improvement, global awareness, risk management, and visual thinking – creates a masterful blend that resonates across baking and business analysis. Whether you’re sculpting a delectable cake or orchestrating a cutting-edge business solution, the essence of success lies in skilfully blending the right ingredients to create a masterpiece that not only delights but endures in the ever-changing landscapes of taste and technology.

A way to manage Risks in Requirement Management Lifecycle Risk Champions

As a Business Analyst, you would already have worked with Risks; and if you have not, it is a miracle.

Assumptions are essential part of requirements and Business Analysts’ one of primary tasks is Requirement Management which included eliciting, analysing and documenting requirements.

What is a Risk:

Risk describes an occurrence or uncertain event which may influence the ability to achieve the goal.

In Requirement Analysis, Business Analyst, with the help of other stakeholders, determines the risks. Being said that, it is very critical how a business analyst manages risks to achieve the business goal.

In principal, the project team and stakeholders need to take informed decisions based on the information at hand to achieve the project goal. Hence, it becomes essential to understand what the risk is all about and ways to manage them. Risks, positive or negative, should be understood thoroughly to define the level of tolerance, and to identify the responses.

There is another way to manage the risk by Business Analyst is to engage with Risk Champions.

A way to manage Risks: Collaborate with a Risk Champion:

Risk Champion is a person who by expertise or authority champions an aspect of the risk management process, but who is not the risk owner. They are a bridge to engage the business, to take care of aspects of the risk management process on behalf of the business and to ensure that business is aware about the impact, positive or negative, to the business. They are equipped/impowered to find the impediments available in the different part of the organization which in return helps to identify the strategy to manage the risk. They need to be involved when the business needs to take any big/small decision impacting multiple department of the organization. Many companies assign Risk Champions for each major functional area of the business, including sales, marketing, operations, HR, IT, legal/regulatory and the financial departments. These champions can be charged with assessing risk both in their individual functional areas and as a cross-functional team.

Apart from Risk Champion, there will be a Risk Owner who will be a Business Analyst, Project Manager, Product Owner, or a Process Owner generally.

Risk Champions should have most of following traits to be successful:

  • Risk coordinator: Ability to work with multi-functional team for risk management
  • Understands risk: A good understanding of risk management concepts, principles, and processes. They need to be aware of the compliance requirements as well if the industry is working under regulations.
  • Experts: Expert in their function / process in which they are champions.
  • Good soft skills: Strong leadership and motivational qualities; and Good communication skills. Good analytical skills to assist with the analysis of root causes to risk problems.
  • Influencers: Ability to influence the decision makers to keep the organizational needs above all. They need to work very closely with the head of the function they represent.


How it all works:

  • Business Analyst with the help of Project Manager, Product Owner, or a Process Owner identifies the risks.
  • The Business Analyst, who is now the risk owner, engages with the Risk Champion to determine the way to handle the risks.
  • Business Analyst and the Risk Champion will work with cross functional Risk Champions & stakeholders, in a workshop, to identify the severity and probability of the risk occurrence and any budget requirement.
  • In this workshop, they will decide the action items for all the stakeholders to take to prepare & execute all the risk management plan.
  • The Risk Champion, who is working with the Business Analyst, will keep an eye on the progress on all the action items along with the business analyst.
  • Another session of workshop will be arranged to take the decision using the identified the severity and probability of the risk occurrence and budget requirements.
  • After the decision has been identified, the plan will be sent to the executive body for approval.
  • The executive body will evaluate the plan and the champions are required to clarify all the questions raised by the executive body.
  • After the approval, the plan will be ready to be executed under the supervision of the Risk Champion, who will keep all other Risk Champions in the loop.

Factors to consider:


  • They will provide direct and honest feedback keeping organizational needs in mind.
  • A well-designed approach which can work in any cross functional venture.
  • Everyone is aware about the plan and the progress.
  • Risk Champions will make sure that project team does not deviate from the approved plan.


  • The process is time consuming.
  • Requires resources with specific skills and dedicated time.
  • Business Analyst will have to invest his/her time in the Risk management activities along with the Risk Champion.
  • It can reduce the importance of risk champions if he/she does not have required skillset.


The inclusion of Risk Champions has worked in our organization and it has made our decision-making process robust.

However, in my opinion, not all organization needs nor can afford this structure.

This framework will work greatly in those organizations which are working under any regulatory body including, but not limited to, banks, broking companies, financial services companies.

Risk Championship framework can also work outside the project i.e in the BAU environment with great results.

As a Business Analyst, I always believe that the effect of risk management on any project is underestimated. However, at the end, it is just a framework which is as good as any framework if it has resources with required skills and experience.

In my opinion, Risk Champions are not rival to Business Analyst as they are essential Business Analyst themselves with expertise in Risk management.

The Disruptive Business Analyst

Disrupt. By definition disrupt means “to prevent something, especially a system, process, or event, from continuing as usual or as expected.

To throw into confusion, throw into disorder, throw into disarray, cause confusion/turmoil in, play havoc with.”

From a technology perspective, it refers to “any enhanced or completely new technology that replaces and disrupts an existing technology, rendering it obsolete. It is designed to succeed similar technology that is already in use. Disruptive technology applies to hardware, software, networks and combined technologies.”

So, what about the disruptive business analyst? I work mostly with tech projects so for me the disruptive business analyst is working with what we used to call bleeding edge technology on new projects for anxiously awaiting project clients leading tech teams on exciting and sometimes dangerous new project adventures. End users and subject matter experts are awaiting a nearly ready solution during user acceptance testing (UAT) and at implementation rollout to the end user community with this creative solution. Hopefully the tech team… and the business analyst… along with the project manager have provided a workable solution that meets their requirements dead on. This can be difficult, of course, anytime you’re moving to a new technology that you’ve not worked with before, the project team hasn’t worked with before, the client has never likely seen or used it before, and that may not have been implemented in the client’s type of industry before. You’re on the edge… you’re going where no one has gone before (well, with that customer in that industry anyway…).

Stay abreast of new technologies

Since the business analyst is usually at least the liaison between the tech team and the project manager on a technical project – and is sometimes even the co-lead or sole lead of the project – then it is obviously critical that he remain relevant and current of ongoing tech trends and new technology. Through regular training, reading and research, this is easy to do and in terms of products, technology and security, conferences and the exhibit rooms at these conferences are a great way to get first hand face to face knowledge and deep dive information from the individuals creating and introducing this technology. Conferences like CES (Consumer Electronics Show), Interop and Black Hat will have briefings, demonstrations and training available for attendees and they can be fascinating ways to enhance your knowledge level.


Ensure the right team assembled for the tech implementation

A new technology is being used on our high-tech solution for the project client. Is our project team up for the challenge? Is the learning curve reasonable or do we need part time or full-time consulting or new resources on the project? That initial assessment must be made or at least assisted by the business analyst. And this determination needs to be made – and not lightly – as close to the kickoff of a new project as possible so as not to result in a timeframe extension, budget overrun and big, long learning curve for newly on boarded project resources.

Oversee customer training and education on the tech solution and the technology used

The project manager works closely with the customer throughout the engagement. There is no question about that. But on many tech projects the business analyst works even closer and for extended periods of time. On one of my projects, the customer wanted a change order to have the business analyst work full time onsite for the remainder of the project resulting in a $100k+ change order with a high profit margin added to the project. I was happy to oblige, of course. Especially in cases like this one, the business analyst is going to have the best feel for the customer’s ability to understand and eventually take over a new high-tech solution. Should education and training take place? Often the answer is yes. Yet another change order revenue opportunity! Win-win. This is an area where the business analyst will usually need to play point on – be aware.

Ensure Cybersecurity measures are taken

While hackers know that organizations using legacy technology are the easiest target, most get more challenge and enjoyment from cracking new technology. If you are embarking on new tech adventures on your project, know that you may be a target, especially if you are handling any sensitive data with this new tech angle. So, know that if you’re utilizing bleeding edge technology, you are on the hackers’ radar – you are a likely target will need to take proper measures. It’s best to address this possibility early in the planning phases while assessing risks and the skill set needed for your project team.

Summary / call for input

Are you a disruptive business analyst? Most business analysts working with startups and large corporations entering new areas of delivery are going to be utilizing new and cutting-edge technology. The key is to be fully engaged, ensure the client understands – at least to some degree – the new technology and that you have the right talent designing and implementing the project solution. Oh, and that the end user community knows what they are getting. It never hurts to make sure that your project manager is on board with the same technical understanding. Project management is sometimes project management across all complexities and industries… but I’ve always felt that a technical background is critical to the tech project manager’s success in managing tech projects. Sounds logical – and it is logical. I’ve seen it with my own eyes. I’ve got the tech background myself, but I’ve seen many colleagues fail miserably on technical projects because of a lack of tech background and understanding.

Readers – what’s your take on this list and these areas of emphasis? What would you add to it or change about? Do you agree with it? Tell us about a project you played a key role on using new technology and how you managed issues and risks – if there were any – in the implementation. Was it smooth? A success? A failure? Let’s share and discuss.