Information Technology Reference
In-Depth Information
However, when conflicts did not allow for a mutually satisfactory resolution, an
appeal to authority was invoked, specifically allowing the Prosecutor's Office to
make the determination as to the path to be followed.
5.9 Prioritization
Indeed, the failure in prioritization was a significant source of tension within the
SIS project team. An illustrative comment came during one of the requirements
walkthroughs as one of the lead consultants remarked in exasperation, “As far as I
can tell, we've spent about six months pouring over minutiae because some of us
don't have the ability to say 'No!'.” The need for prioritization was underscored by
requests for customization that were essentially limitless:
I think the challenges are to not go crazy with modifications, because you can modify the
system so easily. We could do everything that everybody wanted but it would take us ten
years. Essentially, from the users, there would be an endless stream of requests if it were
allowed.
-
SIS Training Manager
Despite a clear recognition of the need for prioritization, the SIS project team had
no formal mechanism for prioritizing changes. Rather, the primary mechanism for
determining the necessity of various changes was the input of the Functional Leads
and the discretion of the Project Manager and Technical Lead.
Within the IPSI project, the need for prioritization was widely acknowledged,
but not perceived to be fundamentally problematic. As with the SIS project, the
IPSI team lacked formal mechanisms for prioritization, but they did obtain some
simple heuristics to guide the customization of the system. For example, return-
ing the issue of reporting standardization, the BSI Project Manager explained his
prioritizing approach:
What I've done is I've taken all of that information in [feedback on desired fields], as much
as I've gotten back, and I've come up with a matrix. We've got six or seven columns of
responses. If we have five or more checked, that's going in a report guaranteed. It has to go
in. If it's three to four, we'll consider it. If it's only one or two agencies, we're not going to
do it. That's just a starting point.
In contrast to the SIS project, the IPSI project team felt comfortable that pri-
oritization would emerge naturally. Again, this stance reflected the project's overall
focus on requirements evolution rather than a priori clarity with respect to all agency
needs.
5.10 Diversity of Inputs
Given the nature of the two projects analyzed, the diversity of inputs was relatively
high in both settings. On the University SIS project, requirements were derived
from a wide range of sources, including the vendor platform (PeopleSoft), multiple
legacy systems, individual schools and functional departments, and the project con-
sultants. While the challenges of integrating the consultants' requirements have been
Search WWH ::
Custom Search