FiloGrant’s Agile Response to the Covid-19 Pandemic

By Jeroen Valkier – Certified Creating Agile Organizations Trainer.

Business Adaptability to Face Covid-19 Lockdown and Social Distancing

FiloGrant provides and fulfills custom made financial services for entrepreneurs. These services consist of financial support for the development of business in the form of loans and grants to entrepreneurs. FiloGrant acts as contractor for MoneyWell. MoneyWell designs the financial services and pays FiloGrant for service development and provisioning. FiloGrant uses and develops a platform to publish and fulfill the services.

Fig. 1 Graphic showing the services provided by FiloGrant as commissioned by MoneyWell

The impact of covid-19

With the emergence of the Covid-19 pandemic MoneyWell decided to support businesses for the devastating effects that lockdowns and social distancing had on their revenue.

The desire of MoneyWell to compensate these businesses posed three key challenges for FiloGrant:

 

• an increase in the rate at which MoneyWell requests FiloGrant for the fulfillment of new types of loans and grants

• a tremendous increase of applications per loan or grant.

• the need to get a new service delivered in weeks instead of months.

In this report, I share how MoneyWell used Agile organization design to deal with the challenges posed by the Covid-19 pandemic. I will assess the effectiveness of these measures in light of the principles described in Creating Agile Organizations (Ramos and Pavlichenko – 2022).

FiloGrant needed to provide Relief4All fast

To provide relief to entrepreneurs from the effects of lockdowns MoneyWell commissioned FiloGrant to provide a new financial service called Relief4All. The pressing circumstances demanded that Relief4All was to be published in weeks instead of months. This proved to be quite the challenge for FiloGrant. There were two main reasons for that. First, delivery times that were common for new financial services would be unacceptably long for Relief4All. Secondly, conflicting goals between two essential units within FiloGrant were causing ineffective performance for both.

In the following paragraphs, I will elaborate on these two main causes and how FiloGrant dealt with them.

Long Delivery Times

The steps in the process of setup, development, publication and fulfillment of the financial services are shown in the graphic below. This process includes designing the fulfillment process and developing the software needed to support that process:

Fig. 2 Schematic showing the activities and actors in the process of setting up and fulfilling a financial service.

Under ideal circumstances, this process should go like:

Design Service: a representative of MoneyWell contacts an account manager of FiloGrant to specify the need, terms and funds to FiloGrant.

Choose Technical Platform: This account manager takes that information to FiloGrant and discusses it with information architects and analysts, who decide which of the key platforms to use to develop the software supporting the process of fulfilling the financial service.

Design Fulfillment Process:

With this choice made, developers work with the coordinator of a designated Fulfillment Team to work out the fulfilment process.

 

• Automate Fulfillment Process: The developers automate this process based on the process design.

• Add Marketing Content: work with marketing communications to ensure that the proper texts are used

• Review results: have the legal department, the fulfilment team and marketing communications do a review.

• Publish a service: the development team and marketing communication make the financial service known and available to entrepreneurs.

However, as you might have expected, this rarely happened.

The Reality Of Dependencies Between Teams

Unfortunately, this work was seldom done as sequentially as described above. Because each new financial service has its unique properties, developers had to regularly go back and forth between operations, legal and marketing communications to make sure they automated it correctly.

For example, when the designed process turned out to be legally non-compliant, developers had to redesign the process with operations, and they’d have Legal do a review again. Or when marketing texts didn’t match the terms of the service, changes to the process and the way it was automated might have new legal implications. This resulted in changes in the process, which resulted in changes in the software, which resulted in changes in texts. This led to endless loops and deadlocks due to these dependencies. What caused even more accidental complexity was the fact that developers, process coordinators, financial reviewers, project specialists, legal experts, and marketing copywriters were all part of different functional teams. These all had their own worklists, priorities and focus. The organization design assumed sequential dependencies between teams, but in reality, the dependencies were reciprocal.

Reciprocal dependency When it comes to dependencies between tasks, there are three kinds: pooled, sequential and reciprocal. Pooled dependencies (like sharing a resource) and sequential dependencies (one task needing the completion of another task) can be coordinated relatively easily by planning and coordination. Reciprocal dependencies (where tasks mutually require the output of other, like a surgeon and surgical assistant working together) however require twice as much coordination.

