Before We Start, Is Your Idea/Initiative Actually a "Project"?
Make sure your idea or initiative fits the definition of a project, as follows:
- A temporary endeavor with a beginning and an end.
- Creates or enhances a unique campus IT product or service or prepares members of the campus community for the shutdown of an existing IT service.
- Is progressively elaborated, i.e., the project requirements, plans, and schedule become increasingly detailed over time as the project is better understood.
- Requires the participation of two or more IT team members for a duration of one month or greater.
If your idea meets the above criteria, make a formal request to start a project via one of the two options below. NOTE: It is common to perform a "Discovery Project" to figure out what your real project needs to look like. A typical discovery project usually includes defining high-level (though not necessarily formal) business requirements and may also include business process analysis (as-is, to-be), exploration of vendor options, and a small prototype or pilot. Generally speaking, a well-planned discovery project results in the team uncovering enough about the scope and solution approach to enable them to write a solid Project Charter. Also generally speaking, the larger a project is likely to be, the more valuable a discovery project will be to its eventual success.
Request Enterprise IT Project via the Systems Governance Group (SGG)
Request one-time capital funding for Enterprise Systems, i.e., IT systems that enable us to run the university:
- Student applications, enrollment, course selection, course management, grading
- Faculty and staff hiring, payroll, benefits, performance management
- Financial transactions, purchasing, vendor payments, reimbursement
- Research proposals, awards, sub awards, closeout, certification
- Email and calendar
- Data warehouse, reporting, and analytics
Learn Moreabout requesting an enterprise IT project via the Systems Governance Group (SGG)
Non-SGG Project Requests
To request a new, non-SGG funded IT project:
Project Management Life Cycle Explained
*A common misconception among project stakeholders is the erroneous belief that the Software Development Life Cycle (SDLC) is a project management methodology. There are even some who believe the inverse, that the SDLC is contained within traditional project management methodologies. In truth, neither is quite correct, and it's more than just semantics. Here's why:
The Software/Systems Development Life Cycle is a methodology that forms the framework for planning and controlling the creation, testing, and delivery of an information system. More specifically, the SDLC process is composed of a number of clearly defined and distinct work phases that are used by information technology resources, such as systems engineers and systems developers, to plan for, design, build, test, and deliver information systems. The SDLC is about quality, consistency, and product delivery in the realization of a product's requirements. In recent years, SDLC methodology has been modified to become more streamlined and less "waterfall" based, with the popular Agile approach being one example.
Project Management Methodology, on the other hand, is the application of knowledge, skills, tools, and techniques to meet project requirements through planning, organizing, measuring, controlling, and reporting upon resources (human, financial, and time). Best practices within traditional project management disciplines list five main phases or "process groups" that include Initiation, Planning, Executing, Monitoring & Controlling, and Closing. The management of a project includes identification of requirements; balancing stakeholder needs/expectations/concerns; and balancing competing constraints (scope, quality, schedule, budget, resources, and risk). Within each phase, tasks are defined to move from one phase to another until the project is closed.
The important distinction between the two is that the SDLC is completely focused on the phases, tasks, resources, and plans needed to deliver information systems. Project management methodology is more agnostic; its process set and approach can be applied to any temporary endeavor with a defined beginning and end, whether it's a construction project, a school research project, planning a move from one city to another, or even an IT infrastructure upgrade project.
* "The SDLC is *NOT* a Project Management Methodology" by Paul R. Williams
The guidance that follows is organized by the Project Management Life Cycle processes; the SDLC process steps are mapped to each at the point when they're performed, specifically in the Planning (Business Requirements), Execution, and Monitoring & Controlling processes.
Project Initiation
A project is formally started, named, and defined at a broad level during this phase. Project sponsors and other important stakeholders perform their due diligence and decide whether to commit to the project. At a minimum, high-level business requirements-gathering is required in this phase. Other activities can include concept development, requests for proposals (RFP), fit-gap analyses, cost-benefit analyses, feasibility studies, and risk management planning— all of which culminate in a Statement of Work (optional) and Project Charter (required).
Statement of Work (SOW)
A Statement of Work (SOW) is an optional input to a Project Charter. It is a document that describes the business need and an overview of the qualities/characteristics of intended deliverables/products that the project would provide. The SOW also describes what is and is NOT included in the project. The Project Manager coordinates creation of the SOW, but most of the content comes from the business project sponsor and business owner.
Project Charter
The Project Charter is a formal document that authorizes the project and gives the project manager the authority to spend the project budget. It is required for UIT-managed projects. The Project Charter defines the project's business case, scope, goals, metrics of project success, major milestones, and high-level risks. It identifies the key stakeholders and the project team members, including the roles and responsibilities of each. The Project Manager coordinates creation of the charter, but most of the content comes from the business project sponsor and business owner.
Project Definition and Planning
A project management plan is developed comprehensively of individual plans for cost, scope, duration, quality, communication, risk, and resources. Some of the important activities that mark this phase are completion of the Project Initiation Checklist (strongly recommended) and creation of a Work Breakdown Structure (WBS— optional foundation of a project plan). A project plan, which estimates and reserves resources, plans dates and modes of communication with stakeholders based on milestones, deadlines, and important deliveries, is required. This phase is also marked by the creation of a Business Requirements Document (BRD). A plan for managing identified and unidentified risks is determined, as this may later affect aspects of a project. Risk management planning includes risk identification and analysis, risk mitigation approaches, and risk response planning.
Project Initiation Checklist
The Project Initiation Checklist is used primarily on Enterprise Technology projects and should be started by the Project Manager as soon as funding for the project is approved. While not all project initiation steps are required or apply to a given project, even those that are indicated as optional/as applicable should be carefully reviewed.
Project Plan/WBS
The Project Plan is one of the most critical (required) parts of an IT project; its development is led by the Project Manager. Both seeded Work Breakdown Structure (WBS) and generic Project Plan templates are available to start your project plan. Detailed instructions on how to set up the project in Smartsheet, the UIT PMO project management tool of choice, are also provided to ensure that the project appears on the UIT Project Dashboard.
Project Resource Plan
A resource plan is used primarily on Enterprise Technology projects to collect information about project resources, the allocation of their time to the project, and the information about their expected charges for project activities that make up the project budget. The budget and planned spend to-date information in the resource plan template, together with the project plan template, allow the project dashboard to be easily generated. This template should be your backup for your project charter cost table; it is required for UIT-managed projects.
Business Requirements
A business requirements document (BRD) details the customer/user needs and expectations and is the foundation for all subsequent project deliverables; it is written by the project Business Analyst. The BRD should answer the question, "What does the business want to do?" Business requirement whats do not decompose into product/system/software requirement hows. Rather, the products and their functional/technical specifications represent a response to business requirements— presumably, how to satisfy what.
Project Implementation
This phase is where the actual implementation/execution work takes place to realize the stated project objectives and scope defined in the project charter. Project tasks and deliverables are completed, adhering to the project plan, starting with a project kickoff meeting. By this point, the planning (or at least a significant portion of it) has been completed so that there is a first set of baseline requirements and planning documents to begin project execution (UIT uses the term "Implementation"). There are six significant Software Development Life Cycle (SDLC) task groupings that take place during this phase:
- Functional Design
- Technical Design
- Development and/or Integration
- Systems Integration Testing (SIT)
- User Acceptance Testing (UAT)
- Implementation and Change Management
Expect that everything will not go as planned during project implementation/execution. There will be normal variances that pop up over the course of project implementation/execution, which might require updates to planning documents, requirements, risk registers, quality assurance procedures, communication strategies, etc.
Agile Development Methodology
Agile came about as a "solution" to the disadvantages of the waterfall methodology. Instead of a sequential design process, the Agile methodology follows an incremental approach. Developers start off with a simplistic project design, and then begin to work on small modules. The work on these modules is done in weekly or monthly sprints, and at the end of each sprint, project priorities are evaluated and tests are run. These sprints allow for bugs to be discovered, and customer feedback to be incorporated into the design before the next sprint is run. UIT primarily utilizes the Scrum methodology for our Agile-managed projects.
Functional Design
The Functional Specification Document (FSD) is written by the project Business Analyst and provides detailed information on how the system solution will function what the requested behavior is. This document is created based on the high-level requirements identified in the Business Requirements Document and provides traceability from the functional specification back to the business requirements.
Technical Design
A technical specification or Technical Design Document (TDD) is written by the development team and describes the minute detail of either the entire design or specific parts of it, such as:
- The signature of an interface, including all data types/structures required (input data types, output data types, exceptions)
- Detailed class models including all methods, attributes, dependencies and associations
- The specific algorithms that a component employs and how they work
- Physical data models including attributes and types of each entity/data type
In short, the functional design specifies how a program will behave to outside agents and the technical design describes how that functionality is to be implemented in code. The Technical Design Document must be approved by the IT project sponsor before proceeding to the development/integration phase.
Development/Integration
During the Development/Integration phase, the system developers take the detailed logical information documented in the previous phase and transform it into machine-executable form, ensuring that all the individual components of the system/application function correctly and interface properly with other components within the system/application. The Development Phase should conclude with a stage gate review to determine readiness to proceed to the System Integration Test (SIT) phase. The Project Manager, coordinating with the development lead, is responsible and accountable for the successful execution of the Development phase and leading the integrated project team that accomplishes the Development phase activities and deliverables.
System Integration Testing (SIT)
SIT is primarily performed on Enterprise Technology projects to demonstrate that different pieces of the system work together. System integration tests cover entire applications (including interfaces to external systems). This function-driven phase assures that the customizations, configurations, and functionality all work as expected per the Functional Design Specifications, Technical Specifications, Business Requirements and other applicable documents. It ensures that the system was correctly built, i.e., per the specs. An SIT Exit Criteria Checklist is prepared by the Project Manager and must be approved by both the business and IT project sponsors before SIT is considered complete and UAT may begin.
User Acceptance Testing (UAT)
UAT, which is performed on most UIT projects, sometimes called beta testing or end-user testing, is a phase of software development in which the software is tested in the "real world" by the intended audience or business representative. This type of testing is not intended to be menu-driven, but rather to be performed by business users to verify that the application will meet the needs of the end-user, with scenarios and data representative of actual usage in the field.
Implementation and Change Management
The overall objective of change management is to ensure a smooth transition from current state to future state with minimal disruption to campus business operations while fully leveraging the capabilities of the new or enhanced system/application.
In addition to change management execution, the implementation phase includes Project Manager preparation and execution of a Rollout (aka Cutover) Checklist, which documents the detailed steps (and business/IT owners of each) necessary to take the system/application "live," in other words, into full, real-world use by campus users.
Project Monitoring and Controlling
Occurring at the same time as the implementation phase (although some monitoring and controlling activities will start as early as the initiation phase), this phase mostly deals with measuring the project performance and progression in accordance with the project plan. Scope verification and control occur to check and monitor for scope creep, as well as change control to track and manage changes to project requirements. Calculating key performance indicators for cost and time are done to measure the degree of variation, if any, and in which case corrective measures are determined and suggested to keep a project on track.
Executive Summary Reports
A project Executive Summary Report is required for all Business Affairs Initiatives and SGG projects and must be prepared and circulated/announced to the executive sponsors via email distribution list on the first and fifteenth of each month. For some projects, it may be advisable to route a draft summary to business owners and IT project sponsors for their input before releasing to executive sponsors.
Team Meetings
Regular team meetings help facilitate issue tracking and resolution, progress updates, risk management, and general team communications. Meeting schedules (number of meetings, frequency, composition) will vary by project, depending upon scope and complexity.
Status Tracking
Regular project status (progress, issues, risks) and financial updates are essential to avoid project failure and ensure accurate project status reporting is available to management.
Scope Management
PMBOK® defines Project Scope as "the work that needs to be accomplished to deliver a product, service, or result with the specified features and functions." The scope of a project is the clear identification of the work that is required to successfully complete or deliver a project. One of the Project manager's responsibilities is to ensure that only the required work (the scope) will be preformed and that each of the deliverables can be completed in the allotted time and within budget. Key to executing this responsibility successfully is clear definition of the scope and traceability from requirements to functional and technical design. Equally important to successful scope management is an agreed change control process and change control board or governance structure.
Project Closeout
The practice of project closeout finalizes all project activities completed across all phases or the project to formally close the project and transfer the completed or cancelled project as appropriate. The purpose of project closeout is to assess the project, ensure completion, and derive and lessons learned and best practices to be applied to future projects. Project closeout should be anticipated and planned as early as possible in the project life cycle even though it is often the last major process of a project's life. At a high level, the key elements of project closeout are:
- Verify acceptance of final project deliverables
- Conduct post-project assessment and lessons learned (Project Retrospective)
- Recognize and celebrate outstanding project work
- Disburse project resources— staff, facilities, systems, etc.
- Complete and archive final product records
- Ensure transfer of knowledge
Closeout Checklist
The Project Closeout Checklist should begin to take shape as early as project kickoff, when clear definition of the intended goals and benefits of the project are being reviewed and agreed upon. However, work on project closeout can and should begin at the time of UAT Exit. While not all project closeout steps are required or even apply to a given project, even those that are indicated as "optional/as applicable" should be carefully reviewed.
Project Retrospective
The Project Retrospective process starts with a survey that is sent to all team members after acceptance by the client. The retrospective results help IT and the business assess what went well and where improvements can be made in the future, in the following areas:
- Planning
- Execution
- Communication
- Governance
- Business Readiness
Top lessons learned are discussed and agreed upon in a retrospective meeting and incorporated into PMO best practice where applicable. Note: This represents the legacy Enterprise Technology retrospective process, which will be replaced in PY20 by a new, common UIT process for project closeout and final report creation.
