Tag Archives: architect

Is design ever ‘finished’?

Finish it by Pedro Travassos, on FlickrOne of the greatest challenges of architecture and design is the fact that there never seems to be enough time.

From student projects onwards there never seems to be enough time to finish designing, detailing and documenting everything about a project.  Essentially, almost every building or fitout is a prototype and to detail every single junction, item or assembly might mean we would never actually finish.  Couple that with the fact that as detailed design and documentation progresses, we may need go back and modify or redesign different parts or elements to improve them or accommodate engineering or product details or the inevitable new client requirement, and at times it feels like design can be a never ending cycle.  Then even as construction takes place, the built reality doesn’t match the ideal, or the contractor has alternative suggestions for products or details.  The client then moves in and the way the space is actually used may differ from their original intentions, or their organisation may have changed over the time the project has taken to come to fruition.  Generally, there  comes a point where further modifications to the the project stop. Its often because of limits, of programs, fee budgets or client expectations –  But does this mean the design was actually finished – can it be and should it be?

To many engineers, it seems that architects and interior designers are notorious for changing their minds and never finishing design.  While it is true that many architects and interior designers are indecisive or looking to constantly keep improving the design at the cost of program (or engineering), it is also just as true that many of these ‘design changes’ are driven by technical or functional requirements.  If the mechanical engineer hasn’t advised the architect of sufficient space they require for plant at the concept stage, the structure may have to change to adjust.  If the client has decided they really need to keep their Comms room onsite instead of using a data centre, then the Comms Room is certainly going to be getting bigger with all the flow on effects to services and other parts of the building that may have.  Many clients and engineers don’t realise that even the smallest of decisions on audio visual or appliances can have flow on effects to the sizes of whole rooms and hence the whole building.  An example is that a corridor with no door in it could be 1m wide, add a door and you might have to increase the width to 1.6m for wheelchairs.  Obviously as architects and designers we try to build some tolerances into our designs from the beginning but extra space gets quickly eaten up.

In every project there has to be points where certain decisions are frozen, and will only change for a significant reason.  Usually we label these points as client sign offs or reviews.  Points at which the client agrees to the design.  The challenge though is always about what level of detail the client signing off.  Unsurprisingly many clients like to leave their changes and decisions as open as possible as late as possible. Its not only the architect or designer that wants to keep their options open.  Even with defined milestones, some clients can be quite difficult about what they believe they have agreed to, particularly if they want design changes and don’t want to pay for them.  Its easier to blame the architect than to concede the client organisation has changed its mind about how they want a space to function.  On one project, we proposed a combined reception and breakout space, initially the client stakeholder group really liked the idea and the images presented.  Some time after signing off on the schematic design and well into our detailed design process, we were informed that the client did not want to proceed with this space.  They wanted a traditional separate reception area, and questioned why we would ever have thought a combined space was suitable.  We found out later that they had decided to temporarily move a different user group into the fitout, and my guess is that the head of the new user group didn’t like the concept.  Thats their choice, but why should we be the ones paying to go back to the drawing board so to speak?

Even without any need for significant client changes during design and documentation, there comes a point where contractors have to price a design and be appointed, and critically construction has to commence.  In an ideal world, the design should not actually be complete before the contractor is selected.  Contractors, and particularly the sub-contractors who are actually doing the work, have their own ideas and suggestions about construction.  These ideas can be a real asset to cost and buildability, as they are the ones that have to actually make it happen.  However, it is rare on larger scale projects (in my experience anything bigger than a single dwelling) or anything put out to competitive tender that this happens in a meaningful way – even on supposed design and construct projects.  Changes and questions inevitably seem to be last minute and often ‘value management’ happens without the input of the designer. Often only the head contractor has been appointed when the design is being finalised, and later the sub-contractors have their own suggestions.

During construction design still continues.  If we detailed every tiny piece of every project then construction documents would be ridiculously complex and would really never end.  Shop drawings and site instructions resolve the finer detail of design.  This phase tends to become the only opportunity for sub-contractor input to design changes.  Whilst we all dream on zero RFIs and variations, is this really a feasible reality?  I’d say not within our current documentation and procurement systems.

