#31 - On Development Reporting

In This Issue

1. On Development Reporting

2. Reading List

Two recent experiences got me thinking about reporting — which is one of those unglamorous things that tells you a lot about how a development team actually operates.

First, a friend reached out to ask if I could share a monthly reporting template to help them prepare for construction on a small residential project. They sent their latest draft for me to take a look at. It was quite short and very light on detail: a high-level summary of projected financial returns, and maybe 50 words each on the status of planning approvals and design. No real information about what the team had been up to for the last month, and no discussion of project risks and how the manager was mitigating them.

Second, I had a large developer client who was struggling with their investor reports. They were spending a huge number of hours on each report, maybe 50+ staff hours across development analysts, development managers, construction managers, accountants… followed by a gauntlet of senior leadership reviews. Despite all the resources that went into these reports, they were often distributed to investors late, or were (at best) rushed out at the last minute. To make matter worse, the primary investor, a large institution, complained that the reports weren’t useful.

This all seemed fixable. So I reached out to my contact at a large pension plan, and asked if they would be willing to share a redacted copy of the very best development report they receive each month, out of their entire North American multifamily development portfolio. They agreed, and sent a very good sample report from a developer in the US. It had lots of fine detail — a permit status log, change order log, cost exposure log, detailed schedule with variances, detailed status of various entitlements, a full line-by-line job cost report, and so on. And very little narrative fluff, which is always nice.

I shared it with my client, expecting they would be thrilled to get a copy of this document. A cheat sheet for impressing an institutional investor? Pure gold.

But do you know what they told me after they reviewed it? To paraphrase:

“There’s no way we could ever produce this. It’s far too much detail, and we don’t earn enough fees to do this much work. It would take us even longer to review this each month, and we don’t have the time. We could never get internal approval to share this much information.”

These examples got me wondering: how is it that some teams can provide this much detail, in a format that investors love, while others can’t?

Reporting is most useful when the development manager treats it as a tool producing great buildings. The circulation of its contents to stakeholders matters, of course, but that is secondary. Writing the report has its own value, and done properly, should improve the quality of the developer’s work.

Reporting is much less useful when you think of it as a regulatory requirement, a box-checking exercise, a piece of storytelling/marketing, or as the minimum amount of information you need to share to keep investors from bugging you with questions.

When setting out to establish your template and reporting practices, it helps to write down what your goals actually are, and to acknowledge tensions and tradeoffs.

For example, sharing more information today does increase the odds that stakeholders will ask more questions tomorrow. If you previously reported a certain key milestone date, and you are changing it now, people will want to know why.

At the same time, transparency builds trust. If you conceal information and people find out about it later, or if stakeholders feel like you’re moving the goalposts too much, you will be considered less trustworthy.

Different audiences will also want different things. Retail investors generally need (and want) less information than institutional investors. They can become confused by the unpredictability inherent in this business. They also prefer proforma information, whereas institutional investors value a lot more process information.

And people talk. If you have a project that isn’t going well and if your reporting is distributed to a large number of investors, then people will hear about your problems. Many developers hate reporting bad news because not only does it cause lots of near-term questions, but it also opens you up to reputational risk.

Different market conditions also encourage different reporting habits. When things are going well, many developers fall into patterns of taking credit for good things and leaving bad things out. The project is on track, so why distract people with minor problems? That reduces the number of questions you need to answer, which frees you up to focus on other things. But when the market turns, this practice can destroy trust quickly. The market is no longer covering up your problems, and investors will be especially unhappy if they think you’re concealing material information.

When I manage projects, I have an Excel file that holds all key project information in one place. Every project has way too much pertinent information for one person to remember, but you still need access to it at a moment’s notice. This is because every development project is a minefield, with hundreds of little things that could blow up in your face if you don’t stay on top of them. I track things like permit expirations, entitlement milestones, lender/equity/regulatory reporting requirements, a key milestone schedule, and project costs from one file that is easily accessible. If some important detail changes on my project, I try to update the file immediately.

Important note: this file is not a proforma, and in my opinion, your proforma should be completely separate. Reporting is about what’s happened in the past, not what will happen in the future. If you muddle these things, you will be tempted to spend time fudging numbers to match a narrative, or fudging a narrative to match the numbers. It’s not a very productive use of time. So I like to focus on reporting the past in my monthly reporting, and I exclude financial returns unless it’s explicitly requested by my stakeholders (which has never happened).

