Author: Nicola Myers

Nicole Myers is a specialist in business analysis with fourteen years of experience, qualifications through IIBA, IREB, OMG, SCRUM.ORG and UNISA, and have spoken at multiple conferences. Nicole is passionate about designing software from one line of writing from the client, supporting my development team and learning new things. Myers lives in Paulshof, South Africa, and foster kittens. Have a look at the features section of her LinkedIn profile to get a feel of who she is. https://www.linkedin.com/in/nicola-myers-ccba-cpre-oceb2/

Building a House: Analogy for the Business Analysis Role

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

Two years ago, my friend asked me what my job role was, and I said that I was a business analyst in Information Technology (IT). However, after all this time, she still doesn’t understand what my job entails. To assist friends of other business analysts around the world, I have written this article to explain what we do. I can’t wait until she reads my article!

Let us propose a world where business analysts are architects, the developers are builders, the inspector is the quality assurance team, and our software client would like to build a house.

Usually, the builders would start building the lounge. This sounds good because they are off to a flying start and the walls are going up, but the builders do not know how many bedrooms the house will need, where the best location for the bedrooms is, or even why they are building the building at all. The kitchen might even end up with four sinks and no oven, or the kitchen might not even exist. Finding out that this is not what the customer wanted when the house is half built is expensive to fix, will not meet the deadline, and worst of all, the house will not be what the customer wants at all!

A far better idea is to include an architect on the team.

Firstly, the architect will sit with the customer and find out the high-level goals of the building, for example, the customer would like a family house in a quiet suburb because currently they live in a noisy complex. They are also expecting a second child. The business analyst (BA) is gathering context on the problem and the customer’s vision.

Right from the start the architect explains the process that will be followed, builds a trusting relationship with the customer, and starts to manage the expectations of the customer, for example, steering the customer away from a water slide in the lounge which could take an extra six weeks. This is change management, which should happen as early as possible and should set the tone for the rest of the project. It should also be noted that the business analyst is the ambassador of user needs and so is the team member that focuses on them.

The architect will then dive into the details and obtain the customer’s requirements, draw diagrams, and can even print a 3D model of the house. It will become clear to the architect and the customer exactly where the main bedroom will be, how large it is, how many windows it will have and so much more. This is the Business Analyst (BA) conducting requirement elicitation, drawing up wireframes, and prototyping the solution. The BA will also choose the best way to engage with the customer, such as through prototyping in workshops or sticky notes on a virtual whiteboard.

To double-check that the architect and the customer are on the same page, the architect will draw up some basic design criteria that the building must meet, for the example given that the room is the older child’s room, when the builders are building the walls, then they must build two windows. This is writing acceptance criteria.

A very important step is that the architect will confirm their findings with the customer to make sure everything is covered and covered correctly. This is the validation and sign-off stage. Note that architects can suggest solutions to fill in the gaps, for example, they can suggest that the house should face north, but it is ultimately it is the customer who makes the decision.

Our builders are brilliant in their field, but they are better at building than communicating. This means that the BA needs to translate what the customer needs so that they fully understand what to do. BAs bridge the gap between the business and technical sides. The architect explains “what” needs to be done, the builders decide “how” it will be done, for example, the builders will use wheelbarrows.

The architect will sit with an interior designer and discuss the finer details to make the house as well designed as possible, for example how to place the cupboards in the kitchen to make the layout practical. This represents the interaction of the BA with the user experience experts to make sure the software is intuitive and a positive experience.

Now the builders know what to do, the building continues nicely, with a few hiccups along the way such as the bricks weren’t delivered on time. The architect will work closely with the builders every day and if the builders have any questions or are unclear on anything then the architect needs to go back to the customer for answers.

Each day the entire team, with the customer, will stand on the pavement and have a quick meeting to let the other team members know what they did yesterday, what they are doing today, and if there are any blockers or dependency issues. This is a daily standup meeting.

Every second week, the team sit around a table on Friday afternoon with some drinks and discuss how the project is going. They say what has worked well and what could have gone better. They decide what to keep doing and what new ways can be put in place to improve the way they are doing their work. This is a retrospective meeting used with an agile approach.

Once a section of the building is complete, then the architect will walk around the building with the building inspector. The inspector will check every detail to ensure the house is built to code and is safe while the architect will ensure that the building is what the customer actually wanted. Sometimes the builders can get really enthusiastic, go off course, and place a central fountain in the kitchen and forget the sink. This is a verification process step.

The house is completed, with a few bumps along the way, but the customer is thrilled (hopefully) and can’t wait to move in.

In conclusion, call us business analysts, business architects, solution designers, or craftsmen but understand that we undertake many daily tasks and play a vital role in the development of successful software projects. We may not build the building but direct it (builders like to build theme parks) and save the customer a lot of money. Hopefully, my friend will understand what I do now!

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.