Define your Org Modelling Requirements

Why is requirements definition key?

If you don’t know what you’re working towards, it’s hard to achieve it. “47% of unmet project goals tie back to poor requirements management” Larson, E. (2014). Therefore, it is important to define a list of requirements and understand what you should build and why you should build it.
 

What does requirements definition for Org modelling involve?

This process usually involves selecting the right data, properties and actions to specify your organization.
The key decisions you will need to make are: 

• Whether to use people or positions data
• Which properties you should include on classification, structure and economics 
• How to capture future cost information
• How to specify change in my future organisation
• If and how to capture changes over time 

Why is it best to split data between people and positions? 

Let’s start with the relationship between people and positions in the organization. Positions are planned according to business needs, which create the demand for people. People are appointed to positions and are the supply of positions. Ideally, there’s a one-to-one relationship between the position and the individual employee appointed to that position. But the reality is more complicated.  

Thinking about people, individual employees are constantly joining, moving through and leaving the organization. In addition, there might be situations where: 

• a single employee performing two positions on a temporary or permanent basis (‘double hatting’) 

• two part-time employees sharing the same position 

• employees taking paid or unpaid leave and not holding any position 

• constant adjustment of employees: changing performance scores, changing rewards, changing department managers 

Considering the positions, there are cases where: 

• new positions are planned which may or may not be filled within the planned timeframe 

• positions may become temporarily or permanently vacant 

• due to changes in business needs, positions may be closed (or ‘demised’) 

• the location in the organization may change with changed reporting lines and the physical location may change as geographic footprints are adjusted 

In order to manage the complexity of constantly changing organization data, it’s better to split people and positions data.
See also: What is the difference between People and Positions Datasets
 

What’s the best practice for org modelling? 

We’ve seen why it’s important to split people and positions data, now let’s talk about what’s the best practice for org modelling. We often recommend organizations to use position datasets to better design their organizational structure, forecast costs and manage workforce demand.  

Firstly, focusing on positions provides control to maintain the logical structuring of the organization, as employee-structured data is not sufficiently sensitive to the changing context of people in the organization. For example, when an employee leaves, the employee information will be deleted but the position can be temporarily shown as vacant.  

Secondly, people data contains only actual costs, whereas modelling of positions enables the impact of an organization’s cost base to be forecast, planned and managed. For example, if you plan to hire an employee in the next year, you can already predict costs based on position information, such as country and job level, before that person joins.  

Finally, the use of position datasets avoids the designer making any decision based on individual employees. Org modelling should enable the organization to have the capacity to execute a defined strategy to achieve its goals. Data fields relating to people (e.g. Name) may influence the designer's decision.  

In summary, modelling with a focus on positions rather than people identifies and manages the full potential size and cost of the organization with minimal impact on designers. 

Which data fields are essential for org modelling? 

There are three types of position data fields that are vital for org modelling: Classification, Structure, Economics. Classification data fields include those such as Position ID or Title. Here, Position ID should be a unique identifier for each position without any duplicates. In addition, you need data to build the organisational structure. The most important Structure data field is the Manager ID, through which you can have reporting lines and create hierarchies. You should also include functional and geographical data fields so that you can visualize the data in different dimensions. The last type you need to include is all data fields related to cost, for example, Position Salary. We’ll talk about the cost elements in next section. 

Example position data fields:  

* If you do not already have the Position ID, you can use your employee ID as a unique identifier or create an ID for each position. 
 

How do I determine cost for my future organization? 

The aim of org modelling is to design a 'future-state' organization and to observe its impact. The cost implications of the design support the financial forecasting and planning of the organization. Therefore, it is very important to capture cost changes correctly. We will discuss in this section how to capture future costs and which cost elements to use. 
 

How do I capture the future costs? 

There are two ways to capture the future cost of a position: manually enter or automatically generate by using a look-up table. For the first option, you will need to enter a cost for a newly added position and update it for a changed or closed position. This requires a lot of manual work and will be very time consuming if the organisation has a large size. For the latter option, instead of typing in the cost figure each time, the cost can be generated based on a look-up table. Here we refer to this look-up table as a ‘Rate Card’. A Rate Card usually defines average (or median) salaries based on certain data fields, such as Location and Grade. Other common data fields used for Rate Card are Function, Employee type, etc. Here is an example of a Rate Card: 

