Built environment design has certain features that define both the industry and the specific way projects within it need to be managed. Firstly, we’re an industry with incredibly complex projects — the number of people involved, the dependencies, the variations of scope and length, the impact of an ever-fluctuating market, and on and on. Intricacy is built into what we do (pun intended).
Secondly, we’re a project-centred sector. We rarely do exactly the same thing twice — even if we’re designing the exact same structures in different places, the location itself will provide new necessities for each project. And projects are not an extension of our normal operations, they are our normal operations.
All this makes it extremely difficult for us architects and built environment designers to use a generalized business and project management software solution. Larissa Leone, co-founder and director of Two Birds Consulting (a consulting practice that focuses on business management for architecture, engineering and construction design (AEC) firms) suggests industry-specificity in your software is key.
“It really is so important to try and get an industry specific system,” Larissa says. “Having worked with a variety of systems over the years I know that if you choose a ‘generalized’ system there is a heavy amount of customization that needs to be done to just get the basics of what a project-based organization requires.”
Joel Gregory, co-founder and CEO of 12d Synergy says, “in the AEC market it’s not just thousands of documents and emails, there’s also gigabytes of geospatial data, CAD drawings, lots of things that are fairly unique to our industry — most generic systems just don’t look after that.”
Given the agreement on the necessity for AEC-specific software, how do you work out what you need from it? What functionality is critical? Which features will lay dormant?
Let’s dive in and take a swim through it:
- Working out what functionality you need — the software audit
Larissa says working out your functionality needs generally starts with the client articulating how they personally want to function in the business and if there is the correct structure in place to support that.
“From there, we discuss outcomes and what the client wants to know about their business at either a click of a button or in a meeting environment,” she says.
“This starts to generate and give life to the outcomes be it visual, graphical representation, numbers that need to be articulated by someone else in the company, or an outsourced professional.
“The most important element of a management system for project focused businesses is to know how a job is tracking at any point in time and then make informed choices about the business from there.”
So, to begin, assess what the most critical business challenges are that you need to solve. Then examine the management software systems you have in place (both business and project) to see how well they support the realization of those outcomes.
If you work with a team, the next step is to assess each of their tech requirements in the pursuit of their individual work outcomes.
Assessing required functionality can continue into an audit of your team’s software usage. Look at:
- Who uses which tools and solutions (and where there are overlaps between them)
- Where the software is used in each workflow
- Which integrations are crucial to core workflows
- What functionality is critical and what functionality is desirable for each team member
- APIs and integrations
One of the benefits of cloud-based software (and let’s face it, there are many) is the ease with which one software can integrate with another. The complexity of our built environment design projects demands a reasonably complex set of software requirements — old-fashioned ERP-style, one-stop-shop software does not suit the way SME design businesses work. The power of integration is an incredible advantage in meeting our associated software functionality needs. APIs(application programming interfaces) are how that integration happens.
Total Synergy product manager Paul Hemmings says an API is a way for one software developer to get their product into another developer’s product.
“Every user is a little bit different, which means, if you’re in a specialized industry like AEC design, the way you want to work will probably be slightly different to the way somebody else wants to do it,” Paul says.
“If you’re doing site reports, then geographic coordinates are very useful. Unless the site you’re working on is a space station, in which case … It doesn’t work that way. So additionally, you might have a project that is different to everybody else’s project.”
Paul explains that one way to go would be to try and build a software that caters to every possible working methodology — the result being a cost-negative, and time-consuming undertaking where you ended up with a product so niche, you’d only have one customer. Alternately, you can connect to niche apps.
“Most of our users are perfectly happy with all the functionality that we’ve given them, and that probably covers 80 percent of what they do. Then for that other 20 percent where you need something specific and niche — it’s only that little bit that you need to find third party apps for. We cover most of the more general capability you’ll need for your AEC business. The bonus is that, if there are any problems with the add-on apps you’re using, it’s not going to kill the business to change them because it’s not absolutely mission critical.”
The result? Considering the possible integrations of your business and project software is another part of assessing the solution’s features. This represents another layer of specificity that could suit your needs in a more tailored way.
Ask yourself, if this software does 80 percent of what I need (and most of that is central to my business), what other apps are out there that can connect to it and cover the remaining functionality I, or my staff, need?
See what applications connect with Synergy
- Thinking about who needs access and where
Another complicating factor in our AEC business and project management is location. Our work and projects necessarily take place across a number of sites. Project files and documents need to be accessed by a lot of people, from a number of places.
This means that one of the biggest questions to answer when considering an AEC business and project software system is a classic: to be (in the cloud), or not to be (in the cloud)? In a reassuring plot development, the answer to that question is simple. Your business software solution needs to be in the cloud. If flexibility and access anywhere, it’s not going to be stored on an on-premises server, only useable where it stands.
The LogicMonitor Future of the Cloud Study from 2018 says, “83 percent of enterprise workloads will be in the cloud by 2020’. That’s 83 percent. And that’s next year.
The Capterra study mentioned earlier asked users about deployment methods of their current project management tool and found the majority use a cloud-based solution (60 percent compared to 40 percent that use on-premises/desktop solutions).
“This finding mirrors the larger consumer shift toward cloud-based tools that provide access to information and updates in real-time, across all devices. In fact, the market for cloud-based project management tools alone is expected to reachUS$6.68 billion by 2026, according to a market growth report by Transparency Market Research.”
If any of those number are even the vaguest indication of the future, then in order for your software to have even the slightest longevity, it best be cloud.
In short, you want your management software to be as designed to your particular work practices as possible, in order to enable as much success as possible. That’s the point.
Two Birds’ Larissa Leone recalls a client of hers in the construction industry who used a non-specific project and practice management software that had to be heavily customized for them.
“It worked well for some of the functions they needed but it failed dismally on most of the outcomes they needed,” Larissa says.
“They had no visibility on their fixed fee projects as there was no capacity to forecast their cashflows on their jobs, there was no allowance for letting sub-contracts. These were the two main things that were letting not only the system down but more importantly the business.
“We moved to an AEC-specific software last year [editor’s note: ahem — that’ll be Synergy!] and it fundamentally turned the business around. It enabled the project managers to do their jobs more effectively and more comprehensively, it provided the correct numbers against jobs, but most importantly, it allowed the business to know what was going to happen in the future. This enabled the company to grow and evolve making the right decisions along the way.”
Recommended reading
