Body
Quick Links: | Project Definition | Project Submission | Project Initiation | Project Execution and Monitoring | Project Closure |
Project Definition
A project is a temporary endeavor with a defined start and end date undertaken to deliver a unique product, service, or result. Projects differ from operational work in that they introduce change, require coordinated planning, and carry defined outcomes.
Best Practice:
Before submission, ensure the work truly meets the definition of a project. If it does not create a unique outcome or has no clear end, it likely belongs in operational or maintenance queues.
Project Submission
All projects must be submitted through the DoIT Project Submission Service.
This ensures proper intake, prioritization, transparency, and alignment with the Division of IT and institutional priorities.
Operational / Maintenance Project Submission
Operational and maintenance-focused work requires the following information at submission:
If all details are not available at the time of submission, they may be refined later. However, providing accurate estimates upfront improves workload planning and queue management across IT teams.
Best Practice:
Even for operational work, clearly articulate the problem being solved and the expected outcome. This avoids scope creep and misaligned expectations.
Non-Operational / Maintenance Project Submission
Projects that are non-operational (e.g., new systems, enhancements, integrations, or initiatives) are submitted through the same service. Once received:
-
PCMO Analysts review the request
-
High-level requirements are analyzed
-
The request is categorized and routed to the appropriate project queue
Best Practice:
At submission, focus on what is needed and why. Avoid solutioning too early. Clear problem statements lead to better requirements and stronger project outcomes.
Project Initiation
Project Initiation formally transitions an approved request into an active project and establishes the foundation for execution.
Converting and Creating Project Requests
When approved and ready to begin:
-
Open the ticket
-
Navigate to Actions > Convert to Project
-
Select the appropriate Project Type (e.g., Division of IT Maintenance Operations Projects)
-
Under Advanced > Project Template, select the applicable template (e.g., Operational Project)
This action loads standard artifacts such as:
-
Operational Project Checklist
-
Hardware Installation Plan
-
Application Development Plan
Requirements Gathering (Critical Initiation Step)
Requirements Gathering is a mandatory best practice during initiation for all non-trivial projects.
Purpose:
To ensure a shared understanding of business needs, constraints, success criteria, and scope before execution begins.
Key Activities:
-
Identify stakeholders and subject matter experts
-
Elicit requirements using interviews, workshops, document reviews, and observation
-
Document functional, non-functional, and business requirements
-
Validate requirements with stakeholders
-
Establish scope boundaries and assumptions
Outputs:
Skipping or rushing this step is the fastest way to guarantee rework, delays, and dissatisfaction later in the project.
Adding Project Resources
Project resources must be added so individuals can be assigned tasks and report time and effort.
Steps:
-
Open the Project
-
Go to the Resources tab
-
Select Actions > Add Resources
-
Enter resource details
An individual must be added as a resource before being assigned project tasks.
Adding Stakeholders
Add stakeholders to ensure visibility, updates, and communication. Stakeholders will be notified of progress through the client interface.
-
Stakeholders ensure visibility, communication, and alignment.
Steps:
-
Open the Project
-
Navigate to the Stakeholders tab
-
Select + Add
-
Enter stakeholder details
-
Stakeholders receive updates through the client interface.
Completing the General Section
Complete all required fields under the General tab, including:
Accurate completion supports reporting, governance, and executive visibility.
Project Execution and Monitoring
Project Plan Creation
Select an appropriate planning method:
Applying the Operational Project template provides baseline plans such as:
-
Operational Project Checklist
-
Hardware Installation Plan
-
Application Development Plan
Best Practice:
Plans should directly trace back to approved requirements. If a task does not support a requirement, it likely does not belong in the plan.
Project Implementation
Execute project tasks while actively monitoring:
-
Risks
-
Issues
-
Dependencies
-
Scope changes
Risks and issues should be logged and managed within TeamDynamix as they arise.
Weekly Status Updates
P
Project Managers are required to post weekly status updates.
Steps:
-
Go to Project Details > Update
-
Update:
-
Status
-
Percent Complete
-
Comments (recommended)
-
Save the update
Project Health Definitions
| Health Value: |
Definition |
| None |
No status assigned. Project has not started. |
| Green |
Project is on track. |
| Yellow |
Project has challenges, mitigation underway. Sponsor should be informed. |
| Red |
Project is at significant risk. Escalation to sponsor required. |
Important Note: If no updates are posted within 8 business days, the project health will automatically downgrade by one level.
Project Closure
Once work is complete, formally close the project in TeamDynamix.
Steps:
-
Go to Project Details > Actions > Close
-
Select whether to send a Closure Survey and specify recipients
-
Update:
-
Project Status
-
Health
-
Percent Complete
-
Additional Comments
-
Save to confirm closure
Best Practice:
Confirm all requirements have been met and accepted before closure. Capture lessons learned to improve future projects.
Help us improve our Knowledge Base! Click Yes or No below, then let us know what worked — or what didn’t. Your feedback helps us improve our content and provide the best possible support.