One of my Aunt’s saddest stories related to when she was working in the outback of Australia more than fifty years ago. She was in a tiny settlement with one small store and one large bar. On a particularly hot day, out of the bush came a man tracking his family that had been eaten by some large strange animal. He was extremely distressed and confused. My Aunt decided to help. What did the animal look like? Where was it going? It turned out that it wasn’t an animal at all, but a truck. His aboriginal family was being cleared from their land in a terrible and still relatively recent part of Australian history.

How is it that a man thought that a truck was an animal? If we have no context for something that is truly new then we can only use our predefined constructs and language to describe something. When the car was first invented, people thought of a carriage without a horse and designed them to look like carriages. It is what people understood.

This is relevant to me because I need to explain OrgVue. I need to explain something that is so new that people don’t have sufficient terms of reference or the language. It is natural for humans to try to simplify something. They want to put it in a box. “So it is an Org Charting product” or “a visualisation product” or “Excel on the web with the ability to work with hierarchies”.

Marketing people talk about “Categories” and if something is a new category then you have to define both the category and product. Marketing people also tell you to keep it simple. To communicate in less than one minute. In an elevator. To nail what it is in a couple of sentences, or in one short seven word phrase.

It is easy to state some of the things OrgVue does that more traditional products also do:

• It helps you visualise data. You can build dashboards, infographics and many other images but it isn’t a traditional “dash boarding” product like Tableau or QlikView
• It is a database… but not the sort you would normally think of. It isn’t a relational database, but it builds a graph. You can store, add, change and track data
• It is an Org Charter. You can build org charts with pictures on them, but you have over a dozen types of cards and another dozen (plus) ways of laying out those charts. The card is just a type of report and it is all “just data”
• You can run surveys, but these are also forms and built into the fabric of the product

These are all understood and well defined “solutions”. So is OrgVue just a bundling of different products into one? When Steve Jobs launched the iPhone, he said he was launching 4 new products. They all happened to be things that used to be separate. The iPhone was a smartphone (phone, calendar, e-mail), camera, the web, an iPod and eventually all the apps. The iPhone brought it all together. So, is OrgVue just bringing all this stuff together? No, it is more. It is doing something different still:

• It enables you to define processes or objectives and link them to people or roles in an accountability matrix. Equally, you can see projects or customers or risks or a “work breakdown structure”, and…
• You can define the cost of each process or the amount of time that each employee spends on that process, enabling you to create a cost to serve, and…
• You can see the process maps in a range of ways, just like you do with chevrons in PowerPoint but connected with data, and…
• You can do calculations just like in Excel, but also traverse a hierarchy and the graph, and…
• The event store keeps track of every single change to every single cell of data with a record of who made what change and when so that history can be played back or actuals tracked against target

Of the funniest things said to me (with respect to OrgVue that is) was by the actor who did the voice over for our intro video.

The actor is famous enough in his own right, having starred in films such as “Pirates of the Caribbean”. He decided to help my cousin out (I’m from a very large family) who in turn is a budding film Director and was helping us with our OrgVue film on “Cousin rates” (even better than mates rates). After doing the voiceover he said, “So does OrgVue make the coffee and take out the milk too?” Ahhhh.

So, what do we do? How do we communicate something so new and, I believe, so powerful? It is not like all these things are different components. They are all within a single, simple user interface. Equally, it isn’t that we started out trying to create what we have. It just happened because it was necessary to solve the business problems of getting to grips with detailed organisation design, HR analytics and workforce planning.

Perhaps this challenge is similar to that faced by spreadsheet software such as Excel in the 1980’s.  Even in its early days Excel could do many things – store and analyse data, compute formulas, and run custom programmes (macros) – it was hard to communicate.  How do you describe Excel?

Excel was not only financial planning software, but it was finance professionals that quickly figured out its value for their field and helped popularize its use into what we see today – Excel is used in nearly every business function. Microsoft and other early spreadsheet developers had set out to develop a digital version of a paper accounting worksheet, but in the process built something with far more uses than they could have imagined at the time.

We have done something similar with OrgVue – it is far more useful and powerful than we could have imagined in its early days, yet so incredibly difficult to put into words.  This has an upside: we find new uses for OrgVue all the time.

The OrgVue team is very excited to be presenting at the ODN Europe conference taking place at Prospero House, Borough High Street, London on 25^th – 26^th April 2013. We will be talking about the revolution in Organisation Design being led by OrgVue.

There will be a coffee stand at which delegates can learn more about the latest release (v2.4) and OrgVue is also going to host the conference directory, giving attendees a PDF lookup guide with as many details as they want to share.

A few years ago I was doing an organisation design piece for a multinational FMCG firm. They wanted to transition their supply chain organisation from a country to a central one in order to improve their ability to commercialise new products, improve their functional excellence and drive cross border synergies. After lots of concept, process and detailed structural design, a big question came up (and always comes);

How many FTEs do we need, in what roles and why?

Of the circa 6,000 FTEs, roughly half were in the plants. Each plant had grown independently from a design perspective. Some would have 8 people doing a given role while others would only have 2, for the same scale of plant. That is a 400% difference and was replicated across a large percentage of the various roles. Another issue was different plants had subtly (and not so subtly) different structures; orders of magnitude differences in investments in core processes and large ranges in % cost by supporting processes/functions.

As outlined in my rightsizing blog post, there are four generic methods to answer the question, “How many FTEs should we have per role?”. The one used to answer this multi-plant question is driver analysis. A driver is one or more metrics that define the number of FTEs needed. It is normally a set of multiplications and additions. The maths should be simple and understandable. It is useful to do driver analysis in situations where there are a number of organisational units that are different in scale and complexity but fundamentally do the same thing. For example manufacturing plants; call centres; sales forces…

Generic Examples:

