Sample Iteration Plan: 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 Define Evaluation Mission 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.

Sample Iteration 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 engineering 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: Design Business Process Realizations 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. In parallel with building the process realizations, you need to look at types of system sort, as described in Workflow Detail: Explore Process Automation. The degree of business engineering performed depends on the desired results. If the purpose of business engineering 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 engineering, 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 discipline, 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' 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: 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 Software Development Plan, mapping out the phases (Inception, Elaboration, Construction, and Transition), and major milestones. Define the high level approach to testing in a "Master Test Plan" (see Artifact: Test Plan).
Prepare the environment	Assess the current state of the project and its surrounding organization (see Workflow Detail: Prepare Environment for Project). The Role: Process Engineer develops a first version of the Artifact: Development Case. The Role: Tool Specialist selects tools for the project, and sets up the tools necessary to support the Requirements work. The Role: System Analyst produces a first draft of the Artifact: Use-Case Modeling Guidelines.
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 Role: 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.
Complete the iteration	The scope of the remaining work in this initial inception iteration (which is planned in the Artifact: Iteration Plan) will depend on the project manager's assessment of the risk (because, for example, the system is unprecedented, the domain is new to the development team, or the requirements are still not well understood or are particularly onerous). If the risk is low, there may be need for little more than clarifications of some requirements, in Workflow Detail: Refine the System Definition and Workflow Detail: Manage Changing Requirements, before a decision can be taken by the stakeholders to commit to development, and the elaboration phase can begin. If the risks are judged to be high, then it may be necessary to do more exploration in this initial inception phase iteration, as described in the (optional) Workflow Detail: Perform Architectural Synthesis, in which the Role: Software Architect determines a set of architecturally significant requirements, which are modeled or prototyped (in Activity: Construct Architectural Proof-of-Concept), with the objective of increasing confidence in the feasibility of the project. At the end of the initial inception iteration, the scope of the project and its associated risks are reevaluated to update the Business Case. Then the Iteration Plan for the next iteration is constructed; in parallel, the Software Development Plan and any of the artifacts it contains are updated, if this is warranted.

Result

The scope of the project should be understood, and the stakeholders initiating the project should have a good understanding of the project's ROI (return on investment), i.e. what is returned, for what investment cost. 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, architectural proof-of-concept, 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.