Skip to main content

Leveling up your ArcGIS Urban Metrics: Pro Forma Analysis for Planners

Metrics are perhaps ArcGIS Urban’s most powerful feature, but their complexity can make them intimidating for less experienced users. This blog explores how metrics can be deployed to rapidly perform even complex calculations by demonstrating how to configure a Pro Forma analysis for use in any Urban model or plan. 

Metrics are one of the most flexible, powerful tools in the ArcGIS Urban toolbox. With effectively configured metrics, planners can quantify and understand the precise impact of proposed and potential development. However, it can be easy to miss out on the full potential of metrics in Urban. Many users simply configure the “big 3” metrics - population, households, and jobs - and stop there. These are obviously crucial values to model, but metrics can give you much more than this - from tracking the effect of proposed inclusionary zoning policies on affordable unit counts, to understanding the impact of heavy rain event run-off at a site-by-site level.

In this blog, we will take a deep dive into the use of metrics to easily perform an important evaluation that frequently escapes the consideration of planners: pro forma analysis.

Pro forma are financial feasibility analyses typically performed by real estate developers when assessing the viability of a development. However, the ability to perform a pro forma analysis is also important for municipal planners. Planners attempting to implement affordable housing policy are no strangers to pushback from developers, who may argue that policies make development economically unviable. But by incorporating pro forma analysis into our policy development workflows, we can pre-emptively provide developers with the numbers to show them that more equitable housing policy still can be financially viable.

So how can we leverage ArcGIS Urban metrics to perform pro forma analysis on the fly? Let’s get into it.

Note: The pro forma we will be configuring is a basic static “Back of the Envelope” analysis, typically performed by developers in the early stages of project exploration. More advanced Discounted Cash Flow analyses are possible but beyond the scope of this blog. Additionally, for the purposes of this blog, we will be focusing on pro forma for a residential condominium (rather than purpose-built rental) building.

Part One: Expected Revenue

To complete our pro-forma metric configuration, we will need to configure both sides of the profit equation: expected cost and expected revenue. We are going to start with revenue.

To determine our expected revenue, we need to be able to calculate the number of residential units of different sizes (1 bedroom, 2 bedroom, 3 bedroom) our potential development will contain, and then, using an expected sale price for these unit types, calculate our total revenue. First, let’s set up our inputs - we will add “Variable” metrics for 1 bedroom unit size (m2), 1 bedroom unit price ($), and 1 bedroom target distribution (%). As we add variables to our metrics, we will not actually assign a value to any of them. This will allow us to modify them as needed when evaluating different development sites.

Screenshot of three metrics within an ArcGIS Urban metric dependency graph.

The yellow warning icons are telling us we have not set values for each variable. We can ignore these for now.

Next, we will need to determine how many 1 bedroom units our buildings can actually contain. To start, we will need a metric that will calculate the net floor area of all residential spaces. We will add Net Space Area as an input metric (available under the “Spaces” dropdown), and add a Space Use Type Parameter metric that we can call “Residential Filter”. We will configure this Residential filter with a value of 1 for our residential space use types. Then, we will add a multiplication operator (called ”Net Residential Floor Area”) to multiple these two metrics together. This acts to filter out floor area from any non-residential space uses within our building.

Next, we’ll multiply this new Net Residential Floor Area by our 1 Bedroom Target Distribution (%), which will allow us to calculate the portion of our residential space that we expect to be used for 1 bedroom units. Then, we’ll divide this value by our 1 bedroom unit size (m2) metric, to calculate the number of units that can fit into this space. Finally, we’ll multiply this number of units by our 1 bedroom unit price. This will give us the total expected revenue from 1 bedroom units.

Configuring the Residential Space and 1 Bedroom metric calculations

Next, we’ll simply repeat the steps above for 2 bedroom and 3 bedroom unit types. When complete, we’ll sum all of our separate expected revenue metrics into a total Expected Revenue metric.

Screenshot of large metric dependency graph within ArcGIS Urban.

The full metric graph resulting in an Expected Revenue value.

Part Two: Expected Costs

There are a number of elements that go into costing for a pro forma analysis, including:

  • Land Cost
  • Hard Construction Costs
  • Development Charges & Other Soft Costs
  • Construction Loan Interest

Let’s go through each of these in turn, starting with land cost. Land cost is often expressed in terms of cost per m2, so first we’ll add a new variable representing this, again leaving the value blank so we can modify this on a site-by-site basis later. Then, we’ll add the Parcel Area (under the Parcel dropdown) as an input, and multiply these two values to get a total land cost value.

Configuring the Land Cost calculation