• Number of calls, cases, projects
• Revenue, sales targets
• Number of manufacturing lines
• Productivity improvements

The example I am going to use is that of a manufacturing plant. This sanitised example was used to compare c20 manufacturing plants across Europe. Each was different in terms of their volume, mix of lines and in part, level of technology capability but had a broadly similar process.

The steps are:

• Define a standard org chart
• For each role, define if it is fixed or variable. If it is fixed, it’s typically 1 FTE but not always
• If variable, determine what the driver is and how the drivers size the role
• Build the model:
  • Collect the assumptions for each plant
  • Build the calculations
• Sense check, review and test (there may be interaction here, as the drivers are refined)

Define the standard Org Chart

The first two levels of our example can be seen in the diagram below.

With all the 39 roles shown in the below with the 16 variable ones in yellow and the remaining 23 in blue.

Define the list of drivers

In this example, there are5 basic types of drivers.

1. The number of lines by types of line: Each line has a number of operators per line. Not all lines are the same in their nature
2. Number of shifts: There are shift workers and non-shift workers. The number of shift workers needs to be multiplied by the number of shifts
3. The presence or not of a technology: Not all plants have the same technology. By having a yes or no to a type of technology, then the accuracy of the model can be improved. This can also lead to the easy development of a business case
4. Senior roles: The number of admin staff is driven by the number of senior roles as one admin looks after x executives.
5. The volume: Volume isn’t actually a driver but an output. However, calculating the cost per volume is a way of sense-checking the scale and economics.

The drivers and the volume of each driver for each plant is then documented.

Build the model and populate it

The table below highlights most of the calculations. For each role, there is a driver. Take the example of “Line Type B Operators”. The calculation is that there need to be 40 operators on the 4 lines. There are 2.5 FTEs per line and 4 shifts with 4 lines = 2.5 * 4 * 4 = 40. In other words, pretty simple.

The column “DriverNum” is from the lookup table. For instance, in the given example, there were 4 Line Type Bs (that means 4 different manufacturing lines of a given type. Each type is an apples-to-apples comparison). The 2.5 FTEs per line is shown on the right most column in green. This is one of the critical “assumptions” or “driver ratios”. The way of determining this number is through internal benchmarking (how many actual FTEs are working on Line Type B, by plant by shift) and discussions with experts who know the type of line and can validate from experience that 2.5 is a workable number. This type of analysis leads to discussions as to why some plants have more than 2 and why some might only have 2 and what the negative impact is of only having 2 vs. 2.5 (the 0.5 means that 1 person floats between two lines, supporting activities like set-up).

From this you can roll-up the total number of FTEs, as shown in the 3^rd from right column, i.e. there are a a total of 272.75 FTEs for the example plant. This data can be seen visually in the scaled org chart view for the manufacturing roles, below.

We like the scaled org charts because it helps to give a sense of proportion within the familiar org chart picture.

Test it

Once the driver model has been developed, it is clearly crucial to test the thinking and results. The best way to test is for a group of stakeholders to review many of the conclusions in graphical format and to see the organisation in different ways. Each way is likely to raise a different question, building both confidence and refinement in the recommendations. For example, the split of the roles can be seen by depth.

For the highlighted plant, the As-Is number of FTEs is 314 and therefore there is a difference of 41, or 13%.

Scaling the analysis for all plants

The next step is to run all plants (in this example 20 plants) and to see the impact. In this example, there are 20 plants with 4,423 As-IS FTEs. The driver model based on a standard Plant Org Model reduced this to 3,825 or 598 fewer FTEs. The below shows a scatter plot of each plant, coloured by the Area (region) they are from. The x-axis is the difference in number of FTEs between As-IS and modelled. The Y-Axis is the number of current FTEs and the bubble can be any other measure (e.g. revenue; quantity…)

Lastly, the work should probably not stop there. Further analysis should be conducted at the function and role level. What transpires is that some plants have significant variances at the function and role levels. Seeing 3 times more staff in one role isn’t unheard of.

Additional elements of analysis and test could include:

• Spans of Control – have a max and min for each role type (This is in fact another driver)
• Output measures vs. the numbers, e.g. Revenue or units produced vs. the numbers
  • Large plants vs. each other
  • Small plants vs. each other
• Quality scores for those with a higher ratio of staff in a function (e.g. Quality FTEs)
• The reactions of functional leads and the workability of what the model is actually concluding
• Other possible drivers that are harder to quantify, but might have an impact. For instance:
  • Age of the plant vs. % difference in age
  • Level of capital investment vs. % difference in capital investment
• Items like level of automation should be captured within the model. However, if they are not, then a view on this as a way of explaining the variances…

These sorts of exercises don’t mean that each plant has to suddenly reduce its numbers in some sort of dogmatic automatic way. Hence the need for the additional elements of analysis in the above example. There may be robust reasons for ‘settling’ on another outcome. For example capital investment is required to get the numbers of operators on Line Type B to 2.5 from 4 in many plants and the ROI from that investment would be below the minimum hurdle rate. However, it does raise dozens of insightful questions.

The quality of the analysis is based on the robustness of the standard Org Design and the drivers selected. That requires a good understanding of many of the as-is current designs through detailed interviews & workshops with those who manage and truly understand the plants. Like all bits of analysis, it can all too easily be garbage-in-garbage-out.

Benchmarking is always dangerous and the “Magic Number” is one of the greatest threats to proper right-sizing. So be thoughtful, careful and reflective. But, equally, don’t let the “because it is tough” get in the way of doing the work. Don’t let wool be pulled over your eyes either. Not every “operation” is so different to warrant 400% difference in numbers. In the end, you will all learn a huge amount and will drive a more robust answer to the question: “How many FTEs do we really need?”

Can an organisation really be designed? Do people really work that way? Should it not just evolve? Does it apply to highly paid knowledge workers? Should people not just work it out?

