Make Your Professional Service Firm Grow (Part IV)

A simulation model to analyze growth scenarios in professional service firms

Oliver Grasl
Tuesday, July 26, 2016

A step-by-step tutorial on how to build a simulation model to analyze growth scenarios in such firms

A Simulation Model to Analyse Growth Scenarios in Professional Service Firms

In my Make Your Professional Service Firm Grow (Part III) in the Make Your PSF Growseries, I analyzed different gaming strategies for the Make Your Professional Service Firm Grow Game – in this post I will show you how to build a System Dynamics model that you can use for such an analysis, in seven easy steps.

I like to build simulation models in small steps, testing intermediate stages as I go along. That makes it much easier to find mistakes (which will inevitably happen) as I go along.

I am going to build the model using System Dynamics and the Business Prototyping Toolkit

To make it easier for you to follow along I have created a separate model for each step, you find them in our GitHub repository.

To make it easier for you to follow along, I have numbered the list of assumptions underlying the game:

Project Volume. The average project volume is 16 person-months.
Project Duration. The average project duration is 2 months, i.e. 8 project delivery staff are involved for 2 months.
Prospecting Effort. The prospecting effort to generate a lead and write a proposal is 4 months.
Project Acquisition Duration. The project acquisition duration is 6 months, i.e. it takes 6 months between generating the initial lead before a newly acquired project starts.
Market Conditions. Market conditions are perfect, i.e. both the prospecting and acquisition success rates are at 100%.
Delivery Fee. The project delivery fee is EUR 17,600 per person-month, i.e. the daily rate per consultant is EUR 880.
Billing Interval. Projects are charged on a monthly basis.
Collection Duration. The collection duration is 2 months, i.e. it takes 2 months after revenue is collected and arrives in the bank.
Workplace Cost. The workplace cost per staff member is EUR 1000 per month (rent, laptop, software licenses and services…).
Overhead Cost. The company has an overhead cost of EUR 306.000 per month (administrative cost…).
Staff Salary. The average salary per staff member is EUR 80,000 per year.
Hiring Duration. The hiring duration for new staff is 3 months.
Initial Cash. The initial cash is at EUR 1,000,000.
Initial Staff. The company initially has 200 professional staff members, 20% of which are assigned to business development. In this setting, the company is stable.
Initial Backlog. The initial backlog of project weeks is 320 person-months, and the initial number of prospective projects/proposals in the sales pipeline is also 320 person-months.

And here is the game itself, in case you have not had a chance to play it yet – the objective is to reach the cash targets by hiring the right number of staff and deciding how many of them to assign to business development:

How did you perform?

Did you manage to solve the puzzle?

By trial and error, or did you have a clear strategy?

Let us build a model that captures all the game assumptions, which we can then use to analyse the game systematically.

It is easiest to start with cash and cash flow because these are clearly defined concepts that leave little open to discussion. They are also straightforward to model in System Dynamics.

By definition, cash flow is simply the difference between the cash that flows into the company (e.g. when customers pay the bills and we collect the revenue) and that which leaves the company (e.g. for wages and workplace cost).

The stock and flow diagram is shown below captures this nicely.

Now let us quantify the model. Given assumption #14 we know that 160 professional staff are assigned to project delivery, and given assumption #6 we know they turn over EUR 17.6k per month each. Assumption #7 tells us that we bill project work on a monthly basis.

