Information Technology Reference
In-Depth Information
and-material priced contracts. Whatever the case may be, the project acquisi-
tion phase would certainly include the definition of the scope of the project,
which is the initial requirement for the project.
2. Requirements elicitation/gathering—During this phase, Business Analysts
from the vendor organization (or internal analysts if requirements definition is
not outsourced) would elicit/gather the requirements from the client executives.
They would be using personal interviews and surveys to elicit the requirements
and study the existing process manuals, formats and templates to gather the
requirements. They would then be analyzed to form the project requirements.
Sometimes the requirements may be provided by the client along with the
purchase order. In such cases, the organization just needs to assess the received
requirements for adequacy and completeness.
3. Analyze the requirements—Subject the collated requirements to analysis to
determine their technical feasibility, eliminate duplicates, group them into
logical groups and prioritize them, Analysis is described in Chap. 4 of this
book.
4. Finalize the requirements—This involves documenting the analyzed
requirements to ensure that they are conforming to the agreed standards and
obtaining
internal
approvals
after
due
quality
assurance
process
of
the
organization.
5. Customer approvals—The finalized requirements would then be submitted for
customer review and approval. The customer would review the requirements
document and request improvement, if necessary, by providing the feedback.
When the customer is satisfied, approval would be accorded to the requirements
document. Now, this approved requirements document would be brought under
the vendor's configuration and change management process. This document
would be the reference point for all interaction between the customer and the
vendor in matters relating to project requirements.
Outsourced project—upgrade—Outsourcing a major product upgrade to a
vendor is risky as the source code needs to be provided to the vendor to upgrade the
product. It had to be done in the case of Y2 K conversion. Millions of LOC (Lines
of Code) had to be uploaded to vendor's computers for them to convert it to be
compliant with Y2 K requirements. No major breach-of-trust case was reported
arising out of stealing intellectual property contained in the source code even
though most of the upgrade is carried out overseas. In cases where the upgrade is to
re-develop the code on a new platform, of course, the original source code need not
be given to the vendor. Requirements in this scenario would evolve in this manner:
1. Project acquisition—In this scenario, the definition of scope would be much
more lucid than in the scope definition of a new project. This is due to the fact
that the product is working and the upgrade requirements are better defined. It is
usual to get a list of detailed requirements in the RFP (Request for Proposal)
itself. However, in platform upgrade, requirements may have to be elicited/
gathered
from
the
customer
executives.
The
RFP
provides
the
initial
requirements.
Search WWH ::




Custom Search