There are many who criticise rational design. That believe it either just can’t be done or shouldn’t be. That there is another way and by implication that other way is mutually exclusive to the rational design approach.

It will probably surprise most people who follow my blog posts and even know me well, that I have a huge amount time for this view. Having done my best to understand Economics, I know just how poor ‘we’ are at understanding it. That our tools are so blunt, they are almost useless. Einstein famously wrote on his blackboard at Princeton that:

“Not everything that counts can be counted, and not everything that can be counted counts.”

It is with this in mind that we preach several core principles in doing effective Micro design:

• It shouldn’t become too detailed as too much detail will overwhelm you and make it unmanageable. By definition, the rational approach is limited by its ability to document; think it all through; to understand it. By definition, therefore, it can only be a sketch. It isn’t the reality but a guide to who does what.
• Micro design is a system and it is all the elements working together than make it work. But you can only really understand two elements together at one time, or all elements from only one perspective (a job description has a large number of elements and is a way of pulling it all together).
• To understand how it is going to work in practice (HOWWIP), you have to talk it through. That you can’t (shouldn’t try to) process design everything in detailed convoluted swim lanes.

Chris Rodgers, an expert in the field of Organisation Dynamics, has a view that I totally agree with in “the Wiggly-ness of an org”. That an organisation is in “constant flux.”

As he states on his website:

So, do we give up? Do we say no structure? No boundaries? Are these things truly mutually exclusive? And if so, should the rational approach admit defeat? Then what?

If all our time is then spent trying to define things informally, where do you know where to focus in the first place? Does this sort of approach work for the likes for junior staff who desire and need direction? Perhaps then it works for senior employees only, those who are true experts in what they do and don’t need direction? But even then, is there not a risk that they will they pull in different directions? Can they solve issues in teams with different agenda?

So, why do I simultaneously like the concept of organisation “Wiggly-ness” and “Rational Design?” Why do I believe you can have your cake and eat it?

I like it, because I know people are not robots and don’t all fit in neat boxes. That there is a natural tension between trying to provide structure and letting people work out what is best. That I know we all suffer from what economists call “Bounded Rationality”.

It can work if you follow the core principles I outlined above. I think the point is enough structure, enough detail to make sure everyone knows what they need to do, who is responsible (broadly) for what. That there is a clear direction and set of principles. That the organisation size has been robustly thought through… And then let the team work it out. If things are too unclear, provide more definition. Use the HOWWIP to work out some of the finer points, but as I say in the HOWWIP blog post, you can’t define everything.

The above has loads of questions and pretty theoretical concepts. So a sports example might help explain what I mean.

Rugby is a highly structured game. There are 15 clearly defined roles. A prop is a totally different type of role to a scrum-half or full back. There are times during the game when the entire team is in their role (e.g. during a scrum). The moves are practised. Technique is honed over years. There are moments, however, when structure breaks down. When a ‘back’ needs to clear a ruck and a forward draw an opponent in and make a killer pass. (This may be double Dutch, but bear with me).

One of my brothers was living in Japan in the nineties. As a good ‘Kiwi lad’, he decided to coach one of the local rugby teams. The training was a good 3x longer than any training session in New Zealand. They trained so long because every drill was broken down into such micro detail that it took an age to discuss each step and movement. They would discuss a drill at length. Where everyone would stand. How they would pass the ball. How it would be caught, carried, passed again. The angles of the elbows and hips… once they did it, everyone was asked how it felt. They would discuss and discuss.

Now, let’s take another extreme. You give the kids a ball and tell them to play. Just play. We used to play hours and hours of touch rugby (no tackling, all quite free form). We would develop instincts. Learn how to catch, pass or dummy and make a break. The sorts of things who just can’t “train”. That developed skills and awareness. It meant that you can “play the game in front of you”.

Now, if you only ever played ‘the game in front of you’ without structure, you would fail. If you only trained with precise structure, equally, you would fail. My point is you need both. You need to know your role, when to play your role BUT equally, you need to build instincts. Know how to see gaps, break the structure and go for it. It is about learning how to read the game. That all takes time and different forms of practice.

So, from my perspective, there is no conflict between rational design and organisation dynamics. They need each other, just like “yin and yang” which is used to describe how seemingly opposite or contrary forces are interconnected and interdependent in the natural world; and, how they give rise to each other as they interrelate to one another. Too much of either is a bad thing and the denial of either is putting your head in the sand.

OrgVue version v2.4 was released into live in April 2013. This is a summary of the main improvements that it offers:

2. New and Better Functionality

2.1. Account Management

In OrgVue v2.4, account management and security has been upgraded so that:

• On logging in, you see a list of the one or more tenants to which you have access
• You can administer the multiple tenants to which you have access using one log-in
• The log-in screen itself looks more modern

The benefits of this for administrators are that you have much greater control over potentially several client accounts.

Please note that for security reasons, only one person at a time can be logged in with any particular username. A second concurrent log-in with the same details will result in an automatic log-out of the first person logged in.

2.2. Dashboards

OrgVue v2.4 offers 9 standard dashboards, up from 2 in v2.2

The dashboards are listed below, with the value that we see in each dashboard:

2.2.1. Bubble

The bubble dashboard gives an intuitive sense of the size of populations being shown.

2.2.2. Charts

The Charts dashboard delivers all the functionality that users have previously accessed through the Charts tab. It adds better legends – which show the population being described with their colours. And it offers much better performance in terms of speed. For example, charts that took 12 seconds to load can now be accessed through dashboards in 4 seconds.

Users may still choose to use ‘Charts’ to gain access to underlying data, which can be copied out from the Charts tab into Excel.

2.2.3. CrossTabs

