Iteration Workflow: Inception Phase
The inception phase is focused on establishing the business case and a baselined vision
for the project. The inception phase is of significance primarily for new development
efforts, in which there are significant business and requirements risks which must be
addressed before the project can proceed. For projects focused on enhancements to an
existing system, the inception phase is more brief, but is still focused on ensuring that
the project is both worth doing and possible to do.
Illustration of a Plan for the Initial Iteration of the Inception Phase
This illustration shows how a project begins, and how the various workflows relate. It
is constructed from the Workflow Details as they would appear at the time of the first
iteration of the project. The intent is to indicate dependencies and show where workflows
occur in parallel. The lengths of the bars in the chart (indicating duration) have no
absolute significance. For example, it is not intended to convey that Conceive New Project
and Plan Test must have the same duration. There is also no intention to suggest the
application of a uniform level of effort across the duration of the workflows. An
indication of the relative effort can be seen in the Process
Overview. You can navigate to the corresponding Workflow Detail pages from each line
of the chart - just click on the Workflow Detail name. This illustration was created from
a Microsoft® Project Plan.
|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. Prioritize those business processes that affects
the system being built, and detail those according to Workflow Detail: Refine Business Process
Definitions. Workflow Detail: Identify
Roles and Responsibilities and the Workflow
Details: Refine Roles and Responsibilities shows how you further refine your
understanding of the responsibilities that need to be carried out by the organization.
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
|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 Requests and an outline of the Artifact:
Consider the feasibility of the project, and outline the
|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 Software Development Plan,
mapping out the phases (Inception, Elaboration, Construction, and Transition), and major
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 Software Development 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.
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 Software
Development 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.