Monte Carlo Simulation of Projects – an (even simpler) explainer

In this article I’ll explain how Monte Carlo simulation works using an example of a project that consists of two tasks that must be carried out sequentially as shown in the figure:

Task 1 takes 3 to 7 days

Task 2 takes 2 to 5 days

The two tasks do not have any dependencies other than that they need to be completed in sequence.

(Note: in case you’re wondering about “even simpler” bit in the title – the current piece is, I think, even easier to follow than this one I wrote up some years ago).

Assume the project has been carried a number of times in the past – say 20 times – and we have the data shown below for the two tasks. For each task, we have the frequency of completion by day. So, Task 1 was completed twice on day 3 , four times on day 4 and so on. Similarly, Task 2 was completed twice on the 2^nd day after the task started and 10 times the 3^rd day after the task started and so on.

Consider Task 1. Since it was completed 2 times on day 3 and 4 times on day 4, it is reasonable to assume that it twice as likely that it will finish on day 4 than on day 3. In other words, the number of times a task is completed on a particular day is proportional to the probability of finishing on that day.  

One can therefore approximate the probability of finishing on a particular day by dividing the number of completions on that day by the total number of times the task was performed. So, for example, the probability of finishing task 1 on day 3 is 2/20 or 0.1 and the probability of finishing it on day 4 is 0.2.

It is straightforward to calculate the probability for each of the completion days. The tables displayed below show the calculated probabilities. The tables also show the cumulative probability – this is sum of all probabilities of completion prior to (and including) current completion day. This gives the probability of finishing by the particular day – that is, on that day or any day before it.  This, rather than the probability, is typically what you want to know.

The cumulative probability has two useful properties

1. It is an increasing function (that is, it increases as the completion day increases)
2. It lies between 0 and 1

What this means is that if we pick any number between 0 and 1, we will be able to find the “completion day” corresponding to that number. Let’s try this for task one:

Say we pick 0.35. Since 0.35 lies between 0.3 and 0.75, it corresponds to a completion between day 4 and day 5. That is, the task will be completed by day 5. Indeed, any number picked between 0.3 and 0.75 will correspond to a completion by day 5.

Say we pick 0.79. Since 0.79 lies between 0.75 and 0.95, it corresponds to a completion between day 5 and day 6. That is, the task will be completed by day 6.

….and so on.  It is easy to see that any random number between 0 and 1 corresponds to a specific completion day depending on which cumulative probability interval it lies in.

Let’s pick a thousand random numbers between 0 and 1 and find the corresponding completion days for each.  It should be clear from what I have said so far that these correspond to 1000 simulations of task 1, consistent with the historical data that we have on the task.

We will do the simulations in Excel. You may want to download the workbook that accompanies this post and follow along.

Enter the completion days and the cumulative probabilities corresponding to them in rows 1 through 8 of columns A and B  as shown below.

Then enter the Excel RAND() function in cell A10 as shown in the figure below. This generates a random number between 0 and 1 (note that the random number you generate will be different from mine).

Next, fill down to cell A1009 to generate 1000 random numbers between 0 and 1 – see figure below ( again your random numbers will be different from mine)

Now in cell B10, input the formula shown below:

This nested IF() function checks which cumulative probability interval the random number lies in and returns the corresponding completion day. This is the completed by day corresponding to the inputted probability.

Fill this down to cell B1009. Your first few rows will look something like shown in the figure below:

You have now simulated Task 1 thousand times.

Next, enter the data for task 2 in columns D and E (from rows 1 through 7) and follow a similar procedure to simulate Task 2 thousand times. When you’re done, you will have something like what’s shown below (again, your random numbers and hence your completed by days will differ from mine):

Each line from row 10 to 1009 corresponds to a simulation of the project. So, this is equivalent to running the project 1000 times.

We can get completion times for each simulation by summing columns B and E, which will give us 1000 project completion times. Let’s do this in column G.

Using the MIN() and MAX() functions over the range G10:G1009, we see  that the earliest and latest days for project completion are day 5 and day 12 respectively.

Using the simulation results, we can now get approximate cumulative probabilities for each of the possible completion days (i.e days 5 through 12).

Pause for a minute and have a think about how you would do this.

–x–

OK, so here’s how you would do it for day 5

Count the number of 5s in the range G10:G1009 using the COUNTIF() function.   To estimate the probability of completion on day 5, divide this number by the total number of simulations.  

To get the cumulative probability you would need to add in the probabilities for all prior completion days.  However, since day 5 is the earliest possible completion day, there is no prior day.

Let’s do day 6

Count the number of 6s in the range G10:G1009 using the COUNTIF() function.   To estimate the probability of completion on day 6, divide this number by the total number of simulations.  

