Project Management And The Inception Phase 6e3e14

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 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

•

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.