The CrossTabs dashboard helps you visualise key comparisons on one page – showing up to 4 variables for each comparison. It is controlled through the normal charting controls on the right hand side of the screen. Your selection of ‘Chart by’ and ‘Colour’ define the horizontal and vertical axes.

2.2.4. Distribution

The Distribution dashboard helps you visualise key comparisons as a line chart on one page. Like the Cross-Tabs dashboard, it is controlled through the normal charting controls on the right hand side of the screen. The line chart is an effective way of visualising outliers in dimensions of data

2.2.5. Infographic

The Infographic dashboard helps you to bring data to life. It is controlled through the charting controls on the right hand side of the screen. It is an alternative to the Bubble chart as a way of visualising the data. It has the advantage that every point in the dataset is actually represented on the screen as an icon, allowing the user to hover over any item in the dataset. In future releases, items will be clickable to allow users to access data through the image.

2.2.6. Pie

The Pie dashboard allows you to create a range of pie charts (or more exactly, doughnut charts) for your data:

2.2.7. Quality

The Quality dashboard has been retained in v2.4, and is included in these Release Notes for completeness.

2.2.8. Sunburst

The Sunburst dashboard can now be shown with much greater detail, either in its traditional ‘single large’ burst format or split down into multiple separate sections:

2.2.9. Word Clouds

The Word Cloud dashboard allows you to visualise the frequency of categories in a dimension of the dataset, while colouring and grouping by another variable.

2.2.10. Correlations

The correlations dashboard has been removed from v2.4, on the grounds that it has been overtaken by the 9 dashboards above.

2.3. Fully Configurable Dashboards

In addition to the standard dashboards listed above, clients can specify the dashboards that they want to present. Configurable dashboards can include any data that is in the dataset, and any visualisation, from line charts to bar charts to bubbles, word clouds or infographics. Concentra can configure these dashboards for sharing within the business.

2.4. User-Defined Dashboards

In OrgVue version 2.4, we are giving users the ability to configure dashboards themselves, backed with training and support from Concentra. Users who will find it easy to configure their own dashboards include people who are comfortable with Java scripts and Access databases. We would usually recommend some training from Concentra to get started with configuring your own dashboards.

2.5. Property Pane

The new Property Pane in OrgVue v2.4 is significantly easier to use. It appears on the left hand side of the screen, making it easy to see the details relating to any individual in the data set.

The Property Pane is available when you are working on the Worksheet, the pivot table or the Org Chart:

2.6. Dates

Dates are now handled by OrgVue as a specific type of property, joining numbers, images and text. They can be defined by users in the format that they prefer. Key benefits for users include:

• Users can now group dates in ‘Bins’ when sorting data and creating graphs
• OrgVue’s time series functionality now allows dashboards to start graphing events over time
• Users can analyse events that have occurred  by ‘year’, by ‘month’ (in whatever year) and by ‘day of the month’

In this case, the user has chosen to use the format MMM yyyy for Start Date and dd/MM/yyyy for Role Start Date:

Please note that date formats vary specifically according to syntax, so e.g. MMMM yyyy will generate a full month name, whereas MMM yyyy will generate a short month name. This gives the user a great deal of control in displaying dates and analysing date information.

The Benefit for users is that you can analyse trends in data, for example patterns in start dates by month:

2.7. Images

Image upload is simple and easy in OrgVue v2.4. On the Property Pane, any property can be set to ‘Image’ and the User can upload a photograph by clicking on the ‘Upload’ button.

2.8. PDFs

OrgVue now generates high definition PDFs from its dashboards. This gives the user a new option to export and share OrgVue outputs. The PDFs generated can be single page, multiple page (in the case of producing multiple charts for different areas of the business, for example) or multiple PDFs, if you want to generate an individual chart for each area of the business to be sent separately.

PDFs go hand-in-hand with the Dashboard functionality to offer a major new advance in Users’ abilities to create reports in OrgVue and share them. PDFs have advantages including being able to be read on smartphones and tablets. They are produced in extremely high definition, using vector graphics, meaning that they are ‘infinitely zoomable’ and look great in print and on screen.

In v2.4 PDFs generated from OrgCharts remain as bitmaps – so to produce very large or high-definition OrgCharts for printing, we continue to recommend zooming in to extreme close-up then using the camera icon to capture the image as normal.

2.9. Surveys

Surveys have become more advanced in OrgVue v2.4. Via the Property Pane, data fields can be edited, can be nominated for inclusion in or exclusion from Surveys and can have their Question Type defined:

Defining the type of question to include on a Survey:

2.10. Lookup Expressions

OrgVue v2.4 allows you to use LookUp Expressions in order to keep your main dataset updated with a reference set of data. This can be useful where the reference set of data needs to be updated periodically, and the change needs to be dialled through the entire population of your main dataset.

To use a lookup dataset, the key steps are:

1. Determine field in your existing data set which you will use to ‘Lookup’ additional data (in this example, we are using the ‘Grade’ field from the ‘People Link Example’ data set)

2. Create new data set of data you wish to have against Lookup value (Grade), e.g.

3. Create a new data set in the ‘Lookups’ tab and copy/paste new data in.

Important: the ‘ID’ of new data set must match the Lookup value:

4. Use the OrgVue Expression Language to obtain the lookup value from your source dataset using the following formula:

node.lookup(‘<lookup value>’).<lookup target value>

for example:

node.lookup(‘Grade’).targetsalary

In this example, node.lookup(‘Grade’).targetsalary will return the target salary from the Lookup data set for the associated Grade from the selected node in your current data set

5. A formula can also be set as the value of a Property, e.g.:

2.11. Conditional formatting on data entry

In OrgVue v2.4, conditional formatting allows users to see where data entered does not conform to a pre-defined list of values.

Example:

2.12. Other Improvements

2.12.1. Using Tab To Move Around

Users can now use ‘Tab’ and ‘Shift Tab’ buttons to move up and down through the Property Pane, and through pdfs created from OrgVue.

