Skip to main content

Tag: Methodologies

What is Business Agility

Written by Business Analysis (BAPL) on . Posted in Articles.

Success today requires the agility and drive to constantly rethink, reinvigorate, react, and reinvent. – Bill Gates

Business agility is not about rolling out New Ways of Working (NWOW) or Agile methods via a ceremony, but it is about business analysis capability to continually assess the market needs & being able to reshape & remodel an organisation to meet these needs.

A generation ago, a “Kodak moment” meant something that was worth saving and savouring. Today, the term increasingly serves as a corporate bogeyman that warns executives of the need to stand up and respond when disruptive developments encroach on their market. – Scott D. Anthony

As we are entering the 5th Industrial revolution, the age of software, we can see that business agility and software engineering excellence are paramount for organisational success.

Today six of the top organisations in the world are technology companies and four were founded by software engineers. It is not surprising to predict that those organisations that master software engineering in the next decade will survive & thrive, while those that don’t will flounder or dwindle.

Even traditional manufacturing companies such as car manufactures are being disrupted. The electric car now utilise over 1 million lines of code & it is predicted that the autonomous car will require over 1 billion lines of code. Car manufactures will employ more software engineers, business analysts, testers than production line workers in five years time.

How do you improve software initiatives? Are you taking control of your software engineering or are you only using cookie cutter New Ways of Working (NWOW) for Agile transformations?

 

Advertisement

Connecting software initiatives to business outcomes through value streams is the key. Success can only be driven by the market that drives the reshaping of the business. If you have no connection between your delivery squads and business success, you will inevitably fail.

We trace from market analysis, value streams and delivery backlogs to make sure that business agility is realised fully. Feature driving, compliance driving, user ability, or low defect driven are measured to enable real business agility for a competitive advantage.

Exceptional business analysis is the key to successful business transformation for the future uncertainty. The best way to predict and lead the future is to create it.

  • “Increased ROI: Business analysis keeps the focus on the value delivery to the customer. Enabling organizations to better define products with business analysis to deliver the right outcome that meets customers needs and eliminate requirements with minimal value.
  • Increased success rate: 71% of failed software projects can be traced to poor requirements – CIO Magazine, 2006. Mitigate the risk of failed initiatives with business analysis throughout all planning levels and prioritize implementation of requirements with the most potential benefit to the customer.
  • Reduced costs: Better defining the product and focus on the right requirements eliminates unnecessary changes or rework with logical and orderly decision-making, tailoring and aligning solutions to the business or customer needs.
  • Gain competitive advantage: Accelerate product delivery and be the first to market to gain market share by creating a clear roadmap from the current to future states and building a consensus among stakeholders”. IIBA

Here’s the thing about exceptional business analysis

 Business Analysts help your company to think about the “why” before going ahead with a strategy, which will helps prevent technology initiatives from providing little or no value to your organisation.

Here’s an example of exceptional business analysis. A client sought a solution to manage their approval process and documents. These were associated with their major energy capital projects, having a value of up to $100 million.

We analysed the business process automation, mapped the future state processes, and explored the business and functional requirements through a series of stakeholder workshops. This was achieved by using aspects of our methodology and customising templates from our Business Analysis Centre of Excellence (BACOE)

­­­Based on these documented processes and requirements, we developed an automated workflow solution.

The outcomes of the process automation solution were:

  • Increased consistency of the approval process
  • An automated audit trail for the approvals
  • An increase in document tracking, resulting in a greater efficiency with approvals
  • Reduced time spent on approvals by eliminating manual approvals
  • Reduced resource wastage on printing

In the final analysis, we found that by minimising the delays for approvals, this reduced the external contract resources required for approval processes. Within six months, the cost of developing the solution was paid for by the benefits of the automated workflow.

An exceptional Business Analyst requires a unique skillset that many senior executives have never experienced. However, you need to engage in proper business analysis to provide a greater chance of transformation success.

As increasingly competitive organisations look to become more innovative to survive and prosper with technology, business analysis is critical.

If you want to deliver better products & services to customers, and not to become a “Kodak moment” then let us help you to improve your software initiatives!

Copyright © 2021 www.business-analysis.com.au

Contextual Awareness in Business Analysis: An Analogy

