Page 514 - Using MIS

482 Chapter 12 Information Systems Development

In some projects, we can reduce costs by increasing time. If, for example, we are required
to pay laborers time-and-a-half for overtime, we can reduce costs by eliminating overtime. If
finishing the deck—by, say, Friday—requires overtime, then it may be cheaper to avoid over-
time by completing the deck sometime next week. This trade-off is not always true, however.
Extending the project interval means that we need to pay labor and overhead for a longer pe-
riod; thus, adding more time can also increase costs.
Consider how these trade-offs pertain to information systems. We specify a set of require-
ments for the new information system, and we schedule labor over a period of time. Suppose
the initial schedule indicates the system will be finished in 3 years. If business requirements
necessitate the project be finished in 2 years, we must shorten the schedule. We can proceed in
two ways: reduce the requirements or add labor. For the former, we eliminate functions and fea-
tures. For the latter, we hire more staff or contract with other vendors for development services.
Deciding which course to take will be difficult and risky.
Using trade-offs, the WBS plan can be modified to shorten schedules or reduce costs. But
they cannot be reduced by management fiat.

Manage Development Challenges

Given the project plan and management’s endorsement and approval, the next stage is to do
it. The final WBS plan is denoted as the baseline WBS. This baseline shows the planned tasks,
dependencies, durations, and resource assignments. As the project proceeds, project managers
can input actual dates, labor hours, and resource costs. At any point in time, planning applica-
tions can be used to determine whether the project is ahead of or behind schedule and how the
actual project costs compare to baseline costs.
However, nothing ever goes according to plan, and the larger the project and the longer
the development interval, the more things will violate the plan. Four critical factors need to be
considered:
1. Coordination
2. Diseconomies of scale
3. Configuration control
4. Unexpected events

Development projects, especially large-scale projects, are usually organized into a variety
of development groups that work independently. Coordinating the work of these independent
groups can be difficult, particularly if the groups reside in different geographic locations or dif-
ferent countries. An accurate and complete WBS facilitates coordination, but no project ever
proceeds exactly in accordance with the WBS. Delays occur, and unknown or unexpected de-
pendencies develop among tasks.
The coordination problem is increased because software, as stated, is just thought-stuff.
When constructing a new house, electricians install wiring in the walls as they exist; it is impos-
sible to do otherwise. No electrician can install wiring in the wall as designed 6 months ago,
before a change. In software, such physical constraints do not exist. It is entirely possible for a
team to develop a set of application programs to process a database using an obsolete database
design. When the database design was changed, all involved parties should have been notified,
but this may not have occurred. Wasted hours, increased cost, and poor morale are the result.
Another problem is diseconomies of scale. The number of possible interactions among
team members rises exponentially with the number of team members. Ultimately, no matter
how well managed a project is, diseconomies of scale will set in.
As the project proceeds, controlling the configuration of the work product becomes diffi-
cult. Consider requirements, for example. The development team produces an initial statement
of requirements. Meetings with users produce an adjusted set of requirements. Suppose an
event then occurs that necessitates another version of requirements. After deliberation, assume
the development team decides to ignore a large portion of the requirements changes resulting