Establishing the baseline

Your baseline dataset defines the ‘as-is’ organization.  At the start of an org modelling project the ‘to-be’ organization matches this baseline. As position-level ‘actions’ are specified – as positions are added, flagged for removal, or changed – the ‘to-be’ organization is immediately visualized and comparisons to the baseline are automatically generated.

An accurate baseline dataset provides the foundation for your modelling Project. This article runs through the main requirements and considerations.
 

What is the scope of the project?

Transformation need not to happen to the entire organization. As the matter of fact, one may find more success starting with a smaller scale project and gain valuable experience before embarking on more complex endeavour. The following are common ways to limit the population you need to work with:

• By Layer
• By Department/ Function
• By Location

When using the Org Modelling Guided Experience, all positions in the selected baseline dataset are included in the scope of the project. If you want to limit the scope, a draft of your core dataset should be created which excludes out of scope positions.

When using the Advanced Solution is used, you can create individual workstreams or specify which positions are in scope at the set-up stage.
 

Should a People Dataset or a Positions dataset be used?

For flexibility, our solutions accommodate both Positions and People datasets.  Best practice is to use Positions data:

• Position data remains stable over time as it is not susceptible to short-term fluctuations generated by people leaving or joining the organization. When an employee leaves, the position remains in the structure as ‘vacant’ with an associated position cost. As a result, spans and layers analysis remains unchanged, and full size and cost of the organization can be consistently reported.
• Modelling decisions – for example deciding to remove or change a position – should be informed by business need and should not be influenced with reference to the current incumbent.

For more information on People and Positions, see Why is it beneficial to split people and positions data?

What properties are needed in the baseline dataset?

Hierarchy Properties. Your selected baseline dataset needs to be a hierarchical dataset where all positions are connected in a single reporting structure through an ID and Position Manager ID properties.
Modelling Properties are used to define positions in the ‘to-be’ organization. During the modelling assignment, when a value for one or more modelling property is changed, the position is automatically categorised as ‘changed’.  There are three types of modelling property:

• Labelling Properties: for example, Position Title  
• Organization Dimension Properties: these are typically
  • Functional, e.g., Function, Sub-Function, Department
  • Geographic, e.g., Country, Region, Location, Site
  • Business Unit, e.g., Business Line, Product Area, Customer Segment
• Size and Cost Properties: typically, FTE, Position Grade and Position Cost.  In addition to being used to define positions, these properties are also used for reporting the ‘rolled-up’ size and cost of teams, subgroups and the overall ‘to-be’ organization.

Best practice is to select only the properties which are needed to specify Positions in the ‘to-be’ organization. Less is more: a greater number of modelling properties leads to more inputs being required when positions are modelled.

How can the baseline data quality be checked?

A modelling project needs to be based on accurate data. Without an accurate starting point, any analysis comparing the ‘as-is’ organization to the ‘to-be’ will be compromised.  Credibility will be at risk.

The quality of your baseline dataset needs to be established before starting the modelling assignment as any changes made after will result in positions being automatically categorized as ‘changed’.

Orgvue's template packs for Data Cleaning (1) reveal where there are errors or inconsistencies in your data, (2) enable these to be rapidly corrected, and (3) provide a record of your corrections so these can be fixed at source.

Common issues which can be addressed are:

Should a static baseline, or a rolling baseline be used?

Agreeing the baseline

When redesigning organizations, politics and personalities are never far from the surface. Predictable patterns of change resistance can be anticipated and prevented. “I don’t recognize my organization”, “Your data is wrong”.  Don’t let these classic behaviours risk derailing your project.

1. Take the time to analyse the baseline, ‘as-is’ organization. Orgvue’s template packs for organizational analysis rapidly equip you with detailed insights.

2. Share your analysis of the baseline with all stakeholders.  Invest the time to do this in person, and with stakeholders individually and collectively.

3. Get explicit approval from every stakeholder. The key word is explicit: don’t take silence to be agreement. You need everyone signed-up in agreement of your starting point.