Written by Jeff Hutchings on . Posted in Articles.

In the martial arts there is a concept called seeing without looking. May seem odd, but it makes sense when it is put into perspective.

At bottom, a Martial art is any of the various fighting skills, mainly of East Asian origin, such as kung fu (Pinyin gongfu), judo, karate, and kendō. Martial arts can be divided into the armed and unarmed arts. The former include archery, spearmanship, and swordsmanship; the latter, which originated in China, emphasize striking with the feet and hands or grappling.

Most Martial Arts involve a lifetime of dedication and training, and is as much about cultivating the person as the person’s adeptness in the Art form.

Back in the day, the Martial Arts weren’t a means of getting fit or winning medals: they were often a means of survival. With a weapons ban in the Ryukyu Islands in the 16th century, using your body as a weapon for defense became commonplace.

As practitioners’ progress, brute strength and mental fortitude aren’t enough to master the Art – it takes mental clarity and intuition.

Therefore, practitioners have to master the concept of seeing a whole picture without looking at any one piece of it. Masters of the arts often tell students to see as if your eyes are peering from behind you. Mastering this meant that an opponent’s movements are perceived before they actually begin. It begins with not focusing on one aspect of what is in front of you – you are perceiving the situation without mental noise, and without guessing what happens next. An open mind and full awareness allow the fighter to detect subtle changes in breathing, expression, posture, etc.: tell-tale signs of what happens next.

As a business analyst we hate to admit, or mumble under our breath, I didn’t see that coming, or I really missed that!

I came from a technical background and what I found happening with a new BA project was that I wanted to start answering the how of a solution as opposed to the what. I understood databases, cloud storage, web interfaces and such, and I’d immediately start to formulate in my mind a potential scenario that might suit the client’s needs: “So, it seems to me that you are looking for…”

Rabbit holes appeared as places where I thought the solution should go – I wasn’t taking the entire picture into perspective. I was looking at the bits and pieces of it that made sense to me – that stood out.

Advertisement
The purpose of a BA – as my team and I often hear from our learned manager – is to assist the client in understanding the what. What is the ask? What is the process that this solution will support?

This requires standing back and perceiving form 10, 000 feet, not magnified-glassing the storage, UX, outputs, or data travel bits of it.

True, the BA has to dig into the individual elements of a project to get to individual, granular requirements, but seeing it as a machine as opposed to individual cogs at first, assists in this.

A standing back, context-overview approach helps you identify those subtle bits and pieces that you eventually need to document, as well as potential rocks in the road.

To take the Karate analogy further, open eyes and an open mind allow you to catch that the opponent holds their breath before an attack, or shifts the toes of front foot slightly outward before moving; both of which you’d miss if you were expecting a front kick, or you are thinking about delivering one.

After all, what you miss is just as important as what you capitalize on.

A robust research solution to capture data on wildlife in the field isn’t of much use if portions of the field are without network connectivity.

Oftentimes the environment that the solution will exist in has significant impact on the usability and added value to the business, and we miss that if we’re focusing on the software or data flow while overlooking the context.

Perhaps it means initially looking at the night sky as opposed to a zoning in on Sagittarius.  The context offers insights into what pieces constitute the whole, and which need to be examined.

For example, understanding administrative and physical safeguards undertaken by a third-party vendor is important if your solution has a cloud component you’re utilizing – even if it is a small piece of the end product.

There’s nothing new here for a business analyst, but I do find myself having to remember to see from behind me once in a while during the scoping of a project, and during subsequent documentation, in order to keep things in perspective and not to miss the factors outside (but connected to) the solution.

Elements that drive a process aren’t always evident, and I find that revisiting the bigger picture, and asking questions about the frame, and not just the portrait, are helpful.

To wax philosophical for a moment, the old Martial Arts adage of perceiving things with a clear mind is also helpful in everyday life. Observing life around us without laying our preconceived notions on them, or labelling or judging them, brings new aspects of them to life. Stillness of mind is like a physical rest for a weary back: it is necessary because it is beneficial.

Getting lost in the weeds in business analysis affects schedules and costs. The solution, I believe, is to regularly re-examine the swamp.

Business Analysis Report: Writing Guide From Preparation to Submission

Written by Amanda Dudley on . Posted in Articles.

