aenspire delivering developmentprofit.com

4:10am Beep, Beep, Beep. Like a hungover Ninga I rolled out of my future wife’s bed in a small flat in Sandringham. Stumbling down the stairs my eyes found their focus on a flashing luminescent green screen of a Nokia 3210 cellphone. The stop loss trigger had activated on Nasdaq listed CMGI. My shares had been automatically sold, but not before taking a horrifying fall. I had purchased it at just over $150, and now it was less than $50. I was wide awake now.

‘What did this mean?’ I pondered as I downed my breakfast ritual of 2 Diet Cokes, albeit a little earlier than most days. CMGI had been the best performing stock in America. They had the perfect business model – they invested in Dot Com companies.

‘Oh well, this sure bet tech thing is looking a little like how some property developments end up. Burned.’

‘CollaborIT is different though,’ I thought. ‘Our customer base is growing and it is gong to be amazing once we launch in Chicago.’

…

Less than a year earlier I had confronted my boss, Tony at Verve Cafe in Parnell over breakfast.

“Look, all my mates are going to London to work in finance and tech. They are earning huge amounts of money. And to be honest I am a little bored and frustrated trying to coordinate contractors and consultants on our projects. I want to go to the UK.”

I had only been working in property development for a couple of years, but had become more interested in technology. At night I self taught HTML and Cold Fusion coding. I built a website for Eden – in 1998, as far as I could tell, it was the second property development in New Zealand to have its dedicated own marketing website. I started a business with my flatmate and we started building websites. Our lawyer was one of the first to buy. I was the property development manager slash website guy.

But by this eggs benedict breakfast in the Spring of 1999, I wanted more. I truly was frustrated with the inefficiencies of property development.

‘Why couldn’t architects figure stuff out with the engineers without calling me?’

‘What do you mean you don’t have that version of the drawing?’

‘I gave you that variation request last week, where is the answer?’

All too common words in the property developers vernacular.

Tony sat there, expressionless, I imagine expecting a Dear John resignation.

“But,” I started to continue.

“But?” Tony replied. I am pretty sure he was thinking I was about to ask for a raise, using the going to London thing as some sort of juvenile employee leverage.

However, I was serious and finally brave enough to broach the question. “Tony, what if we – you and me – do our own Internet thing. That keeps me here and who knows what we can do?”

And like a true bona fide entrepreneur, one who I am eternally grateful to for that opportunity, without a second of thought he replied, “Sure, 50/50 You can wind down everything else you are doing and come back to me with a proposal. What are your thinking?”

“I have no idea, but what if I come back to you with a proposal say a couple of months after Christmas?” I said.

“Sure.”

And CollaborIT.com was born. [Note: The url CollaborIT.com has since been acquired and in use by a company not related, in any way, to the business I started as we discuss in this article.]

Well that name came many months later.

I truly had absolutely no idea what sort of Internet thing to do. A few weeks later, I was on a plane home from the gold coast after celebrating New Years eve on the dawn of the 2nd millennium. Actually I recall we spent midnight in McDonalds in Coolangatta, because you could experience the countdown in NSW and walk out the back door, wait an hour and do it all over again in Queensland. Anyway, the inflight magazine had an article about an Interent service called Buzzsaw that had just launched in the States.

And CollaborIT had found its mission.

“Buzzsaw is one of a few new applications that is using the internet to facilitate collaboration and document sharing in construction projects,” I said addressing the three others in the dark boardroom at the top of one of those towers along Symonds Street (New Zealand’s silicon valley of the day) one autumn evening.

“There are a few others also starting, including some guys in Melbourne with Aconex but they are focused on procurement as well and targeting contractors. We can do our own one and I believe the key to project collaboration, to make it successful is to get clients on board, the developers and the owners. Then, once they are sold on the concept they will ‘force’ everyone on their projects to use it.”

“Ok, we are in then. A Redwood and Greenwood Technology joint venture. We will build the software and sort out the administration and seek out further venture capital with our recently made American friends when we need it and you run it Crosby. Craig will help with business development once you have a product to launch,” Simon the CEO said. [Of course I am using some literal licence here, as the details of how and what we would do took months to figure through].

CollaborIT.com had a board, funding, a technology delivery partner and was in business.

Now the American friend, was the technology founder turned venture capitalist Chris Coffin who came to New Zealand with a view to take the America’s cup back to San Francisco. His money was made, if I can recall the story correctly, by developing email and modem software many years earlier that allowed bands on tour to get paid quicker, essentially on the night of their gig. Before his technology, it could take weeks for bands to collect their payment. He also was partly responsible for scaling the Palm Pilot when he worked at US Robotics in the 90’s.

With a substantial war chest in the hundreds of millions he funded the America True campaign, and whist in New Zealand planted seed capital in a handful of tech start-ups through his investment vehicle Vision Ventures. Eventually, Chris settled on one company that was pioneering SaS using a Citrix systems platform as well as building leading edge applications. Greenwood was providing Software as a Service, a dumb terminal linked to a central server technology – where you subscribed for applications and all your centralised IT support on a monthy basis. Yes even back in 2000 you could access all your applications via a cloud from anywhere there was an internet connection.

One reason for his angel investments in New Zealand, was that it was cheaper to produce software in New Zealand than in the United States, especially given the exchange rate at the time. Chris’s view was, build and test software in New Zealand, where it was cheap and the isolate market represented a low reputation risk to trial new ideas. And then if an application showed promise, he would take it to the American and essentially the world via his headquarters in Lake Forest, Chicago.

CollaborIT had angel eyes looking down from a very high place.

So we built it.

The best way of describing CollaborIT is it was like a glorified online drop box for property development projects, with a twist. Not only could you access documents but you could also access software applications, using nothing more than a dial-up (remember those days?) internet connection and a basic computer.

That mean’t not only could the architect upload the latest plans, which would automatically notify the project team via an email, text of fax* but the developer could then mark them up (red line) online to discuss with the project team in real-time. And every version was kept, and an audit trail recorded who did what and when. That way, there was no more ‘Have you received the latest detail from the architect Mr Engineer?’ because with two or three clicks you could check yourself. With some automated workflow integrated into the software, variation management, a big bug bear of mine as a young development manager, was enabled.

[* Yes CollaborIT was fax friendly. In 2000, in the real estate and construction game we worked in an interesting technology transition phase where I would print out emails to fax to people!]

Not only that, but with deals struck with Microsoft and other application providers, we could provide real-time access to applications without having the user pay for the entire software. Think of opening a Project schedule file or running CAD mark-up software without ever trying to install it on your computer.

The user interface was made as intuitive as possible. It looked like a folder tree on the left and files opened in a window on the right. And because essentially you were running software that normally ran on a desktop, you could drag and drop, create folders and do everything else in document management that was not so intuitive with a standard web based interface in those days.

One of my big learnings in software development, is you have to make it as easy as possible for users. Otherwise they simply won’t use it. Another learning is that every feature you add needs to be carefully considered. Once they get used to it, every user becomes an internet mogul with a wish list of features. However, every feature added creates complexity for new users, and often puts them off. So we released new features very judiciously. In the end, we made the features you had access to linked to your login, so advanced users might have the whole suite, and beginners, just the necessary functions.

Of course, and a unique selling proposition at the time, was if a user or a project had specialist software, we could make that accessible to all users. So CollaborIT had software within the software.

The business model was simple.

Primary revenue was generated from users who paid a monthly per user per project fee to access CollaborIT and a monthly per MB fee to pay for storage and bandwidth. The more projects and users the more revenue.

Secondary revenue was based on customization. As the number of projects grew, a third revenue source became apparent- consulting services to implement the system within projects and project teams. However, first we had to get a critical mass of projects online, and enough users familiar with the system before we could think about charging them a consulting fee.

The cost structure was also simple, CollaborIT was charged a per average user at anyone time fee and a per MB data storage fee. And there were all the normal expenses of administration and marketing and of course the capitalized cost of building the software in the first place, ongoing feature development and maintenance.

With enough projects fixed costs would be covered, and the fees were set to make a margin on each new user/MB and project.

Because I was an ex development manager, I and a few staff did all the user testing on pretend projects, pretending to be a developer, contractor or consultant on different computers in different places. Our first clients would facilitate the real user testing. And that worked out without many issues.

About a year after that boardroom presentation version 1.0 was built. Simon came up with the name ‘CollaborIT’ and we went to market.

I had to buy a suit. And a tie. I was transitioning from software development director to salesman.

We thought we started with a bang. Our very first meeting to demonstrate CollaborIT was with none other than Lendlease in Sydney. We finished putting together our sales presentation in the Symonds Street boardroom at about 2am, I went home for a few hours sleep and Craig picked me up to go to the airport at 6am.

Internet connections were not what they are like today. We had planned to test a few things in an Internet Cafe before the meeting, but we couldn’t connect. We didn’t know if it was an Internet connection issue or the software was down. Then came the meeting.

I can’t recall who we met, but he was high up in the organisation and in charge of rolling out the very concept of CollaborIT, online project collaboration, on their worldwide projects. What a whale of a client, if we could land them. And, the software worked well enough for us to bluster through a presentation that made it look like CollaborIT was 100% perfect.

That was the last we heard from Lendlease. But it gave us some experience and it gave us some confidence there was a real market out there for this type of product.

The next year, all of 2001 I was in sales mode. Phone calls, emails, meetings, presentations. All throughout New Zealand and in Sydney and Melbourne. In between scheduled meetings, I would don the suit and simply walk the CBD’s methodically going to every property development company’s office to try and make a contact, or if I was lucky to give a presentation on the spot. No LinkedIn back then.

My initial marketing strategy was:

1. Get the private property developers interested and sold on the concept. The benefits being saving time and money on collaboration, having an audit trail to track project and consultant/contractor performance, less printing as documents could be formally issued via CollaborIT and overall improved project efficiency.
2. Find a champion within their company who had enough power to influence/force others to use the system, as well as process and IT nous to ‘control’ CollaborIT – that’s called a super user today.
3. I help the champion set up the project structure on the software and how they were going to use it and then they would role out CollaborIT on a test project or two.
4. I would ensure the key users (architects, project managers, development managers, engineers, main contractor) were well trained. Live trained, because every new user became a sales target. Most were doing multiple projects or had other clients with projects.
5. Momentum would build. We would use testimonials and champion CollaborIT advocates to convert prospects to users, and wala every private developer would be using CollaborIT on all their projects.
6. With a few projects onboard we would hit Australia hard – they had the customer base market size we needed. Surely we would convert them as easily as Kiwis.

It soon became apparent we didn’t have enough resource to live train everyone and be able to rapidly scale the number of users. It took a long time to set the project up on CollaborIT. Not because of the software – that was super easy. But because when a project was set-up you had to think exactly how you would use it on a particular project and ensure that all who used knew their responsibilities. Otherwise it would just end up like a communal dropbox. People used it in different ways. Some simply used it for the online plan markup function. Others as a pure ‘cloud based’ document management system. My bluechips used it as a full integrated project management and collaboration tool.

Private developers loved the concept. Many were happy to get it going on their projects. The cost to value benefits were just so good, for any development manager who experienced on a day to day basis, like I had for two short years, the frustration of coordinating everyone and document on a project. But there were few champions within private developers actually willing to really enforce its use on their projects. And when a consultant or contractor moaned because they didn’t want to use a new system, or because they had their own system, or blame internet connection speeds (horribly slow at the time) most would relent. So CollaborIT, as easy as we made it, was just a bit too hard for them.

But there was substantial success with government projects. There, the project director in charge, often had the power to make sure everyone did use the system. Some actually wrote CollaborIT’s use into contracts and fee agreements.

With Super Power Champion Users like Shane on the Southland District Hospital Project, Derrick on Tauranga Hospital and Dunedin Airport, and others on 4 large Prison projects, the Northern Busway and wastewater upgrades we got traction. Plus these projects typically had the budget to justify CollaborIT to their boards and CEO’s.

Other uses came out of left field. One law firm used CollaborIT to manage retirement village contracts. An investment bank used it in the due-diligence for a large global M&A deal.

It wasn’t happening overnight but revenues were slowly increasing.

Then Chris made an offer. He would invest a substantial amount into CollaborIT for a substantial equity share. And we would take it to Chicago and market to America.

