Chapter 11 • IT Project Management 417Work breakdownis a basic management tech-
nique that systematically subdivides blocks of
work down to the level of detail at which the proj-
ect will be controlled.Time estimates are typically based on the relevant
past experiences of the organization or the project manager,
or both. Other sources for time estimates include bench-
marking studies for similar projects in other organizations,
activity estimates embedded in software estimation pack-
ages, and project databases of system consultants.
The detailed work activity list, the task interdepen-
dencies, and the time estimates for each task are then used
to develop a master schedule for the project that identifies
theproject milestonedates and deliverables. The level of
detail provided in a master schedule depends upon project
characteristics such as size, functional complexity, and
task interdependencies, as well as organizational practices.
Some project milestone dates will also be highly
influenced by time demands particular to the organization.
System implementation activities are frequently scheduled
to coincide with calendar periods when transactions affected
by the new system solution are much lower in number or can
even be temporarily left unprocessed during the conversion
to the new system. For example, it is very common for
major system tests and new system cutovers in U.S.-based
organizations to be scheduled for three-day holiday week-
ends. In other situations, a project implementation date near
the end of a fiscal period will be targeted in order to mini-
mize historical data conversions.
The project scheduling process is somewhat differ-
ent when an organization has adopted a timeboxing philos-
ophy. The term timeboxingrefers to an organizational
practice in which a system module is to be delivered to the
user within a set time limit, such as six months. (This tech-
nique is a characteristic of the rapid application develop-
ment [RAD] methodology discussed in Chapter 9.)
Because the intent of timeboxing is to deliver new IT solu-
tions as rapidly as possible, a work plan might be designed
in which a given module is initially implemented during
the timebox without full functionality, and then the func-
tionality is increased in subsequent releases.
A common pitfall in developing a master schedule
is a failure to understand the interdependencies among
project tasks and subtasks. Including a customer verifica-
tion step as part of the master scheduling process can
help identify misunderstandings at an early stage of the
project planning cycle. Another common pitfall is esti-
mating task completion times based on a level of expert-
ise associated with an experienced worker, rather than the
average worker typically available in the organization.
Effective scheduling is critical to the project’s suc-
cess and is a key input to the project budgeting component.
However, the master schedule is also meant to be a living
document. A good planning process therefore also pro-
vides for change-control procedures to request schedule
changes. Aside from a process to request the necessary
management approvals, changes to the master schedule
should be documented with the date of the change, the
nature and reason for the change, and the estimated effects
of the change on other project components (e.g., budget,
resource allocations) and related project tasks.Budgeting
The project budget documents the anticipated costs for the
total project. These costs are typically aggregated into
meaningful categories at the level at which the project
costs will be controlled.
There are two traditional approaches to estimating
project costs: bottom-up and top-down. The project work
plan from the scheduling process is typically used for a bot-
tom-up process: Cost elements are estimated for the work
plan tasks and then aggregated to provide a total cost esti-
mate for the project. According to Frame (1994), a top-down
approach “eschews” the cost details and provides instead
estimates for major budget categories based on historical
experience. A top-down approach (also called parametric
cost estimating) could be used in the project initiation stage
because not enough is known about the project to do a work
breakdown analysis. However, once a master schedule has
been developed, a bottom-up process is recommended,
especially if the project is large and complex. These two
approaches can also be used as checks for each other.
No matter which approach is used, the budgeting
process needs to build in cost estimates to cover project
uncertainties associated with changing human resources,
immovable project deadlines (that could require overtime
labor), as well as changes in technology and contract costs
outside the organization’s control.
Like the master schedule, the project budget is a liv-
ing document of anticipated total costs. A good planning
process therefore also provides change-control procedures
to request approvals for deviations from an estimated
budget. Changes to the budget should be documented with
the date of change, the nature and amount of the requested
budget deviation, the reason for the change, and the esti-
mated effects of the change on other project components
(e.g., scope, schedule, resource allocations).
According to Frame (1994), inexperienced estima-
tors typically fall into three estimation traps: They (1) are
too optimistic about what is needed to do the job, (2) tend
to leave components out, and (3) do not use a consistent