Is the solution also the problem?
As designers we communicate our design intent using a number of different media and I think it is fair to say that good communication skills are at the very core of a good architect. So by improving the quality of communication we can improve the entire design and construction process.
The way that we communicate today is different from the way we communicated 10 years ago, which was different from the way our ancestors communicated 100 years before that. While the environment within which we communicate has developed around available technology, traditionally we have changed our process to suit the tools available to us.
People ask me all the time 'which CAD application should I buy?' and my answer is always the same: 'It doesn't really matter which application you buy, what does matter is how you use it. ' It is how you use the tool to communicate with others. Sure, some applications are more suited to the kind of projects you undertake than others, but all of them will perform the simplest of tasks required to get the job done. All CAD applications deliver tools to draw on the computer and print onto paper.
Unfortunately, there appears to be a real drive to get away from 'selling' CAD in favour of 'delivering solutions'. It appears that it is friendlier to provide a solution, to solve a problem. There is much better karma from helping someone than there is in pursuing them for their money - a process which leads to problems. When you sign a cheque for a solution you think it is a job done. Sorted. Problem solved. No more money to spend. But the purchase rarely performs as expected. You bought it based on the understanding that it was going to work the way you work, but it does not. So to get the job done you change your process to fit the tool. Immediately you are in an unfamiliar environment.
Imagine what would happen if everyone changed the way that they worked every time that they started a new project - but an alarming amount of practices do exactly that. Because CAD enables us to communicate in a new way by sharing CAD data, our process has changed to accommodate it. We are all now able to use CAD drawings from other consultants as overlays. This means that we no longer need to redraw the information from the engineer or trace over the M&E drawings to view the graphics together.
All of this makes sense but changing your process for each project does not. It will complicate your project resourcing, increase errors and waste time while each person learns the new system. If different projects are working in different ways you cannot simply move designers internally between teams to cope with the fluctuating demand as they will be unfamiliar with the structure of the information.
Although the concept of making information available for the team to share is difficult to knock, it is not without problems. I go back to my earlier point: which CAD application is largely irrelevant, the important thing is how you use it.
It does not matter which standard you use so long as you use one. We can make the computer do the rest for us. Our standards could be converted automatically to those of another party with minimal intervention. In exactly the same way, we can make IT work for us by automating the process of swapping one standard data structure within drawings for another.
The whole idea of having a standard data structure is often regarded as 'complex' and 'difficult' to learn. And it can be. But like everything else we have considered so far, there is an easy solution.
Should we make changes to our process or should we make changes to our tool?
The smart folks would make changes to the tool to accommodate the process. Introducing a complex structure can be off-putting and in many cases leads practices to the conclusion that it is too complicated to be useable. That may well be the case, but it does not have to be.
When CAD applications are developed, there has to be a balance between ease of use and powerful functionality. People will not adopt a solution if the adoption process is too complicated. This means that getting CAD standards off the ground can be a nightmare. Making the adoption process easier is essential.
Only when it makes the day-to-day working environment better will it be accepted readily. The solution is to integrate the standards within the application interface, enabling designers to continue working without having to consider the data structure behind the scenes.
Many practices will describe their skill and dexterity in computer usage, and will describe themselves as 'leading edge', as 'pushing the boundaries' of the technology. But when you look closer you find that their skill is in three-dimensional modelling or rendering. The technology is not flinching, never mind being stretched. The companies that really 'push the boundaries'are the ones that shape the technology to fit their purpose - the companies that customise the interface to make it easier to use and harder to make mistakes.
The companies really at the 'leading edge' have defined their process, tested and revised it and, only then, set about changing the tools to work in harmony with their process.