Business Analysis Articles

Jan 19, 2020
783 Views
0 Comments
Corporate mergers and acquisitions (M&A) continue as a critical means for enterprises to meet strategic objectives such as growing market share or acquiring new capabilities. However, rate of successful outcomes has not grown at the same pace as the number or M&As themselves. In this post, D...
Corporate mergers and acquisitions (M&A) continue as a critical means for enterprises to meet strategic objectives such as growing market share or acquiring new capabilities. H...
Learning about mental models and how to apply them to their work is one of the best investments for business analysts interested in achieving the level of deep thinking that leads ...
Several years ago I was looking for examples using the generalization / specialization technique with use cases. They are not easier to find. And they are typically limited to a us...

Latest Articles

14190 Views
5 Likes
5 Comments

Many people on our Business Analysis workshop ask why we use dataflow diagrams (DFDs). Why not Use Case…or even BPMN? After all DFDs have been around for 20 years, surely the world has moved on?

Well, has it? The primary purpose of a business analyst is to communicate – to stakeholders and to solution providers – and when it comes to communication we all know that pictures (diagrams) are much more effective and less ambiguous than words. Remember the phrase "A picture is worth a thousand words". The question is – which type of diagram best suits our needs? In this article, written by IRM's Training Services Manager Jan Kusiak, we’ll look at using diagrams for stakeholder communications.

Author: Jan Kusiak

9164 Views
2 Likes
3 Comments

Many of us are familiar with the process of business analysis – start by gathering requirements from stakeholders then turn them into a specification which developers can understand. These days however, we need to do more than just document the requirements.

We need to work with stakeholders and business users to understand their systems and analyse their problems – why do you do it this way, why not that way? This is the real value add that the analyst brings to the table. It means challenging the status quo, pushing the boundaries, looking for alternative or creative solutions.

To develop a solution - unless we’re very lucky - we first need to understand the problem that drives the need. In this paper we'll look at how to understand and define business problems – part 2 will look at how to generate solution ideas and part 3 will cover how to choose the best ones.

Author: Jan Kusiak

5319 Views
1 Likes
0 Comments

When your users are physicians and nurses, they don't have time to sit in meetings explaining what they want out of an application or to wade through documents validating requirements. Patient care is their number one priority.

To get over that obstacle, the development team at the University of Texas M.D. Anderson Cancer Center relies on a simulation tool. Using iRise's visualization tool, physicians and nurses can see what the application will look like based on requirements given and quickly change or validate those requirements.
Those applications are part of an electronic medical record (EMR) system that the cancer center has been working on for the past three years, after they could not find a packaged application that met the hospital's unique needs. Sherry Preston, manager of EMR support and development at the center, called the project a work in progress that will continue to evolve.

17698 Views
8 Likes
1 Comments

In this article, I describe one very effective collaborative technique -- the Wall of Wonder (WoW) -- that helps software teams produce the kind of detailed, sharply defined requirements that effectively guide development. As an "emergent" deliverable, requirements evolve through exploration and examination using representative forms such as low-fidelity models and prototypes. A collaborative approach allows business and IT specialists to explore their requirements through these means, while accommodating the necessary fluidity of the requirements process.

19865 Views
7 Likes
0 Comments

While working on a Business Architecture effort several years ago, I collaborated on developing a new internal standard for business process and business capability description. From my perspective, a business capability is the required function or desired service that a business unit performs and the business process is the set of methods employed to realize the business capability. Business capabilities and business processes can be described as current or future state. Their description can also be scaled for strategic or tactical objectives.

This article will present an approach for documenting and aligning business capabilities, business processes, and functional requirements by integrating two distinct tools that leverage robust repositories and object metadata.

11527 Views
1 Likes
1 Comments

Every career has a set of skills that one needs to do their job, and a set of tools to carry out the various tasks required to display their skills. Same is the case for the analyst involved in security assessment... I have chosen the all mighty checklist as my tool of choice for this article.

 

18912 Views
11 Likes
1 Comments

Every area of practice in IT has a set of specific “tools” that supports the standard work of technology professionals. Data Analysis is the capture of data requirements, development of models that reflect those requirements and creation of design to store the data. You can accomplish this with a pencil, paper, and the right skill-set. But it can be done much more quickly and consistently if the process is automated.

There are hundreds of individual software tools and tool-suites that support different facets of data analysis.

8882 Views
1 Likes
0 Comments

Workflow analysis is an application of systems analysis to examine how the applications and tasks performed in an office or practice interact with each other, as well as with the staff performing them. Workflow software applies these analyses to make sure that the right staff member gets assigned the right task, along with the appropriate documents and data files.

8053 Views
2 Likes
1 Comments

Industry experts agree -- the success of any software development project depends directly on the definition of complete, high-quality, accurate requirements. Today's business analyst (BA) takes a lead role in defining those requirements. BAs are responsible for eliciting, analyzing, communicating, and validating requirements for a huge variety of business processes and information systems.