Next, we’ll turn to hard construction costs. Here we’ll add a Space Use Type Parameter metric where we will capture the construction cost per m2 of different space uses (the Altus Canadian Cost Guide is a great free Canadian reference for this information). Then we’ll add Space Area as an input metric (under the Spaces heading), and multiply the two together to get a total construction cost. On top of this estimated cost, developers typically account for some additional contingency. To support this, we can add a new variable metric to capture our hard cost contingency percentage and multiply this by our total estimated construction cost.

Configuring the Hard (Construction) Cost and associated contingency calculations

Now let’s turn to soft costs, which represent all the non-construction expenses of development, such as professional services from planners, lawyers, and architects, development application & permitting fees, and more. Generally, these are estimated as a percentage of the expected construction costs. We will repeat the steps we took for calculating our hard cost contingency - adding a variable to capture our Soft Cost %, and multiplying this by our total hard costs. We will then add an additional soft cost contingency, taking our calculated soft costs and estimating a percentage of this as additional contingency.

Configuring the Soft Cost and associated contingency calculations

One component of soft costs we can calculate fairly exactly is development fees, which for residential developments are typically costed on a per-unit basis. First, we will add a variable to capture our municipality’s development charge per unit. Then we will sum the 1-, 2-, and 3-bedroom unit count metrics we created in the revenue section into a total unit count value and multiply this against our development charge value to calculate total development charges.

Configuring the Development Charges calculation

Then, we’ll sum the outputs of all of the above calculations: land cost, hard costs & contingency, soft costs & contingency and development charges to get a total development cost before financing.

Screenshot of large metric dependency graph within ArcGIS Urban, focused on the inputs to the metric named “Land & Development Cost Before Financing”.

Land cost, soft and hard costs are summed into a new metric.

With this calculated, the last piece of the cost puzzle is the expected interest on any loans taken out to finance the project. The value of the loan itself can be calculated by multiplying the total pre-financing cost against a Loan To Cost Ratio value, which is the percentage of the development cost that will be covered by loans. First, we will add a variable to capture this LTC value, and then multiply the development cost against it. Now we have the total expected loan, we simply need to calculate the expected interest the developer will pay on this loan. To do this calculation, we will add three more variables: loan interest rate, loan duration, and average loan balance as a percentage (if we assume the developer will pay the loan off in equal increments each year, we can set this to 50%). By multiplying the total loan by all of these values, we can calculate an expected interest value. By adding this value to our total pre-financing cost, we get our total expected development costs.

Screenshot of large metric dependency graph within ArcGIS Urban.

The completed Construction Interest & Total Development Costs calculations.

The Bottom Line

Well done for making it this far! We’re just about done. All that’s left to do is add some final metrics that will allow us to compare our expected revenue against our expected cost to determine the feasibility of developments.

First, we will calculate an expected profit by simply subtracting the total development cost from the expected sale revenue value. The final calculation we need to make is a Profit over Revenue return value. This is one of the most commonly used measures by developers to determine feasibility. We can calculate this by simply dividing the expected profit by our expected revenue value. This will result in a percentage value - most commonly, 15% is the goal number here for developers.

Screenshot of a small metric dependency graph within ArcGIS Urban.

The final profit calculations.

And with that, our metrics are configured, and we are ready to start analyzing some sites! To use these calculations for a particular site, first create a plan in ArcGIS Urban covering the site area. Then, open your metrics graph within the plan and fill in all of various variables we have set above based on your understanding of the development landscape in your municipality. Then, simply work within your plan scenarios and Urban will calculate all of the output metrics on the fly.

Screenshot of a potential development in a plan within ArcGIS Urban and calculated Pro Forma metrics.

This development has an expected Profit/Revenue of 11% - lower that most developers are likely to accept. With this knowledge we can consider how to increase this value, such as through more permissive zoning or providing incentives.

I hope that this basic pro forma metric will help you better understand the feasibility of your policy initiatives from the perspective of a housing developer. This is still a fairly simple pro forma – I would encourage you to take this particular configuration as something that can be built upon and explored further, to best understand the power of metrics in ArcGIS Urban to flexibly track even very complex KPIs.

About the Author

Ridley Soudack is an Application Specialist with Esri Canada’s Community Planning team. He works with communities across Canada to develop and implement new planning solutions with ArcGIS. Ridley has a Bachelor of Arts in Sociology & International Relations and a Graduate Certificate for GIS Applications from Fleming College. He has a strong interest in leveraging the power of GIS to tackle global challenges. When not working, Ridley can be found rock climbing or singing karaoke.

Profile Photo of Ridley Soudack