The Cost Of Reciprocal Dependencies

This complexity at FiloGrant can be understood in more detail by looking at the information exchange between each step in the process:

Fig. 3: The exchange of information between people performing the tasks required to set up and fulfill a financial service. Each arrow represents information coming out of a task and the subsequent feeding into another task required for fulfilling it. The dotted arrows indicate a relatively lower occurrence. Red arrows indicate a reciprocal exchange of information.

The tasks shown in Fig 3. were fulfilled by different departments:

Task	fulfilling Units
A	MoneyWell + FiloGrant Account Management
B	Enterprise Information Architecture
C	Development Teams + Fulfillment Teams
D	Development Teams
E	Marketing Communications
F	Legal + Fulfillment Teams + Marketing communication
G	Development Teams + Marketing communication
H	Fulfillment Teams

Table 1. Detailing which units perform the tasks depicted in Figure 3 

Due to the fact these people weren’t part of the same department or programme, people had different goals, different schedules and priorities, and because of that, a lot of time was spent coordinating and waiting on information. As a quick fix, the organization relied on special people to coordinate this information exchange needed for task fulfillment.

The result was super high coordination costs, goal conflicts and slow delivery. Half of the time it took to set up and publish a new financial service was spent on coordinating this flow of information between the people performing these tasks. This excessive coordination wasn’t just wasteful. It was also detrimental to the efficiency of the flow of work and caused tremendous personal stress for the people doing this work.

Making Sense Of The Situation

To understand what is going on, we can look at this complexity from a different perspective. When we display the tasks in a Design Structure Matrix, we notice that tasks C, D and F are dependent on each other in both directions: they are reciprocally dependent on each other.

TASKS  ⇨ ⇩	A	B	C	D	E	F	G	H
A
B	X
C	X	X		X		X
D		X	X			X
E				X
F			X	X	X
G						X
H							X

Table 2. This DSM shows the task interdependencies for setting up and fulfilling a service. The black X’s indicate frequently occurring sequential interdependencies. The red X’s indicate frequently occurring reciprocal interdependencies between tasks.

Although the flow diagram in Figure 3 helps, we can spot the cause for the coordination more easily in a DSM. You can find the reciprocal dependencies as X’s in the upper right section of the quadrant. As the situation at FiloGrant demonstrated: if these tasks are not performed by a single department or team, coordination chaos ensues.

Luckily, the opposite is true as well. Following the 5th guideline of Creating Agile Organizations, containing reciprocal dependencies within a single unit can help lower these coordination costs.

Organizing Relief4All into a Product Group

The work to set up and publish a new financial service was spread over many different teams and departments (as shown in Fig. 3). Previous efforts to shorten delivery times failed because these units were only optimizing the performance of the separate tasks, rather than the delivery of the actual customer value: the financial service.

To remedy this for Relief4All, FiloGrant tried something else. First it was decided that the processes for Relief4All were to be developed on the UniPro Platform (one of the key platforms FiloGrant had at their disposal). Secondly, FiloGrant created a new unit by combining the responsibilities of the setup, publication and fulfillment of the Relief4All service into a product group. The product group’s purpose was to design and deliver this particular financial service from start to finish. It was staffed with all the people required to do the work shown in Fig. 3. This new unit was headed by a leadership team. This leadership team consisted of the manager for the National Grants department and the UniPro Programme Manager.

This resulted in a product group that was capable of setting its own course, and deciding on its own structure and processes. The Relief4All product group could rid itself of any work that wasn’t contributing to the delivery of the Relief4All service, and optimize its own working processes to get the service into the hands of the entrepreneurs as quickly as possible.

The creation of the Relief4All unit resembles the organization of a Product Group as described in the first guideline for Creating Agile Organizations: Organize into Product Groups. Looking from the outside in, the Relief4All service is the product as provided to the entrepreneurs. The people needed to design, set up, publish and fulfill this service were all included in the Relief4All unit, creating a semi independent unit with its own leadership.

Fig. 4: Showing the structure of FiloGrant after creating the Relief4All Product Group

This provided the Relief4All unit with a level of autonomy needed to create and adjust its own internal structure and processes. As a result this unit became more agile than the organization that contained it.

