In our most recent post, Cheryl explored how business analysis can be used whenever products, services or processes are being created or enhanced, or when seeking to understand customer needs. She gave some great examples of how business analysis can be applied not only to IT projects, but within non-IT environments as well. In this post, let’s take a brief look at the relationship between business analysis and the life cycle used on projects which develop or enhance products, services and processes.
Within the PMBOK® Guide, project life cycles range from plan-driven predictive life cycles, such as are used on plan-driven building construction projects or “waterfall” software development, all the way to change-driven adaptive life cycles, such as are used in lean building construction or the publishing industry or in marketing or in agile and lean software development. The project activities within these life cycles often differ in many ways; they are generally of differing duration, sequence, and concurrency. They often are conducted with different levels of formality, and different techniques and tools. They often differ on when and how the product is delivered to its stakeholders for feedback. These life cycles also differ in whether there is an expectation that project team members will focus on one role or will be able to take on other roles in addition to their specialties.
Despite the differences between the life cycles, there is still a lot of commonality between them. One important area of commonality is that no matter what life cycle is used, you still have to understand the problem you’re trying to solve in order to consider solution options to address it. Business analysis practices are at the heart of that commonality. No matter what the life cycle may be, business analysis thinking is needed to help identify and confirm stakeholders, to define and confirm scope, to clarify the understanding of the problem at hand, to understand the usages which the solution must support, as well as to prioritize how the solution will be delivered. Business analysis thinking is also needed to articulate the solution to whatever degree of detail is necessary and sufficient to guide those who have the expertise to architect it or design it or construct it, or to test to confirm that it meets expectations.
Activities which enable elicitation, analysis and all the other business analysis knowledge areas need to occur, no matter what the life cycle may be. For example, using models can be a great help to a project. Models created as part of a project using an adaptive life cycle may be much less formal than those created as part of a project using a predictive life cycle, yet they serve the same purpose: to help people think and reason together to understand a problem and its solution.
You can expect the Foundational Standard in Business Analysis to highlight the commonality of business analysis thinking which needs to take place in any project while honoring the differences in how that thinking is accomplished ::-).
Perhaps you have examples of how the same kind of business analysis thinking occurs during predictive and adaptive life cycles? Or maybe you have a differing perspective. Either way, we’d love to hear from you!!