In this example, if you add a new position based in the United Kingdom with a grade of B2, the cost of the position will automatically be shown as 58,000. Also, if you upgrade a US-based position from C1 to C2, the cost will change from 64,500 to 72,700. By using the Rate Card, the cost change for any modelling action will be captured automatically. The rate card can be updated monthly or yearly to have a more accurate view of the cost impact over time. 

Which elements do I use for future costs? 

Generally, in addition to the base salary, there are bonuses, incentives, benefits, etc. included in the total compensation. When modelling your organization, you could choose to only use salary or the fully loaded cost. If you want to include all cost components, the first way to do this is to apply certain rates to the base salary. For example,  

• Salary (20,000) 

• Bonus – 5% of the salary (1,000) 

• Incentive bonuses – 5% of the salary (1,000) 

• Benefits – 25% to be applied on Salary + Bonus + Incentive bonuses (5,500) 

• Total compensation (27,500) 

Furthermore, these rates can be different depending on the location, function or other elements. For example, you could apply a 10% bonus rate to sales employees and a 5% bonus rate to non-sales employees. 

If the organization has a global scope, you will also need to consider exchange rates in order to see the cost impact from a company-wide perspective. Exchange rates can be set to automatically look up by country. 

In general, we recommend creating a rate card with the averages of the total compensation so that you include all the cost elements without adding complex calculations and the costs are automatically generated rather than entered manually. 

How do I specify the change in my future organization? 

Org modelling includes actions such as adding, removing and changing existing positions to create a 'future state' organization. This section will focus on the reasons behind all these modelling changes and how to track changes over time. 

Why do we need ‘change reason’? What are the common options? 
When designing your organization, you’ll make changes with different reasons behind it. It's important to capture the reasons because sometimes it's hard to see from the change itself. For example, when you change the reporting line for a position, the reason could be that you have closed its manager position, or that the whole team is moving to a new department. Therefore, we need the ‘change reason’ to explain it. This is not only beneficial to you, but also to all other designers who can share this information. In addition, you will be able to split the different types of changes and visualise the impact on each one. 

The most common change reasons are: 

• Decrease scope (usually for positions being demoted or downgraded) 

• Increase scope (usually for positions being promoted or upgraded) 

• Relocation (usually for positions being changed to another country/city, e.g. from UK to US) 

• Move to new team (usually for positions with changing reporting lines) 

• Other changes (for other minor changes, such as position title changes) 

In addition, there are reasons for new positions, such as Insourcing, Investment, New market/product line, etc. As well as reasons for closing positions, such as Outsourcing, Closing market/product line, etc. 
 

How could we track design changes over time? 

Tracking design changes helps you to assess and understand the impact from a time perspective, such as changes in headcount and costs from month to month. It also makes it easier for you to implement plans in the future. Design changes and key impacts can be tracked across periods, waves and initiatives. 

If you already have a clear plan in place, you can capture the exact date when the planned action will take effect. This way, you can view the impact from the perspective of any period (date, month, quarter, year). For example, if you plan to close a position on 1st May 2024, then you should capture 1st May 2024 as the action effective date and the cost and headcount of the position will be zero after that date. 

But if you only have a rough plan, you can group all actions into certain waves. For example, you could have four pre-defined waves for 2024: 

• Wave 1 = Q1, which starts at 1st Jan 2024 

• Wave 2 = Q2, which starts at 1st Apr 2024 

• Wave 3 = Q3, which starts at 1st Jul 2024 

• Wave 4 = Q4, which starts at 1st Oct 2024, 

then assign all actions to each wave and use the start date as the effective date. If you want to create ten new positions in the first quarter of 2024, you could assign this action to Wave 1 and then the start date, 1st Jan 2024, would be the effective date. The headcount and cost of new posts will not be counted until the effective date. 

Not only by assigning them to dates or waves, but you can also track design changes by grouping them into different initiatives. Org modelling typically include multiple initiatives, each with different effects, such as reduction in one area, investment in another. By grouping actions into initiatives, you can view and understand the impact of the actions associated with each initiative. 

Next Steps 

We recommend that you define your requirements, including: 

• Your data: 
  • People data 
  • Position data, which should include the following fields: 
    • Classification 
    • Structure 
    • Economics 
• Costs: 
  • Rate Card
  • Determine if you will be using salary only, or full loaded costs 
• Change reasons