How Did FiloGrant Do This Redesign?

Looking at Figure 3 and Table 2 we can spot three reciprocal dependencies highlighted as red arrows and X’s between the following tasks:

 

• Design fulfillment Process

• Automate fulfillment Process

• Validate Legal Validity

The dependencies between these tasks required the most coordination and were the cause of most of the delays. With the creation of the Relief4All Product Group the Leadership Team was able to set up a team that contained all these dependencies within a single unit.

Similar to the fifth guideline for Creating Agile Organizations, containing the reciprocal dependencies, the members of the team were now able to directly adjust their actions to achieve a common objective, without the need for a coordinator.

The increased dependency within the team (in contrast to outside of the team) led to minimal coordination cost, less delays, shorter feedback loops, more direct communication, less handoff of work, and more effective exchange of information between the team members. More importantly, the concepts of dependency within a team became silly as all team members were working towards the same goal at the same time; as a result collaboration improved and dependencies were handled as shared work.

Fig 5. Shows the organizational structure of the Relief4All unit. Red dotted lines show from which functional departments the Product Group was staffed.

Bypassing Account Management to increase learning

Looking at the creation and design of new service (activity A in Figure 3) we see a cooperation between MoneyWell and FiloGrant. At the side of FiloGrant, this task is performed by Account Management. The function of Account Management is to assess the need from MoneyWell’s perspective and help design a service that is operationally feasible at an acceptable cost. Although not common, it sometimes happened that either the demands of MoneyWell were unrealistic, or the needs of the customer were not represented sufficiently. In either case, this would lead to situations where the agreement made with MoneyWell was made to be more important than the actual customer value.

In any case, Account Management operated as the front-end, market facing part of FiloGrant and the rest of the organization as the output generating back-end of the organization. Both had their own local optimizations due to this functional setup.

According to Creating Agile Organizations it is clear that such a setup can get you into trouble rather quickly. The guideline that suggests to Group By Common Customer, recommends creating an organization in which units are grouped around a common customer, and contain all functions that are required to deliver value to this customer.

FiloGrant applied this guideline with a different approach, but with a similar outcome.

Instead of grouping two or more units by a common customer into a single unit (as described in the 6th guideline of Creating Agile Organizations), FiloGrant simply removed the need to group units by allowing Relief4All to bypass Account Management entirely. The separate front-end was effectively taken out of the organization for the Relief4All. This allowed a direct collaboration between MoneyWell and Relief4All. This opened up the possibility of weighing the objectives of the Relief4All services with the capabilities of the UniPro platform, and most importantly, its users. This saved both MoneyWell and FiloGrant a lot of time that would normally be wasted in expressing and resetting expectations of MoneyWell against the capabilities of FiloGrant and the UniPro platform.

Fig 6. Shows the direct cooperation of the Relief4All unit with MoneyWell on the design of Relief4All. The red cross indicates bypassing the structural account management at FiloGrant.

By engaging MoneyWell in the outcomes of the short feedback loops, the Relief4All unit was also able to decide and act on the new course of actions easily and directly. MoneyWell was able to adjust its demands on crucial details without the service losing its effectiveness based on what was feasible for FiloGrant to deliver on short notice. In turn, FiloGrant was able to (re)design the Relief4All unit in such a way that it met the needs of MoneyWell based on the feedback provided by MoneyWell and their customers.

Conflicting goals between the UniPro Programme and National Grants Department

As mentioned earlier, FiloGrant uses the UniPro platform to provide and fulfill Relief4All and other financial services. This platform is developed in house specifically for the financial services fulfilled by the National Grants Department. The platform was developed by the UniPro Programme. This was a unit separate from the National Grants Department. In that structure the UniPro Programme and the National Grants department strongly affected each other’s performance.

Fig 7. Showing the organizational structure of FiloGrant indicating coupling between two units.

In the structure above, the UniPro Programme is responsible for developing the software that automates the processes of publication and fulfillment of the financial services. The function of the Programme is to develop features from which as many financial services as possible can benefit. However, the function of the National Grants department is to optimize fulfillment and focus on operational excellence. The two units had competing goals which caused serious functional coupling resulting in significant effects on the service level.

