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. Each transaction or parcel of work centres around a design to be built — projects are not an extension of our normal operations; they are our normal operations.
These reasons make it extremely difficult for us AEC designers to use a generalised 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 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 obtain a ‘generalised’ system there is a heavy amount of customisation that needs to be done to sometimes just get the basics of what a project-based organisation 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? According to one Capterra user report, “functionality (or rather, the lack of the right functionality) is the main reason why users have switched tools in the past”. It’s clearly important to answer these questions.
1. 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 they 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, ask ‘what are the most critical business challenges you need to solve?’— as an organisation and for your role. Then examine the management (both business and project) software systems you have in place to see how well they support the resolution of those challenges.
Assessing required functionality can continue into an audit of your team’s software usage, if you have one. 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
2. 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. This integration can be 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 software 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.
“If you look at Synergy and all the functionality it’s got, our software would cover 80 percent of what any AEC design business does. Then for that other 20 percent of your workflow — 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 core functionality you’ll need for your business.
“The advantage here is that, because they aren’t really part of the core management system (Synergy), if there are any problems with the add-on apps you’re using, you can change them and it’s not going to kill the business because it’s not a mission critical element.
“The mission critical stuff should all come from the same vendor. However, using connected apps also means that if you don’t like that one, get another one — If you’re looking at something like defect management, which is a common process, you could find 1000 different defecting apps on the app store. And from our point of view, so long as the API works, we don’t care which one you use. You could use any one of the 1000 of them, or even different apps on different projects.”
The result? The potential for integrations with 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?
3. 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 be answered when considering an AEC business and project software system is: to be (in the cloud), or not to be (in the cloud)? In a reassuring plot reveal, the answer to that question is simple. Your business software solution needs to be in the cloud — if it’s going to be flexible and accessible enough to meet your needs, it’s not going to be stored on an on-premises server, only useable where it stands.
LogicMonitor’s The 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 now.
The Capterra study mentioned earlier asked users about deployment methods of their current project management tool and found that 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 reach US$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 summary, you want your management software to be as customized 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 Two Birds had to heavily customize for them.
“It worked well for some of the general functions they needed but it failed dismally on most of the features 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 subcontracts. 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.”
Running a small-to-medium architecture, engineering, or construction design business is an effort that goes beyond full-time. Hours spent on business development may seem hard to justify when they’re unbillable, and harder to prioritize in your packed work schedule. It’s understandable. You love built environment design, that’s why you started your business. You want to spend your time on perfecting your designs and wowing your clients with incredible capacity to meet their every structural and aesthetic desire. But what about the business behind the business? Who’s got your back in that all-important operational arena?
Architect and business consultant Lucy Mori says, “I think what’s really important for architects, and for any built environment designers, whether they’re sole practitioners, a small practice, or even a larger firm, is to allocate decent chunks of time in their diary to their business. And to allocate this time before it becomes absolutely urgent”.
Additionally, the business and project management software user report we’ve mentioned repeatedly says, “69 percent of users spent less than six months choosing their software, and 54 percent spent less than six months implementing the software”. That’s not a lot of time in the scheme of things. Especially if you’ve worked out (using the first section of this guide, no doubt) that the ROI of the software will be doubled in the first 12 months of use.
So, how to make sure we minimize the amount of time we need to take as software buyers, and capitalize on the time we do take?
1. Training and support
When assessing your software options, look for something that offers training services or the option of support — while it may be tempting to employ the have-a-stab-yourself method, it will only cost you valuable implementation time and affect staff adoption adversely (more on this in the next section). Make sure your vendor offers services for things like set up and implementation, data migration, and training. And use them.
The truth is, if your software is functionality-rich enough to be a real solution, you need to be guided through the process of getting it set up. Your guide needs to be someone who understands your business — architecture, engineering and construction design practices work in specific ways with specific terminology — and knows the software you’re deploying in order to get it done efficiently, complete with a full understanding of the features most advantageous to your particular operation. Check for online assistance and documentation, forums, training videos, webinars, consultation options and events at a minimum. A lot of software companies will have their help files and videos publicly available so you can have a look at how current they are, how clear they are, and how easy they are to use as a start.
2. Comparing time lost to time saved
Taking into consideration our expected software costs (which we did in section one of this guide — didn’t we?! nudge) it’s important to compare the cost of time lost in implementation to the value of time saved after it. You need to know the time numbers to know the dollar (or pound, or euro) numbers that make up the real cost. Part of being able to work out the value is assessing downtime, or lost time, while the business sets up, versus the amount of time saved once it’s in place. This will put the time it takes for implementation into perspective as you can see the exponential savings spanning into your business’s future.
Lucy Mori says technology can help in terms of time-tracking apps that integrate with your accounting, and accounting systems that integrate with your invoicing.
“These things definitely save time. A lot of it,” she says. “Also, if you’ve spent the time thinking through the business processes, you can delegate these tasks to non-design staff.”
That’s senior staff time (often your own) that has a financial value over and above the time of the person you delegate to. And all of this time can be redirected towards billable project work or growing your business and managing relationships.
3. Length of subscriptions
Lastly, the concern of time reins over your software purchase considerations in terms of contract-length. We looked at this in reference to cost earlier in this guide, in terms of opportunity cost and depreciation, so there’s no need to go into too much detail on the sums here.
What’s important to mention is that any period you’re ‘locked-in’ to a contract term for your software, you need to consider the cost of the time it will take to overhaul the system if it proves not to meet your needs. If you need a re-do on this entire software-buying process in the future, that’s a liability. It’s also a liability that gets greater the longer you stick with, or are contractually obliged to stick with, the wrong software
It helps to start with the fact that there are generally two ways software prices are structured these days. In the traditional way, you pay a larger lump sum up front and then an annual maintenance fee locked-in to a contract over time. Alternately, there’s the subscription model which “essentially means you pay incrementally, flexibly, and with no locked-in terms”.
There’s a temptation here to use the traditional method of software purchase and “pay it now so it’s done”. However, it’s actually not that simple.
Scott Osborne says the cost over a period of time is not just the actual software fees paid to the vendor.
“It’s also the hardware costs, like the server itself which might cost $10,000, and then a backup server at added expense, and the cost of IT managed services companies which might be $500-$1000 a month, and the cost of upgrades,” he says.
“With a subscription-based purchase, if you’re unhappy after two or three months, you can stop paying; you can switch vendors, switch software. It’s a much smaller risk. […] With a month-to-month contract — the software grows when you grow and constricts when you constrict — you can increase and decrease your licence count as required. And if [you’re not being] served as a customer, you can get out. It keeps things honest.”
Of course, if you’re a larger company with a lot of employees, there are almost always longer-term contracts available that offer discounts. In which case, the investment in time to assess and select your software adequately is more important than ever, as is the investment in a proper implementation and training programme. But now we’re being strategic. About software. This is good, because it really is that important.