Did a major stakeholder in your company contact you to send an analytical report or are you a rookie trying to impress your boss with an excellent business analysis report? If so, you are in the right place. This article will teach you how to write a formal business report, including the preparation and proper structuring hacks. So, sit back and get your pen and notepad ready because you will be learning a lot.

How to Write a Business Analysis Report

1.    Preparation

If you want to have a good business report analysis, don’t just start with writing. It would be best to draw a plan of how to present the data from your analysis. So, here is what an ideal business report plan should look like:

  • From the beginning, have the end in mind

An excellent business analyst typically thinks about their recommendations from the initial stages of a project. For example, if you are writing a report on why the company should start using digital signage, you should already have the best solutions handy. This process may seem complex, especially if you don’t know how to make recommendations when you haven’t started the main report. But if you conduct adequate research, deducing to a coherent chain of events leading up to a specific conclusion won’t be difficult.

  • Who are you writing the business analysis report for?

First off, you need to know your stakeholders before you start writing business reports. A stakeholder analysis will help you get that knowledge. Namely, you’ll discover who are the influential people you need to convince. Secondly, you’ll find people who are project-oriented so that you can convince them of the value of your report.

  • How do you plan on presenting the business analysis report?

You should determine the method you want to utilize to deliver your analysis report before writing. Take Screenvision as a case study of using unique storytelling to win people over when analyzing a new product. Unfortunately, there have been other scenarios of people losing their audience because they didn’t present their analyses properly. For your business report, you can choose between print, PowerPoint presentation in front of an audience, or a combination of both methods to capture your audience’s attention.

Advertisement

2.    Structure

The structure of your report is vital because it may be the reason why your recommendations will convince the right people. A properly structured analysis will give your audience a desirable impression about you and your business. So, when writing your report structure, focus on:

  • The introduction

There are different types of business reports, but they all have an introduction which follows the same pattern. In the introduction, there should be a hook — something that will catch your audience’s interest. Then, explain the background of the project. However, contrary to popular expectations from business analyzes reports, keep your introduction short and understandable if you expect to carry your audience along.

  •  The process of investigation

Another important aspect of your business report is discussing how you came to your recommendations. Your audience needs to know that you put your due diligence to get the data you are presenting to them as facts. You don’t have to give all the in-depth details of your research because it can get boring quickly. All you need to do is provide a simple summary of how you arrived at the factors that influenced your decision.

  • The outcome of each investigation stage

Explaining the outcome of each technique you utilized will help your audience understand why you are advancing these recommendations. Don’t go through your process map in superficial details. Pick out the essential aspects and discuss them extensively. Also, don’t make the mistake of saying “who” told you to make your recommendations. Instead, talk about “why” your recommendations are the best fit.

  • Summary

The summary is the final aspect of your business analysis report template. This part of your report entails rounding up your findings and recommendations. All you have to do is discuss everything you told your audience in simple and short sentences, ensuring you are as precise and clear about your points as possible.

Conclusion

An analysis report is an essential aspect of any business. The most important things to remember when writing reports are the following:

  • Preparation is essential.
  • The introduction can make or mar the analysis and determine if stakeholders will go through the report.
  • Stakeholders want to know the context, not just the problem itself.

So, as a part of the business world, you should always be equipped with the proper knowledge of your field because you never know when you will need to prepare a business report.

But sometimes even with proper knowledge, you will need help from an essay writing service to help you to finish or edit a high-quality report. Nevertheless, this article should help you with writing. Good luck!

Waterfall vs. Agile: A Relative Comparison

Written by Anna Rajander on . Posted in Articles.

The merits of Agile versus Waterfall are well documented. However, it is useful to understand the relative differences between the paradigms and how they impact Business Analysis – particularly if you work in an environment where both approaches are used.

This article attempts to provide a visual, relative comparison between:

  • A traditional Waterfall method that moves through defined phases that include Requirements, Design, Implement and Verify, with a defined gateway denoting the point at which the method moves from one phase to the next.
  • An Agile method that aligns with the 12 principles of the Agile Manifesto.

The approaches are compared across three areas that matter to many Business Analysts:

  • The relative effort is involved in specifying and managing requirements.
  • The relative risk posed by ill-defined requirements.
  • Time to realize benefits.

