Project Management and the Inception Phase

Project management is one of the key disciplines of the inception phase. Activities associated
with business modeling and the environment provides much of the detailed information that the
development team uses to finalize the project’s scope and plans.

Thus, the project management discipline integrates the other activities. During the inception
phase, the initiating and planning processes are the primary focus. The following list identifies
the main activities involved in initiating and planning the project:

• Finalize the system and project scope

• Develop the project and iteration schedules

• Develop the work breakdown structure (WBS), including intermediate deliverables

• Develop the schedule

• Develop resource requirements and the staffing plan

• Identify project risks and confirm project feasibility

• Assess the risks to the project (risk management)

• Determine the organizational/cultural feasibility

• Evaluate the technological feasibility

• Determine the schedule feasibility

• Assess the resource feasibility

• Determine the economic feasibility (cost/benefit analysis)

Finalizing the system and project scope

The activities associated with business modeling discussed previously—defining the business
environment and creating the system vision—lay the foundation for finalizing the project’s
scope. This key project management activity has the objective of ensuring that the scope of the
new system and the project to develop it are well defined. Note that we distinguish between
system scope and project scope. The system scope defines what is going to be built, and the
project scope describes how it is going to be built. For example, maybe the project is to develop
a new inventory management system. The system scope will define the capabilities that need to
be included in the new system. The project scope might describe whether the project will include
staff training and data conversion. Project scope also defines how much acceptance testing will
be required, as well as other quality control checks. As shown in Figure 3-8, we can consider the
system scope to be a component of a larger project scope.
In Chapter 2, we discussed some of the
current adaptive systems development
(ASD) approaches to building
software systems. With the ASD
approaches’ emphasis on speed and
iterations, you may wonder how
important defining the scope is. At one
extreme you could say, “Just let the
projects happen, and we will identify
what we need as we go,” but this view is dangerous. Every project has a limited budget and time
constraints. One of the benefits of determining the scope is that we can prioritize the system
capabilities to maximize the business benefits. If the scope is not identified, we may spend all of
our time and money on functions that do not provide the needed capabilities. We can also
identify criteria to know when we are finished with the project.

A major problem causing projects to fail is a phenomenon called scope creep, which is the
addition of new functions to a system after the project is under way. It has always been a concern
with predictive system development, whereby we try to precisely define the scope at the
beginning of the project. But with the adaptive approach, since the scope is more flexible, scope
creep can become a very serious problem. The user and the development team are often tempted
to “add this one little feature,” but doing so can cause serious delays and reversals in a project.

System scope can be defined in several ways. In fact, we began developing the system scope
during business modeling, when we defined the business benefits, the system objectives, and the
system capabilities. The points on those lists describe what the system is expected to accomplish
and the capabilities necessary to meet the objectives.

Many times project teams build some preliminary models to help delineate the scope of a system.
One model that is often built during the inception phase is the essential use case model. A use
case is a brief statement of what the system must do to respond to a business event. The essential
use cases are those that are most critical to a business. An example might be to “Create a new
customer order.” The business event is that the customer wants to buy something, so the system
must respond by creating an order. We describe how to identify and build a use case model in
detail in Chapter 6.

At this point in the project, the essential use case model is used as you would a table of contents
—to list the use cases that will be needed in the new system. Below bullet points illustrates a
sample essential use case list for RMO. Obviously, the essential use case model must be
consistent with the system objectives and the list of system capabilities identified earlier. The
essential use case list is attached to the project charter and becomes another document in that
package.

• Look up item availability

• Create new order

• Update order

• Ship an order

• Return an item

• Back-order an item
 • Create new customer

• Maintain customer account

• Create a new catalog

• Update a catalog

• Create special promotion

• Send promotion materials

Project scope is defined using a work breakdown structure, which is explained in the next
section.