What the AEC industry can learn from programmers

When I was at?university, I read an article about extreme programming and had a revelation. It was exactly what a colleague and mine sometimes did when working together.

In extreme programming, the idea is to always work together. One is responsible for doing a part of the work, and the other checks the quality. The twist is that both work on different topics. So, it's not a hierarchy but a relationship between equals.

That's what we did. We divided the work and worked independently on our task and when checking the work of the other. For some complete jobs, we sometimes even sat together in front of the same computer; one focused on clicking while the other focused on thinking. But there is more we can learn from programmers.

Test-driven development in AEC

Another very interesting concept is test-driven development, which is used to find mistakes in a volatile environment with many changes.?

Do you know where I'm going with this? As a client rep, I walked through the site and once had to ask how to enter a flat. A last-minute change, and suddenly, the door was missing. I already hear you; this only happens to others. Are you sure?

This test-driven modeling approach would be a great way to build a system that helps everybody working on the project find their mistakes. Not only once but consistently. Examples of test-driven development in AEC could be:

• Modeling the max volume with the correct distances to the border and building a clash detection between the design and the max volume.
• Checking if every room has a door.
• Checking if every room from a list of predefined room names has a minimal window size of 1/12 of the floor area.
• Cecking if every bathroom has a Plumbingwall with a minimum of 12cm of free space.
• Checking for parking slots, room, sizes, and other client requirements.

The key word here is "a system." The great thing about a system is that it's generalized and reusable for other projects. But you need to set up some standards for how you always work. Only with this data standard will it become feasible to define these rules once and then reuse them to store knowledge in the project and in the organization. Unfortunately, in my experience, it was already hard to follow a layer standard in an office; a multidimensional standard becomes even more complicated.

Agile Project Management in AEC

The same principle of a system applies to project management as well. Most people in AEC don't have?any?formal Project Management education, and they learn it from their peers. It's not necessarily bad, but it can lead to some incest of ideas. For example:

• The golden standard for scheduling is the Gant diagram, although nobody likes to read it. Moreover, Gantt charts greatly represent processes when the product goes through different work stages, e.g., in a factory. In a building, it's usually the other way around: The workers have to go through the building and work at different locations. Location-based planning, considering the spatial limits, could be a better approach.
• In Switzerland, everybody works with recaps, separate tasks, and decision lists separated by meeting type. So, in a bigger project, you end up with several lists. Only some engineers think a list is the best way of presenting information; even worse, most people use Word or graphically laid out Excel for these lists. Some clients even provide the word templates as a standard.?
• Another issue with management through tasks is that a task is the smallest possible increment and takes away a lot of autonomy from people. I prefer management through defined results with defined acceptance criteria. The necessary tasks to reach the results are up to the (specialists) doing the work. Some construction companies do that, for example, when they define a plan delivery program. So, not everything has to be new; we need a more conscious approach.
• Usually, we follow a top-down hierarchical project organization. The project manager leads the meetings, does the recaps, and does the costing. There is no way of splitting accountability and responsibility or for some more differentiated roles. A scrum team works differently. The project owner is a part of the team, following the same rules as everybody else (that could be a client rep who works as a team member instead of leading through power). And there is the role of the Scrum Master. The Scrum master is responsible only for the process and helps the team work together. This separation between process and factual work makes so much sense because once you are in the trenches and become a part of it, it's hard to moderate and step back to ensure the best teamwork.

As you see, we can learn many topics from Software Development in AEC Project Management. A good starting point is:

People who program are inclined to think in systems. People in AEC are tempted to work in crisis mode. And always working in crisis mode is no long-term strategy! So, build systems that help the team and you. To do so, don't be afraid to learn from others.

Building up a tailored project management system

In my work, I experimented?a lot?with project management systems and found that every project needs a different approach. Yet I found these?key?ingredients.?

1. Most of the time, the scope and requirements are not defined and communicated well. Therefore, this is a great starting point. I like to make it as easy to understand as possible. We created a PowerPoint presentation in several projects with sketches of the concepts and the work breakdown structure. PowerPoint because this is what the decision-takers are used to.
2. Proactively define rules in the team together and try to build a system where the team starts to enforce the regulations themselves. The first step is to develop the rules and make them accessible. For example, I skipped having a "project management handbook" nobody looked at. Instead, I made it part of a continuous recap.
3. I am moving away from document-based to data-driven information management. For example, storing spatial requirement data in the same database as the solution allows for easy checks and visualizations. For example, the client might want to have a carpet in the office. I document this in a database connected to the BIM model for data visualization and simple checking.
4. Instead of recapping different meetings, I like to work with a project journal, where the same type of information is kept in the same place. I started doing this with Excel, and recently, I developed database solutions for tailored management (new tools like notion or airtable are great for this rapid prototyping).

Therfore, don't get stuck on frameworks and terminology, build?your own, based on more generalized principle:

1. Empower the team/people; don't do it top-down, but work together with the people. Your job as a project manager is to create the best possible environment for people to perform, and you can only do that by involving the people.
2. Separate form and function. This means leaving behind a document-driven approach, where the form of the document is fixed, and embracing a more flexible approach, where the data is stored in a database and can be accessed through different representations. E.g., A list, a Gant chart, a hierarchical view, a plan, or a model;...?What you want to do with the data depends on the form. But you always work with the same data.
3. Start managing quality/scope, cost, and schedule will follow.

How do you approach project management in a digital age?