Tag: Change Management

Beyond Frameworks: Agile Insights from a BA’s Odyssey

Written by Afaq Qazi on April 18, 2024. Posted in Articles.

Reflecting on my journey from a Junior Business Analyst to a seasoned Business Analyst and eventually evolving into a role where Business Analysis and Product Management intersect, I’ve had the privilege to contribute to organizations as diverse as Boeing, Rolls-Royce, and EPAM, alongside navigating the unique challenges of smaller entities.

This path, spanning over 13 years and multiple domains, has equipped me with a deep understanding of Business Analysis from the grassroots, teaching me the crucial balance between adhering to frameworks and embracing the agility necessary for today’s dynamic business environment. This narrative is an exploration of that journey, emphasizing the transition from rigid methodologies to agile adaptability, and the critical importance of customer focus and stakeholder management.

In the early stages of my career, the allure of frameworks was undeniable. They presented a structured way of understanding Business Analysis and Product Management, offering a semblance of control and predictability in the chaotic realm of project management.

However, as I progressed, the limitations of these frameworks became increasingly apparent. The real-world application of Business Analysis goes beyond the confines of any framework. It demands an acute awareness of the shifting business landscape and the ability to think on one’s feet—a blend of deep analytical thinking and pragmatic street smarts.

This evolution in perspective was mirrored in my approach to project management. Initially, my focus was on mastering the technical aspects: understanding the ‘what’ and ‘why’ to navigate towards solutions and create value for users. Yet, I quickly learned that the essence of effective Business Analysis lies in the ability to communicate, adapt, and understand the broader business context—skills that are foundational yet flourish only with experience and deliberate practice.

Communication emerged as the cornerstone of my professional development. The capacity to engage with a diverse set of stakeholders—customers, engineers, designers, and executives—and synthesize their insights is paramount. It’s a skill that goes beyond mere articulation; it’s about understanding the audience, choosing the right words, and effectively conveying complex ideas in a manner that resonates.

This skill set has been instrumental in navigating the complexities of projects, ensuring alignment across teams, and driving towards common goals with clarity and purpose.

As I embraced the agile methodology, the importance of flexibility became glaringly evident. Agile is not just a buzzword; it’s a mindset that values adaptability, customer-centricity, and continuous improvement.

It challenged me to think differently about project management, to be more iterative in my approach, and to prioritize direct feedback loops with stakeholders and customers. This agility has been crucial in climbing the project ladder, allowing for rapid pivots and adjustments in response to new insights or changing market dynamics.

Customer focus and stakeholder management have been the bedrock of my growth as a Business Analyst. Recognizing the criticality of these aspects, I’ve dedicated myself to becoming adept at navigating the complex web of stakeholder relationships and ensuring that the voice of the customer is always at the forefront of decision-making. This has involved honing my ability to manage expectations, articulate value propositions clearly, and foster an environment of trust and collaboration.

In retrospect, the journey from adhering strictly to frameworks to adopting a more flexible, agile approach has been transformative. It has taught me that while frameworks provide valuable guidance, the essence of Business Analysis and Product Management lies in the ability to adapt, communicate effectively, and maintain a relentless focus on the customer and business objectives.

As I continue to navigate this ever-evolving landscape, these insights will remain central to my approach, guiding my decisions and actions in the pursuit of creating meaningful, impactful solutions.

An End and a Beginning: A Practical Application of Business Analysis Techniques

Written by Nosa Adagbasa on January 24, 2024. Posted in Articles.

Business analysis is not just an IT-related profession; it is a profession that has expression in every facet of life, and hence one of the reasons why you should take pride in this profession if you are a business analyst or why you should aspire to be one.

The tools and techniques are transferable skills that have applications or expressions in other aspects of life.

I briefly discuss two as the curtains close in 2023.

Lessons learnt
MoSCoW

Have you taken time to reflect on 2023 and list out the lessons learned? Making use of this powerful BA technique is one of the ways you can identify what went well in 2023, what didn’t go well, where you made mistakes, and what you can put in place to avoid those mistakes in 2024.

