Objective
The objective of this phase is to ensure that there is a somewhat reasonable expectation that a reliable, effective software can be built on time and within cost to meet the customer request.
Initiation activities are meant to ensure that the customer request:
(1) aligns with the Mission & Vision of the University
(2) presents no legal or ethical infringements or liabilities
(3) is not a replication of an existing system or one that is currently in development for the university
(4) provides a high-level statement of work (SOW) that is refined enough to allow advancement into the Planning phase
Entry Criteria
The Initiation activity begins when an IT Service Request is received from a customer and the intake authority considers the request to be reasonable and worthy of investigation.
Roles & Responsibilities
Customer/Requestor – It is the responsibility of the Customer or Requestor to clearly explain the value and purpose of the effort to include the necessary and expected business benefits anticipated with the completion of the project. There should be a presentation on the background of the problem at a high level that covers the business problem, known issues and opportunities to improve the campus community. Unless there is an inflexible constraint resulting from funding (e.g., grant guidelines), the customer should avoid proposing any specific technology or product to be used to meet requirements.
Intake Authority (IA) – The primary job of the Intake Authority when reviewing the project request is to determine that the value of the proposed project makes it a worthwhile undertaking for the University. The proposed endeavor needs to be compared with other efforts at the University and within IT to determine its value and to ensure there is no duplication of effort across existing projects. Additionally, the IA will need to determine if IT has appropriate resources to handle the proposed project. As part of the identification of resources, the senior IT Stakeholder and senior Customer Stakeholders must be identified for the purpose of making high level decisions throughout the SDLC. The IA must work with the customer to ensure a project sponsor is in place to support the effort. The project priority must be determined and conveyed to the customer.
IT Technical Assessor – A Technical Assessor (Evaluator), usually at the level of project manager within an appropriate IT department, provides a more comprehensive analysis of the customer request to ensure the goals of the project are attainable.
Common Artifacts
Formalized Request describing of the need or opportunity to improve the campus community through the successful implementation of the proposed project. The description should include the identification of where campus needs and opportunities are currently not being met.
Project Evaluation document contains statements indicating that the items identified in the Objectives of this phase were considered and the associated findings.
Review (Revision)
The IA provides the high level project background information to the IT Technical Assessor (Evaluator) so that the Project Evaluation Form can be completed. When the IT Evaluator completes the report it is reviewed by the IA to ensure that the project is still considered viable and desirable. Revision to the customer proposal can be made if the Project Evaluation Form highlights significant risks.
Approval
The project advances to the Planning Activity when the IA approves the Conceptual Proposal and Project Evaluation Form. For larger, more complex projects, the IT and functional leadership will review and approve the Evaluation Form and make the recommendation to move to the Planning Phase.
Exit Criteria
The existence of a Conceptual Proposal (intake and evaluation) approved by the appropriate IT and functional leadership will signify the end of this activity.