|
|
| An iterative project management approach with short development cycles and frequent feedback. |
|
| Work completed in “sprints” lasting 1–2 weeks. |
|
|
|
| A prioritized list of features, tasks, or requirements waiting to be worked on. |
|
| Items the team will pull into the next sprint. |
|
|
|
| The approved version of scope, schedule, or cost, used to measure performance. |
|
| A schedule baseline created after project kickoff. |
|
|
|
| A formal proposal to modify a project’s scope, schedule, or cost. |
|
| A request to add new features after initial planning. |
|
|
|
| The final phase where the project is evaluated, documentation is completed, and the project is formally closed. |
|
| Completing lessons learned and marking the project closed in TDX. |
|
|
|
| Any output produced by the project, such as documents, products, or software features. |
|
| A finalized project charter or a functioning login page. |
|
|
|
| Tasks or events that rely on another task to be completed first. |
|
| You cannot start user testing until the development team delivers the prototype. |
|
|
|
| A problem that has already occurred and requires action. |
|
| "The new server is not compatible with legacy applications." |
|
|
|
| A measurable value that shows how effectively the project is achieving key objectives. |
|
| "System uptime reaches 99.9%." |
|
|
|
| A significant event or checkpoint marking progress in the project timeline. |
|
| "Business Case Approved" or "Testing Complete." |
|
|
|
| A temporary effort is undertaken to create a unique product, service, or outcome. |
|
| Migrating departmental data storage to a new secure environment. |
|
|
|
| The individual or group providing funding, support, and high-level guidance. |
|
| A department director approving resources for a system upgrade project. |
|
|
|
| The person responsible for planning, executing, and closing the project. |
|
| The PM ensures tasks are assigned, risks are tracked, and updates are submitted in TDX. |
|
|
|
| A foundational document authorizing the project and defining objectives, scope, and roles. |
|
| Used before project creation in TDX to secure approval. |
|
|
|
| An indicator of whether the project is on track (Green), at risk (Yellow), or off track (Red). |
|
| Project Health = Yellow due to delayed vendor response. |
|
|
|
| A tool used to track Risks, Actions, Issues, and Decisions. |
|
| Logging each risk with an owner and mitigation plan. |
|
|
|
| Defines team roles: Responsible, Accountable, Consulted, Informed. |
|
| PM=Accountable Developer=Responsible Director = Informed |
|
|
|
| A potential event that could negatively impact the project if it occurs. |
|
| "Vendor delays may affect the delivery timeline." |
|
|
|
| The boundaries of what is included in (and excluded from) the project. |
|
| Included: Setting up new servers Excluded: Writing end-user training materials |
|
|
|
| Unplanned additions or changes to project scope without proper approval, often leading to delays. |
|
| A client keeps requesting new features after development starts. |
|
|
|
| A fixed period of time (usually 1–4 weeks) in which work is completed in Agile projects. |
|
| Sprint 3 includes tasks related to database improvements. |
|
|
|
| Anyone who has interest in or is impacted by the project. |
|
| Students, faculty, IT staff, and department admins. |
|
|
|
| A specific unit of work that supports project completion. |
|
| "Configure user access permissions" is a task within a security upgrade project. |
|
|
|
| A linear methodology where phases occur sequentially. |
|
| Requirements → Design → Development → Testing → Deployment |
|
|
|
| A hierarchical breakdown of the project into smaller, manageable pieces. |
|
Planning
1.1 Create Charter
1.2 Define Scope |
|