Functional coupling When two units within an organization affect each other’s performance in fulfilling their purpose we call this functional coupling. Functional coupling is something we want to avoid when designing organizations, especially when it has a negative effect on the performance of at least one of the involved units. Functional coupling causes an organization to be less agile, when decisions or actions in one unit cause the other unit to lose performance. An example of functional coupling occurs when an organization has a unit responsible for quality assurance, and a separate unit responsible for product development. In this example Quality Assurance specifies company wide quality standards and processes. The Product Development unit develops and ships the product the company gets its revenue from. When the performance of the Quality Assurance unit is measured by the adherence of the Product Development unit applying their standards, and the Product Development unit by the number of paying users, one of them has to suffer. It’s either the Quality Assurance unit for not achieving their objectives because Product Development does not comply, or Product Development suffering missed opportunities due to unnecessary work done on irrelevant quality criteria and adherence to needless processes.

This functional coupling between the UniPro Programme and the National Grants Department meant that both suffered from suboptimal performance. Ultimately, neither of the two units were able to fulfill their purpose optimally.

Creating a leadership team to combine authority with responsibility

To make sure Relief4All wouldn’t suffer from this functional coupling, the leadership of Relief4All was shared between the manager of the UniPro Programme and the manager of the National Grants department. By creating this Leadership Team, the managers of the functionally coupled units, were now able to define a clear and dedicated function for Relief4All. By joining their responsibilities, and using their combined authorities they were fully capable to choose the right course of action, independent of other units. This leadership team reported directly to the responsible Director of the National Division of FiloGrant.

Fig 8. Showing the organization structure of FiloGrant with red lines indicating the leadership team for the Relief4All, made up of the managers of the UniPro Programme and the National Grants Department

As a result, this leadership team was able to design a process and structure that was optimal for the fulfillment of Relief4All, and also develop features that supported exactly and just that. For example, Relief4All generated an enormous demand from entrepreneurs resulting in thousands applications a day. The people assessing the applications were not able to process that many fast enough. The leadership team decided that the assessors had to focus on only those applications that were abnormal. The remaining applications were processed by an automated process without the intervention of a human. Combining their authority and responsibility allowed them to make this decision much faster and much more effectively then FiloGrant was able to originally.

First release within 4 weeks

Setting up Relief4All as a Product Group, bypassing Account Management, containing reciprocal dependencies in the development team, and creating a leadership team. The sum of all these changes in the organization for Relief4All had a significant outcome. Relief4All was able to publish the service and subsequent updates roughly twice as fast compared to any previously published service of comparable size. This resulted in the first release to entrepreneurs within 4 weeks after request by MoneyWell. Work continued with very short feedback loops of 1 week. The creation Relief4All unit proved to be successful.

Conclusion

FiloGrant created the Relief4All unit in response to the urgent need caused by the Covid-19 pandemic. The company made changes that resemble the CAO Guidelines 1, 3, 4, 5 and 6. This had the desired effect:

 

• due to creating the Relief4All leadership team, and including all essential parts in the product group, there was no longer a need for coordination between the managers of the previously involved units (legal, market communication, enterprise information architecture);

• the leadership team had full responsibility and authority to manage the performance of the Relief4All service, rather than its parts;

• MoneyWell and FiloGrant engaged into a collaboration where real learning from the product and the way it was developed took place.

• the people working in the new unit no longer experienced goal conflicts, because everyone had the same goals, priorities and focus: to set up, publish, and fulfill Relief4All.

In the end, MoneyWell was provided with what it needed for prompt publication of, and regular updates on the Relief4All service.

Faced with the challenges posed by MoneyWell, both the FiloGrant and the UniPro platform software proved “soft” enough to make the necessary changes. That being said, MoneyWell had quite a hand in that adaptability. It was raw urgency and pressure that MoneyWell exerted on FiloGrant that created the Relief4All unit within weeks without structural reorganization. Something that would not have been possible without this pressure.

This leaves to question what this means for the adaptability of FiloGrant without this externally applied pressure. In my next article, I will review the changes the organization UniPro Programme underwent and the effectiveness of trying to repeat the effects of the Relief4All unit to the broader portfolio of financial services FiloGrant provides.