Please visit us at:
http://www.gregmoorepdx.com/index.php/category/architecture/
Monday, June 7, 2010
Monday, April 12, 2010
It's all code
How times change.
Back in 2007, I lamented that technology is "all code." In those days, as a AEC technology specialists, we were coming to the end of that age - when everything we wanted to do was all code.
Today, it's a very different story. Not too surprisingly, we have tools available to us that are changing our industry - and I don't recall writing a single line of code. AEC is embracing a strange sense of comradeship among the different disciplines. Perhaps we've either realized nobody listens to the complaining of just one sector or we've banded together in a survival mode.
Some time ago Integrated Project Delivery - still a vaporware concept - popped up out of nowhere. It is now driving the AEC industry to consolidate liability and production methodologies to capitalize on the various different expertise bases that exist in the industry. Ultimately, projects should be delivered quicker, cheaper and better designed. Regardless of the current state of hold-up in the industry to fully realize this dream, supporting technologies are pushing forward - such as: BIM, PIM and DAM to name a few.
We don't write a lot (if any) code any more if we're hopping on these bandwagons. This is a good thing. You can't expect an Architect to write code to enable his or her workflow. Automating one-off needs, perhaps - but not the whole flow. Leave that to the IT department, and at that - in a limited capacity.
The purpose of code is to create electronic tools that can be used by one or more people. Fortunately, we've all but moved to models of developing for more than just the self. Ironically, we still find the one-off nature of many Architectural firms still dictating one-off code, too.
As our tools become more advanced, easier to use and understanding of how we use them, our practice will continue to go through a long-term normalization phase that will ultimately remove the idiosyncrasies within our industry that have long plagued us. We'll be able to collaborate more. We can design better. We can design faster. We can design, period. Production work of decades past will become less and less of a burden.
We thought for a long time that the solution was to spend more time on our design and strategies. That was a result of the barriers that have been put in place (liability, in particular) by a dispassionate building industry intent only on quick, large profits. As we work to partner together more and more, we remove or change many of these boundaries.
Will Architects ever return to their former glory as societal icons? It's not likely. After all, there are lots of them and the practice looks nothing like it did 1000 years ago when the pyramids were being constructed. Times have changed and they continue to do so.
Back in 2007, I lamented that technology is "all code." In those days, as a AEC technology specialists, we were coming to the end of that age - when everything we wanted to do was all code.
Today, it's a very different story. Not too surprisingly, we have tools available to us that are changing our industry - and I don't recall writing a single line of code. AEC is embracing a strange sense of comradeship among the different disciplines. Perhaps we've either realized nobody listens to the complaining of just one sector or we've banded together in a survival mode.
Some time ago Integrated Project Delivery - still a vaporware concept - popped up out of nowhere. It is now driving the AEC industry to consolidate liability and production methodologies to capitalize on the various different expertise bases that exist in the industry. Ultimately, projects should be delivered quicker, cheaper and better designed. Regardless of the current state of hold-up in the industry to fully realize this dream, supporting technologies are pushing forward - such as: BIM, PIM and DAM to name a few.
We don't write a lot (if any) code any more if we're hopping on these bandwagons. This is a good thing. You can't expect an Architect to write code to enable his or her workflow. Automating one-off needs, perhaps - but not the whole flow. Leave that to the IT department, and at that - in a limited capacity.
The purpose of code is to create electronic tools that can be used by one or more people. Fortunately, we've all but moved to models of developing for more than just the self. Ironically, we still find the one-off nature of many Architectural firms still dictating one-off code, too.
As our tools become more advanced, easier to use and understanding of how we use them, our practice will continue to go through a long-term normalization phase that will ultimately remove the idiosyncrasies within our industry that have long plagued us. We'll be able to collaborate more. We can design better. We can design faster. We can design, period. Production work of decades past will become less and less of a burden.
We thought for a long time that the solution was to spend more time on our design and strategies. That was a result of the barriers that have been put in place (liability, in particular) by a dispassionate building industry intent only on quick, large profits. As we work to partner together more and more, we remove or change many of these boundaries.
Will Architects ever return to their former glory as societal icons? It's not likely. After all, there are lots of them and the practice looks nothing like it did 1000 years ago when the pyramids were being constructed. Times have changed and they continue to do so.
Friday, September 18, 2009
Retire your Wizard hat
For many companies, trust in IT is waning. This is particularly true in organizations with long established IT. Gone are the days when we were the experts in everything. Simply put, there’s too much to know and many of our users are much better with the application of technology and user interfaces than we are. On the same hand, we’re far more adept at certain aspects of it than they are.
In our firm, we have a older generation of employees and owners who are experienced and classically trained in Architecture. They have a background in getting things done with or without technology. With some notable exceptions, most in this category have established means and methods for accomplishing their work and continue to lean on IT for much of their Technological needs and questions. Google and Email are their primary Internet destinations, only as needed. “Do I click or double click” questions are still common. They are cognoscente of their impact on the network – bandwidth, storage use, etc. They see your yearly budget and know what you spend and roughly why.
Then there is the younger generation. They grew up with technology. They aren’t afraid of it. Many have become more adept at it than IT is. They call IT when they can’t get to their Gmail, Facebook or Twitter account or when they can’t remember an AutoCAD command they may have used in college. Issues such as archiving, storage capacity, bandwidth, etc are someone else’s problem in their mind. They complain and deem you incompetent when things are slow or down.
The younger generation is challenging much of our established, antiquated assumptions about what we truly manage and provide. Interface questions like clicking vs. double clicking don’t come out of this generation. Questions such as “Why can’t I use BitTorrent?” and “Why aren’t we just using Gmail instead of Outlook?” can be expected. When they need a solution to a task at hand, they don’t email helpdesk – they hit Google, Twitter, Wikipedia, Blogs and Forums. They find something cool, try it out and spread the word with the other younger employees via Twitter, IM and email.
As a result, this younger generation sees IT as getting in the way of progress. Yes, we block a dangerous stuff on the Internet. No, you’re not free to install anything you want on your company-owned computer. Yes, we buy the software and install it. No, you don’t get to have a Mac. No, you can’t have the Adobe CS suite. Yes, we have standards. No, it’s not okay to insist the Contractor only talk to you via email (this really came up recently).
Without going too much into social differences between generations, the conclusion is that the expectations are different. The younger staff want us to get out of their way, the older staff prefer we show them what to do.
Where does that leave IT? In a strange spot. Bridging a ever widening gap effectively between owners and employees. It’s uncomfortable and makes us seem like a-holes to the youngsters and ineffective at maintaining consistency in the organization to the older generation. Yikes!
What’s to be done? Here’s a few things I’m trying right now. Your mileage will vary depending on your firm culture:
1. Look over the shoulders of the younger staff. They can teach you a lot about what they’re using. You can’t keep them off the Internet (nor should you), so take the opportunity to learn from them what it is that they’re doing. Find out what they would like to do if you allowed (or the firm allowed) them to do it. You are no longer the wizard. Your wizard hat is retired. Accept this. Your career depends on it.
2. Bring the Older staff up to speed. Principals and PM’s are notoriously ‘busy’. Little do they realize, mastering the use of technology is no longer an optional situation. To save face (for you and your owners/pm’s), spend time either one-on-one with them just exposing to technologies that the younger staff is using. Plant the seed that if they learn some new and more efficient ways of doing things, they may not be so busy all the time. Let them know about your wizard hat retirement.
3. Bring the Younger staff up to speed. The young ones aren’t always right. Hear them out, but bring them up to speed on why we do things the “old way.” This is an amazingly successful tactic. Either you will correct their misgivings about why certain rules and processes are in place, or you will learn a new way of thinking that may be the red-tape cutting opportunity to feed real change to old-school policies and procedures.
4. Educate everyone together, let others educate you. Try changing your training sessions into discussions and knowledge transfers. Present your training for the first half, spend the second half discussing the applicability to process and different methods for accomplishing tasks. Try spreading real knowledge, not just “How-To’s”.
5. Revise old Rules publicly. You’ve probably got old policies that are overly restrictive. Change some and flaunt to the office how less restrictive they now are. Put some trust into your employees and ensure that you have communicated to them your newfound trust in them. Yes, it’s risky. Older staff may grumble.
6. Use well known “credible” sources validate your assertions. If Walt Mossberg or David Pogue say it’s the best thing since sliced bread, and you happen to agree – run with it. If, however, Mike Vizzard is ga-ga over something, think twice. Nobody knows who he is except us. You may as well say “my hamster likes it.” Architects don’t trust most experts.
7. Be the Dictator sparingly. Nobody likes a dictator. Yes, you know a lot more than they do and have to clean up their mess when things go bad. Don’t slap someone on the hand if you don’t have to. See #5. Remember that your job isn’t to make your job easier. It’s to make everyone else’s job easier.
8. Talk about the Infrastructure. For the staff that are technologically inclined, clue them in to the impacts of their interests on the infrastructure. Listen to their suggestions, try not to laugh and really put some thought into how their ideas could work (and why they won’t if it’s really true) and be candid about the costs. Remember that the Internet is “free” in many minds. The reality of a corporate infrastructure costing lots of money is mind boggling to some as a result. How many people in your office steal Internet at home from their neighbors? You may be shocked how many. You may be even more shocked as to how many feel that it’s their right to do so.
In our firm, we have a older generation of employees and owners who are experienced and classically trained in Architecture. They have a background in getting things done with or without technology. With some notable exceptions, most in this category have established means and methods for accomplishing their work and continue to lean on IT for much of their Technological needs and questions. Google and Email are their primary Internet destinations, only as needed. “Do I click or double click” questions are still common. They are cognoscente of their impact on the network – bandwidth, storage use, etc. They see your yearly budget and know what you spend and roughly why.
Then there is the younger generation. They grew up with technology. They aren’t afraid of it. Many have become more adept at it than IT is. They call IT when they can’t get to their Gmail, Facebook or Twitter account or when they can’t remember an AutoCAD command they may have used in college. Issues such as archiving, storage capacity, bandwidth, etc are someone else’s problem in their mind. They complain and deem you incompetent when things are slow or down.
The younger generation is challenging much of our established, antiquated assumptions about what we truly manage and provide. Interface questions like clicking vs. double clicking don’t come out of this generation. Questions such as “Why can’t I use BitTorrent?” and “Why aren’t we just using Gmail instead of Outlook?” can be expected. When they need a solution to a task at hand, they don’t email helpdesk – they hit Google, Twitter, Wikipedia, Blogs and Forums. They find something cool, try it out and spread the word with the other younger employees via Twitter, IM and email.
As a result, this younger generation sees IT as getting in the way of progress. Yes, we block a dangerous stuff on the Internet. No, you’re not free to install anything you want on your company-owned computer. Yes, we buy the software and install it. No, you don’t get to have a Mac. No, you can’t have the Adobe CS suite. Yes, we have standards. No, it’s not okay to insist the Contractor only talk to you via email (this really came up recently).
Without going too much into social differences between generations, the conclusion is that the expectations are different. The younger staff want us to get out of their way, the older staff prefer we show them what to do.
Where does that leave IT? In a strange spot. Bridging a ever widening gap effectively between owners and employees. It’s uncomfortable and makes us seem like a-holes to the youngsters and ineffective at maintaining consistency in the organization to the older generation. Yikes!
What’s to be done? Here’s a few things I’m trying right now. Your mileage will vary depending on your firm culture:
1. Look over the shoulders of the younger staff. They can teach you a lot about what they’re using. You can’t keep them off the Internet (nor should you), so take the opportunity to learn from them what it is that they’re doing. Find out what they would like to do if you allowed (or the firm allowed) them to do it. You are no longer the wizard. Your wizard hat is retired. Accept this. Your career depends on it.
2. Bring the Older staff up to speed. Principals and PM’s are notoriously ‘busy’. Little do they realize, mastering the use of technology is no longer an optional situation. To save face (for you and your owners/pm’s), spend time either one-on-one with them just exposing to technologies that the younger staff is using. Plant the seed that if they learn some new and more efficient ways of doing things, they may not be so busy all the time. Let them know about your wizard hat retirement.
3. Bring the Younger staff up to speed. The young ones aren’t always right. Hear them out, but bring them up to speed on why we do things the “old way.” This is an amazingly successful tactic. Either you will correct their misgivings about why certain rules and processes are in place, or you will learn a new way of thinking that may be the red-tape cutting opportunity to feed real change to old-school policies and procedures.
4. Educate everyone together, let others educate you. Try changing your training sessions into discussions and knowledge transfers. Present your training for the first half, spend the second half discussing the applicability to process and different methods for accomplishing tasks. Try spreading real knowledge, not just “How-To’s”.
5. Revise old Rules publicly. You’ve probably got old policies that are overly restrictive. Change some and flaunt to the office how less restrictive they now are. Put some trust into your employees and ensure that you have communicated to them your newfound trust in them. Yes, it’s risky. Older staff may grumble.
6. Use well known “credible” sources validate your assertions. If Walt Mossberg or David Pogue say it’s the best thing since sliced bread, and you happen to agree – run with it. If, however, Mike Vizzard is ga-ga over something, think twice. Nobody knows who he is except us. You may as well say “my hamster likes it.” Architects don’t trust most experts.
7. Be the Dictator sparingly. Nobody likes a dictator. Yes, you know a lot more than they do and have to clean up their mess when things go bad. Don’t slap someone on the hand if you don’t have to. See #5. Remember that your job isn’t to make your job easier. It’s to make everyone else’s job easier.
8. Talk about the Infrastructure. For the staff that are technologically inclined, clue them in to the impacts of their interests on the infrastructure. Listen to their suggestions, try not to laugh and really put some thought into how their ideas could work (and why they won’t if it’s really true) and be candid about the costs. Remember that the Internet is “free” in many minds. The reality of a corporate infrastructure costing lots of money is mind boggling to some as a result. How many people in your office steal Internet at home from their neighbors? You may be shocked how many. You may be even more shocked as to how many feel that it’s their right to do so.
Wednesday, July 1, 2009
Stay Tuned...
It's been a little while since I last posted. I just wanted to give everyone a heads up that I'm working on two separate articles that I think you will all be interested in:
Vendor Management
Understanding your vendors and how to manage them most effectively will depend a lot on your own internal resources, despite vendor promises to make things "easier".
Cloud Computing: What you should know
Today we find ourselves bombarded with the notion of cloud computing. What is it and why on earth would anyone in Architecture actually be interested in it? You may be surprised to find that it's not far from reach, even for Mid-sized firms. You may also be surprised to learn that you can host your own cloud right from your server closet!
Stay tuned for these and more articles!
Vendor Management
Understanding your vendors and how to manage them most effectively will depend a lot on your own internal resources, despite vendor promises to make things "easier".
Cloud Computing: What you should know
Today we find ourselves bombarded with the notion of cloud computing. What is it and why on earth would anyone in Architecture actually be interested in it? You may be surprised to find that it's not far from reach, even for Mid-sized firms. You may also be surprised to learn that you can host your own cloud right from your server closet!
Stay tuned for these and more articles!
Thursday, April 9, 2009
Downturn Economy: Strategies that Don't Work
Distributing Coordination Responsibilities
When you take responsibilities that really are best done by one person, say managing a Samples Library, writing AIA contracts or organizing and distribute it among multiple people, problems will happen. It's a simple case of no leadership and central decision making. How one person goes about it will undoubtedly conflict with another person's strategy. In the end, unless you set ground rules (not guidelines, but hard rules) on how tasks are to be carried out, you're asking for a complete collapse of a system your firm likely spent many hours and dollars to make right.
Waiting for the perfect RFP
Let's face it, RFP's are in short supply today. Striking a balance between what you go after and what you decide is a "No-Go" just got a little more difficult. For firms that don't go after anything under $5 million, let's say, may find themselves hurting to find RFP's to go after. Consider the market and react, don't wait. If you need to go after the little $1-2 million projects, do it. You might be surprised how often you win these.
Putting Technology Development Projects on Hold
There are probably a few development projects you have that really only benefit one person, department or group. These can go on hold. Take a look at everything else and look at it closely. The firms that survive this recession must stand out. Technology is a critical component for development in these uncertain and slow times. Your ability to meet client needs with technology will impress and could be the difference between your being selected or your competition.
Spreading Everyone Too Thin
After a layoff, the questions of who will do the work that former employees did is perhaps the most perplexing to answer. The bottom line is, don't ask one or two people to shoulder the load. Use the whole office, make it clear what everyone is now responsible for handling, and set some ground rules for how it's done (remember, it's not a democracy - it's YOUR firm). Likewise, don't assign marketing tasks to a design Architect that hates marketing (hard to believe, but there are those who are just that arrogant out there).
Change Everything
It's easy for an Executive to decide to change everything that the firm does to try and "Re-invent" the firm. Don't do this. Change that is managed and done incrementally is the most successful, particularly when it impacts day-to-day routines that are long established.
When you take responsibilities that really are best done by one person, say managing a Samples Library, writing AIA contracts or organizing and distribute it among multiple people, problems will happen. It's a simple case of no leadership and central decision making. How one person goes about it will undoubtedly conflict with another person's strategy. In the end, unless you set ground rules (not guidelines, but hard rules) on how tasks are to be carried out, you're asking for a complete collapse of a system your firm likely spent many hours and dollars to make right.
Waiting for the perfect RFP
Let's face it, RFP's are in short supply today. Striking a balance between what you go after and what you decide is a "No-Go" just got a little more difficult. For firms that don't go after anything under $5 million, let's say, may find themselves hurting to find RFP's to go after. Consider the market and react, don't wait. If you need to go after the little $1-2 million projects, do it. You might be surprised how often you win these.
Putting Technology Development Projects on Hold
There are probably a few development projects you have that really only benefit one person, department or group. These can go on hold. Take a look at everything else and look at it closely. The firms that survive this recession must stand out. Technology is a critical component for development in these uncertain and slow times. Your ability to meet client needs with technology will impress and could be the difference between your being selected or your competition.
Spreading Everyone Too Thin
After a layoff, the questions of who will do the work that former employees did is perhaps the most perplexing to answer. The bottom line is, don't ask one or two people to shoulder the load. Use the whole office, make it clear what everyone is now responsible for handling, and set some ground rules for how it's done (remember, it's not a democracy - it's YOUR firm). Likewise, don't assign marketing tasks to a design Architect that hates marketing (hard to believe, but there are those who are just that arrogant out there).
Change Everything
It's easy for an Executive to decide to change everything that the firm does to try and "Re-invent" the firm. Don't do this. Change that is managed and done incrementally is the most successful, particularly when it impacts day-to-day routines that are long established.
Monday, May 12, 2008
Technology: The Art of the Now
The most common complaints I hear today about technology today is:
Let's consider for a moment that the automobile has one major purposes: Getting you from Point A to Point B. This is a simple MO to accomplish.
Then, lets consider the Personal Computer. It's purposes are endless - only limited by imagination. It's a canvas of unlimited potential just waiting to be assembled into the masterpiece that you wish it to be.
Your PC may be best suited as a business productivity enhancer or perhaps a personal life organizer. It might be the repository for all things that are important to you or your company.
The similarities with a painting or sculpture end there.
Technology is a constantly changing masterpiece. Sometimes, it looses form and has to be rethought. Sometimes, it's amazing in ways that you will only come to appreciate in time. The point is - it's always changing.
Technology is, in fact, the Art of the Now.
Sure, it's frustrating when you spend a ton of money on something that's obsolete the minute you walk out the door and probably doesn't even work right out of the box. It's very similar to the buildings your firm designs. It's not going to be perfect and do everything. It may be pretty, it may be functional, it may be somewhere in between.
Just like your clients, you must be keen to what your needs are. Stop trusting your computers will do what you want them to and ask the tough questions. Technologists are just now getting it and coming up to speed with this idea that their product won't solve world hunger or put a stop to war. It happened to Architects at one point. Let's do our part to educate the technologists of the world on their changing role. Tough love is the name of the game.
- Cost
- Planned Obsolescence
- Unnecessary Features
Let's consider for a moment that the automobile has one major purposes: Getting you from Point A to Point B. This is a simple MO to accomplish.
Then, lets consider the Personal Computer. It's purposes are endless - only limited by imagination. It's a canvas of unlimited potential just waiting to be assembled into the masterpiece that you wish it to be.
Your PC may be best suited as a business productivity enhancer or perhaps a personal life organizer. It might be the repository for all things that are important to you or your company.
The similarities with a painting or sculpture end there.
Technology is a constantly changing masterpiece. Sometimes, it looses form and has to be rethought. Sometimes, it's amazing in ways that you will only come to appreciate in time. The point is - it's always changing.
Technology is, in fact, the Art of the Now.
Sure, it's frustrating when you spend a ton of money on something that's obsolete the minute you walk out the door and probably doesn't even work right out of the box. It's very similar to the buildings your firm designs. It's not going to be perfect and do everything. It may be pretty, it may be functional, it may be somewhere in between.
Just like your clients, you must be keen to what your needs are. Stop trusting your computers will do what you want them to and ask the tough questions. Technologists are just now getting it and coming up to speed with this idea that their product won't solve world hunger or put a stop to war. It happened to Architects at one point. Let's do our part to educate the technologists of the world on their changing role. Tough love is the name of the game.
Sunday, November 11, 2007
When Architecture Gets "Ignored"
A criticism that I've had over the years from various Architects is that IT appears to spend more time researching and protecting systems than supporting the actual practice of Architecture.
It's hard to argue with this on the surface: Security issues, rapid mandatory upgrade cycles and the BIM movement have made a lot of tough work for the IT department in recent years. Looking back, many IT departments were better suited to support our Architectural staff when these issues were minor or didn't exist.
But that's the past, and this is now. The long and short of it is something of a "Coming to Jesus" realization for both management and technology departments both.
1. Technology isn't getting cheaper or better - In fact, one might be able to argue that it's getting more expensive simply on the grounds of demand. As far as I can see, this trend is unlikely to abate. As modern designers, we tend to consider an improvement to technology as a simplification of seemingly unnecessary complexity. Rarely does this happen. Technology companies make money when you buy a new product. We've taught them that we're willing to do this, even when paper-thin promises for new functionality are the basis for purchase.
2. New pressures are added to the IT plate constantly - Didn't see "Green Computing" coming, did you? I certainly didn't. I had written it off as a fad attached to the Green political campaign and never considered the facts and implications of my data center consumption. Just like the Green movement, new large initiatives will continue to appear. Most of them won't be the brain child of the IT department.
3. The Internet should be rethought - Its difficult to argue against a disconnection of the Internet, but your firm should consider it - at least as a "what-if" exercise. Step back and be sure you understand why you have Internet to every computer. Evaluate if it's really necessary or if there are better ways. It's a good exercise to understand why you got it in the first place and how it's developed into a business tool.
4. Technology will only get more complex for everyone - More programs, services and ways of using technology are coming onto the scene every day. The number of updates to your existing software is even more staggering. Everyone, not just IT, will continue to need training on a regular basis. It's difficult to keep up on and one could argue that much of it provides little benefit to Architectural practice. Regardless, our software and hardware vendors continue to focus us on staying current by changing license and support agreements. This renders your mastery of any software or "electronic" process or work flow obsolete immediately. There will always be a supposedly better way to accomplish anything.
5. Remember that Architecture comes first - If you're firm is like mine, the business of Architecture comes first. Remember this always, IT guy. You may "need" to deploy a security update immediately, but your PM's and PIC's can't be slowed down by it. They have jobs to do to. The buck used to stop with you, but now that's not always the case. You still call the shots on how, but when and how much is costs may be up to a larger group of people to decide. This is perhaps the most frustrating part for seasoned IT. We do have to let others in on our decision processes more often than before. It's uncomfortable, and nobody is as qualified as you to make the decision from a technical perspective. Hold your ground, but don't ignore your fellow co-workers. They're needs are in fact important.
There isn't a hard-and-fast solution for any firm. If you experiencing growth, this is the time that can be the most frustrating for you. You're going to be pulled from all directions and you are going to get the lowest level of compliance with your policies you'll ever see. Hang in there, do your best to remind people of the rules and never loose your cool. It could be the difference in your continued employment and you being outsourced.
To be successful in the current state of Technology, IT must roll up their sleeves and put in some elbow grease to succeed. Remember how hard you worked to get AutoCAD 2005 deployed? Get ready to invest energy like that more often. IT people are the worst work ethic examples and are master procrastinators (we spend much of our time trying to find a "better and more efficient" way to accomplish something rather than just doing it). It's in our best interest to shed ourselves of that mindset and label. Become a doer!
Last - Re-evaluate yourself. Do you still want to pursue a career in IT? It's getting tougher. If this level of pressure and responsibility (and proactiveness!) aren't comfortable, it may be time to consider steeping into a different profession. Your job is to ensure your Architectural staff can do their job. This is job #1. If you can't see eye to eye with this and still insist on focusing on patching and upgrading constantly, consider looking elsewhere for work. You'll save yourself and your firm a great deal of heartache.
It's hard to argue with this on the surface: Security issues, rapid mandatory upgrade cycles and the BIM movement have made a lot of tough work for the IT department in recent years. Looking back, many IT departments were better suited to support our Architectural staff when these issues were minor or didn't exist.
But that's the past, and this is now. The long and short of it is something of a "Coming to Jesus" realization for both management and technology departments both.
1. Technology isn't getting cheaper or better - In fact, one might be able to argue that it's getting more expensive simply on the grounds of demand. As far as I can see, this trend is unlikely to abate. As modern designers, we tend to consider an improvement to technology as a simplification of seemingly unnecessary complexity. Rarely does this happen. Technology companies make money when you buy a new product. We've taught them that we're willing to do this, even when paper-thin promises for new functionality are the basis for purchase.
2. New pressures are added to the IT plate constantly - Didn't see "Green Computing" coming, did you? I certainly didn't. I had written it off as a fad attached to the Green political campaign and never considered the facts and implications of my data center consumption. Just like the Green movement, new large initiatives will continue to appear. Most of them won't be the brain child of the IT department.
3. The Internet should be rethought - Its difficult to argue against a disconnection of the Internet, but your firm should consider it - at least as a "what-if" exercise. Step back and be sure you understand why you have Internet to every computer. Evaluate if it's really necessary or if there are better ways. It's a good exercise to understand why you got it in the first place and how it's developed into a business tool.
4. Technology will only get more complex for everyone - More programs, services and ways of using technology are coming onto the scene every day. The number of updates to your existing software is even more staggering. Everyone, not just IT, will continue to need training on a regular basis. It's difficult to keep up on and one could argue that much of it provides little benefit to Architectural practice. Regardless, our software and hardware vendors continue to focus us on staying current by changing license and support agreements. This renders your mastery of any software or "electronic" process or work flow obsolete immediately. There will always be a supposedly better way to accomplish anything.
5. Remember that Architecture comes first - If you're firm is like mine, the business of Architecture comes first. Remember this always, IT guy. You may "need" to deploy a security update immediately, but your PM's and PIC's can't be slowed down by it. They have jobs to do to. The buck used to stop with you, but now that's not always the case. You still call the shots on how, but when and how much is costs may be up to a larger group of people to decide. This is perhaps the most frustrating part for seasoned IT. We do have to let others in on our decision processes more often than before. It's uncomfortable, and nobody is as qualified as you to make the decision from a technical perspective. Hold your ground, but don't ignore your fellow co-workers. They're needs are in fact important.
There isn't a hard-and-fast solution for any firm. If you experiencing growth, this is the time that can be the most frustrating for you. You're going to be pulled from all directions and you are going to get the lowest level of compliance with your policies you'll ever see. Hang in there, do your best to remind people of the rules and never loose your cool. It could be the difference in your continued employment and you being outsourced.
To be successful in the current state of Technology, IT must roll up their sleeves and put in some elbow grease to succeed. Remember how hard you worked to get AutoCAD 2005 deployed? Get ready to invest energy like that more often. IT people are the worst work ethic examples and are master procrastinators (we spend much of our time trying to find a "better and more efficient" way to accomplish something rather than just doing it). It's in our best interest to shed ourselves of that mindset and label. Become a doer!
Last - Re-evaluate yourself. Do you still want to pursue a career in IT? It's getting tougher. If this level of pressure and responsibility (and proactiveness!) aren't comfortable, it may be time to consider steeping into a different profession. Your job is to ensure your Architectural staff can do their job. This is job #1. If you can't see eye to eye with this and still insist on focusing on patching and upgrading constantly, consider looking elsewhere for work. You'll save yourself and your firm a great deal of heartache.
Subscribe to:
Posts (Atom)