When creating a new project, engagement, or product from scratch, we should think in terms of its full life cycle. For this reason I have drawn the diagram of my business analysis engagement framework with two extra cycles. One shows an extended period of operation and maintenance, where the originally delivered capability is exercised by the customer for its intended use. During this time the system may be maintained, modified, and updated. When the delivered capability as a whole is no longer useful, it is retired and replaced. This is shown as a separate and final phase of a long-term engagement.
Here are the all the possible phases in the context of a full life cycle engagement, with the two new additional phases added. The new phases occur after the initial engagement has been closed out, including final delivery, acceptance, and handover to the customer. Note that different internal and external vendors or consultants may serve on different engagement teams during the initial engagement phases and the extended support and retirement phases.
The Framework:
- Project Planning
- Intended Use
- Assumptions, Capabilities, and Risks and Impacts
- Conceptual Model (As-Is State)
- Data Sources, Collection, and Conditioning
- Requirements (To-Be State: Abstract)
- Functional (What it Does)
- Non-Functional (What it Is, plus Maintenance and Governance)
- Design (To-Be State: Detailed)
- Implementation
- Test
- Operation, Usability, and Outputs (Verification)
- Outputs and Fitness for Purpose(Validation)
- Acceptance (Accreditation)
- Project Close
- Operation and Maintenance
- End-of-Life and Replacement
Here is the above list in the more stylized and streamlined form I show in the main figure(s).
The Framework: Simplified
Intended Use
Conceptual Model (As-Is State)
Data Sources, Collection, and Conditioning
Requirements (To-Be State: Abstract)- Functional (What it Does)
- Non-Functional (What it Is, plus Maintenance and Governance)
Design (To-Be State: Detailed)
Implementation
Test- Operation, Usability, and Outputs (Verification)
- Outputs and Fitness for Purpose (Validation)
Operation and Maintenance
End-of-Life and Replacement
Discussion of these topics is always a bit vague in the BABOK, because the business analysis oeuvre explicitly differentiates itself from the project management oeuvre (see here for a discussion of the overlaps), and also because the BABOK tries not to be overly prescriptive. It gives you a whole bunch of techniques and contexts and ways of thinking about things, but it never says, “Do A, then do B, then do C.” My framework may appear to be at least a little bit prescriptive, but it isn’t really. It really just codifies language that is already in the BABOK, and it gives practitioners a better feel for what they’re doing and when and why. I discuss how the main phases all occur in different contexts and management approaches here. I touch of the same things in my standard presentation on my overall framework.
In keeping with this amorphousness and flexibility, I’ll point out that individual modifications to an existing, deployed capability are themselves independent engagements with all six of the standard phases. This is true even if there are many such modifications over a long period of time, and even if individual ones are small and informal enough not to require large-scale efforts in every phase. I include the figure below for illustration of the idea.
Indeed, the End-of-Life and Replacement phase is likely to be a full engagement on its own.