To get the cumulative probability you would need to add the estimated  probability of completion for day 5 to the estimated  probability of completion for day 6.

…and so on.

The resulting table, show below, is excerpted from  columns J and K of the Excel workbook linked to above. Your numbers will differ (but hopefully by not too much) from the ones shown in the table.

Now that we have done all this work, we can make statements like:

1. It is highly unlikely that we will finish before day 7.
2. There’s an 80% chance that we will finish by day 9.
3. There’s a 95% chance we’ll finish by day 10.

…and so on.

And that’s how Monte Carlo simulations work in the context of project estimation

Before we close, a word or two about data. The method we have used here assumes that you have detailed historical completion data for the tasks. However, you probably know from experience that it is rarely the case that you have this.

What do you do then?

Well, one can develop probability distributions based on subjective probabilities. Here’s how: ask the task performer for a best guess earliest, most likely and latest completion time. Based on these, one can construct triangular probability distributions that can be used in simulations. It would take me far too long to explain the procedure here so I’ll point you to an article instead.

A gentle introduction to Monte Carlo simulation for project managers

And that’s it for this explainer. I hope it has given you a sense for how Monte Carlo simulations work.

Conversations and commitments: an encounter with emergent design

Many years ago, I was tasked with setting up an Asia-based IT development hub for a large multinational.   I knew nothing about setting up a new organisation from scratch. It therefore seemed prudent to take the conventional route – i.e., engage experts to help.

I had conversations with several well-known consulting firms. They exuded an aura of confidence-inspiring competence and presented detailed plans about how they would go about it. Moreover, they quoted costs that sounded very reasonable.  

It was very tempting to outsource the problem.

–x–

Expert-centric approaches to building new technical capabilities are liable to fail because such initiatives often display characteristics of wicked problems,  problems that are so complex and multifaceted that they are difficult to formulate clearly, let alone solve. This is because different stakeholder groups have different perspectives on what needs to be done and how it should be done.

The most important feature of such initiatives is that they cannot be tackled using rational methods of planning, design and implementation that are taught in schools, propagated in books, and evangelized by standards authorities and snake oil salespeople big consulting firms.

This points to a broader truth that technical initiatives are never purely technical; they invariably have a social dimension. It is therefore more appropriate to refer to them as sociotechnical problems.

–x–

One day, not long after my conversations with the consulting firms, I came across an article on Oliver Williamson’s Nobel prize winning work on transaction costs. The arguments presented therein drew my attention to the hidden costs of outsourcing.

The consultants I’d spoken with had included only upfront costs, neglecting the costs of coordination, communication, and rework. The outsourcing option would be cost effective only if the scale was large enough. The catch was that setting up a large development centre from scratch would be risky, both politically and financially. There was too much that could go wrong.

–x–

Building a new sociotechnical capability is a process of organisational learning. But learning itself is a process of trial and error, which is why planned approaches to building such capabilities tend to fail. 

All such initiatives are riddled with internal tensions that must be resolved before any progress can be made. To resolve these tensions successfully one needs to use an approach that respects the existing state of the organisation and introduces changes in an evolutionary manner that enables learning while involving those who will be affected by the change.  Following David Cavallo, who used such an approach in creating innovative educational interventions in Thailand, I call this process emergent design.

–x–

The mistake in my thinking was related to the fallacy of misplaced concreteness. I had been thinking about the development hub as a well-defined entity rather than an idea that needed to fleshed out through a process of trial and error. This process would take time; it had to unfold in small steps, through many interactions and conversations.

It became clear to me that it would be safest to start quietly, without drawing much attention to what I was doing. That would enable me to test assumptions, gauge the organisation’s appetite for the change and, most importantly, learn by trial and error.

I felt an opportunity would present itself sooner than later.

–x–

In their book, Disclosing New Worlds, which I have discussed at length in this post, Spinosa et. al. note that:

“[organisational] work [is] a matter of coordinating human activity – opening up conversations about one thing or another to produce a binding promise to perform an act … Work never appears in isolation but always in a context created by conversation.”

John Shotter and Ann Cunliffe flesh out the importance of conversations via their notion of managers as authors [of organisational reality].  Literally, managers create (or author) realities through conversations that help people make sense of ambiguous situations and / or open up new possibilities.

Indeed, conversations are the lifeblood of organisations. It is through conversations that the myriad interactions in organisational life are transformed into commitments and thence into actions.

–x–

A few weeks later, a work colleague located in Europe called to catch up. We knew each other well from a project we had worked on a few years earlier. During the conversation, he complained about how hard it was to find database skills at a reasonable cost.

My antennae went up. I asked him what he considered to be a “reasonable cost.” The number he quoted was considerably more than one would pay for those skills at my location.  

