Quick Links: | Understanding Purpose and Scope | Defining a Project | Project Intake and Submission | Project Initiation | Requirements Gathering | Project Planning | TeamDynamix Project Setup | Project Implementation and Monitoring | Project Closure |
Understanding Purpose and Scope
The DoIT Project and Change Management Office (PCMO) Execution Framework provides a standardized, end-to-end approach for initiating, planning, executing, monitoring, and closing projects. It also ensures that change is managed intentionally, stakeholders are engaged, and outcomes align with Division of IT and institutional priorities.
This framework applies to Project Managers, Directors, and Project Leads responsible for delivering operational and non-operational work through DoIT.
Defining a Project
A project is a temporary effort with a defined start and end date that delivers a unique product, service, or result.
Projects introduce change and require coordination, planning, and governance. Work that is ongoing, repetitive, or does not have a defined end typically belongs in an operational or maintenance queue rather than in project execution.
Best practice: If the work does not create a unique outcome or has no clear end point, reassess whether it should be submitted as a project.
Project Intake and Submission
All work must enter DoIT through the DoIT Project Submission Service. This supports intake, prioritization, transparency, and alignment with institutional goals.
Operational and maintenance submission requirements
Operational and maintenance submissions must include:
- Estimated hours
- Required staff and roles
- IT departments involved
- A designated Project Lead
Details can be refined later, but accurate estimates improve workload planning and queue management.
Best practice: Clearly define the problem being solved and the expected outcome, even for operational work. This reduces scope creep and misalignment.
Non-operational work review and routing
Non-operational work such as new systems, enhancements, integrations, and initiatives follows the same intake process. After submission:
- PCMO Analysts review the request
- High-level requirements are analyzed
- The request is categorized and routed to the appropriate project queue
Best practice: Focus on the business need and the reason for the request, not the proposed solution. Starting with a solution too early can weaken requirements and create rework.
Project Initiation
The initiation phase establishes the foundation for project success.
Define the project goal
Clearly explain why the change is needed and what success will look like.
Example: Transitioning to a new HR system to streamline employee management processes.
Develop the project charter
The Project Charter is a high-level document that defines:
- Purpose and objectives
- Scope and constraints
- Key stakeholders
- High-level risks
Template: Project Charter
Identify stakeholders early
Use a Stakeholder Register to identify individuals and groups impacted by or involved in the project, including staff, departments, faculty, students, and leadership.
Template: Stakeholder Register
Secure initial approvals
Obtain charter approval and sponsor sign-off before moving into planning.
Conduct the project kick-off
Align stakeholders on goals, roles, expectations, and next steps.
Template: Kick-Off Presentation Template
Requirements Gathering
Requirements gathering is required for all non-trivial projects.
Its purpose is to establish a shared understanding of business needs, scope, constraints, and success criteria before execution begins.
Key activities include:
- Identifying stakeholders and subject matter experts
- Gathering requirements through interviews, workshops, document review, and observation
- Documenting functional, non-functional, and business requirements
- Validating and confirming requirements
- Defining in-scope and out-of-scope boundaries
Outputs include:
- Approved requirements
- Clear success criteria
- Defined scope boundaries
Skipping or rushing this activity often leads to delays, rework, and dissatisfaction later in the project lifecycle.
Template: Requirements Gathering Workbook
Project Planning
Planning translates intent into an executable roadmap.
Develop the change management plan
Identify risks, mitigation strategies, and activities that support adoption and transition.
Template: Change Management Plan or Workbook
Define the communications plan
The communications plan should define:
- What will be communicated
- Who will receive updates
- How often communication will occur
- Which channels will be used
Template: Communications Plan
Create the project schedule and work plan
Develop the Work Breakdown Structure (WBS) in TeamDynamix using either:
- Waterfall task sequencing
- Card Wall for Agile-style planning
Plans should include realistic timelines, resources, and dependencies.
Best practice: Every task should connect to an approved requirement. If it does not, it may not belong in the project plan.
TeamDynamix Project Setup
Once a request is approved, the project must be set up correctly in TeamDynamix so work can be tracked, assigned, and reported consistently.
Convert request to project
- Open the ticket
- Select Actions > Convert to Project
- Choose the appropriate Project Type
- Select the correct Project Template
Standard templates may include:
- Operational Project Checklist
- Hardware Installation Plan
- Application Development Plan
Add project resources
- Open the project
- Go to the Resources tab
- Select Actions > Add Resources
Add stakeholders
- Open the project
- Go to Stakeholders
- Select + Add
Complete general project information
- Impact Level
- Communications approach
- Project costs
This information supports reporting, governance, and executive visibility.
Project Implementation and Monitoring
Execution is where planning is carried out, progress is monitored, and stakeholder communication must remain consistent.
Execute the plan
Complete tasks as planned and use approved change control when adjustments are needed.
Maintain stakeholder engagement
Use the Communications Plan consistently to manage expectations and address concerns.
Monitor risks, issues, and scope
- Risks
- Issues
- Dependencies
- Scope changes
All risks and issues must be logged and managed in TeamDynamix.
Post weekly status updates
- Go to Project Details > Update
- Update project status, percent complete, and comments
- Save
Project health definitions:
- Green: On track
- Yellow: Challenges are present and mitigation is underway
- Red: Significant risk exists and escalation is required
If no update is posted within 8 business days, project health is automatically downgraded.
Project Closure
Closure ensures accountability, captures lessons learned, and completes the handoff.
Verify objectives and deliverables
Confirm that all requirements and deliverables have been completed and accepted.
Conduct final stakeholder check-in
Confirm stakeholder satisfaction and address any remaining concerns.
Document lessons learned
Record what worked well and what did not to improve future projects.
Archive project documentation
Store all project artifacts in their designated locations.
Close project in TeamDynamix
- Go to Project Details > Actions > Close
- Update status, health, and percent complete
- Send closure survey if appropriate
Recognize success
Acknowledge the team’s work and successful delivery.
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.