Since the activities of a BA are so critical to a timely, cost-effective, successful software project, it is important to equip the modern BA with a toolset that supports and accelerates all requirements definition activities, as well as provides the BA with practical guidance and resources to support this rapidly evolving role.

This toolset, known as a Business Analyst Workbench, allows analysts to do the following:

  • Gather and record stakeholder needs from a variety of sources
  • Interpret and analyze this information to produce a set of solution requirements
  • Collaborate with stakeholders to validate the requirements
  • Communicate the agreed-upon requirements to those who need to design, build, and test the solution

A Business Analyst Workbench can dramatically increase the accuracy and efficiency of both requirements definition and test definition. But what should you look for when evaluating a potential workbench?

A full-featured Business Analyst Workbench should satisfy four main criteria:

  • Support for multiple requirements approaches
  • Support for all phases of the requirements definition lifecycle
  • Intelligent integration with other application lifecycle management (ALM) tools
  • Inherent change management of requirements

Author: Tony Higgins

49834 Views
23 Likes
18 Comments

Whether you’ve never heard of Agile or you just finished your nth Agile project, you need to understand that Agile is here to stay! Are you, the Business Analyst, an extinct species in this new world? Is your career changing? Do you need new skills?

Agile guru and visionary Scott Ambler talked with Adrian Marchis, ModernAnalyst.com's Publishing Editor, and shared his vision on what’s next for Agile and his thoughts on the role of the business analyst in the Agile world.

14851 Views
3 Likes
1 Comments

Change seems to be a popular word in this pivotal election year. When I think about change, I recognize that it impacts each of us in many forms. One of the biggest changes I’ve experienced as a Business Analyst was the transition from working requirements in a traditional project lifecycle to an Agile methodology. The change was introduced to my project team as a management directive with management support.

Our project was an enterprise initiative funded as a multi-year program. The program was comprised of three parallel workstreams with shared releases. Our workstream’s objective was to build out data and data services for the other workstreams and the enterprise to use. The team was made up of experienced Information Technology (IT) professionals and a brand new business unit. We were halfway through the program’s duration when our workstream was called upon to employ Agile methods. The other two workstreams we serviced stayed with traditional waterfall software development, which presented challenges interfacing with each other. The entire program had already completed a Business Architecture phase that outlined the program’s objectives, future state vision, and capability implementation plan.

11987 Views
3 Likes
1 Comments

A question was asked in the Modern Analyst forums. I paraphrase:

"How does a BA do their work in an Agile project? Can you give some practical examples?"

I've thought quite a bit about this topic and have experience with BAs on agile developments as a project manager and business analyst.

As a project manager I get frustrated by (but understand) the analyst’s need to move through the sensible steps of understanding the problem domain, documenting it, socialising it and then briefing the solutions team.  Many BAs struggle with breaking away from that paradigm, but to work in an agile style you have to get comfortable with the concept of 'just good enough.'

As an analyst practitioner I took it upon myself to act as a proxy for the product owner – which in a corporate environment came with the challenges of multiple stakeholders, the fact that you are not the product owner and thus don't really have the final say, and a number of other challenges that typically stump people trying to move to agile.

My circumstances were unique in some ways. I had worked in the organisation for some time and had established good relationships with all the key stakeholders. They really did trust me with their requirements because, over time, I had learnt (and shown I had earned) their business.

I also maintained high bandwidth communications with the stakeholders throughout the project and kept them informed of what was happening and how the system was shaping up in the context of their business needs. And expectations were managed.

And, lastly, at the end of the development phase of the project we kicked back into formal gated style UAT and release management.

I think the things I articulated there are useful guidelines for any BA or Project Manager on any project, but these dimensions enabled an agile approach in a waterfall type environment. I put myself forward as the product owner and acted as a proxy for the business stakeholders.

Will it work for you?

It depends on where you are working and your relationship with your client groups. A while ago I put this question of the readers of my blog: "Can the BA act as a proxy for the client?"  I got a resounding no from people that I respect and so I'll re-state that my circumstances above are probably the exception to the rule.

What I have learnt is that the BA can be a very useful person, and even play a crucial role, on an agile project.

Before I go on to speak about that I need to qualify what an agile project is: Originally when people talked about agile software development they were talking about precisely that: software development. The project community has always had a problem separating out the project lifecycle from the software development cycle. If you don't know the difference between these two concepts you need to go find out.
Here is one explanation.

So anyway, projects run many software development activities and naturally the processes and methods bleed into one another. And agile development was soon mixed into the concept of agile projects. And that's fine, but it presents a set of challenges for organisations wanting to transition from one way of doing things to another.

Have you ever learnt to juggle? I did. Hours of practicing in front of my bed so I didn't have to bend down to pick up the balls all the time. But I practiced with three balls and if I try to juggle four or five it's just too hard. I could set aside the time and practice until I get it right, but really, I am satisfied with three. It works for me, so why sweat the effort?

