Get notified of new posts
Upstream Planning @ WFP¶
In this blogue post, I present the work I did while working at the Supply Chain Planning team in the World Food Programme. More precisely, I will focus on the change management aspect of the project we implemented together with my boss Eric Combette. I believe it can bring a bit of light, and potential lessons, on how change is attempted in large organizations, how it sometimes fails and also how it sometimes manages to succeed.
Note
As I often do in this blogue, I will not do a very thorough job in accurately describing the general context. Instead, I will present what I remember + what I think is more relevant to the actual topic of the post. This will probably result in an incomplete, potentially inaccurate picture of my former employer.
About WFP¶
The UN World Food Programme is a humanitarian organization (the largest one in the world, it claims!). It provides food to countries under emergencies. It also does many other things to provide support to countries that need it, e.g., it handles the logistics for medicines, it sends cash transfers, it provides training & support to governments, etc.
Some basic numbers: in 2024, it received USD $ 9.8 billion in donations and distributed around 2.5 million metric tons of food. Mostly grains, pulses, vegetable oil, but also Specialized Nutritious Foods (SNF).
WFP is organized into Country Offices (CO), one per country. And Headquarters (HQ). There used to be Regional Bureaux (RB) in between but I've heard that is no longer the case.
About the Supply Chain division¶
The Supply Chain division is the largest division in WFP. It handles the operations: procuring, shipping, transporting, storing and distributing the food around the world.
It's organized as one can expect, roughly with a unit for each verb mentioned above, plus a few other units that give support to the operations: monitoring and quality, planning, research an development, etc.
I will focus on one of the supporting teams, the planning team, which was the team I joined.
About the Planning team¶
The Planning team is a data savy team of engineers that gives support to different areas of the organization by crunching numbers, creating visualizations and sometimes running smart algorithms.
When I arrived it was organized around the "client team" that was being supported. Some gathered data, provided reports, built dashboards, and gave information to the Supply Chain and Emergency management. Some provided tools, training and support to the Programme team that designed the food interventions for each country. Some built reports, dashboards and data pipelines to help COs manage their operations more efficiently. Others, helped with consulting in methodology and data management to governments.
Finally, there was the "Upstream Planning" sub-team, that did sophisticated ad-hoc analyses on the global supply chain and gave (sometimes unsolicited) advice to the finance team on how best to plan the global procurement and distribution of food.
It is this last sub-team that I joined.
Upstream Planning¶
I was hired with a main task: to drive (i.e., do) the design, implementation and the roll-out of a new decision support system to carry out what is known as "Sales and Operations Planning" (S&OP) for the "Upstream Planning" of WFP operations.
Let's define a few things, in my own words:
Sales and Operations Planning is the process of linking the demand plan (a forecast of what we need to supply) with the production and financial constraints in order to produce a realistic, efficient and collaborative plan that meets the needs of each department in a reasonable way. It's usually a monthly process that ends with a plan or changes to an existing plan. In the case of WFP there is no production.
Upstream Planning refers to all the decisions and processes (procurement, shipping, storage, road transport) that bring the food inside each country that will consume it. This is usually carried out at HQ. As opposed to "Downstream Planning", which refers to what happens inside that country and is typically done by each CO.
Upstream Planning is inherently global because of, among other things:
- Lead times are usually quite long (6 months is normal). On top of it: food can sometimes be bought (and stored) in advance in order to obtain a better price (e.g., during the harvest season).
- Demand is quite volatile, because emergencies can happen unexpectedly and because the availability of funding to supply each emergency/ operation is very hard to predict.
- The transport network is unstable. It is not easy to "move back" food once it enters the destination country, some transport corridors (and country borders) can open and close unexpectedly. Imported food is stored at the entry port and these ports are often shared among several countries (especially in West and East Africa).
- Finance constraints. There is a limit on how much food can be bought without knowing the exact funds that will be used to cover it. This is also called the "envelope" and can be understood as limit on "unsold" inventory.
Planning such a high-level, global problem had many challenges, and the computation problem was not one of them. I present the three main types of challenges below.
Challenges and previous attempts¶
A key point in this project is that the S&OP process did not exist formally. So a big part of the initial task was to bring the different teams together and convince them to become part of a new methodology, ideally powered by some decision support system that allow such collaboration (which did not exist either). Many of the teams involved required a fair amount of convincing.
Another challenge was the technological flexibility. Previous to my arrival, this exercise had been tried twice already: (1) with a standard commercial Supply-Chain Optimization software and later (2) with Excel. Partly because of the nature of the operations, and partly because of the immaturity of the S&OP process, the requirements for Upstream Planning were special, complex and frequently changing. This made it hard to fit and adapt an off-the-shelf product or an Excel spreadsheet.
Finally, one challenge was data availability and credibility. There had been huge achievements in data standardization over the years in the organization. But it was still hard to find reliable data from the historical operations, and it often required manually fixing or adding more data each time a study was run. This validation, parametrization and fixing was time consuming and hard to automate.
In what's left of this blog post, I will mostly cover the first of the three: how to change the methodology, motivate management and convince people to change their way of working. In a later post I may touch on the more technological side, including the choice of tools and the flexibility they provided, and the way the data was collected, cleaned and used for each study.
How to set up a (new) methodology¶
Looking back to decipher how/ why something worked is not an easy task: sometimes it's hard to pinpoint the actual cause, other times it is easy to ignore all the failed attempts that were needed to get to what worked. In this case, and if I had to summarize what we did and what worked I'd say: we try "everything", and probably each thing contributed in one way or another.
When I first arrived, I spent a while learning the business and reading all the previous work on this topic inside the team, which was already significant. I remember starting to draw diagrams on how a monthly upstream planning process should look like, together with my boss. I have many years in consulting and I believe it is always better to summarize and communicate things graphically, even if I am not good drawing (neither in paper or on a PC).
In any case, it is the easiest part to draw diagrams with team names, processes, roles and tasks. "In paper", anything is possible:
Proposed S&OP diagram with teams involved, approximate dates, tasks and deliverables. S&D: Supply and Demand. PR: Purchase Requisition. PO: Purchase Order.
The hard part is always to change the people inside the teams and behind the processes. Our first attempt was top down: we made pretty PowerPoint presentations, we presented them to the bosses, we wrote documents and sent them via email. We organized a workshop that never took place. We waited for wasted 6 months.
In the meantime, I started building the tool and trying to use it to provide insight to the other teams planning. Because, another relevant point: our team had no real voice in the current planning process. And our attempts at "checking"/ validating the work of other teams was not well received, as one may expect. I would imagine them thinking "here come the nerds who think they know best to tell us how to do something we've been doing for years".
The second attempt was bottom up: I started having coffees with the teams behind the processes, sometimes bringing home-made cookies and cake. Also, in a slight change of strategy: we started offering our technical help on analysis these teams requested, even if we thought the analysis could be done differently. This worked partially and helped buy some credibility (and good faith).
Little by little, we continue working and improving the tool and its data pipeline. And also we invested a lot of time validating the results we got by comparing it with existing studies to check for inconsistencies, fixes and improvements. Despite my efforts, the first studies of the tool were useless, mostly because of using errors in data or choosing the wrong data for the study.
At some point we had done a couple of actual useful studies. And we got some opportunities to push for visibility: we managed to sign up to an internal innovation competition. And we pitched the idea to UN and government officials in Munich during the Munich Security Conference. This got us (1) funding to grow the team and (2) a bit more credibility with upper management.
More or less at the same time, we decided to take the lead and go all-in in a high-visibility strategic study. By "all-in" I mean that we over-engineered the study into a very rigorous exercise on risk management, security stocks and the price to pay to avoid different kinds of risks. The study was, after a few initial hiccups, very well received and it gave us (me) an excuse to meet and later have coffees with people higher up, too.
Little by little, we took advantage of several emergencies (unfortunately a common thing in the humanitarian world) to use our now-very-operational tool to provide in-point, fast, extremely accurate and very well-informed answers. This was helped because we started measuring, under pressure from our sponsors, the impact of the studies in financial savings. With just a couple of emergencies + a regional plan, we had a couple million dollars in savings and much more food served on time. And these kind of benefits are hard to ignore.
A few of the initial studies we ran with the planning tool we built.
I remember one of the Supply Chain bosses proudly showing me an extensive interactive report he had received from someone else via email on some local procurement opportunity analysis with maps, charts and tables. The report was in fact mine, and apparently it had circulated virally via email without too much attribution.
Finally, a lucky (well deserved?) change in management in the Planning team made life a lot easier. Here the top-down gear went into full action and the management support gave us a larger clout: we organized planning workshops and started getting requests for support and collaboration from other teams and regions. The team got more funding and continued growing and becoming more professional.
The process I left in place when I decided to leave never reached the ugly but stable diagram we had planned and that I showed above. It was a mix of many recurrent but useful studies: a tactical global plan for some specialized products (SNF), a couple tactical plans for some regions, a global strategic study, etc. Each process/ study/ plan was successfully implemented because the teams involved were convinced the tools and the methodology was useful and because they knew management not only approved, but encouraged it. But they were still nascent processes: being new and in flux, they still required a heavy involvement of the Upstream Planning team to sustain them.
Final thoughts¶
I wonder if these processes ever go the way they're "supposed to" or "designed". I've never been a fan of "complete restructuring" or "re-engineering" of processes that often come imposed by higher management or (worse) external consultants. In my experience these usually end in failure and oblivion.
I prefer a gradual, practical and organic change from the current position into something better. Even if it's harder, costlier and takes longer, I think it's a safer approach to change management. Safer in that there is less risk it goes bad, there's less risk of rejection and also it can be stopped at the point where it makes sense to stop changing, while still keeping the benefits up to that point.
Also, I think some people would say "if you would have waited for the management to change, you could have saved all the home-made brownies". I do not agree with this theory of "let's just wait until management opens their eyes": I think many of the actions we did from the bottom-up contributed to change the way management saw the project, the team and what we were capable of.
In the case of "Upstream Planning" I consider the work I did a success. I would have preferred for it it to happen faster and the process to be more widely adopted. We were the "data people" and we were aware of the daily cost of not implementing the tools further, financially and socially.
But I still choose an "imperfect-but-improving process" to a "perfect-paper process yet-to-be-implemented" anytime.