My proforma updates happen on a separate cadence — much less frequent than project updates. This is generally OK because unless I’ve made large changes to budget or schedule or deal structure, the proforma should not be changing much.

Once a month, I run through everything as part of a capital call/bank draw process. This is easy and fast, because everything except for my project costs is already up to date in my master file. I can copy/paste the various tables and provide written narrative for each section of the report. This is a forcing function — because I include so much detail in my report, and because the report is due on a certain date, I cannot procrastinate! I need to stay on top of all these details. And because I manually populate all of this information, I need to actually think about it.

This is another important point: If I didn’t share a given piece of information, I wouldn’t need to update my records or my memory about it as frequently. That would increase the odds that I forget about some important detail. Remember, there are hundreds of data points on a project that will be minor most of the time, but can suddenly become urgent and important. Your investors will probably never get into the weeds of your permit expirations or your timeline for securing temporary power, but they will find it comforting that you are on top of it.

Once you’ve got your template done, it’s very quick to run through each section and make updates. At this stage, it might be helpful to run your report through an LLM to look for typos and make minor grammatical/syntactical improvements. I strongly recommend that you do not use AI tools to draft reports, because that defeats the purpose of using the report as a tool for improving your own professional competence and project awareness. Doing a report manually is a good type of friction — going through it helps you commit things to memory, and to observe connections that you might otherwise miss.

My own experience has been mostly with highly engaged institutional investors, and that’s given me a certain perspective on reporting that might differ from other people’s. But the following guidelines have held up pretty well for me:

• Err on the side of transparency. I’ve seen far more problems arise from concealing risks than I have seen from disclosure.

• Use reporting as a tool to improve your own project management.

• Have only one author on each report. If two people contribute, you’ll need to coordinate writing across their schedules, and there will inevitably be items that contradict one another and need to be resolved. Complexity grows exponentially with each +1 person who gets involved.

• Delegate reporting authorship down to the actual project manager wherever possible. This drastically improves information quality. If there are two levels of management between the author and the project, the information has almost certainly been… massaged.

• You will make mistakes on every project. When it happens, own it! Disclose them quickly and explain how you’re setting things right. This builds trust, and creates strong incentives for you to improve as a professional. If you hide problems, you will not act as forcefully to correct them.

• It’s better to have a typo or an awkward phrase than to delay a report.

• Senior leaders should be ruthless about improving their organization’s reporting processes, until they do not need to review each report. If you need to review every document before it ships, your process and goals probably need improvement.

If you set reporting up this way, it should not consume a huge amount of organizational energy every month.

After I started writing this article, I posted the following poll on X.

These results seem right. I have been the primary author on many development reports, and when things are going well it should only take a few hours per month. Even when I had responsibility for pretty much every section and updating my own cost numbers manually, I probably spent 2-3 hours per month generating these reports; my accountant might spend an hour or two making sure everything tied to our accounting software and bank records. Even in a busy month with lots of complexity and updates, it was certainly less than a full day of total work.

Interestingly, I’ve noticed an inverse relationship between hours spent on a report and its quality. There are lots of reasons for this, most of which we’ve already covered: if you require lots of layers of review, quality declines because information is filtered. If you have too many cooks in the kitchen, no one knows everything about the project and there will be confusion and lots of necessary coordination.

The best way to produce a great report is to keep the process and the outputs simple.

The Impact of Institutional Investors on Homeownership and Neighborhood Access. By NYU professor Joshua Coven. The Trump administration recently signed an executive order aiming to limit institutional ownership of single family homes. This issue has been controversial in both the US and Canada. Interestingly, this paper finds that institutional ownership 1) increases the quality of rentals and causes a net reduction in rents, 2) decreases the quantity of homes available to homebuyers and slightly increases sale prices, and 3) improves social mobility by providing lower income families with access to better neighborhoods and schools.

If that last point interests you, here is another paper that examines the link between single-family rentals and educational achievement…

Educational Achievement Gains Afforded by Moving to Single-Family Rentals, by Tom Mayock and Kelly Vosters.

On Being A Dad. By Derek Thompson. A lovely little essay about the experience of being a parent.

Cities Keep Planning for Seniors to Downsize. The Data Shows They’re Not Moving. Great discussion from the Missing Middle Initiative, on a topic that I’ve been tracking my entire career: the (supposedly) imminent wave of Baby Boomers who will downsize from large single-family homes to urban apartments.

I write this newsletter because I like to connect with smart people who are doing interesting things. Reach out by replying to this email or commenting below.

Thank you for reading, and have a great month.