The cost is the monthly salary (80k/12) plus EUR1k workplace cost and the overhead cost of EUR 306k (assumptions #9, #10, #11). Thanks to assumption #13, we also know the initial cash level is at EUR 1000k.

So we can define the following values:

Note that I clearly separated the cash in and cash outflows from the cost and collecting revenue converters instead of adding the numbers directly into the flow (e.g. by setting cashIn=collectingRevenue instead of cashIn=collectingRevenue=160*17,600).

The reason I did this is that I like to keep my simulation logic out of the flows as far as possible – this makes the model visually more explicit and also makes it easier to refactor the model (e.g. moving logic around between diagrams).

We ought to check that the model works as expected: the cash flow should be constant and equal to cashFlow=160*17.6-200*(80/12+1)-306=976.67. This also means that after 24 months we should have cash=1000+24*922.67=24440.08.

I have plotted and tabulated the values below, as you can see the numbers are as expected.

Another good model-building practice is to explicitly model the constants: there should be no “magic” values that are not explicitly named, because these are difficult to interpret for anyone reading the model (including yourself should you come back to the model at some future time).

So instead of setting

we should explicitly define a stock or converter for each number. That makes the model much more readable, makes each equation simpler to read, understand and correct.

This leads to the new diagram below.

I have modeled the professional service staff as stock (and not as a converter) for two reasons:

We know that the number of staff will change over time
We cannot instantaneously calculate the number of staff the firm has in a given month from other elements in the model – the only way we can know how much staff the firm has is by knowing the initial number (200 in this case) and then adding the number of staff that has arrived since (we will model the hiring process in Step 7). In System Dynamics, variables that behave this way are modeled using stocks.

Because we have only reorganized the model without adding any new logic, we expect nothing to have changed. Nevertheless, we should check that this is true.

Now that we have modeled the cost side, we should take a look at the income side. In any company, it is important to distinguish between making revenue and actually collecting it, because the company will have to finance the period in between from its own funds.

In our case, this is particularly important because we are in a growth scenario and the new staff’s wages have to be paid before the revenue they are making actually arrives in the PSF’s bank account.

According to game assumption #8, there is an average collection time of 2 months. Hence we can model the collection process as a stock of receivables – the inflow is determined by the monthly revenue, the outflow is simply the inflow delayed by the collection time.

The revenue is simply the monthly project delivery fee time the delivery rate. Given our assumptions about staff allocation (#8), the delivery rate is initially at 160 project months/month.

Note that we are using a DELAY-function to define collectingRevenue – the DELAY-function ensures that collectingRevenue is always equal to the value makingRevenue had 2 months previously. DELAY-functions are very important in modeling dynamical systems, so I have added a separate chapter below to explore this function in detail.

With this model and these concrete values, we expect the receivables to be constant at collectionTime*revenue, which is 2*17.6*160=5632, and we expect both makingRevenue and collectingRevenue to be constant and equal to revenue, which is 17.6*160=2816.

The table below shows the model is behaving correctly.

Unfortunately, because everything is constant, it is difficult to see whether our model of the receivables is working correctly. So we ought to test our model with some fluctuating revenue, to see whether the revenue collection is delaying properly – note that this is purely a test, the values we used for collecting revenue have nothing to do with game assumptions.

The graph below shows our model is behaving nicely, the shape of collectingRevenue is identical to that of makingRevenue, except that the entire graph is shifted by two months (i.e. by the collection time).

To illustrate this better, here is another scenario with the collecting time set to 1 month instead of two, but the same monthly revenue.

And again for a collection time of 5 months.

And this is what happens to the receivables in these two scenarios.

Before we go on to step four, we should take a closer look at the delay function – it is used very frequently in System Dynamics and it is important that we understand it properly.

When modeling a business, we frequently encounter situations where we have to model delays. One way of doing this is using the DELAY function.

The delay function DELAY(f,p,i) simply delays f by p periods if the current timestep t is greater than p, or else it outputs the initial value i:

DELAY(f,p,i)(t) = f(t-p) when t>=p

= i when t<p

To illustrate how the delay function works, I have included a little example below that shows the effect the delay function has on a simple stock where the inflow is any function and the outflow is simply the inflow delayed by the delay time.

The plot below shows what happens when the outflow equals the inflow delayed by 6-time steps – the graph of the inflow is simply shifted to the right by 6 timesteps.

Note that we have set the initial value to be equal to 0 here – we need the initial value because the delay function “looks back in time” (by six timesteps in this case) and the inflow has undefined values for negative timesteps (because the simulation does not start until time step 0).

The graphs below show what happens to the outflow at various delay times.

In the following graphs, we are keeping the delay time constant, but are playing with different initial values.

In Step 3 we defined revenue as the product of the project delivery fee and the project delivery rate, both were constant in that model. Given game assumption #6 we know that the delivery fee is constant, but clearly, the project delivery rate will depend on how many projects the PSF has acquired and also on how much staff the PSF can assign to project delivery – if no (new) projects are acquired, then the delivery rate will (eventually) be 0 regardless of how much staff the PSF assigns to projects.

On the other hand, if no staff is assigned to project delivery, then the delivery rate will be 0, regardless of the number of projects that have been acquired.

In this step, we model the projects as a stock with an initial value of 320 person-months (two months of project backlog, assumption #15). The outflow is equal to the project delivery rate, which itself is equal to the minimum of projects and the project delivery capacity. For now, we assume this capacity is constant at 160 person-months (i.e. 160 project staff delivery one month worth of project work per month).

The plot below shows how the project backlog decreases steadily for the first two months and then remains at 0 – the reason it cuts of at 0 is that we used the MIN-Funktion to constrain the outflow projectDeliveryRate.

Initially, the delivery capacity is exactly half of the project backlog, so the backlog drops to zero after two months. We can take a closer look at this mechanism if we use different values for the delivery capacity – the graphs below show that as soon as the project backlog drops below the project delivery capacity, the delivery rate is constrained to be equal to the project backlog, before it drops down to zero.

You can see this even better if you take a look at the concrete figures:

In our Step 4 model, we assumed that the project delivery capacity was constant and equal to 160 – while this value is certainly correct at the beginning of the simulation, it will not be constant throughout the game, because the project delivery capacity depends on the number of professional staff we have and on the percentage of staff assigned to project delivery (or business development, whichever way you look at it).

The diagram below shows how we can model this – given the number of professional staff and the average amount of work done per staff member per month (the “work month”), we can easily calculate the work capacity as the product of these two numbers. The business development capacity is then equal to the work capacity multiplied by the percentage of staff allocated to business development, and the project delivery capacity is then simply the difference between work capacity and business development capacity (because the assumption is that professional staff either work in project delivery or business development).

The following equations specify this in detail:

We can test the model by comparing the project delivery capacity, the project delivery rate and the project backlog for different business development allocations:

Slowly we are getting there, our model is almost complete now. We have all the stocks in place, but two of them – Projects and Staff – still have no inflows. Let us take a look at the project acquisition process first.

Taking a look at #3 of our assumptions, we know that it takes 4 months of effort to generate a lead and write a proposal.

We also know that a project we acquire will have a volume of 16 person-months (Assumption #1).

In step 5 we introduced a converter that tracks our business development capacity, so we can calculate the rate at which we generate proposals as:

From Assumption #4 we know that it takes six months to turn a proposal into a project – we model this using a delay function:

Note that all proposals end up being projects, there is no loss – this is because we are assuming that market conditions are perfect (Assumption #5).

How can we test this part of the model?

Well in the steady state, we expect the number of proposals in the pipeline to be equal to the number of projects in the project backlog. The following graphs show that this is so:

Now let us see what happens if we increase the percentage of staff allocated to business development to 40% after 3 months – we expect the number of proposals to go up as soon as we do this. Because we can only increase our business development staff by reducing project delivery staff, we would expect the project backlog to rise straight away. We should be generating more proposals now, but because of the acquisition duration, we would not expect this to affect the project backlog for 6 months – hence there should be a steeper increase in the project backlog starting in month 9.

Below I have provided both the graphs and the concrete values of the proposals and the project backlog in this scenario – as expected, the number of proposals starts rising as soon as we reallocate staff to business development. The project backlog starts to rise straight away because we have reallocated staff from project delivery to business development – in month 10 (i.e. 6 months after reallocating staff) the first projects are acquired and hence the project backlog starts rising even faster – of course, we should have hired some extra project staff by this time to compensate, we can test this in the next step.

But why does the number of proposals peak at 1280 proposals?

I had to think about this myself for a little moment: in month 4, we assign 40% of our staff to business development. They immediately start generating proposals at a rate of 0.4*200*16/4=320 project months per month.

Every month 160 project months leave the proposal backlog and enter the project backlog. The delay is 6 months, so in month 10 we expect to have 160*6=960 extra project months in the pipeline. If we add these to the 320 project months that were already in the stock of proposals, we arrive at 960+320=1280. At month 10, the number of projects-months leaving the stock of proposals rises to 320, which equals the number coming in. So at this time, the level of proposals becomes steady at 1280.

Below is a graph that shows that the project proposal rate changes from 160 to 320, as expected.

The only aspect of our model that is missing now is staff recruitment – recruitment is zero initially, but setting the recruitment to the right level is part of finding the right game strategy.

We model recruitment as a simple stock and flow structure that involves a delay depending on the hiring duration – the stock and flow diagram and corresponding equations are shown below – we know that the hiring duration is 3 months thanks to assumption #12.

We can now continue the scenario we investigated in step 6: in time step 4, we changed the business development allocation to 40%, which led to the project backlog increasing. We also saw that the backlog of proposals leveled out after 10 months, with an outflow of 320 project months per month. To deal with so many projects, we need 320 project delivery staff, next to 80 business development staff.

Because hiring actually takes three months, we need to hire them in timestep 7.

Once they arrive we will need to change the ratio of business development because now we will have 80 business developers and 400 staff total, so the percentage will be back to 20%.

All in all, this leads to a 100 % growth scenario. Let us check to see how our model behaves.

Wonderful, we now have a complete model. We should now perform some sanity checks to see whether it is working correctly. Before we do that, we ought to make sure that we have incorporated all assumptions in the list. When building models we mostly keep an excel sheet containing all requirements and assumptions regarding the model and any issues that arise along the way. That way we can make sure we do not forget anything.

The table below shows which assumption is covered in which model step.

Before we start experimenting with growth strategies, we ought to ensure that the model behaves as expected.

Make Your PSF Grow (Part 2) Blog Post Graph 1 EN

Let us do a few quick calculations to make sure we understand the underlying assumptions … the company has 200 professional staff members, 20% of which are assigned to business development. This means that 160 persons are continuously working on projects. The initial project backlog has 320 months in absolute terms, i.e.the backlog relative to the number of project staff is 2 months into the future.

Let us check the revenue side first. Initially, the PSF is fully booked and working at a rate of 160 person-months per month, so the company is making EUR 160*17600 = 2. 816. 000 per month of revenue from projects.

The cost side is a little more intricate: each staff member costs EUR 100000/12 = 8333 on salaries and an extra EUR 1000 workplace cost, i.e.EUR 9333. At 200 persons in the company, this sums to EUR 414.615 in staff cost. We also have an overhead cost of EUR 306,000 per month, so the total cost is EUR 1.839.333.

Putting all these figures together leads to a cash inflow of EUR 976, 667 per month. I have summarized these figures in the table below:

Note that these are monthly figures – so, if these figures remain stable, then after 2 years, at the beginning of month 24, the company will have cash equal to the initial EUR 1 million plus 23*976, 667 which amounts to EUR 23.463 million.

Fantastic, our model is complete (i.e. it covers all assumptions) and it seems to be behaving as expected. Now you can use it to follow along with the discussion in my Make Your Professional Service Firm Grow (Part III) in Make Your PSF Grow. Make sure you can reproduce the values in each step.

Make Your Professional Service Firm Grow (Part III)Overview Next Post