Iterative Analysis and the Diminishing Business Strategy

Approach: Decisions, Decisions!

IT departments are good at biting off more than they can chew.  Often times, 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 cumulatively 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 rather 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 be gathering and eliciting requirements for one iteration while supporting 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, strategy, 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 brainstorm 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, 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.  

Staying Focused

Business stakeholders are usually busy executing the responsibilities of the role for which they were employed.  This leaves little time for “strategy formulation” in which 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 with an iterative project as the analysis sessions are smaller and more focused on the current iteration rather 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 is typically high during the early iterations.  This leads to well-defined, complete detailed requirements which ultimately lead 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 rather than requirements elicitation and definition.  

The Slippery Slope

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 begins 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 cannibalize 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 instead of eliciting and defining new requirements, the iterative method of project execution breaks down.  Time lines and budgets are the first to be impacted but the real loser here is the quality of the final product.  

Answers and Insights

To avoid this oft-occurring scenario, if possible, the project Business Analyst’s goal should be to capture as much of the entire project’s requirements, vision and strategy up-front during the project initiation and early iterations.  Not only does this curb against the risks stated above, but the functionality implemented in early iterations can be created knowing what is coming up without guessing.  It is understood that many companies will likely push back on this type of up-front project cost, but it is proven to result in higher first-time quality and a better final product. 

Author: Steve Bixler is a Business/Operations Analyst with over 10 years of 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 at [email protected] or on LinkedIn at http://www.linkedin.com/in/stephenbixler.