Note that this does not only apply to the current year or next year; rather, it is a set of business analysis techniques that can be applied to different seasons and phases of life.

Lessons learnt

What went well?

A1: Why did it go well?

B: What didn’t go well?

B1: Why did it not go well?

C: What mistakes did I make?

D: What can I do to rectify or avoid the mistake in the future?

E: What are my achievements?

F: What lessons have I learned?

2. MoSCoW

Based on your analysis above and the lessons learned, you can draw up your plan for the future (the next phase).

A: What must be done?

B: What should be done?

C: What COULD be done

D: What won’t be done

This can also be seen as a positive thing to do in the new year and a negative thing to avoid.

While new year resolutions may be difficult for some, using the above BA skills should help you plan your coming year with hopefully less pressure.

Concluding Remarks

As a phase comes to an end and you look forward to a new beginning, take time to consider these business analysis techniques, take time to reflect on the lessons learned, and plan the MoSCow for the future.

The Dilemma of Test Scripts

Written by Kimberly Yoss on May 31, 2023. Posted in Articles.

Mention software testing to 10 people in IT and you will get several different responses.

“That’s what QA is for.”

“Unit testing covers what we need.”

“What do we need to test for? The application works fine!”

“We’re Agile. We don’t need to test.”

“The client’s not banging down my door – so all is good.”

“No, we can’t release to UAT yet. I’m only halfway through writing the test scripts.”

“I don’t have time to test.”

“I don’t know how to test this. I’ll need some guidelines.”

“That’s not in the budget.”

If you work as a BA in an IT department, you have likely heard all of these retorts – sometimes even from those who should know better.

It is also a trigger that can lead down a deep rabbit hole of shortcuts and excuses, with the ultimate result being sloppy code, error-prone software, and possibly tons of rework post-release. Not only impacting you and your team, but also potentially leaving your company with very unhappy customers.

Software testing has several variations, all meant to ensure that the customer is happy in the end and that fewer issues, or bugs come back to haunt the product development team. Unit testing and smoke-testing are two of the most common types of testing. Unit testing is ordinarily done by the engineer as a part of coding and is meant to test the individual functions of the various components of the specific software. Smoke-testing is done after the release of the code into production. It serves as a means to make sure that nothing has been broken by the new code. Another critical form of testing is called regression testing, which focuses on how the new code works with the existing code. Regression testing requires additional planning and visibility of enhancements between releases.

At a bare minimum, unit testing and smoke-testing are essential. They are cheap and easy and require a minimal amount of effort.

The real testing, however, comes in the form of functional tests and acceptance tests. This is how you connect the code that is created by the engineers with the business needs of the customers and the real-life use of the application.

Functional tests validate that the newly designed process aligns with the requirements that were provided to the development team. Functional testing is best performed by either the business analyst or the QA analyst. A distinct benefit is gained here when functional tests are designed and completed by someone who is familiar with both the application and the enhancement requirements. Here is a tip: well written requirements and an experienced QA analyst are your best friend for stellar results!

Acceptance tests (also known as User Acceptance Testing or UAT) validate that the finished product aligns with the needs of the business user. This type of testing allows the end user to touch-and-feel the new process to make sure that it will correctly address the defined business need. An end user is also looking to make sure that the workflow is not made worse. At the end of the day, the user still has a job to do!

A well-designed set of test scripts is the most efficient way to track results, and to facilitate tracing the functionality back to the requirements. A plethora of applications exist that do this for you! Many of these applications can also run the test scripts in an automated fashion, which works great for regression testing. If I have access to an experienced QA analyst, I leave the decision up to that person. I simply provide rock-solid requirements and expectations and make myself available for questions.

That said, I am a big advocate of DIY.

