iDTF Charter
IT Workgroup Redesign Proposal
October 2006
In light of challenges that ITCH workgroups have faced since the concept was first proposed several years ago, a redesign of the workhgroup (herein refered to as iDTFs) function was identified as an important task for the ITCH for the 2006-07 academic year.
This document represents a first cut at redesigning the ITCH iDTF. The goal is to specify how they are formed and function to ensure the greatest utility to the institution.
1. Types of iDTFs
Issues: In the past, there have been many different types of iDTFs created based on the need for topical research, development, or large scale process re-engineering. Do we establish different types of groups depending on the type of work or what the deliverable(s) are? What initiates the creation of a iDTF?
Proposed Resolutions: iDTFs are initiated at the ITCH-Core level to address broad institutional IT questions. Proposals to charge a iDTF can be pushed to the ITCH-Core from the other ITCH groups. iDTFs should be charged to answer a single question or series of related questions to help guide;
* Technology trends and issues, and their institutional impacts
* Process redesign and re-development issues
* System and application development issues, both technical and non-technical aspects.
* Feasability studies
This would mirror more closely the DTF model which answers questions and recommends a course of action regarding a broad institutional issue.
2. Scope of Work
Issues: Clear and "agile" scoping of a iDTF charge is key in ensuring an effective deliverable. In the past, vague and open-ended projects resulted confusion regarding the responsibility of, and final deliverables from the iDTF
Proposed Resolutions: To reiterate, the scope should be based on a question or series of related questions that need to be answered in order to guide IT planning, process re-design or development work. A preliminary scope (no more than a page) should be created and agreed upon by the ITCH-core that includes the following key components;
* What is/are the question(s),
* Who is the sponsor
* What are the start/end dates,
* Who are the initial participants, and
* What are the final deliverables
Once this is created, the iDTF develops a project approach to the charge identifying intermediate milestones and individual responsibilities. Again, this is a short, concise document (less than a page) that is pushed back to the ITCH-core, and will help the group to more specifically target how it intends to deliver the results.
3. Timeline and Duration
Issues: In the past, iDTFs had a very loose timetable (if any) for completion. This increased both frustration and confusion regarding when exactly the project was finished and allowed for unwieldy and unrealistic projects.
Proposed Resolutions: All iDTFs have a maximum 3 month timetable to completion. If it is perceived that this is not enough time, then the scope needs to be reviewed to allow for a quicker, more applicable turnaround or the scope needs to be divided into discrete pieces and assigned to multiple iDTFs.
4. Participation and Group Governance
Issues: There are limited staff resources available for this type of work and a seemingly infinite number of projects that need attention. How do we assign, solicit or bribe participation in the iDTFs in a sustainable way that ensures representative participation and optimum functionality? How is the coordinator determined?
Proposed Resolutions: An attempt is made by the ITCH-Core to enlist interested parties to participate in the iDTF to ensure broad domain knowledge and specific technical knowledge is well represented. At this time a *coordinator*can be established, or this individual can be decided upon by the group at the first meeting when they develop the project approach document.
October 2006
In light of challenges that ITCH workgroups have faced since the concept was first proposed several years ago, a redesign of the workhgroup (herein refered to as iDTFs) function was identified as an important task for the ITCH for the 2006-07 academic year.
This document represents a first cut at redesigning the ITCH iDTF. The goal is to specify how they are formed and function to ensure the greatest utility to the institution.
1. Types of iDTFs
Issues: In the past, there have been many different types of iDTFs created based on the need for topical research, development, or large scale process re-engineering. Do we establish different types of groups depending on the type of work or what the deliverable(s) are? What initiates the creation of a iDTF?
Proposed Resolutions: iDTFs are initiated at the ITCH-Core level to address broad institutional IT questions. Proposals to charge a iDTF can be pushed to the ITCH-Core from the other ITCH groups. iDTFs should be charged to answer a single question or series of related questions to help guide;
* Technology trends and issues, and their institutional impacts
* Process redesign and re-development issues
* System and application development issues, both technical and non-technical aspects.
* Feasability studies
This would mirror more closely the DTF model which answers questions and recommends a course of action regarding a broad institutional issue.
2. Scope of Work
Issues: Clear and "agile" scoping of a iDTF charge is key in ensuring an effective deliverable. In the past, vague and open-ended projects resulted confusion regarding the responsibility of, and final deliverables from the iDTF
Proposed Resolutions: To reiterate, the scope should be based on a question or series of related questions that need to be answered in order to guide IT planning, process re-design or development work. A preliminary scope (no more than a page) should be created and agreed upon by the ITCH-core that includes the following key components;
* What is/are the question(s),
* Who is the sponsor
* What are the start/end dates,
* Who are the initial participants, and
* What are the final deliverables
Once this is created, the iDTF develops a project approach to the charge identifying intermediate milestones and individual responsibilities. Again, this is a short, concise document (less than a page) that is pushed back to the ITCH-core, and will help the group to more specifically target how it intends to deliver the results.
3. Timeline and Duration
Issues: In the past, iDTFs had a very loose timetable (if any) for completion. This increased both frustration and confusion regarding when exactly the project was finished and allowed for unwieldy and unrealistic projects.
Proposed Resolutions: All iDTFs have a maximum 3 month timetable to completion. If it is perceived that this is not enough time, then the scope needs to be reviewed to allow for a quicker, more applicable turnaround or the scope needs to be divided into discrete pieces and assigned to multiple iDTFs.
4. Participation and Group Governance
Issues: There are limited staff resources available for this type of work and a seemingly infinite number of projects that need attention. How do we assign, solicit or bribe participation in the iDTFs in a sustainable way that ensures representative participation and optimum functionality? How is the coordinator determined?
Proposed Resolutions: An attempt is made by the ITCH-Core to enlist interested parties to participate in the iDTF to ensure broad domain knowledge and specific technical knowledge is well represented. At this time a *coordinator*can be established, or this individual can be decided upon by the group at the first meeting when they develop the project approach document.
