Body
Overview
These are recommendations only.
Purdue IT technician groups should be closely aligned with organizational structure. Cross-functional, product-based, and split teams should be avoided. In TeamDynamix, technicians should belong to only one team.
Following these recommendations will:
- Improve staff’s ability to easily identify work assigned or requested, whether it is related to incidents, service requests, RFCs, problems, or projects. Work can more easily flow to a single desktop for each type of work. Staff will not have to go look for work from multiple groups.
- Improve a supervisor’s ability to identify work trends and improvements when/where needed, whether it is related to incidents, service requests, RFCs, problems, or projects. Supervisors can more easily track and evaluate work when it flows through consistent escalation that are related to well defined groups.
- Improve visibility into a groups staffing levels compared to workload. Workload and efficiency for individuals and organizational teams are harder to assess when resources are split and mixed with resources from disparate units.
- Improve visibility into accountability and reporting. Metrics will be more clear and easier to generate when teams and escalations are well defined.
- Reduce complexity of escalation and work management between and within groups.
- Ensure that one group/person owns the customer experience of tickets at defined levels. When groups are built with disparate resource the ownership of the customer experience is blurred.
Details
What is a group and how should a group be structured?
A group should be formed around two or more individuals who work together to administer, support, and/or maintain a defined set of products and/or services with a meshing of functions and mutual support.
- Individual contributors should be a member of one and only one group.
- The skills and knowledge individual group members have may be different, the same or overlapping with other group members.
- All FT/PT technicians should have notifications enabled.
- The group's products and/or services can be a combination of one or more
- products/services wholly provided by the group
- defined portions of products and/or services supported by the group
- Each group should have one person identified responsible for the operational excellence of the group. This can either be a manager or team lead.
- Each group should have their chain of command up to their director as a member of the group.
- Managers may have multiple teams in situations where they manage two distinct groups with differing scopes.
- Primary directors should be a member of every team within their area.
- Primary directors and managers with more than one group should have notifications disabled by default
Visual Example of a Group's Scope
How will group be named?
Group names will be built from the following components
- “IT”: to signify this is a IT team within the TeamDynamix ecosystem.
- Area abbreviation: Values like "SE", "EA", and "PIER" will signify groups within the same director's area.
- Campus indicators: Values like “PFW”, “PNW”, “PWL”: will only be used for groups that are associated to one campus.
- Multi-part group name: This will be the group’s descriptive identifier. Typically, multiple words will be separated by an “_”. Managers can request changes to this component.
Each of the above three component pieces will be in all caps and separated by an “_”. Examples include:
- IT_SE_SERVICE_MGMT
- IT_EA_HRIS
- IT_CSS_PWL_AG_SUPPORT
- IT_PIER_WINDOWS
Alternatives to Membership of Multiple Groups
There are a few scenarios when it feels easier to have an individual contributor as a member of multiple groups. Here are some common example and alternatives to consider.
- Backing up another group
- Visibility into another groups tickets can be obtained through a report that can be added to a custom desktop. This provides a way for other groups to take tickets as they have time.
- Have the primary team transfer tickets to another group on an as needed basis. This can illustrate staffing limitations.
- Consider moving the backup resource into the group
- Assistance needed on a ticket
- The primary group member can take responsibility for the ticket so control over the customer experience is maintained within that group. They can create sub tasks that are assigned to another group for the portion of the work in which assistance is needed.
- Advanced support needed
- Have the primary team escalate tickets to the higher tier team on an as needed basis. This illustrates skill separation.
NOTE: Each group should create and maintain escalation Instructions and make them available to tier 1 groups to assist with timely and accurate escalations.
Still need help? Click the 'Purdue IT Request' button to start a ticket.