When the day of practical completion arrives and the client moves in, many clients think the design process is well and truly done.  However the best clients realise that as you inhabit your spaces you will understand it and realise things you didn’t see during the design process.  Almost everyone can relate to this through their own homes.  Did the furniture you thought of before you moved in suit the spaces in the way you pictured?  It’s the reason why many architects like to camp on a site, or live in their own unrenovated or under furnished homes before they make all the final design decisions.  Its a great idea for clients to save some of their design contingency to continue to work with their architect or designer in the months after they move in to undertake those additional little projects that can make that space just right.  Even with the best design and planning, organisational, technology and other forms of change mean that design should never be static – a building should never be considered finished ‘forever’.  Maybe the built elements are complete, but the lightweight furniture type elements will always need to change over time.

So I believe the answer is no – design is never ‘finished’.  But that shouldn’t mean that we avoid decisions or sign offs, whether by the designer or the client.  If we don’t say stop here and allow the team to move on, then the building will never be built.  In his book, Linchin, Seth Godin talks about the concept of ‘shipping’ which he defines as getting a project completed and out the door.  It is better to have something that is not perfect out there in the world than to have nothing at all.  To me, this is the ‘finished’ that we need to realise as architects and designers, otherwise we could still be working at 2am every day.  To quote Seth Godin “If you want to produce things on time and on budget, all you have to do is work until you run out of time or run out of money. Then ship.” Maybe its not quite that easy, but apparently the more we try the easier it gets.

Ceilidh Higgins

Image Credits: “Finish it” (CC BY 2.0) by  Pedro Travassos 

Where to From Here: Embracing technological change

la libertad tiene un precio. by ... marta ... maduixaaaa, on FlickrIs architecture on the verge of the greatest change in centuries? Ceilidh Higgins looks to the future and predicts disruption of epic proportions. This is part of the ACA’s Where to From Here series, which invites reflections on the recent ACA – SA State of the Profession research.

The architectural profession could be sitting on the brink of the largest shift in how we practice since the Middle Ages and the time of the master builder. Alternatively, we could become totally irrelevant to anything except the boutique house. The scary thing is that much of our profession seems totally unaware this seismic shift could soon occur.

I really enjoyed writing this article for the ACA, it brings together a number of topics I have written about over the last few years.  To read the full article go to the ACA website here.  If you are interested in the ACA-SA State of the Profession research you can find a summary here.  I also recommend checking out the other articles in the series.

Ceilidh Higgins

Image credits:la libertad tiene un precio.” (CC BY-NC-ND 2.0) by  … marta … maduixaaaa 

Will a Robot take my job?

If I am an architect, a designer, an engineer or even BIM manager – Will a Robot take my job? This is the big question I recently presented in my talk at RTC Australia as part of the session BIMx: Big Ideas around Big Data.  Open up my slideshare presentation above that accompanies this blog post.

NESTA, a UK innovation charity has a quiz you can take to see if a robot is likely to take your job.  The quiz asks a series of 6 questions around skills and ongoing learning, if you manage complex real world tasks, work with, teach and manage people, or design and manage technology, machines and systems. It uses your answers to determine how likely it is a robot would take your job.

The answer is that an architect is “Robot Proof” with a low probability of a robot taking our job.  BUT does this match with our experience? Are architects, engineers, or designers really likely to be robot proof?

Whilst we think a robot won’t take our job – what about a computer?

Many of us would agree that BIM has already resulted in smaller project teams. Computers have long been a part of the design process.  Whilst we often forget CAD standards for ‘computer aided design’, computers can now aid the design process in much more significant ways than back when AutoCAD was released. Its interesting though that today a google search of computer generated architecture still mostly generates links related to rendering and imagery, rather than designs produced by computers.

If you think that BIM won’t take your job – what about Big Data?  We are already using data to check, verify and evaluate options within our designs. As the scale of the data available gets ever bigger these processes become more complex and more powerful. Right now google searching for data generated architecture won’t get you many hits related to buildings, but this is sure to soon change.

Rules based checking might not yet be big data. But it is about using data sources to validate designs or documentation. Examples include checking codes or standards using software such as solibri.

Again data analysis doesn’t necessarily mean big data yet.  Analysis began as something that architects did using pen and paper, a site analysis diagram for example. Data analysis is starting to become more computer driven which allows for much more significant analysis to take place.  Examples include environmental or performance analysis of buildings, or analysis on a larger city scale looking at land use and traffic patterns. This kind of analysis is very much in the realm of current uses for big data.

Data is also the basis of simulations. For example fire or traffic simulation modelling is based upon creating algorithms from data. Currently the simulations used within the AEC industry are relatively simple algorithims.
Big data gives the potential for developing significantly more complex simulations. Last year at RTC in Chicago I discussed the potential for big data to allow us to simulate human behaviour in complex building types such as workspaces with the potential of increasing a companies productivity. (see blog post here)

