Is your Architecture Firm Suffering from Technical Debt?

Is your Architecture Firm Suffering from Technical Debt?

Most likely, but to solve the problem, you have to understand the problem.

Technical Debt shows up in architecture firms in a variety of different ways. For instance, if you...

  • are using REVIT (or some other BIM software) to draft in 2d, i.e., paying but not utilizing software to its total capacity
  • have ever made a change in a file to meet a deadline mid-project and continued to use that same workaround the remainder of the project
  • are trying to use one application (like excel) to run everything in your business when there are better solutions
  • find yourself subscribing to a lot of different cloud-based services to run your business, and could probably consolidate some programs
  • do not have a full grasp of all the applications that everyone in your office is using

… your firm is suffering from technical Debt.

Technical Debt is a term that comes out of the software development world and is defined as follows:

Technical debt (also known as design debt or code debt) is the implied cost of additional rework caused by now choosing an easy (limited) solution instead of using a better approach that would take longer.

In architecture firms, technical Debt is often the result of underutilizing or trying to overutilize software which increases the amount of time spent doing something or the unnecessary extra money spent on software applications.

Similar to monetary Debt, if the technical Debt is unaddressed, it can accumulate “interest,” making it harder to implement changes later and increasingly more expensive year after year as the software subscription services continue getting, stealing more time from projects and money from your bottom line. The latter half can quickly increase as you look at the growth in technology spending as more software providers come online and utilize a SAAS business model.

Why are we doing this to ourselves? (For what it’s worth, we’re not the only industry that suffers from this.) For small and medium-sized firms, many leaders need to understand better the software solutions they purchase, whether drafting, project management, communication tools, etc., and reevaluate their current tech stack before they buy more. Larger firms often struggle to keep track of who is using licensed and unlicensed (software employees downloaded themselves) and don’t spend enough time to ensure that everyone uses the software in the most productive way possible.

So how do we solve the problem?

First, we acknowledge that there’s a cost to doing business, and one of the best ways to manage it is to understand the implications of your software decisions properly.

I’ve been in forums where architects want to find the one tool that does it all (it usually means that it doesn’t do it all well), which means that in doing so, you may be saving money but losing time in managing the process.

One example of this is timesheets. I worked for a firm that made everyone fill out their timesheets in excel. It was cost-effective because it was part of the Microsoft suite, and we didn’t pay for any project management software. However, our bookkeeper consumed most of her time:

  1. compiling those timesheets
  2. using them to create project views so project managers would understand how their projects were processing
  3. and finally, using those to invoice clients correctly.

So while we saved money on the software, our project managers often operated with days-old information, and rarely did those on the project clearly understand how many hours they should be billed for each phase of work. The process was also ripe for errors if any numbers were transposed wrong.

Second, understand that SAAS (software as a service) and cloud-based applications are not going away, but knowing that, you can better build it into your operations budget. In the same forums, many architects complain about subscription-based software purchases. Software companies are moving towards SAAS because it’s a better business model. SAAS-based cloud applications also enable companies to provide better solutions for distributed collaborative-based work.

Below are seven ways you can keep your SAAS spending and, in return, technical Debt under control.

  1. Get a list of all the applications that everyone in your company uses (even the free ones).
  2. Assign someone in the firm to own each application; you can spread the responsibility over several individuals if you need to.
  3. Give each owner the responsibility of tracking SAAS product releases (updates) and creating operations, processes, and procedures for the company on how to use the application.
  4. Have each application owner meet regularly, review the apps, and remove redundancies.
  5. Optimize licenses: Does everyone need to be on the most expensive plan? Do you save more by paying annually as opposed to monthly?
  6. Track renewals. Use the renewal process to vet the existing applications and see if there’s a way to negotiate a better deal with the vendor.
  7. Ensure proper onboarding for all applications, especially company-wide ones, for better communication and collaboration.

#design #architect #licreatoraccelerator #practicemanagement #businessoperations

This is a excellent article. Thank you, Evelyn Lee As a vendor to AEC, I would like to point out that technical debt also makes some architects bad consumers. In many other industries, software providers work with their customers to build the products they want. We have found architectural practices which understand this dynamic. But we've also found practices that hold on to 30 year old systems so they don't lose a day to training. They don't understand why they have fewer and fewer days (and fewer dollars to spend on new systems.) #architecture #efficiency #digitaltransition

Louis Schump

Creative Director at Gensler

2 年

the obvious details that few take time to examine or address - thank you evelyn !

I have this thing about how architecture and tech share a lot of concepts — for example: - design staples like hierarchy, grids, and modules - frameworks and tools such as design thinking, user personas, prototyping, and iterative processes - user experience fundamentals such as navigation and legibility Now I’m adding technical debt to the list of shared concepts :-) Which is to say: Agreed. Just as tech orgs regularly audit for and eliminate technical debt, so should architecture firms.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了