2.12.2. Simpler, Cleaner Interface

OrgVue v2.4 has been built with a cleaner font, a lighter background for increased visibility and easier viewing. The cleaner font comes through into pdfs published from OrgVue.

Old:

New:

2.12.3. Refresh or Recalculate Options

In OrgVue v2.4, there are options to do a ‘Shallow’ refresh, refreshing the visual image only or to do a full ‘Recalculate’ of the data shown on the grid. When no mathematical changes have taken place, and re-calculation is not needed, using the ‘shallow’ refresh can be a quicker way of updating what is shown on the screen.

3. Queries and Feedback

I love acronyms and jargon… because I love ideas and I love frameworks, perspectives or methods being summarised into a short word or acronym. One of my favourites is HOWWIP, which is short for HOw Will it Work In Practice, pronounced “How Wip”. Now, I’ll grant you that this probably isn’t the most elegant word and yes, we (Giles Slinger and I) invented it. So yes, it is perhaps a bit rich of me to say it is one of my favourites. That is a bit like every parent thinking their baby is beautiful and extremely cute… far cuter than normal by some margin.

Putting all that aside, the central question on everyone’s lips is, “How will it really work?”. The design process is theoretical. It is a construct of the mind. It needs conversion. That is what the HOWWIP is all about.

So what does HOWWIP really mean and why is it useful in the context of organisation design?

1) What does it really mean?

It is what it says on the tin. How will the organisation really work… really work in practice? When we say really, we mean REALLY REALLY… like on a Tuesday morning when x, y, or z happens.

2) Why is it useful

A large part of Making the design (it) Real (MiR) is getting everyone’s head around what the design really means to them personally. How will they be impacted and how will it work. Part of this is about the interface design. How items of work will be handed from one person to another. Another is bringing tangible clarity to what can be seem pretty theoretical. To see a decision matrix with a set of acronyms such as RAS (Responsible; Approve; Support) is one thing. To understand what “Approve” or “Support” really means in the context of that decision is another. For example, “Approve” the recruiting plan might have the Finance Director, HRD and Business Director with “As”. The HOWWIP is a face-to-face brain storming session on the practicalities of delivery. It anticipates issues and deals with them once spotted. That they need to get a hire form filled in by the second Tuesday of the month… or that all roles must be in the budget that is signed off annually by those same people. However, if there is an exception mid-way through the year, then the MD must approve and…

The HOWWIP is about thinking through exceptions and issues. It is thinking through the sorts of things that will trip the design up. This doesn’t mean it has to be exhaustive. By its very nature, it just can’t be exhaustive. So really don’t try. Just try to be representative. What it gives is a set of case examples which should be helpful in sorting other issues as they inevitably arise. It is almost like a form of “Case Law”.

The HOWWIP question log

It is a good practice to list all HOWWIP questions in a “HOWWIP Question Log”. Every time some asks, “How will that work”, document it and see if you have the answers. These are the sorts of things that would often appear in a FAQ. They double as a test of the “implementability” of the design.

An exercise:

• Take one sub-process that involves interaction at many points within the business – e.g. recruitment, L&D or appraisals
• Think and talk through the process. Aim to understand it:
  • Define where the process starts and finishes
  • Identify the points where there are hand-offs
  • Define in the Inputs; Activities; Outputs at each stage plus any decisions
• Test that the process will work and that it is clear:
  • List a set of questions as to how the process will work
  • Have a group stand-up in a small circle with each person in the circle “acting” one (or more if more roles than people in the circle, but always being clear what role you are “playing” at any time) of the roles. Start with the first step and then pass a “who’s got the monkey” juggling ball to the person who acts next.
  • At each step, say: what it is you needed, what you will do and what the outcome will be.

What you need (Input)? What you will do (Activity)? What the outcome will be (Output)?

• Write up any orphans (activities or decisions that don’t have an owner), gaps, issues and questions on a flip charts/white board and then into Excel/OrgVue/Word/PPT…
• Review after the completion of an area to understand the amount of workload that was missing from the original description. Debate and resolve the issues
• Use the HOWWIP Question Log as the place to document the outcomes

The pros and cons of Level 2 design

Level 0 is a summary map; Level 1 is the processes depicted more as steps and then the activities; decision; deliverables as bullet point lists below each process (or sub process). The processes are hierarchical in nature… Level 2 is a swim lane with owners and icons representing various actions such as decision; activity; sub-process; output… (I will publish another blog in due course to explain the differences in more detail)

A “swim lane level 2 process map” is a form of a HOWWIP. It details how a process should work. My experience is that these have their time & place, but are not the full answer and should be started with caution. They can be confusing; they are idealistic; they can be hard to follow; they take lots of time to generate… So don’t try to define everything as a level 2 process map. Just do it where there are lots of hand-offs; when a fairly strict process should be followed; where there are loops and complexities… the key is to define them and then aim to improve them. Count the number of hand-offs and asks whether that is workable. The number of times that I have seen 15+ hand-offs within a single process (once the process has been documented) is pretty remarkable (in a bad way).

What about employee engagement? The politics? What’s in it for me?

In our approach, these crucial questions are dealt with as part of the Making it Real (MiR) stage in the process. They are all crucial questions and are major topics in their own right. HOWWIP is about how it will work pure and simple. During the design process, it can get all a little too theoretical. There are hundreds of really simple questions that need answering. Not all those questions can be answered during the design phase, but the HOWWIP aims to address the ‘nitty-gritty’ of how things will really work. That is it. Nothing more and nothing less.

In summary:

Embrace the HOWWIP. Embrace making things real and thinking through how stuff will really work. My experience is, it is only at the HOWWIP stage that you know whether the design will really work. It is the place where you will get the “Oh sh*t” and “we really need to work that one out” moments as well as the “an-ha” and “yes, I can finally see how this is actually going to work”. It is where it all starts to become real. Enjoy those moments.

