Author: Esther Folorunso

Esther Oluwabusayo Folorunso, MBA, CBAP Esther Oluwabusayo Folorunso is an experienced and certified business analyst currently working in the Higher Education Industry. She holds a Bachelors degree in Entrepreneurship/Business Management from the Federal University of Agriculture, Abeokuta, Nigeria and an MBA in Management Information Systems from Fort Hays State University, Kansas, USA. She presently serves on the Board of the IIBA Tampa Bay Florida Chapter and is a speaker on everything business analysis and Change. You can check her out on LinkedIn https://www.linkedin.com/in/esther-folorunso

How to Mitigate Scope Creep

Written by Esther Folorunso on July 24, 2024. Posted in Articles.

The BABOK emphasizes that scope is about defining clear boundaries. It’s about understanding what the project or solution entails and what it doesn’t. While there is no clear definition of the word scope in the BABOK, it does refer to this concept in some ways: scope modeling, solution scope, etc.

However, have you ever felt like a project kept growing in size and complexity, slowly eating away at your resources and deadlines? Well, the culprit has a name: scope creep. As a business analyst or project manager, one of the most challenging aspects of any project is ensuring effective control over scope creep.

By the way, what exactly does the word scope creep mean?

Scope creep, sometimes called requirements creep, is simply the addition of requirements, tasks, or deliverables that are usually more often than not out of the project scope. Another definition by the PMBOK explains scope creep as “adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval. This situation often results in pressure to deliver beyond the initial agreed-upon scope, as formally stated in the project charter. This uncontrolled expansion happens without corresponding adjustments to time, cost, and resources, leading to significant project overruns.

Therefore, to achieve successful project delivery, it is crucial to understand scope creep and how to mitigate it.

What are some of the causes of scope creep?

Poor scope definition and work breakdown structure (WBS): A too-broad or poorly defined scope often results in misunderstandings about project requirements and goals, steering projects off course. This ambiguity creates a high potential for scope creep. Also, if the initial project goals and deliverables are poorly defined or leave room for interpretation, changes and additions become easy to justify.
Ambiguous Project Objectives: Vague or ambiguous project goals can lead to differing interpretations and expectations among stakeholders. Setting ambitious goals that are out of reach for the allocated time and resources can lead to pressure to add features or functionalities to meet those goals, even if it strains the project.
Too Many Cooks in the Kitchen: Having an excessive number of stakeholders with decision-making power can create confusion and lead to conflicting requests that push the project beyond its original scope.
Poor stakeholder engagement: Internal disagreements among stakeholders and inadequate planning also contribute to scope creep. Simply defining the scope isn’t enough; it’s essential to consider and address stakeholder opinions and concerns to prevent scope creep.
Changing Market Conditions: Changing market conditions, such as new trends or competitive pressures, often trigger scope creep by prompting the inclusion of new project features or requirements not initially planned. This expansion can lead to the project’s scope exceeding its original boundaries, impacting timelines, budgets, and resources.
Lack of Change Control Process: The absence of a formal change control process allows for unauthorized modifications to the project scope, leading to scope creep and potentially impacting project timelines, budgets, and outcomes.

Impact of Scope Creep

Budget Overruns: Additional features or requirements will typically require more resources, leading to increased costs.
Resource Strain: Team members may become overextended, leading to burnout and decreased productivity.
Quality Compromise: Rushed or inadequately planned changes can affect the overall quality of the deliverables.
Schedule Delays: Unplanned additions to the project scope can extend the project timeline and even lead to missed deadlines.
Stakeholder Dissatisfaction: Failure to manage expectations and deliver within agreed-upon parameters can lead to dissatisfaction and a loss of trust among stakeholders.

Methods for dealing with scope creep:

A clear definition of the project scope is necessary.

All stakeholders must ensure that the scope statement is detailed and agreed upon. Before starting any project, we must establish a clear definition of the project scope and a baseline. To arrive at a clearly defined scope, the thorough gathering and documentation of requirements is the first line of defense against scope creep. Using techniques such as interviews, workshops, and surveys ensures clarity and completeness from the outset. Successful completion of this process will aid in the development of clearly defined objectives and requirements. When project goals and requirements are well defined from the beginning, it prevents misunderstandings and ensures alignment across all stakeholders. This clarity sets the foundation for a focused project scope and minimizes the likelihood of scope creep throughout the project lifecycle.

Change Management

It is crucial to implement a robust change control process. This includes having a formal process for evaluating and authorizing any changes to the project scope. Developing and enforcing a structured process for submitting, evaluating, and approving scope changes is crucial for maintaining project integrity. The criteria for assessing change requests should be part of this process, guaranteeing their alignment with the project goals and their ability to fit within the existing constraints.

Impact Analysis

Conducting impact analysis for proposed changes will help understand their effect on the project. Assessing each change request’s implications on the project’s timeline, budget, and resources will help to make informed decisions. By incorporating this, one can effectively manage scope creep and ensure projects stay on track for success.