If I am running functional tests myself, I create test scripts the old-fashioned way: Excel spreadsheets. The perception is that this takes too much time. Yes. It can be tedious. However, if you consider that good test scripts can also be used for system and user documentation – a bonus for start-ups – it is an essential task, regardless of the effort. They can be maintained and re-used.

Put your user hat on and give it a try!

Begin with a few basic columns:

Who is the user? What role is the user filling while performing this task?

What is being tested? Describe the function in simple terms.

What are the exact steps to get the desired result?

What is supposed to happen when the steps are completed?

What actually happened when the steps were completed? Ideally, you would want this to be the same as what was supposed to happen. Many times, it is not.

Did the test Pass or Fail?

Add more context for tracking and tracing back to the requirements, like test IDs for each test and date tracking to facilitate repeat testing. Add a column for additional comments so that the person who is running through the tests can add additional observations about what was experienced during the test.

In short, product quality drives customer satisfaction. Complete and consistent testing and retesting is one of the best ways to drive customer satisfaction with new products and product enhancements. It’s well worth your time and effort.

Happy testing!

Do Your Organization’s Transformation Initiatives Align?

Written by Nicola Myers on May 4, 2023. Posted in Articles.

Organizations are increasingly looking to improve their processes and additionally embrace digital transformation to leverage their capabilities. Two frameworks that have gained traction in this regard are the Business Process Maturity Model (BPMM) by the Object Management Group (OMG) and the Digital Transformation Framework (DTF) used by Laserfiche. While both frameworks aim to enhance efficiency and effectiveness, they differ in their approach. In this blog post, we will explore what these frameworks are and how they align (or not) so that you will be able to be wiser when choosing transformation frameworks.

The Business Process Maturity Model (BPMM) is a framework that assists organizations in assessing their business processes against five levels of maturity. It assists in identifying areas for improvement and developing a roadmap for process improvement. It also provides a common language for process redesign and some government organizations require a certain level to consider an organization’s tender submission.

The BPMM consists of five levels of process maturity, which are as follows:

Initial: This level represents an ad hoc approach to process management, where processes are informal. The success of the work depends on the employee who just gets the job done and this results in inconsistent outcomes.

Managed: At this level, basic processes are documented, and some level of standardization and consistency is achieved but this is sporadic and will depend on the management of that unit. The benefits of process improvement begin to seep in, for example reducing rework.

Standardized: This level represents a structured approach to process management, where end-to-end processes are well-defined and documented, thus removing the silo effect. This includes process measures and using best practices to define processes.

Predictable: At this level, process performance is measured and monitored. The processes are automated and stable with predictable results. Knowledge is gained when quantitatively managing processes, for example, optimally achieving capacity.

Innovating: This level represents a proactive organization with a strong culture of process change while implementing and planning continuous improvement. This results in finding new and better ways to provide value to the client.

The other focus organizations have, is to achieve their digital transformation goals and drive innovation in the digital age. This has a larger scope than just processes. “Laserfiche is the leading global provider of intelligent content management and business process automation. The Laserfiche® platform enables organizations in more than 80 countries to transform into digital businesses”. Their Digital Transformation Model (DTM) provides a structured framework for content digitization and process automation through to data-driven innovation.

The Digital Transformation Model consists of five levels, which are as follows:

Digitize Documents: Converting paper documents to electronic documents. This leads to cost savings and less chance of lost data, but there is no central repository and so the information is fragmented, especially between silos.

Organize Content: Categorizing and organizing documents into a central repository to increase accessibility and improve security. For example, invoices are filed under the accounts payable folder. This organizing of documents assists in streamlining the work being done and supports compliance. It should be noted that at this point the document storage is standardized but the work being done is not yet standardized.

Automate Processes: Eliminating inefficient processes such as paper forms and replacing them with standardized electronic forms. Automation leads to improved productivity, accountability, and capacity but still lacks visibility because the automation is sporadic, and the end-to-end processes have limited visibility.