Requirements Management

The timeline for discovering, specifying, and managing requirements differs greatly between the two approaches. A traditional Waterfall approach includes the requirements phase early in the initiative where the focus is on requirements specification and management activities. At the end of this phase, the ability to change requirements is limited. Therefore, most of the effort to elicit and manage requirements happens during this early phase.

By comparison, requirements elicitation and management activities for an Agile initiative are more evenly distributed over the life of the initiative as requirements are constantly reviewed, updated, and prioritized.

The relative requirement management effort over time for each approach is shown in Figure 1.

Figure 1 – Waterfall vs. Agile: Relative requirements management effort over time

Relative Risk

Missing, incorrect, and/or otherwise ill-defined requirements put the delivery of fit-for-purpose products at risk.  However, the relative risk associated with ill-defined requirements is quite different when comparing Waterfall and Agile approaches.

The risk posed by ill-defined requirements for a traditional Waterfall approach is lower during the requirements phase of the initiative as this is the time when requirements can be added and changed without impacting other areas. After this phase, the risk posed by ill-defined requirements dramatically increases and continues to increase for the duration of the initiative. By comparison, the risk posed by ill-defined requirements to Agile approaches is largely constant throughout the initiative. Figure 2 shows the relative risk of both approaches side-by-side.

Figure 2 – Waterfall vs. Agile: Relative risk posed by ill-defined requirements over time

However, it is worth analyzing the relative risk by its constituent components – the likelihood requirements will be ill-defined and the impact of having ill-defined requirements.

For a traditional Waterfall approach, all the effort to elicit and document requirements happens at the beginning of an initiative with limited mechanisms in place to revise or revisit requirements in later stages – regardless of what new information may come to light. This means that it is comparatively more likely (i.e. higher likelihood) that there will be ill-defined requirements. The likelihood of having ill-defined requirements is fairly consistent throughout the initiative as it is the result of a constraint imposed by the methodology.

Advertisement

In contrast, the impact of ill-defined requirements is low for Waterfall approaches during the initial requirements phase of the project as this is when there are mechanisms in place to actively review and change requirements. After this point, the impact of ill-defined requirements can increase quite dramatically (particularly for initiatives that involve the procurement of resources and/or base products as per the requirements as part of the next phase) and continues to increase throughout the life of the initiative. This is because the cost of changing products increases as the initiative progresses through the design, implement and verify phases.  This is demonstrated in Figure 3.

Figure 3 – Waterfall: Likelihood and impact of ill-defined requirements over time

In comparison, Agile methods include mechanisms to incorporate new information into requirements throughout the life of the initiative, meaning the likelihood of ill-defined requirements decreases as the initiative progresses. By comparison, the impact of ill-defined requirements increases over the life of the initiative as products are incrementally released. This is shown in Figure 4.

Figure 4 – Agile: Likelihood and impact of ill-defined requirements over time

By the end, the impact of ill-defined requirements on comparable initiatives is relatively similar for both Waterfall and Agile methods – it is the likelihood that contributes to the overall difference in relative risk.

Benefits Realisation

Another key point of difference between Waterfall and Agile methods is when benefits are realized. For Waterfall initiatives, benefits cannot be realized until after its core products are fully delivered. There is limited opportunity for early benefits realization in traditional Waterfall initiatives. By comparison, Agile methods offer opportunities to realize early benefits with the incremental delivery of products, as demonstrated in Figure 5.

Figure 5 – Waterfall vs. Agile: Relative time to the realization of benefits

Why does it matter?

So why is it useful to understand the relative differences between Waterfall and Agile approaches? There are a few ways increased understanding of the relative differences between methodologies can help, including:

  • Resource Planning – helping you to plan and allocate resources where they are needed most based on the approach being used.
  • Communication – better able to describe the relative merits and risks of an approach to stakeholders.
  • Arguing your case – provide some talking points to help you argue for an alternative approach.
  • Assessing alternatives – provide a basis for assessing alternative approaches and for tailoring methodologies.

Conclusion

This article has provided a relative comparison between Waterfall and Agile across three areas. In comparing Waterfall and Agile paradigms in relative terms this article does not seek to promote one over the other – both have their place. In addition, this analysis has not accounted for all the available variations, flavours, and mashups of approaches. However, understanding the relative differences between the basic paradigms can assist when preparing and planning to work with a specific methodology – particularly in environments where analysts may be expected to work with multiple different approaches.