So, data can evaluate design – but could big data actually drive design? Is it already happening?  As with data based checking, its certainly true that data driven design exists already – and has for some time, although generally not yet into the possibilities of big data. Computational and generative design is data based upon algorithms and therefore data based design. Algorithms are already being used for design in many different ways.

The use of formulas to create design is an example of data driven design.
An example is the façade of the Auckland Savings Bank by BVN and Jasmax which was designed using Microsoft Excel and the Chaos formula.

The structure of the Watercube by PTW and Arup was designed using an algorithm to determine structural steel member sizes.

A simulation is just another kind of algorithm. Rather than just using simulations to test current design proposals, the simulation algorithims can be part of the design software and the design options can be based upon the outcomes of the simulations.  This bandstand by UK architects Flanagan Lawrence was designed using Dynamo and an acoustic simulation algorithm called acoustamo.

Algorithms can be used to optimise an existing design. At the Barclays Centre by ShoP – detailed design of the steel panels was undertaken using CATIA to generate options which allowed a reduction from 230,000 sqm of steel to 150,000sqm. No two of the 12,000 panels are the same.

This exhibition hall building was designed by the University of Stuttgart’s Institute for computational design.

The question – How can you create a resilient timber structure with as little material as possible? This is a simple example of applying one rule to a simple building type. Using an algorithm inspired by a sand dollar one of natures most efficient structures, this building was designed by computer. The human input to the design is the initial idea and the design of the algorithms. (Read more)
As a side note, it was built by robots too.

What about more complexity? The complexity of trees growing in nature? There is actually already an algorithm for that.  The programming to create suburban housing exists too (its initial use is for generating realistic houses for 3d gaming environments). Using rules based criteria such as number of rooms, adjacencies and architectural style, a suburb of varied housing can be produced.

With big data the questions and the building programs can get more complex. And these kinds of design tools are not as far away as you might think.  Autodesk has a lab project in development called Dreamcatcher. “Dreamcatcher is a goal-directed design system that enables designers to input specific design objectives, including functional requirements, material type, manufacturability, performance criteria, and cost restrictions. The infinite computing power of the cloud then takes over.” The publicity for Autodesk’s Project Dreamcatcher suggests it is for industrial design – the same could potential apply to create rules based design solutions for buildings.

Autodesk are not the only company investing in this technology. Google has setup a spinoff called Flux to explore how data will shape our future. Right now Flux software and much of the media is focused on the metro scale data analysis but the future of Flux is about buildings.

Flux asks “What would happen if we stopped designing individual buildings and started designing building seeds” It is based upon the idea that the data will form seeds.

The information would include the codes, standards, weather conditions, occupant data, building product data and other information available about a building, its site, its occupants and client requirements as well as industry data such as materials, systems and construction methods and costs.

Just as each seed grows up to be a different tree, the building data seeds will grow to be different buildings depending upon the site and its constraints, the client requirements and other project specific inputs.
This kind of design will have a significant impact upon the way our industry operates.  (See post by Randy Deutsch)

This is a clip from a talk by Jen Carlilse co-founder of Flux. (Embeded in slide share or at youtube)

We probably all agree that the building examples in the Flux video are somewhat lacking in the architectural beauty department.  If nature could be an algorithm – could beauty also be an algorithm? Is there the possibility that in the future we could use data analysis to design beauty into our buildings, to use data to design buildings like the Sydney Opera House?

So what will my job be? It won’t be drafting disabled toilets anymore that’s for sure.

I’d like to think that the data will allow us to get rid of the drudgery. It will allow us to focus on the best parts of our jobs. It will allow us to realise the true value of design.

We will still evaluate the computer options and talk to the clients. Whilst data can assist us to make decisions, the human race is not about to let everything be decided purely on the basis of data – if we did we would be doing it already. Human nature is that we still want humans involved in decision making. We still need to tell the computers what to do at some level. Does it mean we all become programmers rather than architects and engineers? Could this process can bring out the best in both humans and computers?

What do you think your job could be?

Ceilidh Higgins

 Imaged Credits:
See slideshare presentation for full image credits.

 

Are you an architect if you don’t draw? Is a design manager still an architect?

