Category: home

The Incredible Disappearing CAD/BIM Manager

I’ve danced around this topic a bit before, but let me strike at the heart this time.  One of the benefits of only having customers who are Architectural firms means we get to see some of the trends that happen in the industry, sometimes even a bit earlier than those working directly in it.

One such trend is the minimalization (is that a word?) of the role of CAD Manager, or BIM Manager, or Design Technology Manager, whichever your firm calls it.  In the early days of CAD (when papyrus was used), the CAD Manager bordered on semi-deity.   Computers were scary enough – CAD on computers (yes, redundancy, I know) was even scarier.  Licensing. LISP. Confusing commands, whole other languages!  Users (and leadership) had no problem signing off on the idea that a CAD Manager could be 100% non-billable, and that was still perfectly OK.

Fast forward 10-15 years, and that “unassailable” guy or girl?  Not so much.  The mystique started to roll away.  Many of the functions that CAD Managers had created in LISP became integrated into the product.  Then Revit hit, and the window was cracked open slightly for BIM Managers.  The reality today, however, is that *most* firms use Revit simply as AutoCAD on steroids.  Plans, elevations, and some modelling.  “True” BIM, or BIM as part of IPD, is still some way away.  So whatever awe that BIM Managers were first held in disappeared shortly after leadership realized, hey, we’ve moved X percent to Revit, and we’re doing just fine.

So a devaluation of the position based on the perceived ease of using both AutoCAD and Revit has contributed, but there are other factors.  Someone I respect opined that the reason Leadership doesn’t value the role is that the decision-makers are all right-brained, design-oriented individuals; and that the actual CAD/BIM production process can be very left-brain. And because of that, they have a hard time valuing the role.

Another opinion is that the proliferation of technology in general has devalued technology support roles overall;  that a much higher comfort level with technology – at all levels, including leadership – leads to more questions of “why”, rather than blind acceptance.

Personally, I think all of those contribute, but right now, the economy plays a large role.  A number of AEC firms are slowly emerging from this economy with a much greater desire to be aware of, and to control, finances.  Unlike when we’re all fat and happy, there is a huge focus on the absolute bottom line – what are my dollars in, and what are my dollars out.   In scenarios like those, “soft costs” tend to play a very minor role in comparison to their big, hard cost brother.

And that, in a nutshell, is why the CAD/BIM/DT Manager is slowly fading away.  It isn’t malevolence, it’s just a case of “I have this person who costs me X dollars and they generate Y dollars”.  If Y-X is positive, you’re OK.  When it isn’t, look out.  Because that is a black and white, very easy to see calculation of how you are contributing to the firm’s bottom line.  And it isn’t reasonable to yell at Leadership for thinking this way; too many people in the negative, and no more company.

Many of you have participated in group/individual personality labeling, for more effective communication.  You’re an INTJ, they’re ENFP, or you’re a muffin and they’re an orange, however your particular program divided up people.  At the end of the day, however, most have the same goal: how do you effectively communicate to an ENFP/Muffin?   Current CAD/BIM/DT Managers should be looking at their *organizations* as a personality type that likes cold, hard facts dished up in an analytical, unbiased manner.

So what does that mean?  Metrics.  Stats.  Black and white numbers, without the BS.  You can say to Leadership “I play an essential role”, or “CAD standards are hugely important to productivity” and you’ll get a nod and a “uh-huh”.  You need to be saying “My role saved this firm $250,000 worth of billable man-hours last year”.

This is *not* easy.  Much of what you do *is* soft.  You help.  You create.  For all intents and purposes, every hour you spend non-billable is a complete money sink.  That’s the hard view.  As difficult as it may be, you should start trying to create actual metrics – statistics – for your role.  Especially those that pertain to supporting billable hours or overall productivity.  An easy one is Save-to-Central times.  Let’s say, because of your optimization efforts, each project STC averages 5 minutes faster, and each staffer saves 4 times a day.  And you have 100 Architects.  And they average bill at $150/hour.  Congrats, that’s a million dollars worth of labor saved over a year.  Or how much time is saved from reusing families you’ve created.  Or how much time is saved by team members who move from one project to another not having to learn a new file structure.  Those metrics are out there.  You need to start finding them, and start assigning numbers that aren’t crazy or unrealistic.  They need to pass the B.S. test.

Thusly armed, go forth on a marketing mission.  You can have the best stats in the world, but they won’t help you one bit if no one knows about them.  Don’t wait for the day when they come with bankers boxes.  Either team up, if your firm is small, or find someone in Leadership who believes in your role, and have them help you craft a simple presentation.  Make your case heard, at the very minimum, of once a year.  If you belong to a group, make sure the group leader is doing this at an executive level.

Because believe me, the case needs to be made.  I believe in your role – very strongly – but I’m bucking the trend.

Filed under: home

Technology Debt in IT Operations

There’s a new buzzword making the rounds in appdev circles called “Technical Debt” – basically, the concept that as a project grows/changes, that there is effort required to manage all the implications of the change, and the longer you ignore that work, the more costly it is to correct down the road.

I’m not above plagiarizing (my Facebook page is basically a subReddit) – and I think there’s a corollary to be found when it comes to traditional IT Operations.

Flying Buttress is a consultancy. People don’t reach out to us when they think things are going great internally, that they have everything covered. We get contacted for three basic reasons:

1) Things are a mess, and they need help.

2) They have a ton of work to do, and not enough internal resources.

3) They want an outside ear and outside eyes to give a different perspective or to provide advice.

