Tag: Risk

Transition Requirements – The Key To Adoption

Written by Tiffany Wiley on September 18, 2024. Posted in Articles.

The key to adoption. Don’t forget the obvious.

As a Business Analyst at heart, requirements play a part in my everyday life. Much to the annoyance of those closest to me, I’m wired to think of everyday activities in terms of requirements 😊

However, transition requirements are sometimes elusive, even to those of us with a couple of decades of experience. But – they are the key to adoption!

A quick little story time…

When my daughter went to her first school, we spent weeks preparing; we got her a backpack and matching lunchbox, new school clothes, new shoes, and a sleeping mat, and we even planned a lunch and snack menu! I even read the school handbook, multiple times! At 3.5 years old; she’s spent her entire life with just the three of us. She never went to a daycare, so this was her first school-like experience, and we were ALL excited! Nevertheless, in all that preparation, we neglected a key piece of information – WE would not stay with her at school.

As we unbuckled her, with excitement beaming from her eyes, she stated “Mommy, we are all going to have so much fun today!”. At that moment, I knew I missed a key piece of information that was going to completely change how the rest of the day went. Oops! And it did…she was distraught! Then I was too!

In all my functional preparation, I neglected to operationalize her new school experience. I completely missed considering my key stakeholder’s transition!

Even with over 18 years of requirements management experience, I forgot the obvious. This is your call to action – don’t forget the obvious!

What are transition requirements?

Transition Requirements (or Transitional Requirements) are like NFRs (Non-Functional Requirements), in that they are often missed in the design and development processes.

As the name suggests, these are the requirements that will ensure a successful transition from the current to the future state.

Why are they important?

Without a plan to transition from the current state to the future state, adoption will surely slow if not stop entirely. You as the Product/Project Manager may be excited about this change, but excitement alone doesn’t cross the finish line!

A transition (or migration) will likely impact other business units and processes. For example, a customer may need to upgrade a current licensing agreement to transition to a new solution. Do you wait to transition them? What is the impact of waiting? Are there legal implications? Is additional training required?

Additionally, on the softer side of a transition, is understanding the change curve. Especially when it comes to process or culture-related changes, transitions can be very difficult. People are creatures of comfort – i.e., creatures of familiarity. And change is unfamiliar….it is uncomfortable. Having a good understanding of change management can help ensure there aren’t gaps in the transition plan and requirements.

How does that tie into overall value?

Value is realized when the solution is adopted. A single transition requirement alone does not generally provide quantitative value. However, the overall plan and requirements’ existence provides a qualitative value by ensuring a successful transition can happen – leading to better adoption and ultimate solution value realization.

Technique for gathering Transition Requirements?

Transition requirements should only be defined once the final solution is known. It doesn’t need to be fully implemented, but it must be known.

Unlike functional (or stakeholder) requirements, these are typically not willingly disclosed or stated by the business or users. Because of this, my favorite technique to start with is questions; to elicit information to then derive the transition requirements from that information. It is important to have a listing of questions to start with, but also being present in the discussion will help uncover additional questions to minimize gaps and assumptions.

Some sample questions and follow-up questions are noted below:

Are there any user skill gaps that need to be filled to operationalize the new solution?
- Is this a training we can provide, or do we need outside help?
- What is the cost of this effort?
- What type of internal messaging is required?
Is there any data that needs to be migrated from the current to the future system?
- If so, how can that be done?
- Migrate all data? Only some data?
- Does data need to be transformed?
- How long to prep? Migrate? Validate?
- Are there any regulatory requirements for transmitting the data?
- What are the ideal timelines?
What is required to retire the current solution?
- Can it just be turned off/eliminated?
  - Do user accounts need to be deactivated?
- Is there a cost associated with terminating (or ending early)?
- Will data need to be deleted? Can it (contractually) be deleted?
What processes need to change to implement the new solution?
- How/when will this process change happen?
- How/when will it be communicated?

Additionally, think about the differences between the two solutions/states. Then identify some questions, even if they seem silly, to help elicit information. Listed below are a couple of sample projects with a few starting questions:

Set your launch up for success by not forgetting the obvious – Transition Requirements.

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

Written by Esther Folorunso on June 19, 2024. Posted in Articles.

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.

Solution:

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.

Solution:

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.

Solution:

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.

Conclusion

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

Written by Adrian Reed on January 10, 2024. Posted in Articles.

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

Written by Christelle Govender on December 20, 2023. Posted in Articles.

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.

Conclusion:

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

Written by Chintan Jariwala on July 2, 2020. Posted in Articles.

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:

Pros:

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.

Cons:

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.

Conclusion

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.