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.
- Silo mentality
- War room
- 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.
- Minor issues are constantly sent to the development manager to rule on.
- The development manager requires they must receive every piece of correspondence between other team members.
- Team members are not sure what the development manager will be interested in. Therefore to cover themselves, cc the development manager on everything.
- Development manager wants to attend every meeting.
- Development manager goes beyond challenging, questioning or searching for solutions and provides technical advice.
- Development manager can’t escape from technical detail and spends a lot of time focussing on minor points.
- 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.
- The development manager is running from fire to fire, rather than setting strategic priorities, deliverable dates and evaluating future opportunities.
- The development manager is always following up where things are at before due-dates.
- 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.
- 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