Personally, my favorite situations are the encounters of the first kind. If you work in IT, you know the satisfaction that comes when you’re able to see the results of your efforts in a tangible way. The mess-cleaning situations are like any other cleanup operation; there isn’t a lot of complexity – plan well, spend well, and put in a lot of elbow grease.

But over 20 years, when I’ve seen bad IT situations, it is usually because firms have accumulated too much technology debt. One of the main concepts of proper IT management is that it requires a constant annual spend. Major fluctuations, either upward or downward, can have severe long-term effects (i.e., dropping a huge amount of money to replace all the computers which means they all end-of-life at the same time rather than in a controlled, staggered manner).

In Architecture firms, my *very* loose rule of thumb is that the IT spend for a firm in standard, non-aggressive IT mode is about 6% of NSR (Net Service Revenue). As revenue goes up, projects come in, bodies get hired, spend goes up; and conversely, bodies lost means IT spend down. But if you start grossly cutting that into the 2-3-4% range, you start accumulating technology debt.

It is not an uncommon situation. Things get bad over time, so leadership goes out and says “hey, we’re in trouble, let’s spend a bunch of money and fix all this”. Consultants brought in, new hardware purchased, and yes, things get better. And soon – sooner than you might think – that need for a consistent annual maintenance spend is forgotten. There’s a “coasting” effect of that injection of equipment that doesn’t always speak to the multitude of components that comprise IT operations.

If you’re Leadership, and reading this – I’m not making this argument to get you to spend money. I’m making this to save you money. Because in IT, that technology debt doesn’t just have a hard-dollar connotation. You will lose far more money over time in outages, lost data, speed issues, and general productivity than you will that 5-6% of NSR. I’ve seen it.

Here’s the dumb car analogy. I’m the mechanic. I’m telling you you need to spend about $100 a year taking care of the various parts on your car. This amount varies based on how nice of a car you have. You tell me, well, I just spent $300 two years ago getting the brakes done. That’s great, but you still need your fan belt changed, wiper fluid, and your left taillight is out. You can pay me $100 a year now to make sure those are taken care of, or we can wait until you’re broken down on the freeway.

I am willing to have philosophical discussions about the relevance and importance of technology to Architecture, but I’m also able to just view it in cold black and white numbers. And technology debt – especially debt that can come due at the worst possible time – is just not good for business.

Filed under: home

Metrics, metrics and more metrics

IT always feels a bit behind the corporate 8-ball when it comes to justifying costs. There’s two main factors for this – the first is that for almost all firms, IT represents the biggest pure overhead money suck (behind labor), with usually zero net income to show for it. Second, IT workers tend to make more money that other support group functionaries, from entry level to skilled labor.

So for 99% of firms, when the c-levels look at the balance sheets, the IT spend is just seen as a painful cost of doing business, with it appearing a bit like the Pentagon’s Black Ops budget – money going in without a good understanding of *what it all means*.

None of that is going to change anytime soon. But with Architects and Engineers – who live and die by exact hour calculations, meticulous details, and precise metrics regarding WIP and profitability – it’s an uncomfortable state. And the default reaction is to try and get IT metrics through a ticketing system.

There’s a bit of built-in conflict here; never, ever do the execs want to force users to open a ticket to get help – but at the same time, they want to see exactly how busy IT is – how responsive it is, how many tickets we did this year compared to last, and more importantly, do we really need that tech in Buffalo?

While this makes perfect sense on the surface, for Architects and Engineers, this is a trap. And here’s why.

1) It is not the statistic you should be caring about. It is very possible that your team does 1000 tickets a year, and the staff hates IT. You can do 900 tickets a year, and the staff loves IT. What is it you really want? Do you want IT to be perceived as responsive, supportive, with excellent customer service? If so, the number of tickets opened/closed will tell you absolutely nothing in that regard. What will? Customer surveys, annually/biannual/quarterly. Identify what the users think you’re doing right/doing wrong, and adjust accordingly.

2) Your IT staff will focus less on customer service, and more on ticket creation/closing. Once IT realizes that the metric leadership cares about is tickets, *that* becomes their focus. User wants a mouse? Ticket. Forgot the wifi password? Ticket. Is it ridiculous to imagine that if a tech knows they’re “short” that month on tickets, that they create some? We all know how police work with their ticket quotas. Is that really what you want IT focused on?

3) It’s a slippery slope. The next logical progression to this becomes the “you need to open a ticket” comment. The phrase users hate hearing. Once ticketing becomes the be-all, end-all, however, the mandatory ticket comment isn’t far behind, either by de facto or de jure.

And that’s not for design firms. Architects and Engineers are high-touch professions. You’re used to getting the same level of service you provide to your clients in turn. That means that the IT guy is sitting out on the floor with everyone else and not in a call center in India, which would be a hell of a lot cheaper. When you’re on a deadline and can’t save a file, you don’t want to talk to “Rick in Bangalore”, you want to talk to a guy you know, and you sure don’t want to have to open a ticket to talk to him.

Tickets have their place. In very large firms, when you have a team or staff who never leave their cubicle, whose only task is to churn through ticket after ticket remotely supporting users, it can help. But that just doesn’t exist in firms under several thousand staff. And it certainly isn’t conducive to providing the highest levels of customer service.

It’s easy to understand the desire to try and tie down some aspects of the ethereal IT spending pit. But it needs to happen in reverse. What do you truly want from your IT organization? And is that goal measured by how leadership and staff feel about IT, or about whether Sally opens 8 vs. 10 tickets in a day?

Filed under: home

Interview with a BIMmie – Gautam Shenoy, Steinberg Architects

This week’s interview is with Gautam Shenoy, BIM Director with Steinberg Architects.

Filed under: home