Ensuring you have the right number of people with the right competencies in the right roles at the right time and place. Is that Workforce Planning or Micro design? Seems like Micro design to me… also seems like workforce planning to me. So, what is the difference?

Below is a list of the five main differences.

Ad-hoc vs. Ongoing

Micro design happens every now and again. It is one of those stand back, work it through types of activities.

Workforce planning (and management) is constant. Employees are constantly moving on to new roles or organisations. It is constantly in flux and needs constant management.

Strategic in nature vs. operational, tactical and reactive

In other words, Micro Design is more strategic in nature. It is about defining where you need to go. Workforce planning & management is about getting you there. They are therefore totally symbiotic. They need each other. Doing workforce planning without a clear Micro Design is like driving somewhere without a map or even a destination in mind.

About defining the “Role” vs. Planning & Execution

It is all in the words. Micro “Design” is just that: designing and defining roles. Roles are made up of objectives; accountabilities; competencies; number of FTEs required for each role; where the role sits organisationally and where the role reports to. The end result is the “Job Spec” or “Role Description”.

Workforce Planning is about who will fill the role. It is about people. It is therefore about compromise because there is rarely a perfect fit between the list of candidates and the job description. Knowing what is truly essential vs. desirable in order to make trade-offs between candidates is a large part of the selection process. Moving on from recruitment to Learning & Development, what training needs to be provided to close the gaps between this ideal and actual competencies? What competencies need closing in what order? How do you even know they have been closed?

Idealistic vs. Pragmatic

In other words, Micro design is about the ideal. It is defining the perfect solution. But reality never lives up to that perfect image. There are always rough edge and human frailties. This is why there is a limit to what can be done by a machine or software programme. Judgement always needs to be applied.

“As-Is vs. To-Be” vs. Time series

What is the As-Is situation and the To-Be design? How and where do they differ? What are the improvements? How big is the change? What is the impact going to be?

How many FTEs are required by role by geography by month/quarter? It isn’t just about two states (As-Is vs. To-Be). It is about the transition of those states, broken into months/quarters into the future. In reality, the To-Be will never be reached because too much changes. The whole concept of “steady state” is a misnomer. In fact, knowing how the plan changes is pretty insightful and worth reflecting on.

Why bother with the distinction?

One of the questions a colleague asked me while reading a draft of this blog was why bother with the distinction between the two things?

Because:

The term “Workforce Planning” is a highly used and recognised term. It means a great deal to a great number of people. In that context, we are also defining a new term, “Micro Design”. Micro Design is one of the 3 elements of our Organisation Design process – Macro; Micro; Making it Real (MiR). Because there are overlaps, I thought it was important to distinguish between the two. This then provides greater clarity on what each separate term therefore means. The difference helps understand each concept.

In summary, the two concepts are closely related. Ideally the Micro Design should lead to workforce planning and management. Both cover the detail of making an organisation work. But they are distinctly different. Design vs. Execution; Strategic vs. Operational; Ad-hoc vs. Ongoing… good design will make implementation workable and implementable. Workforce planning and management are crucial elements in the implementation. In all likelihood those doing the design won’t be doing the workforce management. They may not even talk nor understand the impact they have on each other.

Given how closely linked these two activities are, one wonders how successful either can be without the other?

For 8 years I trained Consultants at A.T. Kearney in how to do analysis using Excel and Access. A big part of the theory is to do know what analysis to do in what tool. I have seen Consultants with MBAs from the best schools in the world take weeks doing analysis (poorly) in Excel when all of it could (and subsequently was) done in hours in Access. When you want to cut & slice & drill large quantities of data, Excel just doesn’t cut it. Even with vlookups, sumifs and even arrays all over the shop Excel just doesn’t cut it. Even worse, I have seen people do pivot tables, cut & paste the output and then do analysis on that data… only for something to change, the pattern of copy & pasting values… a total nightmare.

One of the big tricks is to get the data schema and relationships right. What is the structure that you want to analyse? Setting up primary keys and ensuring they are all consistent across the entire model. The image below shows an overly simplified example of 5 tables, which form part of how to do bid analysis in the context of Strategic Sourcing.

My experience is, in general, most people really struggle to get their heads account designing a relational database or how to write SQL queries with complex joins etc.

So, having gotten my head around relational databases and feel a small quantum of expertise in them, it was quite a surprise when the OrgVue team informed me that we would take inspiration from graph databases in order to solve the Org Design problem I had laid out. What were they talking about? And then we could make it schemaless!!! How? A journey of understanding. Graph databases are a totally different paradigm. There are nodes, edges, properties… what are they?

Starting with the Org Design Challenge

There is an org structure, which is hierarchical. The box (node in graphing speak) has reporting lines and can even have dotted lines (breaking that hierarchy from a simple tree). On top of this organisational structural view, I wanted to be able to define processes and accountabilities; objective trees and again, accountabilities… However, I couldn’t be certain which elements clients wanted to define. What about “Customer Data” in another hierarchy, e.g. markets, segments, location… ?

All this, apparently, was ideally solved by a graph.

So, what is a graph?

Wikipedia says: “A graph database uses graph structures with nodes, edges, and properties to represent and store data. By definition, a graph database is any storage system that provides index-free adjacency. This means that every element contains a direct pointer to its adjacent element and no index lookups are necessary.”

Let me break this down:

“Nodes represent entities such as people, business, accounts, or any other item you might want to keep track of.”