“I think I can help you,” I said, “I can find you a developer for at most two thirds that cost here. Would you like to try that out for six months and see how it works?” 

“That’s very tempting,” he replied after a pause, “but it won’t work. What about equipment, workspace etc.? More important, what about approvals.” 

“I’ll sort out the workspace and equipment,” I replied, “and I’ll charge it back to your cost centre. As for the approval, let’s just keep this to ourselves for now. I’ll take the rap if there’s trouble later.” 

He laughed over the line. “I don’t think anyone will complain if this works. Let’s do it!” 

–x–

As Shotter and Cunliffe put it, management is about acting in relationally responsive ways. Seen in that light, conversations are more than just talk; they are about creating shared realities that lead to action.

How can one behave in a relationally responsive way? As in all situations involving human beings, there are no formulas, but there are some guiding principles that I have found useful in my own work as a manager and consultant:

Be a midwife rather than an expert:  The first guideline is to realize that no one is an expert – not you nor your Big $$$ consultant. True expertise comes from collaborative action.  The role of the midwife is to create and foster the conditions for collaborative action to occur.  

Act first, seek permission later (but exercise common sense): Many organisations have a long list of dos and don’ts. A useful guideline to keep in mind is that it is usually OK to launch exploratory actions as long as they are done in good faith, the benefits are demonstrable and, most importantly, the actions do not violate ethical principles. The dictum that it is easier to beg forgiveness than seek permission has a good deal of truth to it. However, you will need to think about the downsides of acting without permission in the context of your organisation, its tolerance for risk and the relationships you have with management.

Do not penalize people for learning:  when setting up new capabilities, it is inevitable that things will go wrong.  If you’re at the coalface, you will need to think about how you will deal with the fallout. A useful approach is to offer to take the rap if things go wrong. On the other hand, if you’re a senior manager overseeing an initiative that has failed, look for learnings, not scapegoats.

Distinguish between wicked and tame elements of your initiative: some aspects of sociotechnical problems are wicked, others are straightforward (or tame). For example, in the case of the development centre, the wicked element was how to get started in a way that demonstrated value both to management and staff. The tame elements were the administrative issues: equipment, salary recharging etc (though, as it turned out, some of these had longer term wicked elements – a story to be told later perhaps).

Actively seek other points of view: Initially, I thought of the development centre in terms of a large monolithic affair. After talking to consultants and doing my own research, I realised there was another way.

Understand the need for different types of thinking: related to the above, it is helpful to surround yourself with people who think differently from you.

Consider long term consequences:  Although it is important to act (the second point made above), it is also important to think through the consequences of one’s actions, the possible scenarios that might result and how one will deal with them.

Act so as to increase your future choices: This principle is from my intellectual hero, Heinz von Foerster, who called it the ethical imperative (see the last line of this paper). Given that one is acting in a situation that is inherently uncertain (certainly the case when one is setting up a new sociotechnical capability), one should be careful to ensure that one’s actions do not inadvertently constrain future choices.

–x–

With some trepidation, we decided to go ahead with the first hire.

A few months later, my colleague was more than happy with how things were going and started telling others about it. Word got around the organisation; one developer became three, then five, then more. Soon I was receiving more enquiries and requests than our small makeshift arrangement could handle. We had to rent dedicated office space, fit it out etc, but that was no longer a problem because management saw that it made good business sense.

–x–

This was my first encounter with emergent design. There have been many others since – some successful, others less so.   However, the approach has never failed me outright because a) the cost of failure is small and b) learnings gained from failures inform future attempts.

Although there are no set formulas for emergent design, there are principles.  My aim in this piece was to describe a few that I have found useful across different domains and contexts. The key takeaway is that emergent design increases one’s chances of success because it eschews expert-driven approaches in favour of practices tailored to the culture of the organisation.

 As David Cavallo noted, “rather than having the one best way there can now be many possible ways. Rather than adapting one’s culture to the approach, one can adapt the approach to one’s culture.”

–x–x–

To think, to be, to act

It would have been sometime in late 2013. I was in the midst of exploring the possibility of setting up an analytics development centre for a large, somewhat conservative organization. The location of the centre had yet to be determined, but it was clear it would be a continent and a world away from headquarters.

A senior IT executive from headquarters was visiting our subsidiary. I knew him quite well and we had a good working relationship. He frowned as he caught sight of me across our big open plan area and gestured that he wanted to talk.

Uh oh.

I nodded and walked over to a vacant meeting room on my side.  He followed shortly and closed the door behind him.

Brief pleasantries done, he got to the point. “What’s this I hear about a development centre? What the hell are you up to?”

–x–

Despite out best-laid plans, the lives of our projects and the projects of our lives tend to hinge on minor events that we have little control over. Robert Chia stresses this point in his book Strategy without Design:

