Skip to main content

Author: Lavinia Mihaela Dinca

5 Challenges for the Business Analyst on a Hybrid Project

Agile has become a common methodology used in many projects, and it’s being used more often. Experts agree that the future is not agile or another methodology, waterfall, but a hybrid of the two.1

Hybrid projects combine methodologies in an effort to use the strengths of both and minimize each of their shortcomings. Implementing a successful hybrid project means needing to have experience with both.

I will give two examples where a hybrid approach will work.

A large project with both hardware and software components can use a hybrid methodology: waterfall for the hardware component and agile for the software component.

Related Article: 5 Lessons From Working With Agile & Waterfall

A second example is a more challenging one: a complex software project where the GUI is created using agile and waterfall is used for feature development.

Hybrid projects strain most of the team members, but it affects the business analysis team more because they have to keep track of everything being developed.

The hybrid project examples from above may be regarded as the separation of church and state. Using waterfall on a hardware part and agile on software part is not difficult, and most likely the BA teams will be separate anyway. “True” hybrid projects are rare, but they will apparently become a reality. By “true” hybrid project I mean a software project where different features are developed using both methodologies at the same time.

In my opinion, there are 5 main challenges a business analyst faces working on a “true” hybrid project:

1. What goes where

Knowing which part of the project will be done using waterfall and which using agile can be complicated. Waterfall tasks can be hardware implementation, application security features, enterprise business architecture, and critical core features. The agile tasks might be GUI design or business features which can change.

Determining what goes where should be set from the beginning of the project. Problems may arise later on if this isn’t done. When issues appear during the project, they should be discussed with the project manager and any other senior members of the team and an informed decision made about which feature goes where. It shouldn’t only be up to the business analyst to decide.

2.  Requirements prioritization and integration

In a hybrid project, feature prioritization may be extremely difficult. The business analyst has to take into account which features will be developed using waterfall, meaning they will be delivered towards the end of the project.
Some features developed with agile might be dependent on the previous ones, and they should be rescheduled toward the end of the project if the prior deliverable is developed in waterfall.

Requirements integration is also challenging because of the same issue: some features will be delivered at the end, others before.

3. Requirements description and documentation

Requirements description is different in level of detail in both methodologies. On a hybrid project, the business analyst must be prepared to do both: requirements for the waterfall part and requirements for the agile one. The problem that might arise is the gap in documentation. Some features will be more detailed (the waterfall ones) and some more high-level (the agile ones).

I think that the most discrepancy will be in the testing documentation because in waterfall the test cases are developed in the analysis phase for all the features. In agile, the test cases are developed for every use case, in every iteration. This means that the application testing will be very difficult overall.

4. Trace / Identify missing requirements

Tracing requirements and, most importantly, identifying missing ones will be challenging. A common mistake is assuming that a certain feature will be developed in waterfall, meaning later on in the project, and business analysts might move on with other tasks.

Another problem is identifying missing features due to fragmented analysis. Some requirements were taken in the waterfall phase and others during agile sprints. Naturally some requirements might be overlooked and never developed. A common requirements matrix must be maintained regardless of the methodology used to develop the feature and business analysts must be involved in both stages of the project – and not have business analysts for agile and business analysts for waterfall.

5. Communication and collaboration

In any project, communication is very important, but in a hybrid one, it’s the difference between failure or success. The BA’s role must be regarded more as a facilitator for the team. The BAs will have an understanding of all the features being developed project-wide, regardless of the methodology, and they will be in a unique position to mediate misunderstandings, provide clarifications, and even help the team understand why a certain feature should be developed using certain methodology.
Personally, I think that “true” hybrid projects are still a long way to go and that most of the hybrid projects will isolate the agile and waterfall methodologies. I think this situation will last for a few years because there are still companies struggling with agile. Companies implementing agile projects still struggle to understand that a business analyst has an important role to play in an agile project and that this role is not obsolete.

Do you think it is feasible to do software development using both methodologies at the same time?

Do you agree the future will be hybrid? What items would you add or remove from the list?


A Business Analyst’s Perspective: 7 Reasons for Project Failure

Statistics show that the real figures regarding project success are not at all encouraging. Only 30% of projects are considered successful; the others are challenged oroutright failures.

How does one determine if a project is a success? From a project management perspective the answer is simple, the “Holy Trinity” – time, budget, and quality.

