Skip to main content

Tag: Change Management

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

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.

  1. Lessons learnt
  2. 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.

  1. 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

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?

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

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.

10 Soft Skills You’ll Need To Be A Successful Business Analyst

You might already know the technical skills you’ll need to be a great Business Analyst (BA) but do you know the essential soft skills? The role of a BA is deeply rooted in working with people. You’ll often be coordinating with stakeholders, running workshops, or presenting documentation to teams. To be a successful BA you’ll need the following soft skills to compliment the technical ones.


Rapport Building

You’ll need to build rapport with your stakeholders early in a project which you can do in many ways. While you’re waiting for a meeting to start ask your stakeholders questions like, “how is your day going?”, “what are you doing in the weekend?”. I’ve been in meetings where everyone is silent until the workshop begins. Take advantage of this time to build rapport by finding common interests, showing empathy or complimenting them on something such as a tie, a picture in the background of the Zoom or their promptness. This may seem trivial, but it will set you up to succeed as the project rolls out. Your stakeholders will be more likely to attend meetings/workshops, feel more comfortable contributing and start to champion the project and the changes you’re making within the organization.


The Oxford Dictionary defines Empathy as ‘The ability to understand and share the feelings of another’. This is an important soft skill for a BA because we need to put ourselves in our stakeholders’ shoes to understand the problems we are trying to solve. To have empathy means to understand the pain points within the organizations Current State which is essential when we’re trying to fix them. Try to imagine how frustrating it must feel to have outdated, manual process at work when the technology we use at home is so advanced these days. Use empathy to speak to these pain points and get stakeholder buy in and drive user adoption.


Depending on the scope of your project Stakeholders may be attending a lot of workshops and meetings so it’s important to be enthusiastic and positive about what you’re doing. Let’s be honest there’s nothing worse than a dull or dry workshop consisting of people talking at you with slides of written content. To get people to come along for the journey we need to engage them and be enthusiastic about what we’re doing. Speak positively about the benefits and outcomes of your project, show visual diagrams and ask questions to get people involved. Having a positive and bright disposition will pick people up when they engage with you, help them focus on the content and be more likely to contribute.


Active listening

When we’re working on current state or establishing things like user journeys, user personas, use cases or processes a key soft skill you’ll need is Active Listening. Active listening is a pattern of listening that means listening to verbal and non-verbal cues without judging or jumping to conclusions. When you’re active listening you’re not thinking about what to say next you are completely focused on the person communicating. Don’t interrupt them or propose solutions at this stage, instead paraphrase and reflect what you’ve heard back to the person. This will ensure you don’t miss anything, don’t misinterpret anything and help you understand the paint points your users are experiencing in more depth.


When making changes to the organization such as processes, we need to find solutions that work for everyone. For this we will need to think outside the box because realistically we may not be able to meet everyone’s needs, or some people may just be averse to the changes. To facilitate the transition, we can use creative visualizations to get everyone on board the journey; Miro, Figma and Visio are great tools for creating visual diagrams. You can do role plays during workshops, online or in person to outline the steps of a new process. Be creative and use your imagination to make it fun and engaging for your stakeholders.





As a BA you may find yourself on new projects for new businesses often and every situation will be unique. You will need to assess each business’s unique culture, ways of working and environment. Some businesses may be very formal and highly governed while others may be casual and more agile in their approach. To be successful in all these environments you need to be able to adapt, this means finding the right language, terminology, pace, document structure and hierarchy. Recently I worked on a project for a very successful company that still had a startup mentality. They embraced agile ways of working and feared having their autonomy taken away, because of this the word ‘Governance’ was a trigger for many of the staff. We had to adapt our language to suit the client and instead of ‘Governance’ we used ‘Guidelines’. Be adaptable and understand the culture you are working in, don’t work against it, work with it.


Clear and concise communication is important to be successful as a BA. When working with people things can get lost in translation, its our jobs as BAs to ensure they don’t get lost! Be willing to speak up and ask for more detail if you don’t understand something or when you notice others aren’t understanding it either. At times you may need to control the pace of a discussion, to speed it up to keep people engaged or to slow it down if it is moving too fast. There are times when you will need to paraphrase what someone has said to communicate it more effectively to the broader audience. You can use terms like “what I’m hearing is…” or “To put that another way might be…”. Utilizing your communication skills will ensure workshops and meetings stay on topic and you get what you need out of them.


You may find yourself in a situation where you already know the journey ahead for your stakeholders for example a company is implementing an out-of-the-box solution. You’ll need patience to assess their current state to find gaps and bring the stakeholders along for the journey so they can get excited about their new technology and processes, even though you already know the outcome. Another example of using patience is in workshops where different participants repeat information to you, you need to actively listen so they feel heard, but it could get a little boring for you. Lastly, not everyone you encounter is going to be a great communicator, some people talk for too long, some people get off topic, some people are hard to understand, and you need to listen to these stakeholders trying to communicate ineffectively and decipher what they’re saying, this takes patience.



You will find yourself in meetings with technical people, non-technical people and people from all different units of the business. Analogies are a great way to explain complex strategies or technology to people that don’t understand what you’re talking about. If someone doesn’t understand something a great way to describe it to them in terms they can understand may be using analogies. You can improvise and tell them about “One time I went to the supermarket and at the checkout this happened…. Which is like this technology system that does this…”. You will get better at this over time and come to understand what works for stakeholders from different Business Units.

Conflict Resolution

Often our stakeholders may disagree on things like current state or how future state should be. We need to manage both points of view and bring the team to a consensus where possible. Consensus may not be possible in all situations, but we still need to handle the conversations constructively so that everyone agrees upon the next steps.  Some pointers for conflict resolutions are

  • Defuse Anger and facilitate communication
  • Separate people from problems
  • Listen first, talk second
  • Set out the facts
  • Explore options together

Using these tips, we can find a way to move forward together and keep the project on track.

People Process and Tooling (The PPT framework) is a great way to approach IT changes within an organization. I believe the most important aspect in this framework is people because the technology and processes are no good if the people within the organization don’t use them. You can use these soft skills as a BA’s when engaging people to ensure organizational changes are adopted and in turn, you will be successful too.