Skip to main content

Author: Steve Bixler

Iterative Analysis and the Diminishing Business Strategy

IT departments are good at biting off more than they can chew. Often, when a project is approved and funded, the natural inclination is to proceed through the favored development cycle in one single linear fashion. This approach has proven to be challenging given potential risks that compound during the long duration. Because of this, many IT managers have chosen to execute long-term projects in an iterative approach rather than a single linear fashion. This approach is not necessarily agile as the methodology is still “waterfall”-based but as a series of waterfall executions (or terraced). 

This approach introduces new challenges for business analysts. With a single waterfall execution, the project is front-loaded with analysis and design. The business analyst then manages requirements and business needs through the remainder of the process.

With the iterative approach, there is potential for more than one simultaneous iteration execution depending on any overlap in the plan. Any delays or plan-impacting problems encountered in early iterations of the project increase the risk of overlapping iterations. This means the analyst can potentially gather and elicit requirements for one iteration while supporting the development of another iteration, and wrapping-up testing and supporting deployment for even a third iteration.

While there are many challenges that can potentially be encountered using the iterative approach, let’s focus on the challenge that is most likely to introduce risk to the overall project: accuracy of business strategy in later iterations.

With the standard waterfall approach, most business rules, strategies and requirements are defined, elicited, documented and understood during a single analysis phase. The advantage of this is that the entire solution is defined prior to development and is deployed as one complete package.

With the iterative approach, the analysis phases are shortened and scoped to focus solely on the items deemed necessary for the current iteration. This leaves little time for brainstorming and requirements definition for future iterations—even the future iterations have a functional impact on the current iteration. Not only does this approach put the overall solution at risk for missing the intended functional target, but it limits the amount of time business stakeholders are thinking about the overall strategy of the project, product or solution. If your organization engages product managers, they can mitigate this risk by ensuring the current iteration is in line with the overall product strategy. Otherwise, the business analyst must rely on business stakeholders (or the actual business analyst) to prepare for future iterations.

Business stakeholders are usually busy executing the responsibilities of the role for which they were employed. This leaves little time for “strategy formulation” to align project execution. Too often, the overall strategy of the project is sidelined in favor of regular day-to-day job responsibilities. This becomes more apparent in an iterative project as the analysis sessions are smaller and more focused on the current iteration than the entire solution. This in turn reduces the “big picture” thinking encouraged by a longer, more comprehensive analysis phase.

Stakeholder involvement, vision and ability to articulate the business need are typically high during the early iterations. This leads to well-defined, complete, detailed requirements, which ultimately leads to successful design, development, testing and deployments. However, as the project execution moves forward, the risk of losing sight of stakeholder vision and strategy becomes apparent. The ability for the stakeholder and business analyst to define the big picture continues to be minimized by the shortened analysis cycles. This can be caused by any number of issues, including stakeholder availability over time, a rotating cast of stakeholders who join and leave the project depending on iteration focus, and the perceived belief that the big picture will ultimately take shape on its own rather than be defined by the stakeholders themselves.

During these times, the business analyst will spend significantly more time assisting with the definition of business rules and operational strategy than requirements elicitation and definition.

As the stakeholder strategy and vision become less defined over the course of the iterations, so too do the requirements become less accurate. Detailed flows and requirements make way for high-level conceptual ideas. Well-thought-out operational processes make way for on-the-spot “let’s hope this works” process definition. The business analyst still delivers requirements at the end of each iteration’s analysis phase, but the usefulness and accuracy begin to diminish (see Figure 1).

Figure 1: Requirements quality diminishes as analyst time is spent defining business strategy rather than business requirements.


The downstream impact of this creates a snowball effect for the remaining iterations. Technical folks who have come to rely on well-defined detailed requirements for design and development reject the requirements and burn through significantly more time attempting comprehension rather than forward motion. The analyst’s time is then consumed by development needs, which cannibalizes the time the analyst should be spending on the next iteration’s analysis. As this trend continues, the analyst has less time to dedicate to analysis (which is already at risk due to the stakeholder issues above), thus compounding the less-than-optimal quality of future iteration requirements deliverables.

Once the business analyst is spending more time managing the fallacies of the requirements during design and development than eliciting and defining new requirements, the iterative method of project execution breaks down. Timelines and budgets are the first to be impacted but the real loser here is the quality of the final product.

Don’t forget to leave your comments below.

Steve Bixler is a Business/Operations Analyst with over 10 years IT experience in multiple industries.  Steve has analyzed and implemented numerous enterprise-wide solutions leveraging nearly every SDLC and analysis method available.  Steve can be reached via LinkedIn