Information Technology Reference
In-Depth Information
the project lasted for approximately nine months, forming the core of the initial
requirements effort.
Throughout the duration of the project additional requirements were identified
and explored. In general, this ongoing requirement identification was initiated by
the project's Functional and Project Management Leads. Through communications
with the users, the need for a functional or technical change was identified. Based
on these conversations, the Functional or Project Management Leads would draw
up a preliminary specification. The format for the specification documents evolved
over the course of the project, but was generally text-intensive. Its main graphical
component was the use of screen shots which were manually altered to convey a
desired change without reference to the underlying data structure.
Consensus around specifications and change requests was achieved through
walkthroughs. The walkthrough process was introduced roughly halfway through
the project under the recommendation from one of the consultants. The walk-
throughs were attended by the leadership of the project team, including the Project
Director; Functional, Technical, and Project Management Leads; the consulting
Project Manager and lead functional and technical consultants; and training team
representatives. No users, functional SMEs, or technical experts were in attendance.
During the walkthroughs, the spec developer would guide the participants through
a detailed discussion of a requested change and process. Questions were raised and
debated by the entire project team. The walkthroughs generally resulted in three
outcomes: (1) the specification was accepted and the Technical Lead took respon-
sibility for scheduling modifications, (2) the discussion raised sufficient problems
with the current status of the specification so that a decision was made to revise the
document, or (3) the specification was tabled for later discussion.
As noted, the training team was responsible for the determination and resolution
of training requirements. Training requirements were determined through several
sources. First, many of training requirements were outlined in the PeopleSoft doc-
umentation. Second, the IDP process highlighted several of idiosyncratic training
requirements across the university. Finally, the training team identified a range of
additional requirements through the mapping of business processes across the nine
schools. Perhaps surprisingly, business process mapping was not undertaken at the
initiation of the project. Rather, it was first begun by one of the consultants working
with the internal training team. The business process maps were developed outside
of the development platform using Microsoft Visio. The process maps turned out to
be a critical asset, supporting not only the identification of training requirements but
also functional requirements that had not emerged in the initial IDP exchanges.
4.2 Integrated Public Safety Initiative (IPSI)
The Integrated Public Safety Initiative (IPSI) was a multi-party project aimed
at establishing effective information sharing across members of the law enforce-
ment community within a one of the largest counties on the east coast of the
Search WWH ::




Custom Search