Many organizations mandate either a structured (waterfall), iterative, or agile software development methodology (SDM) for all IT projects. It is actually much more effective to select the appropriate SDM for each individual project. Every project is a unique convergence of people, available technology, desired outcomes, and organizational culture. Ergo, those in authority should determine the appropriate methodology based on organizational as well as project factors and all options should be on the table for each project. Organizational considerations include the skills of the people involved in the project. A primary project-level consideration that influences the methodology selection is whether the project is plan-driven or change-driven.
- A structured or “waterfall” SDM works best for extreme plan-driven projects where crossing the t’s and dotting the i’s may be more important than the actual deliverable.
- A “Spiral” or “Iterative” is best for projects where change happens but is not the driving factor.
- Strongly change-driven projects (which are the vast majority) are ideal candidates for the “Agile” approach.
“Plan Driven” versus “Change Driven” Drivers
The “Plan Driven” versus “Change Driven” factors are not typically under the discretionary control of the organization. The business environment and business needs dictate which approach is best. For example, a government mandate (such as a change to a law) creates plan-driven projects whereas the implementation of a new technology is commonly change-driven. In the first instance, the ultimate outcome is reasonably clear and definable up front whereas in the latter case, there is a significant amount of unknowns because the technology is evolving even while people are learning to use it. The business problem that the application will ultimately solve also plays a role. A structured approach generally deals best with problems of efficiency while agile or Iterative approaches are best for those dealing with effectiveness.
Business Value Delivery
A plan-driven approach maximizes the control of the project while minimizing up-front risk. Because change is difficult, the implementation risks can be considerably higher than recognized at the beginning of the project. A Plan-Driven approach does not deliver business value until the entire solution is ready for deployment. A Change-Driven approach delivers business value to the customer incrementally. It assumes change will happen and attempts to minimize the negative consequences. Changes made over the course of the project may even cause the final product to be quite different from originally planned.
A change-driven project, as the name implies, thrives on change. These projects need the “big picture” or high-level business requirements, but the one wearing the BA hat does not do detailed analysis and development of specific requirements until developers are ready to start work on the next release. A plan-driven approach generally requires a formal review of project artifacts at each stage of the project by a formal group whereas the change-driven approach favors an informal, personal (and quite often, conversational) review and acceptance of the working deliverables.
Documentation, Decisions, and Reviews
Plan-driven approaches appear to equate to large documentation whereas change-driven approaches are much more ad-hoc and informal. This is actually a natural by-product of each approach since it is necessary in plan-driven to maintain knowledge over a longer period or to meet regulatory requirements. Change-driven projects tend to assume that what was decided during this iteration will potentially change in the next iteration making it counterproductive to put a tremendous effort into documentation.
Because the plan-driven approach defines requirements early in the process, the project will have a specific time and task to prioritize the requirements. Those prioritizations are not likely to change much over the life of the project. On a change-driven project, priorities are relative and only of interest at the beginning of each release. Changing priorities will often lead to moving a feature into a future release.
How Does This Impact Business Analysis?
Regardless whether plan or change drives your project, the activities that you as the one wearing the BA hat perform are very similar. The requirements elicitation, analysis, modeling, and communicating techniques are just as critical. The major difference is in the timing and depth of the work. A plan-driven project will generally require a significant up-front effort to define the requirements as completely and accurately as possible prior to the commencement of design work and your primary responsibility thereafter is managing change. On a change-driven project, you do all of the aforementioned business analysis techniques throughout the project in an on-going effort to deal with the constant change.
As the one wearing the BA hat, you probably will not be able to select the ideal methodology for your project. However, you may have some influence and in any case should be aware of how the selected methodology influences your business analysis activities on the project. If you have influence, consider the organizational factors (culture, people, skills), regulatory factors (mandated paper trail), and the business problem(s) the project will solve to move those with the authority to make the decision toward the approach most likely to succeed.