We mucked around a bit and turned down the initial offer, thinking it was better to build our user base up in Australasia first, so CollaborIT would become more valuable and we could demand a higher slice of the action. So we stalled.

However, even if we had taken it up it may have not come to fruition as by this time, the dot com bust was well under way. Chris would have been losing large back in the States and then later on, pretty suddenly he quit his investment in NZ. The relative exchange rate simply made no sense to continue developing software in New Zealand.

But I continued with CollaborIT. The software was a success on most accounts. Connection speeds still frustrated many – a problem with the Internet at the time moreso than our platform – but it worked really well. It helped development projects save money.

Two problems mean’t CollaborIT never made it to a listing on the New York stock exchange and why I don’t yet live in a modernist class box perched on a cliff facing San Francisco Bay.

ONE. I didn’t make enough sales. Simple. My responsibility and I failed. In my defense were a few mitigating circumstances that we hadn’t appreciated before we started.

New Zealand is a small market, and there simply were not enough big projects around. Private developers did not stick to it as I initially expected. Yes they could all see the benefits, but any hassle (and change means hassle for many) meant few would persist to enforce CollaborIT’s use.

Each project sale took a huge amount of effort. It wasn’t showing people how to use the software – that was relatively basic. It was setting up the offline process/rules in which they would use the software. Some architects would issue documents via CollaborIT and still send a printed set around – until this was explicitly listed in their fee agreement.

Some had their own internal software that meant they felt they had a double up of internal process to comply with. Others simply didn’t want to adjust their firewall.

Some contractors simply didn’t like it because it exposed their own contractual management misgivings. And they like the fact the variation process was a mess, it made their ability to make claims easier. I will always remember one principal client on a massive billion dollar project telling me the contractor had spent weeks putting together a multi million dollar dispute claim blaming lack of principle responses to variation change requests as a reason for cost overruns. But for him, he simply printed out the CollaborIT audit trail and took that to court. And won.

Superusers, the disciplined ones that utilized CollaborIT to its full potential were few and far between. Probably like great project directors are often few and far between.

I couldn’t convert Australians. Aconex, albeit targeting contractors moreso than developers, was making reasonable progress so there was some sort of competition. But they would of been facing the same issues above that I was. They managed to invest themselves through this and come out the other side a billion dollar company 15 years later. Face to face contact was necessary in those early days, and we needed fulltime staff on the ground to give it a good push – not just a fly-in and out guy. Still a few, mainly architects on international projects, like the World in Dubai became dedicated users. More would have come if I could have sorted the second issue out.

AND TWO. Our back-end technology was not scale-able. Now I didn’t now this at the time and until very late in the piece but going with Citrix was a mistake. And so did the backend server costs. It cost us an ongoing fortune, so the incremental margin per additional user was not that much. In retrospect we should have done a pure website based application, and offered SaS applications a side product. But because how CollaborIT was built, we had to run it through Citrix and on expensive equipment in the cloud. Nothing technically wrong with Citrix, just at the time not cost effective to run to hundreds or thousands of part-time users on a development project. The backend server and date charges, well let’s just say you could do it for one tenth of the cost today.

That extra cost meant we did not have sufficient money for more marketing, or full time staff to get Australia humming. Or to get the original investors fed. That’s what we needed to do to increase the value so we could keep a decent equity stake before taking it to America.

In New Zealand, I don’t believe spending extra on marketing or staff was an issue as I pretty much talked to every single developer, government entity and consultant out there, and simply made myself available without additional cost to anyone in New Zealand at anytime, in person. There were just not enough takers. Our conversion rate was too low. And our price structure meant it would never be a mass market product.

With enough users we would have changed the back end technology, unfortunately no one had the will or funds to redo it. Chris was gone. The technology boom had collapsed. Softbank didn’t exist to throw squillions at it. By 2003 me and Tony decided that was enough, we had given it a shot, the concept worked ok, but CollaborIT did not make enough money. The business model and our execution was flawed. There was no appetite to continue. So let’s move onto something new.

CollaborIT was transferred to its original namer. I went back to property development 101. And until this article I never really gave it that much thought or had much desire to do another dotcom.

That’s why when I read articles and success stories from those who are making it in PropTech, like these fellas, emerging from the New Zealand market and going international I know how hard it is, and how amazing they must be. A decade ago I would have been jealous. Now I am just in admiration.

Here are the only two articles I can find about CollaborIT from almost 20 years ago. About the only thing else I can find from those days is a letter from Donald Trump, whom I interviewed for CollaborIT’s blog at the time.

NZ Herald 2002

Bob Dey Report 2002

P.S.

Of course, Dotcom has turned into a proliferation of PropTech in recent years, so my interest has piqued and I have done extensive research into the ‘next big thing’. That’s how the book Destiny came about. Everything about PropTech (from the history of technology, to where it could go in the future) – related to real estate development and construction, wrapped up in a story about a developer from Chicago… If that sounds like a good read you can get a copy and take a free look at the first chapter or so here from Amazon.
https://www.amazon.com/Destiny-Future-Real-Estate-Development/dp/1095425676/

Cheers

Andrew Crosby

www.developmentprofit.com

The Developer Chronicles: Master-planned Projects

In this series, I describe master-planned projects. The discussion focuses on the difference between a one-off project and a multi-stage, multi-year planned development. I explore the factors that great development teams grapple with every day. I hope you find it of value.

AND you can also contribute to this opensource education by commenting with your own experiences, strategies, tactics and ideas here on LinkedIn. That’s where we can really embrace group network effects for continuous improvement in development management.

The DC: Master-planned Projects #8 Selling the Dream Location

There is only one word that a master-planned developer likes better than “Sold”. And that’s the three letters that one day eventuates after it:”Out”. Selling Out, with a sizable profit* of course, is the ultimate goal for any development. In a master-planned project that can be a long long time away. And there are many other differences between selling a master-planned and a one-off development.

[ *Yes you can measure your profit in social good if you are in the not-for-profit or government housing sector.]

A Different Kind of Selling

In this book I describe four levels of real estate development branding: company branding, master project/estate branding, project building/use branding and location branding. For a one-off project, with a single-use (like office premises) you may not even need to mention your company, pay lip service to the location and focus solely on the product in question. But in a master-planned project, you are likely going to have to grasp different ways of selling at all four levels.

This edition will focus on location branding.

When beginning to sell a master-planned development you might not have a lot of material to start with. Selling a location that no one can yet see takes a vision. A vision to implant your dream, of the desirability of the development you are creating, into the minds of potential buyers. The further your project lies from existing infrastructure – that is the schools, shops, parks, places of work and play, motorway exits, ferry ports, train station and everything else that makes up a neighborhood – the more expansive the vision you must present to potential buyers. If you intend to develop all that as part of your project (aka your master-planned project is essentially a new suburb) then at least you have control of delivering this vision. But if your master-planned project is merely within a new or growing suburb then the vision you present has to line up with the reality of the social and physical infrastructure that may be created under the control of others.

Regardless, more than any one-off project which can count on the infrastructure and community that already exists, you must sell the location first and foremost.*

[Yes, yes, yes, of course, there are exceptions: Pioneering product – like apartments where only townhouses have previously existed – also requires you to ‘sell the location’, for that type of product. New developments in an area experiencing (or about to) gentrification will also require you to help people understand why they should buy or lease in this downtrodden location.]

Branding the Location

Before anyone even considers the product you intend to deliver, let alone the credibility of the developer and builders behind delivery, they have to be interested in your location.

A master-planned project (consistent with the definition as I have used throughout the master-planned project series) IS a new location. And if it’s a new estate in the middle of the property desert – greenfield development, surrounded by actual greenfields – then no one knows this location even exists. Buyers won’t be searching in your location so they may never get to see the property you intend to sell. The solution is simple, you need to bring this new location to people’s attention. Sell them the dream location!

That is going to take a bit of effort and expense. Unless demand for your property product is on the parabolic upswing, where desperate buyers will sniff it out from cities away, expect to undertake a location branding and promotion exercise.

The first step of that location branding is to figure out what assets you have to promote. Borrowing from the accounting profession, the 4 line formula goes like this:

1. Take all your current location assets
2. And your current location liabilities
3. Calculate your location brand equity
4. Then, increase the location brand balance sheet by adding amenity profit