Requirement Prioritization

Working with stakeholders to prioritize requirements and features based on business value and feasibility is important. It is important to use techniques such as MoSCoW (must have, should have, could have, won’t have) to categorize requirements and manage stakeholder expectations effectively.

Regular Reviews

It is important to regularly review project progress against the baseline or agreed-upon scope. This helps to identify and address scope deviations promptly. Weekly touchpoints or standup meetings with stakeholders based on the agreed-upon project approach could accomplish this.

Conclusion

In conclusion, scope creep is a real and ever-present threat to project success. However, the strategies mentioned above can effectively address this threat. Bear in mind that clear communication, proactive planning, and a commitment to a well-defined scope are your best weapons in the fight against scope creep. With these tools in your arsenal, you can deliver projects on time and within budget that meet the original objectives, ensuring success for both you and your stakeholders.

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!

Unpacking BA Requirements for the Blockchain Industry

Written by Esther Folorunso on May 30, 2024. Posted in Articles.

When the word blockchain is heard, cryptocurrency comes to mind next. Some need to realize that cryptocurrency is just digital money and other digital monies, such as stablecoins, exist.

What exactly does blockchain mean?

A blockchain is a shared or decentralized digital ledger of public, private, or hybrid transactions. It relies heavily on the flow of information and, in this case, the flow of transactions across many computers in a business network. This specifies that the blockchain wouldn’t have any core function without information or data. A blockchain network provides a shared, simple, single view of transactions, signifying that transparency is a strength and a win in this industry. Blockchain can potentially revolutionize how enterprises transact business and solve problems creatively.

What makes blockchain, blockchain?

The presence of a distributed ledger, which is the shared database in the network that stores the transactions; smart contracts, which are used to self-manage business contracts without the need for 3rd parties, which means they are triggered automatically when certain conditions are met; public key cryptography, which is used to identify the members in the business network; and permissions necessary to ensure that all transactions are secure, authenticated, and verifiable.

Is there a future for business analysis in this delicate but ever-evolving industry?

As business analysts, we have the strength to feature in any industry or organization and play an integral and delicate role in bridging the gap between the present and the future. Remember, business analysts need to understand that they exist to drive change while still understanding the capabilities and competencies of every shift (Read, Business Analysis, how and why I need to evolve).

Taking a deep dive into the future of business analysis in this industry, business analysts must have at least a basic understanding of how this industry works and the specific details related to the company in which they work. This will help you understand details that would help you identify the business needs and vision, understand the potential of this technology, and align it with the organization’s objectives—understanding how the industry works can be a solid requirement for benchmarking and market analysis in an event where this becomes necessary.

Secondly, the blockchain industry would thrive on the practical and right adoption and application of use cases, which is where business analysis comes in. This is necessary to identify specific use cases that highlight value to the enterprise or company and even the industry as a whole. Business analysts are crucial to determining the context in which blockchain helps attain value or change. Furthermore, this will be useful in communicating diverse use cases for blockchain technology to various audiences with differing levels of technology understanding and divergent business needs. This remains a critical gap; thus, there is a need to ensure and manage stakeholder collaboration, involvement, and engagement.

Thirdly, stakeholders, top management, process owners, and project sponsors need to understand and assess the potential value blockchain would bring, possibly a solution to an identified problem, and determine if it meets their standards. Value assessment could be performed using a SWOT analysis, feasibility studies, cost-benefit analysis, market mapping, decision analysis, modeling, etc. An analysis of possible weaknesses and challenges this technology is prone to is an essential task all business analysts must perform, some of which include security concerns, as there is a possibility that distributed ledgers and smart contracts could introduce security concerns, data access, and storage issues based on the decentralized/consensus mechanisms (proof of work), and the evolving regulatory landscape surrounding blockchain can significantly impact and influence business requirements. It is pertinent to note that regulatory requirements always prevail to avoid costs and penalties in requirement prioritization. For example, the Nigerian government initially placed a ban on cryptocurrency but lifted this ban in December 2023. In this situation, business analysts would need to assess the viability with due consideration of the unstable regulatory requirements.

Fourth, when translating business requirements, there is a need for business analysts to walk closely with the stakeholders, both internal and external, to critically understand the business requirements and correctly translate them to technical specifications through functional decomposition. Suppose the requirements are not adequately broken down into functional and non-functional requirements. In that case, being able to develop use cases might be a challenge, hence the need for a business analyst. However, it is essential to mention that the role of a business analyst extends beyond developing use cases; they also play a vital role in all the business analysis knowledge areas such as planning and monitoring, elicitation and collaboration, requirements life cycle management, requirements analysis, design definition, strategy analysis, and solution evaluation.

Conclusion

Business analysts working with blockchain must be adaptable and embrace continuous learning. There is a need to master new skills while adapting existing BA practices and their skills to this evolving technology. Armed with the knowledge that the future holds exciting possibilities for BA professionals who embrace the transformative potential of blockchain, business analysts need to take the necessary steps to ensure that they will be well-positioned to navigate this dynamic and transformative landscape.