“Ambitious strategic plans, the ‘big picture’ approach that seeks a lasting solution or competitive advantage through large-scale transformations, often end up undermining their own potential effectiveness because they overlook the fine details of everyday happenings at ‘ground zero’ level.“

At one level we know this, yet we act out a large part of our personal and work lives as though this were not so.

–x–

In business (and life!) we are exhorted to think before doing. My boss tells me I need to think about my team’s workplan for next year; my wife tells me I need to think about the future. Thinking is at the center of our strategies, blueprints, plans – the things that supposedly propel our lives into an imagined future.  

In brief, we are exhorted to make detailed plans of what we are going to do; we are encouraged not to act without thinking.

As Descartes famously wrote, cogito ergo sum, our thinking establishes our being.

But is that really so?

–x–

Gregory Bateson noted the following in his book, Angels Fear:

“There is a discrepancy of logical type between “think” and “be”. Descartes is trying to jump from the frying pan of thought, ideas, images, opinions, arguments etc., into the fire of existence and action. But that jump itself is unmapped. Between two such contrasting universes there can be no “ergo” – no totally self-evident link. There is no looking before leaping from “cogito” to “sum”.“

The gap between our plans and reality is analogous to the gap between thought and action. There is ample advice on how to think but very little on how to act in difficult situations.

As Bateson wrote elsewhere:

“What is lacking is a theory of action within large complex systems, where the active agent is himself a part and a product of the system.“

He then goes on to say that Kant’s categorical imperative – “act so to treat humanity, whether in your own person or in another, always as an end and never as only a means – might provide a starting point for such a theory.”

So far, so unsurprising.

But in the very next line, Bateson says something truly intriguing:

“It seems also that great teachers and therapists avoid all direct attempts to influence the action of others and, instead, try to provide the settings or contexts in which some (usually imperfectly specified) change may occur.“

This line resonated deeply when I read it first because it spelt out something that I had learnt through experience but had not found the words to articulate.

–x–

In contentious discussions, it is difficult to change minds using facts and figures alone. Indeed, the current reluctance to be vaccinated against Covid is a case in point (see this article, for example).What one needs in such situations is to reframe the terms of the discussion. In the Covid case that might be to focus on relative risks in terms that people can understand rather than absolute numbers of people who have suffered serious side-effects of the vaccine.

In general, reframing is about changing the way in which people perceive the problematic issue.  The best way to describe how it works is via an example. Here’s one from Paul Watzlawick’s classic book on change: 

A police officer with a special ability for resolving sticky situations in unusual ways, often involving a disarming use of humour, was in the process of issuing a citation for a minor traffic violation when a hostile crowd began to gather around him. By the time he had given the offender his ticket, the mood of the crowd was ugly and the sergeant was not certain that he would be able to get back to the relative safety of his patrol car. It then occurred to him to announce in a loud voice: “You have just witnessed the issuance of a traffic ticket by a member of your Oakland Police Department” And while the bystanders were busy trying to fathom the deeper meaning of this all too obvious communique, he got into his cruiser and drove off.

The specifics of what one might do depends on the situation, but the general idea is to appreciate the situation from the viewpoint of the other party and act in a way that helps shift that perspective in an indirect or oblique manner.

This is one of the key principles of emergent design – and more about that in a forthcoming piece.

–x–

Back to the story I started with:

I realized instinctively that much hinged on what I said and – more importantly – how I said. My interlocutor was clearly upset, and I had to ensure that my words did not infuriate him further. He had the power to stop my fledgling project in its tracks with a word or two in the right ears.

“There is no plan to set up a development centre,” I said, looking him in the eye. “All we have done is hire a couple of people here to help with the workload at headquarters.”

“Who has requested help?”

I told him who. He knew that person well and thought highly of him.

“Where do you plan to go from here?” he demanded.

“Like I said, there is no plan. This is just a pilot to see if we can help improve productivity. The idea is to free people in headquarters so that they can focus on the strategic stuff.”

“Just make sure it doesn’t turn into something bigger.”

“Absolutely,” I responded, mustering what I hoped was a reassuring smile.

“OK,” he nodded and walked out. 

I breathed easier; he seemed to be OK with it for now. But even if not, the conversation was still open. More importantly, I had bought myself some time to pay greater attention to the politics of the project over the coming weeks.

–x–

It was only in retrospect that I realized that the interaction described here was pivotal to the success of the project. How so is a story to be told later. For now, the point I wish to make is that the projects of our lives can be planned down to great detail, but their outcomes are often determined by the unplanned micro-actions we take while doing them.

–x–x–

(no identity – courtesy HaPe Gera https://www.flickr.com/photos/hape_gera/2929195528)