Think of a node as the “thing” or a “folder”. The folder contains information. For instance, if it is a person, then the information you may want to collect includes: Name, Age, Gender, Tenure, Nationality, a picture… All this information within the node is called the properties of the node. In the above Wikipedia example, Node with Id: 1 has name: Alice and Age: 18. Other nodes can have different types of properties. It just doesn’t matter. Knock yourself out and give each node as many properties as you like. Furthermore, not all nodes require the same properties to be defined, and what type of data you hold in each property is entirely up to you. Equally, don’t worry about how to link them, what the primary keys are, the relationships and referential integrity… those are not the constructs of the “Graphing World”.

The next key concept is edges. “Edges are the lines that connect nodes to nodes or nodes to properties and they represent the relationship between the two”.

Edges have values just like properties. For example the famous RACI & RAPID (or our simplified RAS) grids that define accountabilities for decisions or activities or… for a given set of roles. Other examples could be the percentage of their time that someone spends doing given activities (which is part of what we call the IAA, Individual Activity Analysis) or whether someone is in a given role. The range is endless.

The beauty, from my perspective at least, is that you can then slice the data by any property, edge or node. It is free form. For analysts it really feels liberating. It just works. Yes, like Excel or Access (or SQL or any other query language) there is stuff to learn. OrgVue has an Expression Language called “Gizmo”. It allows you to “traverse” the graph. It allows you to create new properties (such as sum of cost; ratio of x:y; roll-up of (x * y + z)… a topic for a much longer piece) or use many of the out-of-the-box properties such as depth; number of children (called outgoing count, e.g. in the context of design this is the Span of Control); is leaf or not (leaf doesn’t have any children, i.e. at the end of the tree).

As the above should be making clear, there is a whole new language surrounding this graphing paradigm. You have children (reports into Node) and descendants (all children, their children… until you get to the leaves). It all feels very organic. You can create and then explore. Like all things, it takes a bit of time to get used to. But getting used to it is pretty easy. My experience is most people I tried to train in relational databases just never got there. And now, finally, there is a way.

As a footnote, what are examples of other graphing databases?

• Social networking sites like Facebook use them
• Amazon recommendations are built on one
• Your SatNav – roads are edges

There are lots of exciting examples of graphs. The idea of graphs is not new (just relatively new to me, but then again, I’m not a computer scientist… just an Economist turned Management Consultant turned Entrepreneur… so what do I really know). In fact, graphs and object orientated databases have been around for ages. The relational database world grew out of the need to maintain integrity of transactional data sets and to allow easy manipulation of these data. It clearly captured market share to the point where “people like me” didn’t know there was even another option or world. So there is another world. It feels organic. It is schemaless. It just works. Enjoy.

People often say one thing but really mean something else. They say our “Vision” but mean “Goal”. For instance, our “vision is to be in the top quarter of x”. A noble goal, for sure. But not a vision. And so it is equally with Workforce Planning.

All too often, what is meant is an overview of the workforce demographics. The kinds of questions referred to often include:

• How many people do we have for a given age?
• What is the gender or diversity split?
• How many open posts are there?

But this is not workforce planning, it is HR analytics.

Workforce planning is about the numbers of “workers” (be they perm or temp; full time or part) required for each time period (by year, month, week…) and what the gap is given the current headcount, given likely attrition and the required skills sets/competencies. I.e. it is temporal in nature. It requires planning, gap analysis, and tracking of progress.

Two main points of view here:

1. We like to think of workforce planning across three time horizons:
   1. Strategic/Multi-year
   2. Operational/In year
   3. Tactical/within the window of current recruitment and staff-turnover churn/replacement cycles
2. We think a better term would be “Workforce Management” than “Workforce Planning”:
   1. To start with, yes, it is about having a robust plan. A necessary but insufficient requirement
   2. It is about knowing the gap between actuals and plan. It is about knowing why there is a gap. What is the root cause? Is it because you didn’t recruit the number in the plan? Is churn highly than assumed? Has the plan has changed?…Only when you know why you are off plan in any given area are in you in position do actually do something about it
   3. It is about knowing how the plan is changing and being able to adapt to change in flight. It is about communication. Everyone knowing the state of play. Everyone being clear what they need to do and how well they are doing. This is management, pure and simple.

Three time horizons of workforce planning

The below figure highlights the relative amount of effort required at a point of time vs the “number of years forward looking”. At most points in time, the Tactical Management absorbs the majority of time, but only has a relatively short horizon.

Strategic Workforce Planning

This is the multi-year stuff. It is related to helping and even driving the overall strategy. If people are your most important asset, then how are you going to make them your differentiator to “win” in future years?

Example of strategic planning include:

• Looking at the number of Doctors who are going to retire in 5-10 years. Spotting that there was a large intake nationally 20 years ago, that the pipeline of existing “talent” and student graduates isn’t large enough to plug the gap. This is where governments need to understand they need to increase the intake of students. Another example of this is the number of nuclear scientists with respect to the nuclear power industry or experienced mine engineers in parts of Australia. They are the sorts of trends that are hard to spot with a “In-Year” or even “In-decade” perspective.

• Thinking through the core activities which will strategically differentiate you the competition. As one strategy professor said (forgotten who, my apologies), “Strategy is about answering two questions. 1) Where to compete? 2) How you are going to win?” Knowing how you are going to win is about knowing what you are going to do better. That is the combination of activities and competence (not all competence is people, it might be having a more dynamic supply chain with a superior footprint or a unique technology,…but a great deal of it is, and it is human competence is always needed  to support any physical/technological one in any event)

• A major transformation, e.g. post-merger; change in legislation, process and IT within a Govt department. Questions are, how many are required in the “New World” state, where and doing what? (This is where the link to OD is so strong. Watch out for my upcoming blog on the differences between the two). I had one government client that was introducing a totally new way of working (new rules, IT, goals.…everything). The change was so big that all front line staff needed weeks of training (was it 2,3, or 4 weeks? One of the many drivers). There was the migration of data. System exceptions resulting in more work (one exception resulted in 360,000 man-days of effort over 5-years alone, or 340 extra staff alone. This was totally off plan). The fundamental question as to how efficient the new vs old world would be and therefore how many people were needed each month for the next 5-years. There was a bulge required. Moving from 12,000 people to well over 16,000 and then down to 8,700. This wasn’t feasible. So the workforce planning drivers, and the quantification of the impact of those drivers ended up determining a great deal of the actual departmental strategy.

 Operational planning & management:

Think budgeting. Think detailed operational business plans and the workforce part of that. Think through core assumptions such as attrition, training to plug skills gaps, which recruitment channels

Examples of Operational workforce planning

• Moving case workload from one business unit to another
• Setting the goals for recruitment and headcount for the year

Tactical management

This is the reactive. This is the day-to-day. It is reacting to unforeseen changes. A key member of staff leaves. Attrition suddenly jumps. Candidates dry up.

We call it “Tactical management”, because it is the execution of both the strategic and operational plans. It is knowing which recruitment channels are working well and which aren’t. It is being able to better predict attrition from sources such as Fast Feedback surveys.

Tactical workforce management gets the least amount of air time but takes the most real time and what we do in reality is what counts at the end of the day.

Almost no question is asked more than what the ideal Span of Control (SoC) should be. There are those that believe the answer is pretty simple, 8. You should have no more than 8 layers and no fewer than 8 direct reports. This is easy to understand and I’m sure there are situations where 8 is the ideal.

Our view is it all depends. It depends on a large number of factors and dogma is incredibly dangerous. Believing there is a simple answer is a classic example of a rightsizing magic number that I referred to in my rightsizing blog.

So, if it all depends, are we just stuck? Or is there a minimum and maximum? The answer is no, no and probably yes (but we can’t say with certainty what that exact maximum is. By the way, the minimum is a bit of a cop out, it is “1”).

Delayering

By increasing the span of control, you reduce the number of managers and layers in the organisation. This gives, all things remaining equal, significant cost savings and improves communication from the top.

In our standard OrgVue demo data set, we have an organisation with 1,505 people and 229 managers, or an average SoC of 6.6. The person at the top of the organisation (depth 1/the CEO) has 6 direct reports. The CEOs reports (depth 2) have an average span of control of 4 while their reports 5.76 and so on, as depicted in the below graph.

The actual layout can be seen in more detail in the “Icicle Layout”. Each direct report is pictured below the boss. (For fun, I have coloured this by age. From Green to Grey).

Each of the 7 layers can clearly been seen and it is immediately obvious that being at level 7 is quite an outlier and some functions only go to depth 3.

The below graph shows this same data, but a histogram of the average depth by department (with the distribution of the age in colour still there).

Understanding this pyramid is useful when thinking through possible delayering savings. It identifies gaps and possible inefficiencies. The simplistic logic of having an average SoC of 8 would decrease the number of managers by 41 to 188. This would mean you only need 5 layers (max depth of 5). This theoretically perfect pyramid would look like the below Excel table.

So, in theory, if you would give us a file with Employee ID, Manager ID (& Employee cost) we would, within seconds, be able to tell you the saving in terms of managers (& likely cost saving/savings range). But reality doesn’t fit such a simple theoretical model. This doesn’t mean such a simple exercise is a waste of time, more that it is useful for highlighting areas to focus in on and a way to raises questions, not answer all those questions.

A framework for thinking through an ideal Span of Control (SoC)

Like most problems, it is useful to break it down into various parts. There is the nature of the subordinates, the boss and the overall context of the organisation. Each of these have various drivers. Understanding these drivers should help to answer what the SoC ought to be.

Nature of the subordinates:

• Level of self direction of work and amount of supervision required:
  • Capability of workers:  If workers are highly capable they will need relatively less supervision
  • Motivation, judgement & maturity, autonomy of workers: Are they self-starters? Are they prepared and allowed to make mistakes? Do they know when to escalate and is real trust given? If the answer is yes, then less supervision is required
• Degree of similarity of task. The more similar the tasks are, the easier it is to manage more

Nature of the boss:

• Trust and relationship: The greater the trust, the better the relationships then the easier it is to supervise more
• Capability of boss: Does the boss have a good understanding and knowledge of the required work. Think of those new to managing or those who are more junior. Management is a competency like many others and it takes time to develop it
• How much “Task activity” vs. “Management activity”
  • Level of content and technical work required from the Manager. If the role has technical deliverables and is required to produce output, not “just manage”
  • Volume of other tasks, such as membership of committees, involvement in other projects, liaising with stakeholders, the number of direct reports will need to be smaller
  • Amount of administrative tasks such as: regular face to face meetings, appraisal and development plans, discuss remuneration plans, explain employment policy changes, recruitment,… then the span of control is reduced

 Context of the Organisation:

• Level of geographical dispersion: the more widely dispersed a business is, the harder it is to supervise resulting in a smaller SoC.
• How much training and development needs to come from the boss? Is it an apprenticeship model or a direction only model?
• Need for cost savings and perspective on the maximum number of layers
• Culture: How autocratic vs democratic? (more autocratic the greater the SoC);
• Amount of change (great the change the greater SoC)

It would clearly be possible to define each group of subordinates and bosses into dimensions based on these drivers. From this it is a relatively easy step to deduct which areas should have a higher or lower SoC. High could mean 12 or even 15. Low could mean 5 or even 3 -> with how extreme being determined in part by the organisational context. From this, a gap analysis can be performed and deeper/more meaningful questions asked. Equally, if it is a priority to reduce cost, delayer and increase the average span of control, then why not focus more on the underlying drivers. It is “leveraging the drivers” that will enable an improvement in the SoC ratio. By doing something to improve the drivers (e.g. reduce the amount of admin takes; improve trust or knowledge of managers…) then any possible theoretical saving might just become a reality.