Business Analysis: How and Why Do I Need To Evolve?

Written by Esther Folorunso on May 15, 2024. Posted in Articles.

Without a doubt, artificial intelligence (AI) is here to stay and is not going anywhere. Still, it would and has even started disrupting the status quo of many industries and organizations. Well, this is an undisputable, crucial innovation. Still, I would gladly refute Elon Musk’s’ claim that “We will have for the first time something smarter than the smartest human. It’s hard to say exactly what that moment is, but there will come a point where no job is needed” (Marr,2023).

The human factor must be considered in every career path or industry; however, professionals in every space and sphere must evolve with the dynamic and changing environment.

Why do we need to evolve?

Regarding my specialization as a Business Analyst, how and why do I need to evolve?

Recently, there has been a surge in the search for business analysts. This is not because this is a new field; instead, it has existed since the Middle of the Old Stone Age, when the ancestors were able to effectively adapt to the changing natural environment, identify their needs, problems, and opportunities, and develop solutions to make their abode livable and habitable.

What is Business Analysis?

According to the BABOK Guide V3, Business analysis enables change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change and design and describe solutions that deliver value.

The business analysis field has undergone several nomenclature changes and could be referred to by different names in different industries. Some famous names include Business systems analysis, business process analysis, functional analysis, product ownership, systems architecture, project management, usability analysis, user experience consulting, operations assessment, and technical writing.

Business Analysis Requirements

The BABOK Guide v3 views requirements as a usable representation of a need and a design as the usable requirement of a solution. Still, both concepts can be used interchangeably and primarily depend on the context of being used or adopted. Requirements need to be identified, collected, modeled, analyzed, validated, verified, traced, prioritized, managed, and maintained in the lifecycle of a project (Pre and post-project stages). Still, they are all related to a business problem that requires a solution. It could be in the form of an organizational objective that must be met, a business process that needs to be optimized, and an existing solution that needs to be improved or even retired. The BABOK guide v3 defines a Context as the circumstances that influence or are influenced and provide an understanding of a required change. This explains that requirements are broad and depend on the context, such as industry, regulation, project, weather, attitudes, behaviors, etc.

Unpacking BA requirements for Artificial Intelligence

Business analysts should not view themselves as AI experts but understand that they exist to drive change while still understanding the capabilities that AI provides and its complexities. Business analysts must see themselves as a bridge between business needs and AI capabilities.

Understanding the complexities of AI algorithms may and may not be a hard nut to crack; however, with a fundamental understanding of Natural language processing/ machine learning and knowing that most AI tools have been embedded with the critical technology to understand human language, as well as the ability to sieve through large data sets and establish a pattern or relationships, could serve as helpful information. Business Analysis could also establish broader knowledge of AI capabilities.

Also, the core of business analysis is need identification and solution generation. Both are valuable, but the most critical is correctly and efficiently identifying existing needs or problems, thus providing room for developing requirements and generating solutions.

This brings us to the question: can AI help in need identification or problem assessment? Realistically, with established data and available documentation, AI could help identify a need, but Hey, that need would be missing users’ humanity. Whatever solution is generated should provide or enhance satisfaction. However, can AI understand the complexity of the human emotion? With AI, we could develop the goals, desired outcomes, and key performance indicators (KPIs) and define roles and responsibilities, but how can usability be assessed?

With AI in business analysis requirements comes data quality, security, and privacy requirements. Every requirement generated for BA activities must answer these 3 data prongs. How reliable is the requirement gathered? If a requirement is trustworthy, it could speak to its quality. Was the requirement confirmed, verified by necessary stakeholders, and validated to align with identified needs?

To achieve these three tasks, the requirements must be specified and modeled to fit the organization’s environment with due consideration of the stakeholders involved. The modeling can be in the form of matrices or even diagrams, for which AI could be beneficial. Still, the prompts must be correct, which reflects the data quality and reliability. Using AI to generate, specify, or even model requirements (inexhaustive) would lead to data security and privacy prongs.

Privacy and security are critical issues in the professional world, not just business analysis. Before every BA task, how AI should be adopted and what data should be provided as AI prompts need to be addressed. There is a need to protect user privacy and define adequate security measures, as IT systems are susceptible to attacks. Privately owned AI tools can still be attacked; strict security and privacy rules must be strictly followed.

This is also very important as some requirements can serve as Unique selling points for a specific business or even a trade secret. In this situation, the use of AI might be optional.

Conclusion

Knowing that the Business analysis role will continue to evolve as a context evolves or dictates or even as a business dictates while putting Artificial intelligence as an addition in a context, it is recommended that the requirements generated in previous contexts be adequately managed and maintained for reuse. When done correctly, this would enhance knowledge sharing as AI could help create a central repository for past project requirements, thus making it easier for business analysts to learn from past experiences and build on existing knowledge, which could lead to overall project success.