Location Assets. Why is your location the bee’s knees for your development? Is it a growth area where buyers can get in early and watch the infrastructure, as well as their real estate values, rise over time? Or are you so far away from the smog and chaos of the city? Closer than others to the ocean/river/lake/forest/mountains? Do you have views? More comfortable micro-climate? More transport options to get to the city, shopping, and employment? Or are you in the zone for a great school (that’s always a BIG asset ?

Yes, it’s not just physical assets. Include social and economic assets and contemplate with a wide brush. Perhaps the area is in part of a winning sports franchise, has lower property taxes or favorable development incentive tax policies.

Get the team to think hard enough and you will end up with a list of dozens.

Write down everything that is great about each asset. Take some pictures, video, drone captures, produce a one-page case study, hold interviews to discuss the ‘asset’ with local celebrities and business people – whatever you can think of to build up the collateral of location assets. This will be well worth the effort and is important for your marketing promotion later on. Needless to say, make sure you take your target market (the buyer’s and end-users) point of view. As a developer, you may have fallen in love with the knowledge that you have purchased a derelict timber factory and removed an eyesore from the community by flattening it to build a suburban office park. But will the tenants care?

Then prioritize the assets. That might be according to value, target market importance, wow factor, or whatever adds most benefit to your vision. The top three become instant forerunner topics for your key brand messaging when you come to promotion time.

Location Liabilities. It’s quite probable your location has some negatives. Just being in a place that’s new (or at least new for the product you want to deliver) for some will be negative. Less than desirable school zone? Surrounded by a lower socio-economic demographic than your target market? Lots of hills, and gullies, without views? Miles away from anything to do, like shopping and sports? Longest commute home into the setting sun on a one-lane crowded highway? High property taxes? Prone to flood/fire/slips? Site of a famous murder?

And again think broadly, liabilities such as restrictive laws on alcohol sales and restrictions on pets to protect native species might exist. Don’t let your buyers be the ones that alert you to their existence, without a strategy to curtail their importance.

Document the issues that these liabilities create. Being well informed and aware of the bias against your master-planned project’s location – before you go to market – gives you an opportunity to strategize how to deal with it.

Now prioritize the liability list in terms of their dream shattering potential. The top liabilities will be those most obvious and emotional. And they will be the target buyer’s key objections to your development’s location.

Calculate Location Brand Equity.

Now join the lists together. Log them in a spreadsheet, create a matrix, rank by colour – whatever works for you best to present and analyze the information. Here is a basic example.

Want to take it further? Then assign a score or a weighting to each item, even a percentage of the target market that you think will find this a deal-breaking or deal-making issue. Then calculate the total score. You might even create your own elaborate Urban Development Rating Tool. Regardless of your approach, the process in itself will help you identify where there are gaps that need to be plugged. Sometimes the asset will easily offset the liability, and other times that might be a stretch too far. For example, being close to forest walks probably will only marginally offset a long commute. But a brand new regional sized shopping mall down the road could easily trump a lack of trendy late night dining options in the area.

The combination of the assets and the liabilities is your net location brand equity. If we take my simple example above, the more dark green and the less dark red, the stronger your location brand balance sheet is.

Add Amenity Profit to the Brand Balance Sheet

Amenity is what you use to plug the gaps. Amenity is all the social, economic and physical infrastructure that adds value to your location. Adding amenity adds location brand equity.

Unless you are producing a fully gated community I am talking about public amenity. Amenity that creates the fabric of the location, as opposed to being exclusive use for one building or a row of houses. So it’s more than just part of the estate and often is external to the development. Whilst you as the developer most likely will have to pay for it, its usage or benefit will extend to the general public.

The approach to add amenity profit starts with three questions;

1. What location assets can we enhance with additional amenity? We could extend our forest walks to include a mountain bike track.
2. What location liabilities can we offset with amenities? We could negotiate with the education department to fast-track a new school. We could work with neighboring developers to complete the roading network to the freeway. And we could include some catalyst retail for a trendy restaurant operator. And by catalyst I mean help pay their rent, at least until things start pumping!
3. What new location assets will be created? Let’s add a lake. A golf course. The grandest of playgrounds. You know a neighboring developer will be creating their own trendy dining and entertainment cluster. If you want examples from the residential space, of themed amenity verging on the absurd (or maybe genius) then read about airstrips and waterskiing here or Zoo’s, Velodromes and Giving Trees here.

Some amenities to improve the location brand balance sheet will be under your full control. Whip out the credit card and start building tomorrow. But other amenities, especially the chunky transport infrastructure, will be subject to the decisions of government entities, the vagrancies of the local community and other developers.

Here’s our enhanced balance sheet updated.

Timing of Amenity. Plans change. The market tanks. Governments are kicked out. The council runs out of money. A new Mayor with an opposite agenda. The timing of new amenity and infrastructure that is provided by others is a decent risk with many master-planned projects. New amenity being delayed, completely redesigned or not eventuating at all can lay waste to your best (and horribly expensive) plans.

So the value to your location brand of new amenity and infrastructure should be discounted by both risk and time. The longer a buyer needs to wait, the less value to them. For example, a new primary/elementary school zone due to open in three years’ time does not hold much value for a family whose kids are ready to go to school next year. The proposed railway station that does not have government funds might only have a 50% probability of happening. The retail developer putting a shopping complex up next door may experience a market slowdown, delaying his plans – and shops for your buyers.

Don’t Forget the Profit. How do you know what and how much amenity to add, and when to stop? Some will be forced by regulation but there are so many assets you could deliver to improve your location.

Go and ask your sales team what amenity you should provide in to improve your locations brand. You might hear them recommending water fountains, bronze statues, a theme park, tree-lined avenues, fully mature palm trees and of course a lake with accompanying stone bridge and restored steamboat.

“Great what else” you enquire.

“Well can we pay to add another lane to the road fronting our project? That will help with the early morning congestion.”

“And an in-ground amphitheater, with olive grove and passionfruit plantation….”

Now, I’m sure this would more than likely add value, in a greenfield residential master-planned project or even a suburban office project but there is one minor problem.

Cash.

How much is it all going to cost? And am I going to get back more than I put in? That’s why I term it amenity profit.

The decision to add an amenity to strengthen your locations balance sheet is a simple algorithm:

If A > C then Y

A: Additional sales income generated because of amenity

C: Additional cost of amenity

Y: Yes, do it!

To paraphrase: in total, will people pay more for your real estate product because of additional amenity than the cost of providing that amenity. Easy.

Well, maybe not so easy. Calculating the cost is not difficult but trying to scientifically extract the incremental value add from a piece of amenity – isolated from all the other variables that affect real estate pricing, aka the market – well, good luck with that.

“So Ms sales consultant can I get 15,000 per house lot extra because there will be a lake down the road?”

“Mr leasing agent, will I get an extra $100 per square meter in rental because we have included ‘Japanese contemplation gardens’ around the base of each building?”

There is a lot of subjectivity involved. And a lot of developers’ artistic opinion. Any assessment of discretionary amenity (the infrastructure you choose to add, not obliged to because of planning regulations) must relate to the target market. Simplistically: the more affluent your target and the weaker the existing location brand balance sheet the more amenity assets you need to add. In low-cost affordable housing schemes, often irrespective of how little location brand equity you have, you just cannot afford to add many amenities. Sometimes when one comes to deliver all the amenity in the developer’s vision, it’s not a matter of delivering the dream, but that the developer is dreaming!

Mostly it comes down to what competition locations provide at similar price points plus your pioneering spirit and the corresponding depth of marketing budget. For example, 90% of the 50 top-selling master-planned communities in the United States in 2019 included a significant water amenity. Something serious to consider then, and probably enough data to approximate the lot premium achieved by providing this amenity to see if your target market pricing can justify it. But what about the amenity profit of ‘The Incline’ a 200-step outdoor staircase at the Meadows in Denver? or a BMX track?

A special note on cost. The design and construction cost of an amenity is only one component. If the amenity is on your project site, you have to account for the loss of Net Developable Area that is consumed. The profit generated by 50 more houses might be higher than the total premium achieved by taking out a hectare to build a lazy river!

And the time it takes to negotiate and gain consent from neighbors and the authorities, may also be a cost your project cannot bear.

Location Promotion

Then go forth and promote your location.

Promote all the existing assets focusing on the significant most valuable ones – the biggest drawcards to your location. Also, use those that are most interesting or unique which could lead to a great story in a marketing campaign and sales communications. For example, the site used to be an air-force fighter jet training base during WWII, or the famous poet used to live on a farm here. Once again, the angle has to have some buyer appeal.

Have the answers ready for the inevitable objections to your location. Do this for every existing liability and issue that has the potential to negatively influence a buyer’s decision.

• How can you turn a liability into a positive? A ‘cold and damp gully’, becomes a ‘wonderful shelter from the prevailing winds’. Or, a ‘lowly rated school zone’ becomes a ‘The high school has improved students grades for 6 years running now’.
• Maybe it’s best to ignore and don’t bring it up, except in the normal process of sales disclosure. For example, if the location was previously an old trash tip or had high concentrations of asbestos in the ground (now remediated of course).
• Can you deescalate its importance? “Look whilst there is no train station close by, the bus network is fantastic”. “Everyone who already lives around here loves the dining experience over there and Ubers back, no hassle, for less than $20.”

Promoting future amenity and infrastructure that is still a glint in an urban planner’s eye come requires stronger consideration. In the ideal world it all happens, on cue, and your sales team can set firm expectations in the minds of buyers – the dream you sell will become reality. However, when the provision of new amenity assets is in the hands of others, or the market changes dramatically so your pricing can no longer generate amenity profit (happens all the time, especially on master-planned projects that are not backed by deep pockets) the promised asset may be delayed or even terminated. So promotion of an amenity should not infer a promise unless you are certain.

As to the detail of how to promote, that’s too broad for this article and I won’t steal any real estate development marketers thunder just yet except to say the worse your brand balance sheet the more you are probably going to have to spend to generate interest. And in 2020 if you are a residential project, that could still mean old-school mass media like Television, radio, printed newspapers and billboards. As well as PR around open days, mayoral cutting the tape or someone semi-famous digging into the ground with a gold-painted shovel.

When to Promote

One strategy where you are creating a new project in the proverbial no-mans-land is to start promoting the location brand before you have product to sell. That could give you a head start in the market. Your promotion could frame it as the up and coming new location, and ‘watch this space’. Or you may wait to start promoting until some of your amenity profit is created – like a golf course or catalyst retail. Then potential buyers can experience tangible improvement in the locations balance sheet.

Where cashflow and budgets limit substantial investment prior to receiving income then you may be forced to launch location brand promotion concurrently with the real estate products you are selling.

Revisit the Location Brand Balance Sheet.

Your location brand balance sheet changes over time. You are adding assets. New liabilities arise. Others complete infrastructure projects. So updating the brand balance sheet, say annually, can generate good information to drive your marketing strategy and promotional activities for the following year.

Eventually, and likely well before you sell out you may no longer have to promote your location. Because you are now a known location and all the asset improvements have been delivered. Excessively promoting something everybody already knows is going to have diminishing returns. At that point in time, your master-planned project is just an existing part of its greater locations fabric. But don’t stop promoting your project!

A Note on Company Branding

Is the company brand so strong that location branding is somewhat superseded? This is when people buy on the strength of your company. Unlike most products though, real estate is firmly tied to the ground it sits on. So there are few circumstances where company branding will trump poor location equity. But once your location balance sheet is improved, if you are a well known and trusted quality deliverer of the product you promise, company branding can be a powerful stimulant to attract buyers and separate you from the competition.

And a Note on Estate Branding

In the largest greenfield master-planned projects – think new suburbs or an entire new town – location branding and estate branding are effectively one and the same. Therefore, a significant component of estate branding is the location branding we have already described. For smaller master-planned projects, now that you have burned the location into the hearts and minds of your buyer pool, you still need to convince them why your project is the place to buy or tenant.

In the next edition, we will discuss further differences in sales and marketing strategies for a master-planned project.

Cheers

Andrew Crosby

The DC: Master-planned Projects – All published editions.

#1 Roads
#2 Net Developable Area
#3 Feasibilities
#4 Stages
#5 Team Collaboration
#6 Architectural Design
#7 Scale Thinking
#8 Selling the Dream Location

P.S.

Now in this blurred world of social media versus professional media, my opinion versus my employer(s), salary versus side-hustle, middle of the business day versus 11pm on a Sunday evening, it can all get a bit confusing. So, here is my value proposition, and both complement and benefit each other.

• If you have a development site that you would like to sell some or all of, to develop yourselves, or to build houses then Universal Homes www.universal.co.nz might be able to help. We focus on delivering value-for-money homes in the ‘relatively affordable’ range, like the 1300 home westhills.co.nz or the 600 plus homes we have built at Hobsonville Point, or the thousands of others around Auckland over the last 60 years. Message me on LinkedIn at any time
  linkedin.com/in/ajcrosby .
• If you want to learn more about real estate / property development and a continuous improvement approach, with books and courses in development management to maximize profit and decrease risk then visit www.developmentprofit.com

The Developer Chronicles: Master-planned Projects

In this series, I describe master-planned projects. The discussion focuses on the difference between a one-off project and a multi-stage, multi-year planned development. I explore the factors that great development teams grapple with every day. I hope you find it of value.

AND you can also contribute to this opensource education by commenting with your own experiences, strategies, tactics and ideas here on LinkedIn. That’s where we can really embrace group network effects for continuous improvement in development management.

Master-planned Projects #7 Scale Thinking

We touched on the concept of scale thinking last time in relation to design. Most people would think about the opportunities that scale provides, but there are also the negatives, like ‘at scale complacency’ in design.

To start, we’ll deconstruct the meaning of scale. If we assume a master-planned project is bigger and takes longer than a one-off project [according to my definition] then a master-planned project IS an at-scale project.

At scale means more than being physically big. Size is relative anyway. One hectare in Manhatten might represent 10 buildings to be constructed over ten years. That’s a big master-planned project. Whereas one hundred hectares in Montana might just mean 10 lifestyle ranches, a relatively small project. It’s all about the dimension of scale that you are referring to.

Scale Dimensions

No not the ones on a ruler! There are different dimensions to scale when you delve deep into a master-planned development. Often interrelated and all relative:

• Size. If one hectare is a decent sized townhouse project, then one hundred hectares of townhomes is definitely at scale.
• Price. A one billion dollar office park is scale compared with a twenty million dollar office building.
• Unit Volume. One thousand single-family homes is scale compared to fifty.
• Time. A project expected to take a decade is scale compared to one finishing in two years.
• Repetition. Three hundred custom doors is not scale compared to 3,000 of the exact same door. Similarly, one floor-plan replicated 300 times enables ‘scale’ more than thirty customizable plans replicated 10 times each.
• Consistency. Ten industrial warehouses a year, every year for twenty years can be considered at scale compared to 3 warehouses this year, twenty next and 2 the following. One house completed every 5 days, could be considered scale versus 100 houses completed in 12 months and nothing for the next six months.
• Certainty. If we know we are going to ‘win’ 10 tenders a year for an average of 50 social housing units each, is scale, versus having no idea if we are going to win five tenders or thirty in the coming year. Pipeline forecasts to demonstrate certainty of scale are often used by governments with the intention of gearing up public infrastructure industries.

Working the Benefits of Scale

So, what are the opportunities that scale presents?

Well, one of the most obvious would appear to be cost savings through bulk purchases. If you buy one widget at a unit price of $10, buying one-thousand might only be $7 per unit. That’s because the manufacturer has managed to cut incremental production costs, and charge you less and still produce the same margin. Because you are ordering at volume, they might even sacrifice a little per unit margin, because the absolute margin is so much bigger. Economies of scale they call it. Wikipedia describes it this way:

“economies of scale are the cost advantages that enterprises obtain due to their scale of operation (typically measured by the amount of output produced), with cost per unit of output decreasing with increasing scale.”

Take this example. You are developing a master-planned light industrial estate, including all the buildings. To spruce up the monotony of it all the draughtsman has gone all artsy placing a fancy art -deco style pattern set into one of the precast concrete panels on one wall of a building. No one pays any attention until the precast panel price comes back months later. That single wall is double the unit price the quantity surveyor had estimated.

“Why is this,” the QS frustratedly asks the pre-cast supplier manager.

“Well to do that one-off design we have to create a special mold. That will cost us about ten grand to sort out. Every other panel goes through the standard template. So whilst we can deliver 100 standard panels at $10,000 each – a clean $1million- this special panel alone is going to cost you double the rate at $20,000.”

“And if we go all Frank Lloyd Wright and imprint the design on every panel, what will 100 of them cost me,” the QS curiously asks.

“One million and ten thousand dollars. Because we are now replicating the same design, from the same mold at scale, Ms. Client QS.”

The QS ponders her companies business plan for the next five years on this master-planned project, before asking, “OK you priced me for 100 panels. But, what if I place a larger order for 2,000 panels, with 200 to be delivered on the first of March every year?”

After running the numbers the precast supplier manager calls the QS back, “If you agree to pay first-year price plus CPI inflation in subsequent years, we can pre-order concrete and materials, as well as lock in our delivery suppliers. That will get the first-year price down to $8,000 per unit.”

That’s scale (according to almost all of the dimensions we describe above) working for everyone.

In property development, cost savings and efficiencies enabled by scale can flow into different areas up and down the production chain. For example:

Design. One house that is to be exactly replicated 100 times in a subdivision only needs to be designed once. That’s one architectural and engineering fee. It also means a cost-estimator only has to calculate the quantities once. It means pre-nail truss and wall providers, or steel wall fabricators only have to create one set of shop drawings. Similarly, one kitchen design and shop drawing, one electrical layout, one plumbing layout. One set of specifications.

Consenting/Permitting. In some jurisdictions, you can get ‘blanket’ consents for a house plan type. With that consent in place, each time you have a new house to be approved you only have to advise the variations to what has been consented. This can reduce building permit costs and the time it takes to obtain official approval. Consider an arrangement where you get a building permit for a blanket range of details and so long as your consent application only includes those details, you will be granted approval. One builder had an ingenious way of getting this scale-flexibility permitted. He had designed and approved one of the most ridiculous houses ever. Each external wall, floor, and roof junction had different materials. Think brick wall with an aluminum window meets weatherboard wall and a steel roof on one top corner and Cedar siding with a wooden window, meets weatherboard wall meets steel roof meets shingle roof on the next corner! With the improbable house consented, only details in new houses that were not in that original consent needed further approval.

Financial Feasibilities. We discussed feasibilities here but one thing we didn’t touch on is how scale can be your friend when undertaking feasibilities. If you have twenty identical suburban office buildings, indistinguishable in location, then conceptually you have one feasibility replicated twenty times – barring some time-based assumptions over sale, cost and yield ‘flation’ (in or de). That is more efficient than doing 20 different individual feasibilities.

Further, for any building and/or super-lot it’s not like you just get the architect to draw up a bulk and location plan and do one feasibility. It’s going to take a bit of back and forth to get the most profitable (or at least fundable) scheme. It might take you a dozen times (if you are truly persistent to secure as much profit as possible). A dozen multiplied by twenty is a lot of bulk and location plans and feasibilities!

Partnerships. A large long-term master-planned project opens up long-term partnership opportunities. Who doesn’t like to secure work for many years? With a bit of foresight and a little more work upfront this can make your project procurement and management processes much more efficient.

Let’s take procuring a civil contractor, in a one-off project, like a subdivision of 100 houses. Typically you create a tender package (drawings, schedule of quantities, specifications) of all the works and send it out to two or three interested companies, that you have identified via consultants, your network, google or if you are lucky past pleasant experience. Then, with a few questions bouncing back and forth, you wait six weeks to get the prices back and work to clarify (‘negotiate’) with each tenderer. Eventually, you select one company for the business end of the negotiations. However, negotiation only gets you so far so you call the design team back to value-engineer for the contractor to find some savings. Finally, with a price you can live with, and your funders and/or investors agree to, you can sign them up. The next project comes along and you repeat the process all over again.

In a master-planned project, if you spend time to make sure your civil contractor has the experience and financial fortitude to handle the longterm commitment, once the first tender is in place and you have confidence in their delivery, you can effectively form a partnership. For future stages of work rather than re-tender work to multiple parties, you work together to keep rates down and the incumbent gets the job. To some, this may seem counter-intuitive – won’t the contractor simply add cost because the job is already in the hand? Well no, that’s not a partnership. A partnership is where both parties collaborate (remember this) for mutual benefit. The civil contractor doesn’t have to close up shop and start somewhere new, with a new unknown client. The developer doesn’t have to risk a tender situation where everyone’s rates have gone up because of demand in the marketplace or worse the industry is so busy no one else has the capacity. Of course, a regular stream of work (and prompt payment) is important to keep this partnership together.

The same approach can be taken with consultants, builders and suppliers. A master-planned project provides the opportunity to grow supporting businesses along the way. In theory the more dependent the partner on the developer’s project arguably the leverage the developer has over that partner. But in practice, a couple of things counteract this. One, often on the back of a successful multi-stage project, the partner’s business also expands elsewhere, sometimes becoming bigger than the project and less reliant on it. Two, overtime the developer gets lulled into the ease of dealing with the same partners and the partners, perhaps unconsciously, allow fee creep to manifest.

Insourcing. This can take a whole edition of the Developer’s Chronicles on its own, but if you want to know more about the pros and cons of insourcing versus outsourcing now then I devote some time to it here. In short, with a project large enough, you might find it more beneficially (both for control and profitability) to internalize many of the project team. That can help team collaboration and streamline delivery. Of course, then you have to create a management structure, complete with HR and IT, office space and all the foibles of employer-employee relations.

A middle-ground position, often sat up for large infrastructure projects, is to rent office space, hire admin and create a place for the team to (co)operate. Rather than employees of the principal, the team member is seconded (se-con-ded) full-time from their respective organization to work for the project. All normal employer-employee relationships are maintained for each person in the team. The difficulty is that over time, it gets cloudy who is a client and who is one’s boss.

Flexibility. Scale provides ample opportunity to be flexible. If your master-planned project suits a range of product types (retail versus residential, high density versus low density etc.) you can adjust your delivery to focus on the most profitable. You can also test products, perhaps via a presale strategy in some areas of the development whilst delivering in others. It could be that you completely reconfigure the output of your site to match the best market at the time.

Having a flexible strategy (and ideally funders and investors) that embrace what the market ‘could’ throw at you is important in all but the most plain-vanilla master-planned projects.

Kicking the Can. With a flexible sizeable master-planned project comes the chance to kick less profitable products down the road (often literally). This might be a valid strategy. If you believe in property cycles, that what is down today, is sure to rise back up tomorrow then there is no point persisting with a low margin endeavor when you can wait that out and concentrate on something else more profitable.

It might not be a choice. External variables like city officials changing their minds over infrastructure investment may force you to delay project delivery. Take for example the situation when the city had agreed to upgrade a $10m intersection, critical to enabling your development’s traffic flows, but now has determined it doesn’t have the budget for another three years. On a one-off shorter-term project, such a delay can be crippling. You may have to stall the project. But on a scale master-planned project you kick that can down the road and change direction for three years to focus on other areas that are not affected.

Kaizen. Constant improvement. One-off projects, especially boutique ones take time and effort. Being one-off means the project is unique with a lot to accomplish to get it right. But there is only so far you can go before you run out of time. So you typically just manage to get it ‘right-enough’.

However, a master-planned project that embodies scale can dramatically increase your resource capacity per unit. For example, let’s assume that on a one-off building of 200 condominiums your project team has 1,000 person-hours to spend on above-ground ‘thinking’ or 5 hours per unit. Most of that time will be addressing everything that is done to get the plans and specifications ‘right enough’. Say 4 hours per unit, 800 hours in total. Leaving 200 hours for improvement.

Now consider a master-planned project where you have ten of the exact same 200 unit condominium buildings. All-else being equal you now have 10,000 person-hours to spend. The team spends the same 800 hours sorting out the ‘right-enough’ matter but now find themselves with 9200 hours for improvement. That’s a whopping 46 times the poor developer with the one-off project. Gosh halve it and halve it again and you still have ten times as much time resource to look for improvements. A wise master-planned project manager uses that time to constantly improve and refine.

With more time you can dig deeper. Whereas on the one-off project you might have had time to evaluate concrete framing versus steel framing, on the scale development you can also dig into the cost benefits of laminated timber or modular methodologies. Where you almost ran out of time analyzing the difference between poured in place versus precast shear walls on a one-off project, now you have time to scrutinize twenty different suppliers of the reinforcing mesh within that concrete mix.

With enough scale, you might have the time to improve every single nail and screw that goes into the project.

Scale working against you.

Of course, economists like theoretical worlds where supply and demand produce expected outputs and external variables don’t get in the way. If there is one thing any seasoned developer knows, project success (or lack of) is all about external variables. And it’s more about your luck in what external variables are thrown at you than your ability to control them! With scale, your risk exposure is, well, exposed. Let’s look at the flip side of scale projects:

Land. One thousand homes, exactly the same – sounds like an architect’s nightmare and a builders dream doesn’t it? Whilst it is all very well and good to have standard house plans that are replicated, there is one little thing that gets in the way. This makes property development different from any other industry where mass production is available. And it is an important matter that many who proclaim offsite construction as the future fail to acknowledge. Every piece of land a house sits on is unique.

There are two facets to land that make every single parcel unique: location (via its legal boundaries), and its physical nature. Every single piece of land, the most important ‘component’ of a building is different. It could be shape, size, topography, soil bearing capacity, or a hundred other things. Every building that goes on land requires at least some customization. It might simply be mirroring the floor plan (and services, and foundations) to allow for solar access. Or it could require independently designed foundations specific to the ground conditions below. And depending on the cost of that, the building above may have to be built out of completely different materials. There goes some of your ability to leverage scale.

Resource constraints. Resources can be constrained when either the scale of your project is much bigger than anything else in the area, or when the industry itself is constrained. If you are about to develop 500 houses annually in a town that has never before built more than 300 houses in total in any given year, then the operators in that town may not be able to handle your scale. Likewise, if you are the first apartment tower in a city that has never built above three levels before, there may be no local operators able to service your supply chain. It doesn’t mean you can’t overcome this obstacle but it does add complexity to your project, Local developers with smaller projects may not have this complication.

As another example, take our precast concrete panel supplier from earlier. We have done a deal where we take 200 panels a year. It’s at a great price. All about scale. 100ha next door has just come up for sale, so naturally, we acquire it and our master-planned project has now doubled in size. With that, we decide to double our build volume and request 400 panels a year, every year for the next five.

“That will be $12,000 a unit.”

“What? Why has the price gone up?” the QS responds perplexed.

“Well, our factory’s capacity is only 300 per year. At 400 you absorb all our available space and we will need to buy and fit out another factory. The cost of that has to be passed on I’m afraid.”

This happens all the time in property development. Subcontractors, main contractors, consultants, council permitting offices, everyone in boom times experience capacity constraints. They simply can’t do any more work – at least at a price that makes it economical for the developer. It also happens when a market starts to turn for the better before the construciton industry has had a chance to gear up. That’s because resource constraints typically move in tandem with real estate market cycles. A scale project may prove difficult to scale-up-to.

Cycles. Supply is inelastic to demand in property development. Real estate is chunky. Take the residential real estate market. The market is dead, nothing is selling. Few houses are being built. Then it shows signs of life. Houses start to sell. Sales increase, listings increase – now that vendors can finally sell. Prices rise. Developers start to get interested. Price rises accelerate. Developers buy land and start building. But the problem is there are few builders around. Construction costs go up. Everyone from consultants to suppliers ramps up their prices in many multiples of the general economy’s inflation. As build margins start to increase, more builders magically appear (many who have been hibernating in recession land since the last boom plus foreigners ready to capitalize). Prices are still going up so developers build as fast as possible. Eventually, construction cost escalation kills affordability. Price rises stop and may even retreat. Developers first refocus on lower priced product but eventually can’t eek out a margin anywhere. Then a double whammy occurs, migration or immigration reverses, the economy tanks and the housing market stops dead in its tracks. Once again few houses are being built. [Sound familiar to anyone?]

With this type of boom-bust market – typical of real estate in western growth cities for centuries – scale is both your friend and your foe. If you buy in the depression, and start building just as things start to pick up your margins could be on a one-way trajectory towards the treetops. But if you buy at the peak and start building as the depression is gaining downwards momentum, your margin and your massive master-planned project might grind to a halt. Then you have a painful wait (especially painful depending on your exposure to debt) until the market rebounds.

Political cycles can also influence scale projects. Carrying a large project – especially one with vested public interest – throughout successive local, state or national governments encourages all sorts of risk to materialize. For example:

• Local government can increase their development levies in tune with tax policy and public opinion – pro rates payer and your charges go up, pro-development and they come down.
• The planning and building codes can change. Whilst you may have locked in your planning at the outset, typically you can’t lock in building code regulations until you actually are ready to build. Even with planning locked, the detail rules can change, and that might effectively make as much difference anyway.
• If your master-planned development involves any public-private partnerships like social housing, developing a school or creating wider area public infrastructure – then what the original political entity agreed to may not survive an election.

Funding. A master-planned project is bigger and is going to take longer than a one-off project. That means you need more money, for longer. More money might necessitate more than one money source. It could mean a consortium of banks and/or bigger banks. It might mean joint venture partners or multiple direct investors. You may have to start out without having the funding allocated to finish the project (never a terribly great idea). And you could be faced with changing (or topping up) financiers along the way. It all points to more paperwork, reporting, and equity-debt restructuring. It also means reporting to more sophisticated organizations, some of whom may not share the same risk-acceptance-profile that developers are accustom to. This can make funding all the more complex than a one-off project.

Front-loading Costs. A master-planned project by definition occupies a more expensive and/or larger piece of dirt. You have to pay for that – typically upfront. For the master-planned project that has grown out of strategic land banking (for example when farmland on the outskirts of a city is purchased, anticipating urban growth that eventually causes the rural-urban boundary to move, upzoning your site) your purchase costs may have been very low. Lucky (and patient) you! But for the rest, purchasing a scale project site is going to burn a few pretty pennies. And that incurs finance or opportunity costs from day one. A cost that can run for many years.

When developing a site of any significant size, it is likely you are going to have to pay for new public infrastructure and/or upgrading existing infrastructure – especially roads on greenfield sites. This can be required well in advance of completing sellable space. So you will need deep pockets to cashflow it.

Even if you don’t have to build infrastructure, from a marketing and sales point of view you might want to. A tree-lined avenue and a picturesque park complete with lakes and playgrounds might be the kickstart that your master-planned project needs to get sales. Once again, a lot of cash being spent upfront, well in advance of seeing the return.

Size. Bigger is better some would say. But not always. One of the problems with large-master planned projects is that they are simply so big. Amplification can hurt. When things are going well and sales prices for 3,000 homes increase 5% per annum your profits are going to soar. But if it goes the other way, you might be quickly underwater. This is no different with any property development project. But because you are more than likely to have funders from larger public organizations, they (or their shareholders) may be less willing or able to see it through to better times.

Another negative is when the size of your master-planned project dwarfs other projects in your area. Effectively you have all your eggs in one basket. Comparatively smaller competitors may be able to eat away at your market share by developing sites that don’t have the infrastructure implications that your site creates. Scale does not always mean you can deliver product cheaper.

Time. Whilst ‘time heals many wounds in real estate’, the contradiction is ‘the longer it takes, the more that can go wrong’. A worthy property development business model to reduce risk is to get in and out of the project in the same market. That’s pretty much impossible for anyone to time, but the probability of timing it correctly is higher for a one-off project with a short duration (Note: I don’t have maths to back this assertion up but it certainly feels right!). If your project is going to take time, and by my definition a master-planned project does, then it is going to experience different markets. Ideally, you start delivering into a hot and rising market, so the excess profits you initially generate set you up to weather any subsequent downturn.

Too Big Too Soon. Scale is great if you can handle it. Deep pockets, lots of capacity to create & manage resource and bigger picture flexible operational decision making is mandatory. Unfortunately, if you don’t have those three ingredients you are quite prone to what Ian Cassels, a developer in Wellington, New Zealand surmises.

“We’ve all heard it before from Sir Robert Jones: “all developers go bust”. I know I have heard it many times. I have my own version of this which is “if development for sale is your business then you’re likely to go bust”. – If more famous quotes about real estate development are your thing then read this!

And many of those who go bust do so because they have gone too big too soon. A couple of single-family home renovations turns into a terrace home subdivision. One project becomes five. And then in no-time, the billion-dollar deal of the century is stitched together, with bankers who have previously expanded their wallets and risk appetite on the developer’s coat-tails. Problem is, the project needs all three secret ingredients, well at least enough of the first one. Few developers on the fast-track without cashflow to see out a downturn (and the mounting debt) transition well.

At Scale Complacency. Earlier we discussed the potential for at-scale-complacency in design. This malady of magnitude can permeate through planning, feasibilities, construction, sales and all things quality control. Thus, just because it’s big, doesnt mean everyone can forget about the detail. One little issue, lots of times, can end up being a big collective issue. Or skimping over the occasional detail can add up to a sizeable lost opportunity.

Butterfly Effect. A decision made early on a one-off project could have ramifications but because of its limited time span and size, the damage will be contained (relatively speaking). In a large scale master-planned project a similar decision early on could, over years or decades, ripple creating unexpected and significant consequences. With all that traffic, bet you wish you didn’t put that through road there now? Or why did we lessen our design standards so early on, now we can’t capitalize on the profit potential of higher value product? Who would have thought tenants would demand that feature when we committed to this? And so on. Of course, this is a problem without a readily apparent solution. Suffice to say it pays to think thrice about the implications of the decisions you are making today and how they could impact overall project profitability and success.

Getting Kicked in the Can. Whilst having the luxury of kicking the can down the road is appealing early on, someone has to pay the piper eventually. And time may have not been the original problems friend. Because problems in property development never seem to fix themselves, maybe addressing issues head-on when the surface is the best strategy.

And that will do us until the next edition.

Cheers

Andrew CrosbyR

The DC: Master-planned Projects – All published editions.

#1 Roads
#2 Net Developable Area
#3 Feasibilities
#4 Stages
#5 Team Collaboration
#6 Architectural Design
#7 Scale Thinking
#8 Selling the Dream Location

P.S.

Now in this blurred world of social media versus professional media, my opinion versus my employer(s), salary versus side-hustle, middle of the business day versus 11pm on a Sunday evening, it can all get a bit confusing. So, here is my value proposition, and both complement and benefit each other.

• If you have a development site that you would like to sell some or all of, to develop yourselves, or to build houses then Universal Homes www.universal.co.nz might be able to help. We focus on delivering value-for-money homes in the ‘relatively affordable’ range, like the 1300 home westhills.co.nz or the 600 plus homes we have built at Hobsonville Point, or the thousands of others around Auckland over the last 60 years. Message me on LinkedIn at any time
  linkedin.com/in/ajcrosby .
• If you want to learn more about real estate / property development and a continuous improvement approach, with books and courses in development management to maximize profit and decrease risk then visit www.developmentprofit.com

The Developer Chronicles: Master-planned Projects

In this series, I describe master-planned projects. The discussion focuses on the difference between a one-off project and a multi-stage, multi-year planned development. I explore the factors that great development teams grapple with every day. I hope you find it of value.

AND you can also contribute to this opensource education by commenting with your own experiences, strategies, tactics and ideas here on LinkedIn. That’s where we can really embrace group network effects for continuous improvement in development management.

The DC: Master-planned Projects #6 Architectural Design

Like any one-off project, for a master-planned project, you have to come up with architectural design. A site plan, building floor plans and some elevations. One key difference with a master-planned project is there are multiple layers of design.

Urban Design

First, and most different from a one-off project, you have the overarching layer of urban design. This is (or some say informs) the general layout of your site, all its key amenity, roads (we looked at roads in detail here), geographical constraints and the stages and/or super-lots within.

All developments have some aspect of urban design. Building design and urban design often morph into a grey zone, where both building architects and urban designers claim it’s their space. Where on the site do you place a condo tower? How does it interact with the public-facing street? What connectivity to the neighboring streets does it enable? And so on. But with a master-planned project, by virtue of nothing else but its size, duration and having to build transport corridors, we are designing a completely new urban environment.

There is a tonne of definitions out there. The Urban Design Group in the UK have summarized plenty here. I quite like the following two as they cover both space and time in the context of a development project.

“Urban design involves the [spatial] design of buildings, groups of buildings, spaces and landscapes, and the establishment of frameworks and processes that facilitate successful development.” – UDGUK

“The process of molding the form of the city through time” – Peter Webber

At the end of the day, regardless of how theoretical we muse, urban design produces a number of practical outputs. The big one is the master-plan or master-site-plan. This is the picture of where all the roads, lakes, parks, shops, offices, homes, warehouses or factories are located. To get there might have been quite a process, and like Mr Webber above describes, it can change over time. Something a bit more detailed than the high level one we discussed here.

The more diverse your master-planned project, they more complications urban design must embrace. Flat is easy. Hilly gets difficult. 1,000 standalone replica 200m2 houses on 400m2 lots on the same road grid, surrounded by clones where sales agents can’t even touch the sides of demand is easy. 700 houses comprising of seventy-eight different floor plans across a range of lot sizes with a town center, a small industrial park, and all next to an existing airport on a peninsula in a soft housing market is not so easy.

One way urban strategists in the project team approach creating the master-site-plan is to break each ‘complication’ into an overlay. The objective of each overlay is to create the best response to that complication. Then you lay them on top of each other. In the perfect world they all line up and then you can start drawing your response – the master-site-plan. Of course, they rarely do and compromises need to be made. That’s where the priority comes into play.

What’s the biggest priority? Profitability – certainly if you are a private or corporate developer. So one of your overlays – the most important obviously – is financial. Obvious to developers and bankers at least. Unfortunately, urban designers are typically architects and profitability might not be always so obvious to them. Master-plans can be heavily influenced, if not dictated by infrastructure, geo-technics and traffic – again profitability might not be so obvious to the engineers either. So the urban design process needs a financial overlay. That means your financial feasibility (as we talked about a few editions ago) is an integral part of the urban design process. As your designer starts drawing site responses to complications, the development manager/ feasibility manager needs to fire the feaso up. You can’t simply leave the urban design to the designers!

You have to start somewhere though, and there is a short-cut that gives the urban designer somewhat of guiding spatial light as to what could constitute maximum profit: maximum density. Thus zoning is an important overlay. In many rising real estate markets, especially over the long term maximizing the allowable Net Developable Area, and then the Gross Floor Area on top of that will be a good proxy for maximizing profitability. If your site already has zoning determined, then much of your urban design framework may be set in stone. Retail here, commercial there, residential elsewhere. If you are starting with the purest of greenfield sites and have the flexibility (and deep pockets) to create your own zoning then each other overlay becomes that much more important.

Let’s look at some other overlays:

• Transport links. Rail stations, freeway access, arterial roads, bus-stops, ferries, and other big-ticket transport connections. This overlay will certainly influence where you place retail and commercial activities. Housing not too close, but not too far (unless lifestyle or rural blocks are your taste). Higher density at the nodes, lower away.
• Topography and physical geography. Hills and valleys. Flat, rolling or sheer cliffs. Streams, rivers, lakes, the coast, and native forests. Some natural features present opportunities and others constraints.
• Sunlight. North-facing or south-facing slopes. Shadow lines from hills, trees or any buildings across the boundary.
• Amenities. Proximity to town centers, places of recreation, schools, medical facilities, beaches, centers of employment, tourism and industry.
• Infrastructure. Where the ‘big’ pipes have to go. What areas can be serviced, which can’t? Powerlines in the way?
• Views, outlook, privacy, quiet, areas where you can enhance profitability, by charging higher rent or sales prices.
• Geo-technical. Soil type, overland flow paths, flood-prone, flood management areas. Yes, you can build on anything, just depends on the expense to do it.

Like almost everything in real estate development, nothing is crystal clear and many overlays influence each other. Where the relationships are not clear, break them down into the simplest layer possible. For example, break topography and physical geography down to buildable areas and non-buildable areas. Or school zones might be deserving of its own overlay.

And you will note that when you look to stage a development, many of the same influences crop up. The urban design will evolve over time. As each stage proceeds, you might be reevaluating urban design for the next stage. This is where Peter Webber’s quote above comes into play.

It’s an iterative process of working through each overlay and its relative priority to maximize opportunities and minimize negative effects of constraints. This alongside constantly analyzing the income potential and the cost ramifications to help prioritize.

With the overlays in place the urban designer can draw a first-cut of the master-site-plan. Then the team must refine, and refine and refine and refine…..fully aware that as time goes on, what you are refining now might not come to be. Refinement never sleeps in a master-planned project.

Superlot Design

Super-lot design is the next layer. A super-lot is defined as a contiguous piece of land within public roads. You can sell it on its own, or you can subdivide further into individual plots for houses, a block of shops, an apartment tower or a logistics facility. Regardless you need to have an idea of the types of buildings -almost always the highest and best use of that super-lot – that will occupy it.

Roads (as we discuss here) have a big part to play determining a super-lot’s external boundaries. But now we must think about the specific buildings and sellable parcels of land within. A single super-lot might be so complicated to require specific urban design all on its own. This is especially so if you are mixing uses in the same super-lot. You may need to apply an overlay approach to the design within the super-lot.

With that in mind now you can design the most efficient, most profitable super-block. And once again, get your calculator out. Crunch the super-lot’s own feasibility as the architects put forward design options.

Additional considerations for super-lot design:

• Sellable land efficiency. Are we allowing for the most efficient and sellable lot sizes and layout?
• Flexibility. Somewhat contradictory to the previous item, does your super-lot allow different types and shapes of plots and buildings that could adapt as markets change over time?
• Is the super-lot efficient and flexible in terms of infrastructure? The cheapest approach will be to provide as many individualized service connections (think driveways, wastewater, stormwater, power & utilities) at the same time as you construct the super-lot. However, this may preclude flexibility (at least at a cost) within the super-lot later on.
• Streets. Roads that surround the super-lot contain elements that cannot be adjusted very easily – and when publicly owned, moving anything might prove next to impossible. Streets can constrict the design within the super-lot, despite how much future-proofing you are trying to cultivate. Street trees, parking bays, rain-gardens, utility ‘boxes’ (like power transformers & sewage pump stations), power lines, street lighting, leased billboards, cellphone towers and bus-stops to name but a few.

Building Design

The stuff that everyone really looks at: the vertical build. What can be different between a one-off project and a master-planned project? That depends on how as a development company we are structured to deliver:

1. Land subdivider. We are creating the urban framework and developing all the land, but we intend to sell all parcels/super-lots off and let others build at their discretion.
2. Land to letterbox. We are developing, designing, building and selling everything.
3. Bit of both.

Whichever development approach, a master-planned project requires additional thinking that a one-off project is rarely concerned with. If you intend to sell land to others, building design is all about control. Controlling the branding, the look and feel, the quality and most importantly the master-planned project’s long-term profitability. If you have rezoned the entire estate then that is one control. Albeit, that might be limited to density and bulk and location restrictions. The other often used control is to create and enforce design guidelines.

Design Guidelines

Design guidelines can be legally attached to the titles as covenants and/or stipulated as part of the sale and purchase contract and/or included in the rules enforced by an incorporated society representing owners in the master-planned estate. Tieing the guidelines to current and future owners is important – so the rules run with the land. This often means that design conditions in the sale and purchase agreement are not legally sufficient to protect the developer from a subsequent future transfer of ownership.

What’s in these design guidelines?

It’s your project so pretty much anything that doesn’t contravene the law! I recall one subdivision in Phoenix tried to ban people flying the American flag – that didn’t go down to well, with pretty much everybody except the committee who dreamt up the idea. However, in the context of a master-planned project, design guidelines are more than just resident restrictions. Rules like no parking on the lawn, don’t put washing drying over the front balcony or limiting dogs to less than 50cm long. All the impediments to daily life. Saying that though, design guidelines and resident rules do overlap. No tarpaulin (poor man’s sailcloth) over your pergola – is a rule (yes a real one put in place by a least one government housing provider) to protect neighbors from the unruly design-inconsiderate antics of those living next door.

We’ll start with the objective of having design guidelines. And if we strip it back to its core, it’s fairly simple: design guidelines are to protect the master-planned project’s developer’s profit. You can spin this a different way of course and say “design guidelines protect the home buyers investment” or are the “design guidelines enforce quality and reputation of your working environment and shopping experience” or “design guidelines to protect the integrity and desirability of the ‘Blue Vista Estates’ brand and name” – all of which might be true, at least in the beginning.

You see when you commence a development you may have very strict design guidelines. ‘Guides’ (which are actually rules) that prevent builders or mini-developers – that you onsell super-lots and parcels of land to – from designing and building any old visual debris. Design rules that are typically over and above what the local jurisdiction allows. Here are two common, albeit blunt, examples:

• “Minimum floor area of 250m2.” This rule sets a minimum size, which indirectly pretty much guarantees a higher price point.
• “Must build by 1 December.” This rule ensures development occurs as quickly as possible – both so empty sections are not left growing weeds and to stimulate demand.

Then there are design guidelines that take it further and prescribe building forms and aesthetics:

• “Allowable cladding materials include brick and timber weatherboard. Timber or commercial grade aluminum window joinery only. PVC siding and windows is prohibited.” This rule attempts to prescribe higher specification exterior materials.
• “No hip or flat rooves.” This type of rule attempts to restrict architectural styles seen not in keeping with the overall development.
• “Garage doors must not face the street.” A rule where the developer is trying to create the illusion of no cars, or at least prevent the dominance of garage doors on front elevations.
• “The upper level must not exceed 50% of the floor area of the lower level.” A guide intended to create an architectural style that forbids boxy developments.
• “Fencing is to be 50% permeable and no higher than 1.2m along the front boundary.” Intended for looks or passive ‘eyes on the street’ surveillance.
• “Front facades must contain a minimum of 50m2 of glazing and a fully landscaped front yard.” Think of the industrial park trying to push a half-decent looking streetscape.

The list of guidelines can run deep. And to help explain you might need to include example drawings and pictures. Guidelines can easily morph into a hefty design manual if you are not careful – in an attempt to fully describe the architectural response the master-planned project developer is looking for. Fairly soon though you run into design rules that are open to interpretation, and potential abuse or technicalities (from the master-planned project developers perspective). So to protect the master-planned project a formal approval process often accompanies the documentation.

The approval process might be as straightforward as ‘all plans must be signed off by the developer prior to construction’. Or it may be a bureaucratic multi-step approval board rivaling (or occasionally with permission replacing) local authority design review panels. A panel might have a representative from the developer, the city and a few architects thrown in for good measure.

Then there is the extreme version of architectural prescription. Not really design guidelines as much as ‘this is the design, now go build it’. Like a book of allowable concept designs or consented plans with no option to modify. This is where the master-planned project developer wants micro-management control over the design (and quite possibly retail selling prices), without actually building and selling the end product.

Design guidelines, especially exacting ones can work quite well when the following circumstances exist:

• The market is booming, demand outstrips supply and generally, everyone is prepared to pay for the privilege to live or operate in a design guideline adjudicated environment, and
• The urban design guidelines accurately reflect the real market for the product to be developed.

However, when the market softens it takes a very stoic developer (and investors/funders) to stick by the design guidelines, especially when they are causing (short-term) profit pain. I have seen countless subdivisions that start with all sorts of restrictions and the nicer (more profitable) homes are first of the rank to be sold and built. Then as the market deteriorates they (or the receivers) throw the design book away to make land sales. Inevitably lower ‘quality’ product gets built. And at that point, the project is on a race to the bottom. The ability to turn back to design higher-end (and more profitable) product as the market improves may now have been severely compromised.

But sometimes, in false hope, you create ‘design misguidelines’. This is when the vision and the reality don’t quite gel. Often in an area where gentrification is before it’s time, or a greenfield site that doesn’t support the underlying value proposition: amenities, schooling, socio-economic wealth, employment etc. Yes, you can sell land that enforces such quality controls at the peak of the market, but in all other times, you are effectively handicapping your potential land buyers.

So the takeaway is to produce design guidelines that are both sustainable and enhance profitability over the lifetime of the master-planned project.

Design at Scale

Is this one project of 1,000 homes or 1,000 home projects?

If you are developing and building the entire master-planned project then you have to think of design at multiple levels. The overall urban design – the big picture. The stage level. The super-lot level. And the individual plot (or lot, or section or whatever quasi-legal term you use) level – the nitty-gritty detail.

With a residential subdivision project of say 3,000 semi-detached homes, or 30 apartment blocks or 20 office towers, you have the opportunity to think at scale. Something you don’t get (as much) with a one-off project.

‘Thinking at scale’ has plenty of positives for efficiency and productivity, in design – for example:

• If we build a consistent volume of 300 houses a year, every year for next ten years, what sort of bulk supply agreements can we enter into with architects, engineers and other consultants?
• What if we just design one office tower and replicate it 20 times?
• What about 5 standard house plans, that we replicate 600 times each?
• What about the exact same configuration for each superlot?
• Can we get a global building consent so we don’t have to apply for each individual building?

And that all works where you are taking a cookie-cutter approach. But there are design drawbacks, especially in projects with a large residential component. This is what I call ‘at scale complacency’.

At scale complacency occurs when the details are glossed over, just because there is a big number. And in a master-planned project, one of the biggest offenders are architectural designers.

Consider this scenario, you hire an architectural firm to design three super-lots of 100 terrace homes each. The architectural firm charges a fee based on a per-home basis. You get the designs back and it all looks the same. The colors are similar. The plans are similar. The windows are in similar positions. The roof forms are similar. The decks are in the same place. The designers have put plenty of thought into the big picture look and feel but have they adequately addressed the detail?

Your modus operandi may have been to cut costs and boilerplate everything. Standard floor plans. Standard colors. Everything a carbon copy. That is a valid strategy if it truly reduces your costs and your master-planned project branding and ‘look and feel’ and most importantly the buyer pool that you are targeting can handle it. But often it’s not. Even if you have brought into the architect’s ‘vision’ that they have designed a cohesive design that links all the homes together in a symphonic melody, you need to check out the detail.

As development manager or design manager, you might only be interested in the stratospheric perspective of each super-lot or stage. From that high-level design view the architect may have done an exemplary job.

All the same the home buyer might not think so. And who is your real customer – the architect or the home buyer? The designer or the tenant? And what do they really care about?

I won’t keep you guessing.

They ONLY CARE about their new home, new office or new shopfront. Sure you might like to skite to your friends about being part of a brilliantly designed award-winning masterpiece courtesy of starchitect so and so. But how is that going to go down when you are sitting on your deck, toasting a chardonnay with all your mates looking out onto a big ugly confronting retaining wall? Especially whilst your 5-year-old daughter, sitting in her bedroom, without even straining, has a panoramic view of the city skyline!

The buyer cares about all the details. They are going to live or work with the details. On a site plan with 100 homes, the buyer is not going to see the finer points in the design. But once the property is built, every detail will be out in all its glory. Unless you have pre-sold or pre-leased and have a thick skin to suffer the abuse from an irate buyer or tenant and the market is so hot, replacements will line up regardless, then I suggest you pay attention.

No not just you, the architect needs to. Train them, coach them, politely remind them, throw their fee letter back at them, whatever, but get them to look at every single individual building and unit to maximize value. Have they imagined themselves on every deck on a summers evening? Do they pay attention to what one will see from the kitchen window, and every other window? Does the fence block a potential parking space? Could the trash can go in that corner? Why not put the transformer around the corner, out of sight? Can a kid play on that gradient? Will we get more sun if the window is higher? What does the room feel like with that metal detail over the window? Yep buyers have emotional attachments to what could be their biggest investment.

Yes, a big list of design considerations, applied to every single unit can be intimidating. Does your architect even have a checklist for such concerns? Don’t let them become complacent with scale. Especially if you are paying them a similar per-unit rate regardless if it’s 10 or 100 units. Even if you have a bulk discount, this level of spatial thinking needn’t take that long. But it does take the mindset to think like the eventual occupier for every space that is designed.

When you are designing your own home, you and your family are across every single detail arent you – from light sockets to window sills? So get your architects to take a similar approach when designing ten thousand!

Now, what if you don’t buy into the architect’s design consistency argument? You actually want your master-planned project to have architectural variety. You might be creating the city’s next suburb, but that doesn’t mean it has to all look the same nor should scale mean compromised individuality. You have told the architect but you are not sure if they are getting the message. You know when the architect comes back on the third attempt and terrace block 15 still looks the same as terrace block 12,13,14, 16 and 27? When apartment tower X looks surprisingly similar to office tower Y. In this situation not only are the design team suffering from ‘at-scale-complacency’ they are caught in a vicious case of tunnel vision. Well, from experience there is only one way out.

Hire multiple architects.

And on that note, look out for our next edition where we explore everything else about scale.

Cheers

Andrew Crosby

The DC: Master-planned Projects – All published editions.


#1 Roads
#2 Net Developable Area
#3 Feasibilities
#4 Stages
#5 Team Collaboration
#6 Architectural Design
#7 Scale Thinking
#8 Selling the Dream Location

P.S.

Now in this blurred world of social media versus professional media, my opinion versus my employer(s), salary versus side-hustle, middle of the business day versus 11pm on a Sunday evening, it can all get a bit confusing. So, here is my value proposition, and both complement and benefit each other.

• If you have a development site that you would like to sell some or all of, to develop yourselves, or to build houses then Universal Homes www.universal.co.nz might be able to help. We focus on delivering value-for-money homes in the ‘relatively affordable’ range, like the 1300 home westhills.co.nz or the 600 plus homes we have built at Hobsonville Point, or the thousands of others around Auckland over the last 60 years. Message me on LinkedIn at any time
  linkedin.com/in/ajcrosby .
• If you want to learn more about real estate / property development and a continuous improvement approach, with books and courses in development management to maximize profit and decrease risk then visit www.developmentprofit.com

The Developer Chronicles: Master-planned Projects

In this series, I describe master-planned projects. The discussion focuses on the difference between a one-off project and a multi-stage, multi-year planned development. I explore the factors that great development teams grapple with every day. I hope you find it of value.

AND you can also contribute to this opensource education by commenting with your own experiences, strategies, tactics and ideas here on LinkedIn. That’s where we can really embrace group network effects for continuous improvement in development management.

Master-planned Projects #5 Team Collaboration

Question: What’s the difference between a good team and a bad team?

Answer: Team WORK!

Specifically: Team working very closely together.

If you thought team collaboration was important for a one-off development then wait until I tell you about a master-planned project.

Who’s on the Team?

Firstly we’ll describe the team. The greater team will consist of internal staff, external consultants and contractors and intermittent exposure to external agencies. Let’s define the core team as those members who meet regularly and together have responsibility for delivering the project.

In a small outsourced team, (typical of nimble private developers) it might be the developer and/or development manager an assistant or two and everyone else is an external consultant or building contractor. In a large corporate where you do everything (design, consent, build and sell) except for specialist consultants (like traffic or acoustic engineers) all of the core team might be in-house.

And on large complex master-planned projects, the core team might constitute a whole layer of internal management, directing a bevy of consultants and contractors.

In all cases will be those agencies like city council, utility network operators, and other quasi-government entities where you must collaborate, but often will feel like a one-sided negotiation (their side!).

Here are the usual suspects for any core development team. Some roles may be done or governed by the same person, effectively a project manager, or some roles might need to be split further.

• Developer/development manager/project director.

Whether its the CEO, the Vice President, Mr Jones, or any of the descriptions above, if this project is your ultimate responsibility, and you are accountable to the investors, funders or board then this is you. We’ll refer to you as development manager (or leadership) moving forward. If that’s your title, but you don’t call all the day to day project shots, then that’s not you. Somewhere down the line, you work for this person and you are one of the following:

• Architect/Design Manager (architects: urban design, interior, outside and landscape)
• Town Planner / Planning and Consents Manager
• Land Engineer / Infrastructure Manager (All things on and below ground: Civil/ Surveying/ Traffic/ Geotech/ Environmental)
• Engineering Manager (Structural, and to a lesser extent fire, acoustic, HVAC, vert, facade)
• Construction Manager (All things built above ground)
• Sales & Marketing Manager / Agency
• Cost Estimator/Quantity Surveyor
• Financial Analyst/Feasibility Manager

Depending on which country you are in, and the complexity of what you trying to achieve the team might need someone dedicated to insurance and in-house legal counsel.

Collaboration Explained

Now that we know our core team, what exactly does collaboration – to collaborate- mean?

Here is a definition I have borrowed from the dictionary.

The words I particularly like to draw upon are the synonyms: Conjoin and Unite. In a master-planned project, it is not merely enough to work together. The team, at least the core team, must unite, conjoin and effectively become one.

Although many developers often feel like they have waded into definition [2] above, items [1] and [3] are spot on. [1] means you work together as a team (think staff), and [3] infers many of those you are working with not in your direct control (think contractors and consultants albeit you have some financial control, and local authorities, utility providers and government where you have zero control).

Bear with me as I go into deep cerebral contemplation. In a master-planned project, because we have multiple layers of design, across multiple stages, across an extended time horizon with high uncertainty, there needs to be a core team that moves in mental unison as the project develops. When things change, like a stage gets re-prioritized or a new risk develops (market heads south), or more certainty is gained (local authority approves a public road) everyone in the core team needs to know. More than ‘know’, they need to understand ‘how’ it affects them and how it affects each other team member. And importantly how their response to such change will subsequently affect the work of each other.

A residential estate scenario to illustrate.

At a project control group meeting, the infrastructure manager explains that the local authority is ready to approve a new road layout. It is in a location that differs from the original master site plan. The urban design architect updates the master site plan. This affects the size of the super-lots, so the building architect updates the super-lot site plan.

This affects the location of services so the civil engineer must update their services drawings. Similarly, the surveyor updates their boundary drawings. But the services now conflict with all a hillside packed with retaining walls, so the structural engineer needs to revise those walls. The walls get higher. She has to obtain clearance from the geotechnical engineer who decides that the retaining walls will require deeper foundations and further moving of boundaries.

This all adds additional expense so the estimator updates their schedule of costs. Sales values in later stages are now negatively impacted by higher than desirable retaining walls. The feasibility manager adjusts the financials and finds out not only does this combination of higher costs and lower values decreases profit but we are below the investment hurdle rate. That’s not going to work.

So the feasibility manager asks – “What happens if we move the road to a different location?”

The infrastructure manager replies, “Of course the local authority will accept a range of locations” (unlikely to be a true story!).

And there you have it, that circular problem is now solved.

This whole process can play out in a variety of ways though, linked to just how collaborative the team really is:

• If everyone in the team is on their A-game and understands their own role sufficiently (aka is not just a business development manager attending the client-facing meeting and actually knows very little) and the meeting is treated as something to get things done, not merely make instructions or pass information, then the net cost might only be a couple hours of everyone’s time, right there and then. I.e. plans are updated/marked up conceptually with team members immediately cognisant of the implications (or at least likely implications) so they can advise in real-time.
• However, if the team has an ingrained inability to do, challenge, or offer anything without first going back to their respective office and spending a week to mull it over. And then spending another week assigning the work to someone else. And not talking to anyone else in the project team during this period. And then waiting to present the changes at a regular monthly meeting another week later. And this approach continues down the line of affected team members. You could have lost many weeks or even months.
• Ideally, in a unified, thinking as one, ‘Vulcan mind-melded’ team, the infrastructure manager has anticipated the potential such issues and sorted it out with the rest of the team before this meeting even took place!

If the team has a central development manager/ project director, then they may mitigate the second linear approach somewhat. But if the second way above is the prevailing team attitude, the development manager will be forced to micromanage the communication between every team member. And they have to be across everything. When this is the case, then there is a tendency for team members to simply default to the development manager for an answer on everything. Effectively that’s everyone in the team absolving personal responsibility. For many development managers that’s how they like it – a pure command and control structure. Often that is necessary for the really difficult, risky and expensive decisions. But for everything else, I say that is an inefficient waste. The project team should be responsible and accountable, not just for their own work but also for considering the work of others. And the development manager’s prime role is to strategically pave the way for the rest of the team to do their jobs.

Three Degrees of Collaborative-ability

I’ll label what I see as the three improving degrees of core team collaborative-ability.

1. Silo mentality
2. War room
3. Mindreader

Silo mentality. In a silo’ed, everyone works on their own, focusing on the impacts on themselves only environment, sorting anything out takes a lifetime. Problems crop up, no one gets notified and the negative impacts are amplified. People crucial to the process might only find out when it’s too late. No one cares about the work of anyone else, except where it directly impacts them. In fact, it is all too convenient when someone else doesn’t deliver, as you now can use them as the excuse. Documentation and expertise is hoarded, or worse, secretly protected by the prying eyes of anyone else on the team. Tom Peters has a lot to say on removing silos (which I apologize for the overused cliche) and aligning teams (read here).

War room. This is where people come together to work together and make critical decisions together. Meetings are workshops to sort issues out. Team members have deliverables and they deliver. The core project team members understand their own part of the puzzle intimately. And each of them is responsible to push those within their sphere of control to deliver. Everyone who needs to be present is there, or just a phone call away, and all are empowered to make decisions and advice from their respective entity. War room orientated project team members have no problems organizing themselves into sub-teams. They can create a platoon with its own sergeant to tackle a specific task. And they communicate the results (aka solution) clearly back to mission control to make sure everyone is on the right page.

Mindreader. The mindreading team is (should be) the utopian goal for any master-planned project. [I have described something similar before with regards to consultants – read here ]. Core team members know the detail in their field and comprehend the bigger picture. They know how to deliver their contribution and have the authority and inclination to influence those under their management to think in a similar, anticipatory way. They know when to cull ineffectiveness and circumvent silo’s that form in their own departments. They can self organize and delegate tasks to solve issues concurrently. They are everything that the war room approach brings. But in addition, critically, they have taken a quantum leap forward. They appreciate and are empathetic to how others in the team might think. They pay attention and learn from the concerns of other team members. “Not my problem,” is their problem. They make it a project problem to be jointly solved. Delivery is faster, more accurate and certainty is achieved early. The infrastructure engineer understands that moving services could impact retaining walls that could add additional expense that could look ugly and deflate property values that will negatively affect the project profitability. They might not on their own be able to figure out the exact implications but they all think and act in a holistic way. Never do they sit back and judge “I will leave that up to the sales team or the architect or the development manager”. In fact, many of the core team are positioning themselves to be the next development manager.

How about some specifics to take your core master-planned project team to mindreading prestige?

• Authority. A mindreading core team member has been given the power and authority to act this way. By the client, the developer, the project director, the development manager – whomever. It starts from the top: a command and control type client will not be able to create the conditions for a mind-reading team.
• Trust is paramount. Everyone on the team must trust that both, others are delivering, and others are working to make everyone else’s job easier. That takes time and leadership that encourages trust. Trust is a two-way street. For leadership to give trust, team members must demonstrate they can be trusted to take their own leadership position. Leadership needs to be satisfied that core team members will persist to find solutions and absorb learnings from critical feedback or challenges. Trust is not built when leaders see someone taking the easy way out or defending mediocrity.
• Open communication. Each core team member takes responsibility for communal understanding. They know to express the implications on their own work so that the rest of the team understands. Leadership encourages open debate so team members do not close up ranks when problems surface. Team members consider other team members perspectives. For example, if you as a construction manager replace an integrated brick letterbox with a standalone metal stick in the ground from the big box hardware store to save cost, you have first cleared that with the sales team to make sure it doesn’t negatively affect sales price by a greater amount. Or if marble has been specified in the office bathrooms but it adds no value to the lease rate, then rather than you -as leasing agent- just accepting it, you indicate to the architect that it can be removed to improve profitability.
• Team stability. People are more important than companies. When people leave the team, not only does intellectual property leave, but so does trust, familiarity, and the ability to cognitively read each other. A new team member has come up to speed, not only in project know-how but also in their assimilation of the ‘group responsibility culture’. That takes time. Master-planned projects are notorious for lack of team stability. Part of the reason is obvious practicalities. Master-planned projects take a long time. Team members leave jobs, get promoted, move overseas, the market goes up and down and everything else in life has a habit of getting in the way. Even so, whatever leadership can do to reinforce and incentivize stability the better.
• Challenge. Question. Search until you find a solution. Everyone has (or grows) the confidence to challenge each other, upwards, sideways, downwards and the status quo. To question the reasons why. Team members don’t assume it has to be this way. Yes, they acknowledge others are experts, but they push for answers. Everyone arrives at the boardroom table on an equal footing. They seek constant improvement. Team members don’t wait for the development manager or client to push them. They have analyzed the options already and can present the pros and cons. They understand the more the team challenges themselves, the more likely the project will be more profitable. The more profitable the easier the project will be to deliver.
• Create cross-department/expertise groups. One way to break silos and help instill trust and confidence in the core team is to create teams within the team for individual workstreams or tasks. Rather than the development manager directing each team, give leadership to a team member. Where your core team may have 6 to 10 people, a smaller workstream team may only have 3 or 4. Each of those individuals will then be naturally closer to the action of other team members, and more willing to challenge and contribute. This helps team members understand how different issues impact others. It also forces the team to work together to find a solution, and analyze the alternatives, before asking before approval.
• Force decisions upon the team. If team members have earned the right to be trusted then make the team members responsible for key decisions. Start small and up the ante.
• Document control and workflow. Collaboration is often thwarted by poor communication. Poor communication is inhibited by poor documentation sharing, version control, and workflow management. Get this sorted.

Where you have a largely internal management team running a master-planned project, led by a development manager then an employer/employee relationship exists. Assuming people in the team are not tainted with silo orientated habits this should make it easier to achieve seamless collaboration. On the other hand, if these team members are also themselves running teams of internal staff and external consultants then they have to embed the same mind-reading collaboration mindset down throughout the team they guide.

If the core team is largely outsourced, (or for any external consultant or build contractor) then you have another little thing that gets in the way: contracts! More specifically big fat disclaimers in contracts. Especially the ones that say ‘the client is responsible for the work of others’. That gives externals a convenient out. You could include a contractual clause which makes each consultant responsible for evaluating the effect on their work of any changes by any other consultant or contractor. And a clause stating that they must advise the project team and client of any impacts immediately. But of course to achieve this you need buy-in and you need diligent consultants. With external builders and their voluminous contracts, it gets more difficult. And if things aren’t going that well and the contract has been dusted off, with attorneys mulling around then it is probably impossible. That is where a project manager between the core team and build contractor has to embed themselves in the psyche of the contractor in order to create a unified project mind.

I didn’t say it was easy.

Use this quote from John Carmack, a legend in video game programming, as inspiration,

“A strong team can take any crazy vision and turn it into reality.”

[A development is a little like a video game: you have to overcome obstacles and defeat increasingly outrageous foes as you work through the levels searching for the elusive treasure.]

Teamwork Control Mechanisms

To make it easier to create a collaborative environment, quality control mechanisms were suggested above. I say suggest because sometimes they can go too far and backfire. They need to be managed in the reality of the development situation. [ Note we’re talking about controlling delivery, not controlling people!]

Key Performance Indicators can be effective so long as they currently relate to the contracted project deliverables and one person’s KPI’s don’t conflict with another’s on the same team! This can often happen, when KPI’s have been set in departmental silo’s or when corporate goals and project goals are not perfectly aligned (for example short-term annual profit versus long term project profit). Whatever you call your targets/ KPI’s/ milestones/ objectives/ goals/ budgets it is important the team is all on the same page. Property development has a lot of targets pre-built in. There is plenty of obvious ones without you needing to concoct any arbitrary ones.

• Settle all houses, one week after they are complete
• Lodge stage two consents by Xmas
• Start building by Easter
• Finish civil works by Mothers day

Of course, to achieve each of these deliverables will be a number of intertwined steps to get there. There should be a comprehensive programme/schedule which lists everything on the critical path. And who is responsible to hit those milestones along the way. And most importantly that the system/software pushes notifications out to everyone that needs to know when there is a change.

When something changes, then everyone’s future KPI’s should be modified to reflect that change. KPI’s that are only decided once a year can become really messy, given the inherent variability of a development project, especially a master-planned one. Sometimes it is easier just to link KPI’s to project performance: ultimate profitability.

Meeting minutes are a control measure that goes without saying. And the team should be expected to run and take meetings with the simple, ‘who, what and when by’ noted to meet their objectives. At a high level, two effective measures are the monthly report supplemented by weekly workstream management. We will talk all about reporting and delivery management in a future edition.

Collaboration software – maybe, if you have someone internal dedicated to administering it and the team has full and contractual buy-in to its use. Ironically this is getting difficult these days with companies own email systems and other communication channels popping up every year or so (Messenger, Dropbox, Wechat, Whatsapp, …). Sometime in the future I will write about founding and running a Collaboration software business, but for the time being, I will say:

• Managing online collaboration systems is difficult in the early stages when you in the pre-developed design conceptual and planning phase. Everything is fluid and changing and you are running multiple feasibilities concurrently with bulk and location and concepts. In fact, such systems can be pointless, to a large degree. Sometimes they can actually detract from the work being done as they can create their own inefficiencies when you are trying to deal with change.
• During detailed design through consenting and construction, a full-blown total immersion collaborative system is easier to implement. That’s because contracts and budgets, programmes and authorities are largely sorted out. There is less room for movement and you can tie workflow to contractual requirements.

Team no, no’s.

When any of the following occurs, you know the team still has work to do, to achieve mindreading collaboration status.

1. Minor issues are constantly sent to the development manager to rule on.
2. The development manager requires they must receive every piece of correspondence between other team members.
3. Team members are not sure what the development manager will be interested in. Therefore to cover themselves, cc the development manager on everything.
4. Development manager wants to attend every meeting.
5. Development manager goes beyond challenging, questioning or searching for solutions and provides technical advice.
6. Development manager can’t escape from technical detail and spends a lot of time focussing on minor points.
7. Development manager has to show themselves around external consultants to demonstrate ‘who is the boss’. Similarly, development manager requires team member to seek approval from them before instructing external consultants and contractors.
8. The development manager is running from fire to fire, rather than setting strategic priorities, deliverable dates and evaluating future opportunities.
9. The development manager is always following up where things are at before due-dates.
10. Team members are not communicating where they are at on particular task, if that task is heading to be late – which if a pattern is established, can give rise it #9.
11. Development manager does not set up teams to work together to solve issues or evaluate opportunities on their own – i.e they always have to be part of the working group, just to make sure.

You will see many of the above points revolve around the development manager essentially micro-managing the team. Some might say this is necessary for control. Others (like me for instance) will argue, that approach is not scalable to adequately run a master-planned project. Nor does it allow team members to grow in their own leadership or become the next development manager. But it does take time for the team to develop where the development manager can sit back and purely focus on the big picture. [Is this really a secret list to remind myself….?]

However, where items are of paramount importance, carry considerable risk, team members have already been given ample opportunity (or lack the requisite experience or expertise) or the horse has already bolted then the development manager might be given a hall pass to insert themselves to manage the situation. That’s just the nature of property development. With the caveat, that coaching (training/teaching/demonstrating/pushing) is provided along the way. So the team member(s) can learn and grow to sort out the next similar situation on their own.

Annnnnnnnoooooooooooyyyying!

Here a list of pet peeves which should irk anyone. This behavior needs to be stamped out immediately! [OK, OK, I mean resolved empathetically with self-control equal to her Majesty the Queen no less.]

• “Which work would you like us to prioritize?” This will happen more on a master-planned project than a one-off, primarily because there are likely to be a lot more work streams running concurrently in a master-planned project. When I hear this my blood boils, especially if it emanates from a consultant or contractor who has taken on the role, fully aware of the size and responsibility of the project. It’s not necessarily a size thing either, as I have heard the same thing from medium-sized companies through to international conglomerates. There are likely two related things wrong. One, they have done a sales job on you, pulling the wool over your eyes when you engaged them and now they are not able to meet your commitments – the resource doesn’t exist. Or two, they are using the complexity and size of your project (or organization) against you so they can serve other clients – they have plenty of resources it’s just not directed your way! In both cases, if the problem persists, get a new consultant or contractor who can handle what they promise.
• “I can’t do that. We can’t do that. They won’t let us. But this. But that.” Really? Things might have changed (time certainly has), so let’s give it a go. Get three new opinions. You might surprise yourself and discover an improvement. Better still reframe to find an alternative. “Not sure if we can do that, but we can do this”.
• “I know this” Where a team member is the world’s self-appointed expert on a topic and there is no other way besides their own. Now, they might be the foremost person in the field. But odds on, they aren’t.The self-important often have a powerful weapon that they love drawing to reinforce their self-designated expert status, if given half a chance: “I told you so”. The problem arises when someone believes their own aura of invincibility and refuses to entertain anything different.
• “We have always done it that way.” Fine. Now can you at least think about doing it a different way? And while you are at it, please explain exactly why have you always done it this way. Caveat: The last three well-known annoyances come with an all-to-common fish-hook though. And not a lot of construction industry change evangelists will want to hear this. If you are one of those who -via self-interest are plugging their own agenda or product and not considering the total picture or any of the associated risks- then plug your ends. In property development and construction there is often a very good reason why it can’t be done and why we have always done it that way!!! That should not stop you challenging though. And if there is really no other way, demonstrate with the evidence, so the team understands.
• “That’s not my department” Where every report and communication from one team member mentions the specifics of everyone else’s contribution so that team member has effectively passed on responsibility for everything. One big self disclaimer. The question then becomes, why do we need this person, if everything they do has an excuse clause, “So and so said this”. Sometimes this is a just a temporary phase for newbies and those less experienced to a project team. The sooner everyone is singing the ” we are all in this together” tune the better.
• “That was all me”. When a team member likes to take all credit for themselves. Or that time when they take credit for something they actually never did. Or when they get jealous of the credit given to another. That same type of person often shies away as soon as there any problems. Leaders should give credit for wins downstream to the team. Conversely, good leaders have no problem admitting responsibility and taking the blame.

The Collaborative Conversation

Let’s end with a positive spin on our conversation. If whoever is leading the team plays their part, and is allowed to play their part from those above, then a truly mindreading team can be created. You know you have reached your collaboration destination when you start overhearing things from the team, without leadership prompting, like this:

• “Here are five options, with pros and cons – lets debate”
• “I agree we probably can’t do it that way. But what are we missing that allows us to do it more effectively?”
• “Who do we need in this team to figure this one out, who is the best in the industry we can ask for help?”
• “Why don’t us three get together, and try and find a solution before approaching the development manager?”
• “I think the client is wrong. Let’s find the evidence and see if we need to challenge that thinking.”
• “This is a major risk and one of the things the project director needs to know. We need to notify immediately and then work quickly to propose a contingency plan.”

To wrap it all up, I kinda like this quote:

“Collaboration is like carbonation for fresh ideas. Working together bubbles up ideas you would not have come up with solo, which gets you further faster.” – Caroline Ghosn

Next time we will talk about the differences between a master-planned project compared to a one-off project when it comes to all things ‘design’.

Cheers

Andrew Crosby

The DC: Master-planned Projects – All published editions.


#1 Roads
#2 Net Developable Area
#3 Feasibilities
#4 Stages
#5 Team Collaboration
#6 Architectural Design
#7 Scale Thinking
#8 Selling the Dream Location

P.S.

Now in this blurred world of social media versus professional media, my opinion versus my employer(s), salary versus side-hustle, middle of the business day versus 11pm on a Sunday evening, it can all get a bit confusing. So, here is my value proposition, and both complement and benefit each other.

• If you have a development site that you would like to sell some or all of, to develop yourselves, or to build houses then Universal Homes www.universal.co.nz might be able to help. We focus on delivering value-for-money homes in the ‘relatively affordable’ range, like the 1300 home westhills.co.nz or the 600 plus homes we have built at Hobsonville Point, or the thousands of others around Auckland over the last 60 years. Message me on LinkedIn at any time
  linkedin.com/in/ajcrosby .
• If you want to learn more about real estate / property development and a continuous improvement approach, with books and courses in development management to maximize profit and decrease risk then visit www.developmentprofit.com