Reality indicates that things are more complicated. A good example is the construction of Sydney Opera House. From a project management perspective, this was one of the biggest planning disasters ever made. Initially budgeted at $7 million, it ended up in costing $100 million.

{module ad 300×100 Large mobile}

On the other hand, when you think of Sydney, the Opera House is an iconic building, immediately recognizable, placed on most tourist advertising leaflets, and certainly a complete architectural success.

The factors of success for IT projects are the same “Holy Trinity”, with a twist: quality should be defined from a business analysis perspective. Specifically, the delivered project must be compliant with both stakeholders and current business requirements. The last part is mostly overlooked because sometimes the stakeholders requirements don’t conform with reality.
Based on my experience as both business analyst and project manager, these are my top seven reasons for project failure from a business analysis perspective:

#1: Business cases are used ONLY to justify the need for the project

I’ve met many project managers and business analysts who don’t understand the importance of the initial project pitch, the justification of why the project is needed. All these people see this as a necessary evil to start the project, and they treat it as such. The practice of the pitch translates to creating business cases that make sense on paper to justify the money and project need. Sometimes it’s worse, the justification and business cases are valid, but the analysts fail to see the importance, and they don’t incorporate the requirements in the project. This is why projects fail to deliver any business value, even if they are considered successful.

Related Article: How Business Analysts Can Help Failed Projects Succeed

Rule of thumb: all business cases must be covered by requirements.

#2: Missing stakeholders

This reason sounds like a rookie mistake and yet is so frequent I’ve stopped counting. Stakeholder analysis is usually disregarded by analysts because theory says the project manager should perform this task. Yes and no. It should be a combined effort for both project manager and business analyst, and more importantly, it should be revised.
Revision should also be the responsibility of the business analyst because they are in the unique position of noticing when stakeholders are missing during the analysis phase. Missing stakeholders translate in only one thing: missing requirements.

Rule of thumb: revise stakeholder list frequently during the project lifecycle.

#3: No user input

This reason is closely related to no #2, and I’ve debated if I should list it separately. Identifying a stakeholder doesn’t mean getting the user input. I’m going to argue this point with an example: a bank notified us, the end users, about their improvement of the internet banking system. No one believed them because they kept saying the same thing for two years.
The bank’s officials knew we were the stakeholders in the project and also the final users. Not once did they tried to see what our problems were, or verify their requirements with us.
The new internet banking system was a complete failure since end users had different expectations of what they wanted. This type of mistake often happens to businesses, and sometimes it’s even worse, when analysts end up gathering requirements from the CFO but never talk to Jenny in Accounts Payable, who is doing something only she knows.epartment managers don’t know everything, especially at the execution level.

Rule of thumb: talk with the stakeholders at all levels.

#4: Poor requirements and communication

Business analysis means mostly paperwork, not only client interactions. The way a requirement is described and detailed is very important. It has happened to all of us to know a topic very well, but when we try describing it to others, we fail miserably, mostly because we assume people should know some basic things.

The top reasons for incomplete requirements are a poor description, poor communication between business analysis and development team, and missing details. By missing I don’t mean they haven’t been collected (covered by points #1), they were, but the analysts failed to fill in the matrix regarding which business case is covered by which requirement.

Rule of thumb: assume nothing, describe and check everything!

#5: Requirements keep changing

There are many reasons why this can happen: the company is not mature enough and doesn’t have an idea of their own procedures or what they want, the business environment changes rapidly and requirements can keep up with it, or the legislation is missing or unclear.

From experience the following approaches help with this problem: detail the project scope accordingly, ask for a decision manager regarding any changes, apply penalties for changes, sign off on requirements more often, and choose the appropriate methodology, such as Agile.

Rule of thumb: less is more!

#6: Requirements not up to date with business environment

Some businesses or CEOs live in their own bubble different than the rest of the world. The business might still be successful due to inertia; they were in the business a long time and their name still has value. By the end of the project, the situation can change drastically and the project might be obsolete because the requirements don’t conform to the business reality.

Rule of thumb: check your information from third party sources.

#7: Project is a complete success, but no one is using it

The project is finished, all the requirements are met, but the application is not used at all. Most people blame the client for not wanting to change. No, the project failed to capture the real needs. Solve the needs/problems your client is facing and your project will be a success.

Rule of thumb: make sure the project is solving a need/problem.

This is my short list and I’m sure there are other several factors for business analysis failure. What do you think about this topic? What items would you add or remove from the list?