Same goes for shifting project methods. Sure your project office is sick of spending months and millions of dollars on wasted projects, but the various other participants in the project aren't feeling the same pain.

And smart, talented business analysts are one of those groups that aren't feeling the pain. Really, in my experience, excellent business analysts are often enough of a catalyst to break the cycle of project failures. Good requirements management, stakeholder engagement and change management really will get you there, even in the most formal waterfall environments. So why do they have to shift their whole way of doing things? They have achieved mastery of their profession, and now you want them to throw all that away and start again?

Well, yes. An agile approach in an agile environment is so much easier for everyone on the project.

Unfortunately an agile approach in a non agile environment struggles. And that environment is basically the stakeholders, the project team and the organisation's bureaucracy. So you end up using hybrid methods like agile in the developer space but more structured at the top end of the project.

The antipathy business analysts often feel towards agile methods isn't helped by the caustic tone of the agile gurus who advocate direct interface between the customer and the development team. Several of them publicly disparage business analysts and actively promote their removal from the process.

I think the key to getting master business analysts to work on agile projects effectively is helping them find a pain point they want to address, and finding a valuable place in the project for them.

The first point probably comes with either maturity – it's not all about them – or with a series of failed projects (naturally not their fault.). The second point – the BA's role – that was your original question, and it doesn't have anything to do with choices of models.
I think the role of the BA on an agile project is two-fold. Your number one role and priority is to facilitate clear requirements. It isn't to document them and it isn't to elicit them. It's to facilitate their clear transmission to the development team.

In some cases this simply means scheduling and booking meeting rooms, while in other cases it requires the BA's professional questioning and modelling skills to draw out an idea and ensure it is elaborated sufficiently for the developers to understand the full dimensions and context of the requirement.

Developers should, ideally, be in the workshops where requirements are teased out, so documentation is a secondary aspect to this work. It is about facilitating communication.

It's also about making sure the client is fully considering other stakeholders. Enterprise scale projects often have many stakeholders, and in less mature organisations the product owner or project sponsor isn't always considering the needs of his or her peers. The BA can help with that.

So, you see my idea of the role of a BA on an agile project is quite different from the traditional and industry view of what a BA does. It becomes much more people focused and much more about understanding the drivers, values and context of the business requirements than the details of the requirements themselves.

I believe these are key success factors that all excellent BAs apply in their job no matter what the project methodology.

I hope this is useful for you. And I am glad to be corrected by people who know better:" Agile Experts, what say you?"

Author: Craig Brown

3800 Views
1 Likes
0 Comments

In business today, any project is ultimately measured by one thing: return on investment. There are dozens of metrics to be measured along the way—from budget and deadline to scope and stakeholder satisfaction—however, at the end of the day, ROI trumps all.

Remember the movie Titanic? It overshot its budget by a nautical mile and took much longer to make than originally scheduled. However, a lifeboat full of Oscars later, the movie grossed about a billion dollars around the world.

Unfortunately, with your current projects, you probably won’t be able to lean on Leonardo DiCaprio to drive profits. That’s why, from a business standpoint, it makes sense to give your projects the best chance of success from the very beginning of the project life cycle. In other words, don’t sink your chances at profitability before you even leave the harbor. Metaphorically speaking, of course.

The best way to do this is to mix business analysis into your project management efforts. For years, professionals have been realizing that the infusion of business analysis can dramatically improve the likelihood of project success. Business analysis is essential for establishing project requirements, ensuring that your stakeholders are on board and eliminating the countless hours of rework that can wreak havoc on your budgets and timelines.

To help guide you in the integration of business analysis into your project mix, I’ve listed five key tips. From requirements gathering to communication to verification, think of it as your crash course in the value of business analysis. Each tip can be mapped back to the International Institute of Business Analysis (IIBATM) Business Analysis Body of Knowledge (BABOK®)

Author: Glenn R. Brûlé

9959 Views
4 Likes
0 Comments

Requirements gathering resources and best practices were found lacking at Fortune 500 companies, a recent study from Voke Inc. found. But if business analysts are equipped with the right tools and enough resources, businesses stand to benefit greatly.

3529 Views
0 Likes
0 Comments

As technology stocks waned in the last few months of the 20th century, some analysts worried that technology degrees wouldn't be as valuable as they had been during the "dot-com bubble." They couldn't have been more wrong.

It's not just industry heavyweights like Google and Apple who are acquiring new real estate to house all their new hires. Employers from nearly every market sector imaginable are luring professionals with computer training with competitive salaries, perks, and bonuses. With large companies taking their IT in-house and small businesses relying on outsourced providers, it seems that everyone in the world wants to hire technology professionals.

According to government statistics, these 10 jobs show the most promise over the next decade.

Author: Joe Taylor Jr.

Page 55 of 67First   Previous   50  51  52  53  54  [55]  56  57  58  59  Next   Last   











Copyright 2006-2020 by Modern Analyst Media LLC