Streamline Processes: Automating common processes (not just forms) to increase visibility and gain business insights, for example, to optimize staffing levels. At the end of this phase, the company will be able to implement streamlined processes easily, have access to complete and consistent data, measure progress using tools like dashboards and visualizations, and involve customers in the process.

Transform Processes: Align processes with business needs, make plans for the future, and become more proactive. Data-driven innovation can be done by leveraging analytics and the organization will be more agile in changing markets.

The frameworks align by focusing on enhancing process efficiency and effectiveness. There is a strong emphasis on the role of technology (such as a central repository) as well as process management concepts (such as end-to-end processes and standardized processes). They both have five levels to compare.

However, there is a major concern with implementing these transformation frameworks and that is when to automate processes and when to standardize them. In the process maturity model framework above, the standardization starts at level 2 and is completed at level 3, while process automation takes place at level 4. In Laserfiche’s digital transformation framework, automation takes place at level 3 and processes are only improved and standardized at level 4. This means by following both transformation initiatives at the same time, the organization is working at cross-purposes, and it is likely that both projects will fail, resulting in a very costly mistake for the organization.

It should also be noted that with the digital transformation framework, there is no initial level where the company is purely paper based. It would make sense that before the digitalization level, there would be a level where the organization is haphazard about its use of technology. This may result in a six-level model and so not aligned with the levels of the process maturity model again.

In conclusion, there are many other business process maturity model frameworks (Robledo, Gartner, CMMI, and Rosemann) and other digital transformation frameworks (for example McKinsey, Forrester’s Playbook, and Capgemini). Whichever you choose, make sure your transformation frameworks align before sinking billions into organizational transformation projects that are heading in opposite directions.

Strong Requirements Lead to Strong Solutions

Written by Timothy Figueroa on September 29, 2022. Posted in Articles.

Strong requirements lead to strong solutions. What are strong requirements? Strong requirements can be defined as the documented details of a customer request that provide readers a request from the customer point of view.

While weak requirements can be defined as documented details of a customer request that do not provide the reader a request from a customer point of view. Weak requirements slow the build factory, increase time to delivery, encourage misinformation, trigger unexpected adjustments to the build plan causing time and resource waste.

The quality of requirements impacts an entire chain of events and resources that are used to drive a customer request all the way to delivery. This chain, high level, starts with communicating your understanding of the customer request, planning and prioritization of the work entailed in the request, assuring development’s understanding of the request so they create the solution wanted, and then back to the customer to assess the solution created to confirm alignment.

Initial conversations with customers over a request are a start point in the elicitation process. Well thought out requirements is the goal and accomplishing this may take several iterations.

A recent example of an initial customer request was as follows:

– “Delivery / vs internal transfers, Split delivery UI from transfer UI”

This start point told me, generally speaking:

The customer has a request,
The request is not well defined,
The initial request implies:
- There is an existing system with a combined delivery and transfer feature,
- A transfer feature is a sub-feature inside of the delivery feature,
- The customer wants the Delivery and Transfer features separated,
- This request will probably entail UI and workflow changes,
- I have questions and clarifications…

Refining this request into a strong requirement entailed interviewing the customer to get their understanding of what was wanted.

A hidden risk to manage in the goal of refining the customer ask into a strong requirement is in the form of “Analysis Paralysis”. Only go as far as needed with details, and not beyond. Do this at speed so you deliver results in a timely manner. The line here is as much an art as it is a science.

The benefit of doing the upfront work that supports strong requirements may be in the form of reducing unexpected events on the way to delivery, assuring the same understanding and expectation of the request by the stakeholders, and supporting the notion that business and technical resources are aligned. In other words, no surprises.

Skilled business analysts will use the IIBA BABOK Elicitation and Collaboration techniques and method to refine requirements so that they are relevant and useful. Preparing, conducting, confirming, managing stakeholders and communication are key guidelines to apply.

In conclusion, Business Analysts with the skill to craft strong requirements will enable the build factory to deliver robust solutions at speed and without surprises.

Strong requirements lead to strong solutions.