7597713652_c246737d9c_oAre you an architect? Do you draw?  In the sense I’m referring to that question today, it is usually meant to include modelling as well, and usually means more than just mark up or do a quick napkin sketch. Are you still an architect if your day job doesn’t involve drawing? What does an architect actually do day to day if they don’t draw? Today, the tasks that an architect do can be so broad, that many architects don’t even seem to understand what other architects they work with actually do. If we don’t understand what our colleagues are actually doing, then is it any surprise that many of our clients don’t really understand (or value) all the tasks that go into creating a building project.

I’ll start by saying, technically, I’m not an architect (although I do still draw depending on workload and projects). The reason I’m not an architect is very much a technicality, and whilst its not about drawing, I think it is relevant to the way in which the profession seems confused about itself and what architects actually do. I studied architecture for 6 years, have worked in the industry for 15 and I have even sat for and passed the Board of Architecture exams. However, I don’t pay the annual registration fee to the board, so that means I’m not an architect. (That’s my choice though, as I work as an interior designer – the relationship between designers and architects being a story for perhaps another post sometime). In Australia, anyone who not passed the exam and registered is not supposed to call themselves an architect, but a graduate of architecture, even if they have been practicing for 30 years.  It’s not this kind of semantics or industry protection that I’m really wanting to talk about today (though personally I don’t think architects really benefit from the protection if the term), it’s the tasks we actually do to deliver our projects. And can often apply just as much to other building design disciplines such as interior design and engineering too.

For any architect (or graduate of architecture) or interior designer that works in an office of more than a few people,  you won’t do everything yourself. Some people will undertake business development and bring in the work, some will have face to face client roles, some will draw, some will use BIM, some will know all the graphic software, some will write specifications, some will be good at the overarching idea, some will be focussing on construction and technical detailing, and someone needs to ensure that the subconsultants are briefed, the team is delivering on time and the team size and mix is the right one.  Most of us do a mix of these things, very few of us are good at all of them. The whole point of working in a team (to me anyway) is to benefit from these different mixes of skills.

Given that delivering a building project is therefore very much a team sport of many different positions, it therefore surprises me then when I hear comments like “as architects is job is mostly drawing” or “what are you actually doing on the project – you are not drawing or writing the spec?”  That fact that the later was made by an architect who was managing more than 20 architects (and happened to be involved with the board or architects), is to me, quite disturbing. Do architects really not understand and value what their team mates are up to on the job, thinking that only certain parts of the project are actually important to the architecture?

I guess that partially it is related to the increasing complexity of large construction projects. When I first graduated a bit over 10 years ago, we didn’t have sustainability consultants, access consultants or BIM managers – every project our consultant teams seem to grow ever larger. (Recently I saw a consultant team list which included a wind consultant – a new one to me).  Managing all of these people, briefing them and coordinating their work is a big job on its own. You can then add the work often involved in meeting client stakeholder management and reporting processes, quality assurance processes and code compliance checking (which whilst we have consultants is still so much the responsibility of the designer be they architect, interior designer or engineer). Between all these tasks n a larger project you easily have a full time role, commonly referred to as design manager.

It is really important that this is understood as a different role to the project manager – whilst one person may do both, just because there is a project manager doesn’t mean you don’t need someone undertaking the tasks of design manger. In fact, sometimes it can become even more critical to  ensure that these tasks are actually undertaken and don’t fall through the cracks when the independent project manager consultant is the lead consultant. They won’t generally do your  co-ordination checks for you. Whilst a project manager ifs often at arms length from the actual design and documentation, and may have very different qualifications and skills to the architect – to me, the true design manager needs to understand what is being designed – they need to be an architect (or a designer or engineer depending on the project/design team being managed). However, there seem to be a lot of architects and designers who don’t understand that this role is very much a valuable and necessary one (whatever it is called), and, if the project team is structured well, not just another layer of management.

If I told an architect who sat at the computer all day writing specifications that they weren’t an architect because they couldn’t manage a 20 person team to deliver a multi million dollar project they would scoff at me. Same thing if I told the autoCAD technical detailer she wasn’t an architect because she didn’t use BIM (and had no interest in learning or even understanding why you would use it). But many these kinds of team members seem to think its ok to put down the work of those managing the projects (or even those brining in the work) as not being real architects because they don’t draw.

One of the funny things to me in all of this, is that in Australia, the registration exams actually focus on these management and practice management tasks – not on design, drawing, technical detailing or specifications. This knowledge is taken as assumed (through your studies and your log book of experience) – neither the written exam or the interview deal with these topics. So maybe it’s the opposite – real architects don’t draw? (But of course in my world they are all expected to use BIM!)

Image Credits: Mennonite Church USA Archives via Flickr