Define
Vision and Business Case (Initial Iteration in Inception)
Context
Green-field development.
Sample
Iteration Workflow
Preliminary: Define the Business Context (optional) |
In cases where the system is being built to support a new or significantly changed
business process, some context-setting business modeling can help to better define the
environment in which the system will operate. This is especially useful if the
stakeholders are having difficulties expressing the requirements on the system needed to
support the new or changed business process, or have difficulty separating what the new
system will do as opposed to what the new business process will do. Defining the
business context starts with Workflow Detail:
Identify Business Processes and Workflow
Detail: Identify Roles and Responsibilities. These initial definitions are then
elaborated in Workflow Detail: Refine Business
Process Definitions and Workflow Details:
Refine Roles and Responsibilities. Beginning at the same time as the initial
business process definition, the Workflow
Detail: Domain Modeling should be used to capture the vocabulary and common terms of
the business. Once the business processes stabilize, domain modeling is performed to
define the business workers and entities.
The degree of business modeling performed depends on the desired results. If the
purpose of business modeling is merely to set context for the system, the effort should be
restricted to the subset of the business which will be supported by the system to be
developed. Further business modeling, while perhaps valuable for other reasons,
tends to be de-focusing for the system development team. |
Start up: Define the vision and scope of the system. |
The Stakeholders of the system to be developed,
working with System Analysts, define the vision and
the scope of the project (see Workflow Detail:
Analyze Problem in the Requirements workflow,
and the Artifact: Vision). The driving factor to
consider in this effort is the user's needs and expectations. Also considered are
constraints on the project, such as platforms to be supported, and external interfaces.
Based on the early sketches of the Vision, start to define the Artifact: Business Case and document the important
risks in the Artifact: Risk List. |
Outline and clarify the functionality that is to be provided
by system. |
Conduct sessions to collect stakeholders's opinions on what the system should do. This
can be done using various techniques(See Work
Guidelines: Storyboarding and Work Guidelines:
Brainstorming). You can also include building an initial outline of the Artifact: Use-Case Model in this session. The Artifact: Glossary will likely be started to simplify
the maintenance of the use-case model, and to keep it consistent. See Workflow Detail: Understand Stakeholder Needs.
The main result of these sessions is the Artifact:
Stakeholder Needs and an outline of the Artifact:
Use-Case Model. |
Consider the feasibility of the project, and outline the
project plan. |
With the input from the use-case modeling, translate the Artifact: Vision into economic terms, updating the Artifact: Business Case, factoring in the project's
investment costs, resource estimates, the environment needed, and success criteria
(revenue projection and market recognition). Update the Artifact:
Risk List to refer to the identified use cases and add new identified risks. Establish
the initial Artifact: Project Plan, mapping out the
phases (Inception, Elaboration, Construction, and Transition), and major milestones. |
Refine the project plan. |
At this stage, the stakeholders of the system to be developed should have a fairly
good understanding of its vision and the feasibility of the project. An order of priority
among features and use cases is established (see Workflow Detail: Manage the Scope of the System,
Artifact: Iteration Plan, and Artifact: Vision). The Worker: Project Manager refines the Artifact: Project Plan, mapping out a set of
iterations using the prioritized use cases and associated risks (see Artifact: Risk List). The plans developed at this
point are refined after each subsequent iteration and become more accurate as iterations
are completed. Note: this is a key differentiator in using this process - recognizing that
initial project plan estimates are rough estimates, but that those estimates become more
realistic as the project progresses and there are real metrics on which to base estimates;
successive refinement of the project and iterations plans is both expected and essential. |
Result
The result of this initial iteration is a first cut at the Artifact: Vision and the Artifact: Business Case of the project, as well as the
scope of the project and the Artifact: Project Plan.
The stakeholders initiating the project should have a good understanding of the project's
return on investment (ROI), that is, what is returned at what investment costs. Given this
knowledge a go/no go decision can be taken.
Subsequent Iterations In Inception
In cases where the project involves new product roll-out or creation of new technology,
subsequent iterations may be needed to further define the scope of the project, the risks
and the benefits. This may involve further enhancing the use-case model, business case,
risk list or project and iteration plans. Extension of the Inception phase may also be
advisable in cases where both the risk and the investment required are high, or where the
problem domain is new or the team inexperienced.
| |

|