...
Term | Definition | Example / Further information | ||
|---|---|---|---|---|
Allocated FTE | Refers to the amount, expressed as decimal number, that an individual is proportioned to a team. | A person might also be allocated across two teams in TeamForm, for example | ||
Allocation | Allocation is a way of describing a person’s membership of a Demand team. An allocation is a membership of a person to a demand team by a particular amount of FTE. People can have multiple allocations and thus can be members of multiple demand teams at the same time. | John is 0.5 FTE allocated to App Squad 1 and 0.5 FTE allocated to App Squad 2. | ||
Allocation Project (sometimes shortened to just ‘Project’) | Allocation project is like a container box that allows us to store allocation data bound to a specific time period used in Planner and Forecast with the added ability to set different customisations and configurations to how we display the data to end users. | … | ||
Association | Associations allow for modelling relationships between teams, beyond traditional parent and child relationships. These relationships can have a categorised with a direction and a type. Associations allow customers to record linkages between 2 (or more) teams, which are independent from the organisation’s hierarchical model. Associations are cooperative relationships between two teams defined by an association type and direction. |
| ||
Attributes | Additional information that can be loaded against people (via imports) or tags (via UI or via imports). | |||
Baseline | A snapshot view of all people and teams at a point of time, to be used during the planning process. Baselines are typically captured before requests for people/teams are made as part of a quarterly planning process | … | ||
Child Teams | Used to refer to groups/teams under parent team. | Config type | Found when creating a new workspace. | |
Deleted Team | Teams that have been set to soft delete = true in the application. They are not visible, but TeamForm maintains historical records of these teams. | |||
Demand teams | Demand team is where “work is done” and which needs people and skills (often in a cross functional team) to deliver outcomes. Previously called ‘target team’ or ‘target group’. | |||
Departure People | A term used to describe when a person is removed from TeamForm through imports | |||
Devtool | An application feature available to TeamForm employees, not not available to customers. Allows some advanced editing of customer’s data, including bulk changes to people, teams and tags. |
| ||
Division | A grouping of people, from the upstream system of record. Divisions represent the supervisory structure of the organisation from HR’s perspective. This dataset represents the structure from a customer’s Human Resources Information System such as Success Factors or Workday. This is different from a team. |
| ||
Entity | A technical term for a type of object that includes both people or teams. | E.g. Tags can be applied to an entity using the Entity tag import (i.e. to either a person or a team) | ||
Forecast | Forecasting enables demand teams to estimate the amount of FTE required from supply teams over a number of horizons (allocation projects). Unlike planning only requests are entered. There is no approval from the supply teams. Because of this, there is no state. Forecasts are not of named people but simply FTE amounts between a supply team and demand team. | |||
FTE | Full time equivalent - represents employee time relative to full time. | A person working part time at 4 days per week will be represented as A person might also be allocated across two teams in TeamForm, for example | ||
Group | A technical term used internally within TeamForm to describe a collection of things. | Teams are the most common Group type, (some the terms can sometimes be used interchangeably) but divisions and objectives are also groups. | ||
Group Type | Types are how TeamForm distinguishes groups (most often Teams). | Some examples of commonly used group types: Agile-Team, Agile-Group, Squad, Tribe, Mission, COE, Business Unit, Area, Function, Chapter, Department, Domain. | ||
Hidden Team | A team that is empty of members and a user has requested the team be removed, but the team must be visible in some App screens to correctly present a planning baseline.
| |||
HRIS / HCM | HRIS - HR Information System alias: HCM - Human Capital Management / HRMS - Human Resource Management System A human resources information system (HRIS) is a software solution that maintains, manages, and processes detailed employee information and human resources-related policies and procedures. As an interactive system of information management, the HRIS standardises human resources (HR) tasks and processes while facilitating accurate record keeping and reporting. Borrowed from this link https://www.oracle.com/uk/human-capital-management/what-is-hris/ | Workday, SAP SuccessFactors, Oracle Fusion HCM etc. (there are many in this field but the above are 3 of the more common SaaS products in the large complex space). For small companies something like Bamboo HR is also a more commonly used option. | ||
Key Result | How a company is going to accomplish and measure the achievement of an Objective. The name is configurable. | What we call this in our app/codebase: | ||
Leaders of People | Managers that have accountability for a group of people within the organisation - their recruitment, professional development, quality of their work output and decisions about assignments to a teams. The specific accountabilities differ between our customers, but the phrase is generally applicable. In the TeamForm application, these users can be considered ‘Approvers’ in the Planner workflow |
| ||
Leaders of Work | Managers in an organisation that have accountability for the delivery of outcomes (e.g. projects) The specific accountabilities differ between our customers, but the phrase is generally applicable. In the TeamForm application, these users can be considered ‘Requestors’ in the Planner workflow |
| ||
Macro Allocations | The former name, and underlying technical implementation, of Planner and Forecast functionalities in TeamForm. | |||
Objectives | Objectives are organisational goals / OKRs which can be linked to teams, to provide an overlay of how teams are aligned to organisation 'goals; or organisation 'work'. Objectives are a hierarchical data model that allows for multiple parents and children. The language presented to users can be customised. Some examples are OKR, Key Result, Group Objective or Epic. | What we call this in our app/codebase: | ||
Orchestrated | The company that originally built TeamForm. | |||
Org Structure | How an organisation arranges and categories their teams. | e.g. “Our organisation is made of Agile Teams that are arranged in Tribes. Each individual in a Agile Team has a home Chapter which belong to Chapter Areas” | ||
People Mapper | (superseded - the previous name of ‘TeamForm App’) | |||
PIT | TeamForm people data model and the ability for users to scroll backwards in an organisation's history. A user can see what the organisation looked like at a ‘point in time’ | There were 50 people in team-a at this PIT that is two months ago. | ||
Planning Period | See Allocation Project | |||
Requisition | The term “requisition” is frequently interchanged with “vacancy” in some organisations. Requisition can represent the same unfilled role, but may also indicate a more advanced stage i.e. approved, funding allocated, or requirement is in progress. | |||
Supply Team | Supply is the where people homed / setup in their reporting lines (typically) and often organised into chapters around practices e.g. SW Engineering, Data Analysis etc. An individual can be in only one supply team at a time at any one time, but is allowed to be in multiple demand teams. Previously called ‘source team’ or ‘source group’. | |||
Support User | A special kind of user account that only specific TeamForm employees have which allows them to access customer tenants and customer data in TeamForm. The format of the username is @support.teamform.co | |||
Tag | A "tag" is a user-defined label that can be assigned to people and teams. Tags help categorise and easily search within TeamForm. | Example: | ||
Tag Attributes | Additional information or “metadata” associated with a person, group or tag. | Example 1: Example 2: | ||
Tag Type | A category/grouping for a given tag, to which multiple values can be defined | E.g. “Role Type” as a tag type applied to people to define a hatted role | ||
Tag Type Description | A short description of a Tag Type. | Role type is a label we apply to communicate the role someone is f a person | ||
Tag Type ID | An automatically generated unique ID for each Tag Type. Note: when you are importing TagTypes and Tags, the field used is tagType - this is actually the tagTypeId behind the scenes. TeamForm allows for renaming the Name whilst keeping the ID consistent for tagging and historical purposes. Note: When you are importing more tag types and tags for an existing tag Type make sure to use the id rather than the name. | DREYFUS_LEVEL | ||
Tag Value | A value that is associated to a tag type, used to categorise or label a person or team. | E.g. for Tag type “Role Type”
| ||
Tag Value ID | An auto generated unique random string for each Tag value. Used for data integrations to import or modify tags | gKX730gw0 | ||
Taxonomy | A shared language for how an organisation refers to their organisational structure and the work they do Each organisation will have its own taxonomy depending on their contexts | |||
Team | A team is a generic construct for grouping a set of people. People are members of a team. Teams can be empty or contain one or more people. Teams can optionally have a type which is a textual label to differentiate different classes of teams. Type gives a team a business context such as squad, guild or chapter. Teams can optionally exist in a hierarchal tree structure. In this graph, teams have a single parent team and optionally one or multiple child teams. A person can thus be considered a member of a team in two different ways:
| |||
TeamForm App | A specific view of TeamForm granted to Power users who need to plan and manage teams.
| |||
TeamForm Directory | A specific view of TeamForm provided to regular team members to gain visibility into people and teams.
| |||
TeamForm Platform | The way we describe the full TeamForm suite provided to customers, including the App, Directory and Reporting | |||
TeamForm Reporting | A reporting tool (also referred to as Redash) that allows users to build queries and dashboards to extract and report on data within TeamForm | |||
Tenant | A separately created infrastructure to securely house a customer’s TeamForm instance Also sometimes called a environment | |||
Unmet Demand | The different between what a Leader of Work has requested verses what a Leader of People has approved or provided. | e.g. as the Tribe Lead I requested 3 FTE of Designers, but the Chapter Lead of only provided 1 FTE so I have an unmet demand of 2 FTE. | ||
User Level | Options:
| |||
Vacancy | A vacancy is a representation of a position that is not filled by a person. Vacancies help represent a complete state of an organisation’s resources for planning and resource allocation processes. In TeamForm vacancy is used in two primary ways
… | Org design
Open position in a team
| ||
Workspace | A separate area within a tenant where changes can be made without impacting other workspaces. Use cases include testing features and data imports before bringing them into production, anonymised training, org redesign, test etc. Other organisations / clients might choose to refer to different workspaces as environments to allow them to have more effective controls and stability. | Typically workspaces are setup for
|