Resources:

Agile Vs Waterfall in Healthcare

Written by Jimmy Rodela on . Posted in Articles.

The healthcare sector is one of the biggest and fastest-growing industries today. It includes companies that manufacture medical equipment, drugs, provide medical services, and facilitate the provision of healthcare products (among other things).

According to the United States Bureau of Labor Statistics, healthcare occupations are expected to grow by 15 percent from 2019 to 2029. The number of nurse practitioners alone is expected to increase by a whopping 52 percent within this time frame. This growth rate is much faster than the average for all non-healthcare occupations.

The rapid growth of the healthcare industry, which is worth a staggering $4 trillion based on the data from the 2020 Forbes Healthcare Virtual Summit, brings with it the need for more efficient patient care, a reduction in costs, and a better overall experience for patients. This is known as the Triple Aim.

This is where tools for project management and extensive knowledge of project management methodologies, namely agile and waterfall, will come into play.

After reading this article, you should have a deeper understanding of the agile and waterfall methodologies as well as their pros and cons. You should also be able to determine for yourself whether adopting waterfall or agile practices is best for any given scenario.

The waterfall development methodology

This flowchart shows the step-by-step process that is used in the waterfall development methodology. Image source: (https://www.macadamian.com/learn/when-to-use-waterfall-vs-agile/) Alt-text: Flowchart depicting steps used in waterfall development methodology: Gather & Document Requirements, Design, Development, Testing, Development/Delivery, and Final Outcome.

The waterfall development methodology is an approach to creating a product or service that entails the breaking down of project functions into distinct stages. Each succeeding stage is dependent on the outcome of the previous one, and completing them sequentially, within a strict budget and timeline, is necessary.

Within the healthcare sector, most people are more familiar with the waterfall development method and are comfortable with using it in their daily activities.

Using the waterfall method allows project managers to have a clear overview of the project. It also gives them an idea of the timeline for each stage of that project.

However, one downside to using the waterfall method is that it is inflexible by nature. This means that difficulties will often be encountered if there is even a slight deviation to the project plan.

 

Advertisement

 

Waterfall development methodology pros

Below are several good points about the waterfall development methodology.

1. Extensive documentation

You won’t be able to backtrack to a previous stage of a project while using the waterfall method without wasting valuable time and resources. This forces you to create thorough documentation from the very beginning.

2. Knowledge stays in the organization

Thanks to extensive documentation, you won’t need to worry about lost knowledge in case someone from the team decides to leave the project. Also, you won’t need to spend time training new team members since they will easily be able to become familiar with the project by viewing the documentation themselves.

3. Team members can plan their time more efficiently

Team members will know in advance what they’ll be working on. This allows them to plan out their tasks more efficiently.

4. Easily understandable

Because the waterfall method lays out the project in a way that is easily understandable, project management is usually straightforward.

5. Client input isn’t required

Client input is kept to a minimum except for occasional reviews, status meetings, and necessary approvals.

 

Waterfall development methodology cons

Below are negative points worth looking out for when using the waterfall development methodology.

1. No backtracking

Going back and making changes to a stage in the project that has already been completed can be costly and time-consuming. This puts a lot of pressure on team members during the planning phase.

2. No room for mistakes during the requirements phase

All the other stages of the project rely heavily on the requirements phase. Making errors here can doom the project even before it makes any significant headway.

3. Deadline creep

The domino effect is common in the waterfall method. This means that once a deadline is missed in just one stage of the project, the succeeding stages will most likely be affected as well.

4. End result may not be what the client actually needs

Because client involvement is kept to a minimum, the end product may end up not being what the client actually needs. This can lead to a major overhaul in the project plan which can eat into the project’s budget.

5. Unforeseen problems

Because the waterfall method is inflexible, it can be difficult to deal with unforeseen problems when they arise.

 

The agile development methodology

As you can see from this flowchart, the agile method and the waterfall method are quite similar. The key difference between the two is the agile method’s added feedback loop. (Image source: https://www.macadamian.com/learn/when-to-use-waterfall-vs-agile/). Alt-text: Flowchart depicting steps used in agile development methodology: Establish Requirements, Design, Develop, Test, Deploy, Micro Outcome, Feedback and Final Outcome.

Most modern healthcare organizations prefer to use agile planning over waterfall planning. This is largely due to the healthcare sector’s growing demand for newer project management tools and methodologies that adapt to constantly changing needs while allowing team members to be both disciplined and accountable.

In a nutshell, the agile development method encourages collaboration and frequent adaptation. This is in stark contrast to the inflexible nature of the waterfall method which favors careful planning.

Additionally, because the customers themselves are much more involved in the agile process, there is a much higher probability of customer satisfaction which can be attributed to agile in customer success.

While the stages of both the waterfall and the agile method are quite similar, the practices and values couldn’t be more different. (Image source: https://activecollab.com/blog/project-management/agile-project-management). Alt-text: Image depicting numerous agile practices and values

Here are three agile practices that you can start using right now:

1. The daily standup

This is a short daily meeting which usually lasts no more than 15 minutes. It allows the team to touch base and share important information.

2. The retrospective

At various stages during the project’s development, the team makes an assessment of their performance.

The three key questions teams ask themselves are:

  1. What worked well for us?
  2. What didn’t work well?
  3. What can be done differently to improve results?

3. Customer demos

This is done by presenting working versions of products or services to the customer at certain points throughout the development stages.

Agile development methodology pros

Below are positive points about the agile development methodology.

1. Agile is flexible

Because agile promotes a flexible approach to project management, priorities and requirements can easily be adjusted on the fly without any real consequences

2. Agile empowers the team

A team that uses the agile development method is NOT directed by a manager. It is expected to be self-organized, allowing members to set their own working standards and timelines.

3. Agile speeds up the production process

Because less time is spent on planning and documentation, the team is able to focus more on what needs to be done in order to be able to deliver a working iteration of the product or service.

A study was even done on applying agile practices to rare disease drug development to encourage evolutionary development, adaptive planning, rapid and flexible response to change, and continuous improvement.

4. Learning is encouraged and embraced

Learning is an integral part of the production process when it comes to the agile development method. With every iteration, the team learns how to improve upon the product or service that they are currently developing.

5. More opportunity for creativity

agile works better when the product’s design and vision isn’t too well defined. This allows the team to develop the product or service in conjunction with the customer’s input.

Agile development methodology cons

Below are some of the negative points when using agile development.

1. Outcome and timeline aren’t as predictable

Though agile’s iterative approach to developing a product or service allows the team to be flexible with their scope and timeline, the drawback is that timelines are often less predictable and aren’t set in stone.

2. The customer needs to invest time in the product

In agile development, the input of the customer is vital to the production process. This means that unwanted setbacks can occur if the client is frequently unavailable.

3. Documentation isn’t available

As previously mentioned, documentation isn’t one of the priorities of the agile development method. With no documentation, lost knowledge can quickly become a major issue should any team members decide to quit.

The lack of documentation can make knowledge transfer, training, and agile implementation challenging.

Based on survey data, 23% of respondents say insufficient training, education, and best practices for implementing agile hinders the proper adoption of agile practices within the organization.

4. A lack of trust within the team can be catastrophic

Trust is crucial in the agile development method since all the team members should be working closely to produce the best results. A lack of trust within the team can cause big problems down the line.

5. Re-work is unavoidable

Because the agile method values collaboration and frequent adaptation, a lot of time is inevitably spent working, and re-working, the product or service. This usually goes on until both the development team and the client are satisfied with the end product.

 

Which development method should you use?

There are a number of factors that you should consider before deciding on the best methodology to use for your healthcare organization.

For instance, if your project, such as adopting new software to improve your organization’s healthcare system, has strict regulatory requirements and there is little to no room to make changes, you may want to opt for the waterfall development method.

On the other hand, if your organization doesn’t have a strict process to follow and you have the luxury of being able to work flexibly, then going with the agile method may be a better choice.

At the end of the day, knowing the strengths and weaknesses of your team, as well as having an extensive understanding of the pros and cons of both the waterfall and the agile development methods for your healthcare facility and operations, will help you make a smarter, more educated decision as to which development methodology should work best for you.