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.