Designing Buildings - User contributions [en]

User:Schumannconsult

2013-03-11T16:24:17Z

Schumannconsult: Protected "User:Schumannconsult" ([edit=author] (indefinite) [move=author] (indefinite))

At [http://schumannconsultltd.com/ Schumann Consult], two words define the culture, ethos, attitude to service delivery and commitment to our Architectural colleagues…. ‘'''Supporting Designers'''‘. This is the umbrella phrase we use for our services, [http://www.schumannconsultltd.com/index.php?p=specifications Specification Consulting] and [http://www.schumannconsultltd.com/#dgm Design Management]. Both services have been developed, tailored and used on many high profile projects around the world with some of the worlds most prestigious architectural firms.<br/>

We are an independent business with a passion for the implementation of quality design in the built environment, through the production of appropriate specifications and design management practices allowing architects to focus on design.

We aim to reduce designers' risk on projects through sound strategies, systems, communications and the flow of information between client, consultants, contractors and manufacturers such that projects are delivered within expectations thus maximising asset value. Our expertise has been built up over 27 years, helping deliver projects around the world.

We do not design, but we understand the challenges that architects and designers face. Our commitment to supporting designers is based on our core strengths and passion for delivering quality design in the real world, often operating behind the scenes providing services that protect the best interests of the architect, client and the project.

Our business is owned by [http://schumannconsultltd.com/index.php?p=profile Nick and Mark Schumann] based on family values, which we believe gives our business the warmth and culture that makes clients and staff want to work with us. We are proud and excited to be a father-son team, which to us is nothing new, having worked together for over 10 years during our time at Davis Langdon. We understand each other very well, have complementary skills, share the same vision and now feel free to operate as independent consultants in a modern way.

Our culture will focus on treating staff, clients and colleagues as family; retaining the trust, confidence and belief that quality will always shine through and will be at the centre of everything we do.

Specification guidance for construction

2013-03-11T16:15:44Z

Schumannconsult:

When writing architectural specifications getting the basics in place from the start will help you build a document suitable to your needs. Listed below are some basic rules to follow when writing your next specification:

<br/>
#Always edit your specification to reflect your appointment and the selected procurement route.
#Always start from a solid baseline document. Do not take the last project you prepared a specification for and change the headers and footers. No matter how vigilant you are, mistakes such as naming the wrong project, specifying incorrect materials and other basic errors will creep into your documents.
#Avoid using the term “or similar approved” in a specification. If you approve it you are assuming liability for it. Instead use the term ‘or acceptable equivalent’. By accepting an alternative the responsibility for Fitness for Purpose moves to the contractor and the architects acceptance is for design intent only. If the architect approves he takes back that responsibility. Normally alternatives are offered for program or cost reasons and the contractor is responsible for the fact that he is providing a different product that must be at least as good quality wise as the one specified by the architect. If the architect is specifying by description only the contractor is obliged to provide technical solution which again he has to be responsible for in terms of quality, performance, appearance and fitness for purpose.
#The proper use of defined terms is important in a specification. Check your contract!
#Document/section identification should appear on every page in the footer for document control purposes.
#Avoid putting specification clause numbers on your drawings. The use of product reference codes is recommended which are all included on a technical reference sheet (T-Sheet) that links the drawings and the specification. This makes life much easier when changes are required.
#Avoid mixing prescriptive and performance specifications. By this it is meant don’t name a very specific product and then provide performance characteristics for that product – this is not necessary and is potential for conflict resulting in claims.
#Avoid specifying temporary works – this is the contractor’s responsibility. Just specify the need to protect adequately, not how to do it.
#Remove names of individuals when specifying products and just provide the company’s details.
#Remove unfinished clauses and terms such as “if required”. If you are specifying a specific technical solution then you have to specify everything.
#Do not highlight particular clauses by using bold or underlining, as this indicates that the clause is of special importance and there is no such thing in a specification, as by default it indicates that everything else is not so important.
#Always allow time to have your specifications proofread!

[[Category:CIOB_competition]]
[[Category:Products_/_components]]
[[Category:Design]]
[[Category:Theory]]
[[Category:Procurement]]

Specification guidance for construction

2013-03-11T16:15:15Z

Schumannconsult: Created page with " When writing architectural specifications getting the basics in place from the start will help you build a document suitable to your needs. Listed below are some basic rules to ..."

When writing architectural specifications getting the basics in place from the start will help you build a document suitable to your needs. Listed below are some basic rules to follow when writing your next specification:
#Always edit your specification to reflect your appointment and the selected procurement route.
#Always start from a solid baseline document. Do not take the last project you prepared a specification for and change the headers and footers. No matter how vigilant you are, mistakes such as naming the wrong project, specifying incorrect materials and other basic errors will creep into your documents.
#Avoid using the term “or similar approved” in a specification. If you approve it you are assuming liability for it. Instead use the term ‘or acceptable equivalent’. By accepting an alternative the responsibility for Fitness for Purpose moves to the contractor and the architects acceptance is for design intent only. If the architect approves he takes back that responsibility. Normally alternatives are offered for program or cost reasons and the contractor is responsible for the fact that he is providing a different product that must be at least as good quality wise as the one specified by the architect. If the architect is specifying by description only the contractor is obliged to provide technical solution which again he has to be responsible for in terms of quality, performance, appearance and fitness for purpose.
#The proper use of defined terms is important in a specification. Check your contract!
#Document/section identification should appear on every page in the footer for document control purposes.
#Avoid putting specification clause numbers on your drawings. The use of product reference codes is recommended which are all included on a technical reference sheet (T-Sheet) that links the drawings and the specification. This makes life much easier when changes are required.
#Avoid mixing prescriptive and performance specifications. By this it is meant don’t name a very specific product and then provide performance characteristics for that product – this is not necessary and is potential for conflict resulting in claims.
#Avoid specifying temporary works – this is the contractor’s responsibility. Just specify the need to protect adequately, not how to do it.
#Remove names of individuals when specifying products and just provide the company’s details.
#Remove unfinished clauses and terms such as “if required”. If you are specifying a specific technical solution then you have to specify everything.
#Do not highlight particular clauses by using bold or underlining, as this indicates that the clause is of special importance and there is no such thing in a specification, as by default it indicates that everything else is not so important.
#Always allow time to have your specifications proofread!

[[Category:CIOB_competition]]
[[Category:Products_/_components]]
[[Category:Design]]
[[Category:Theory]]
[[Category:Procurement]]

Design web for building design

2013-03-11T15:14:56Z

Schumannconsult:

Many Architect’s are being asked to take full contractual responsibility on projects but what does this mean for the Architect or Lead Consultant? It means that it falls to the Architect to appoint a team of Engineers and Specialist Consultants to help them design a project, usually under considerable fee and programme constraints, and to take full responsibility of that delivery on behalf of every other member of that team. If the Architect is sensible then back-to-back agreements with sub-consultants will be set up so as to minimise their risk and only looked at when things have already gone wrong. However wouldn’t it be easier to avoid the hassle of finger pointing, a blame culture and getting legal with a team who at the outset of the project started with such positive feelings and goodwill? At the end of the day this industry is built on relationships and without the relationship moving to the next project, you end up with nothing. A more proactive approach is to make sure you catch problems early enough so that 1) you can do something about it and 2) you can do it in such a way that does not alienate other team members and keeps that positive feeling that you witnessed at the outset of the project going throughout.

Managing a Design Team is not easy. Some Architectural practices are comfortable doing, most likely because they are of such a scale that they have a dedicated in-house management team. Other architects a very uncomfortable about taking on the Lead Designer role. But why? Is it because we don’t like to take risk? Maybe, yet when it comes to design and creative risk Architects are prepared to take it all the time? Do Architects have an issue with taking responsibility on behalf of other consultants? One argument however is that this need not be such a grave concern if you have the correct management procedures in place.

Many practices do not have in house management support, which is why Architects seek to improve the way their projects are managed, either by developing tools and techniques internally or by outsourcing this requirement to other, more suitable consultants.

No matter how big or small the architectural practice or project, knowing where you are in the design process and identifying where your problems lie is absolutely fundamental to achieving a successful outcome, and in that, the monitoring of the design is key.

'''Monitoring Design'''

Design is not predictable, nor is it as sequential as the construction process which can be scheduled using traditional tools such as Gantt charts, where tasks are linked to provide dependencies between each other, and the building constructed according to the laws of physics.

The process of design is very different to that of building it. Design progress cannot be plotted in a linear pattern, nor should the number of intermediate drawings and reports submitted measure it. In short, it is activity related as opposed to time related. The days have passed where architecture, structure and services work independently to one another and design progress is simply a case of counting drawings.

Architects are also very visual individuals. Having to decipher a bar chart to determine design progress is not something that designers want to be doing. It is because of this, it is a constant challenge to be able to schedule and monitor design team activities and progress accurately and meaningfully. The ‘Design Web’ innovation is one such solution to this problem.

The ‘Design Web’ provides an alternative way for Architects to monitor and report design effort and progress using a method that is easy to understand and implement. Using fairly simple techniques, it is a very visual tool that allows designers to take a snapshot of the entire design at any time in the project life cycle – which is particularly useful when trying to articulate progress to the architect’s clients. It is something that is used to ensure that all the various pieces of the design jigsaw are being progressed and if not, instantly see where the problems or blockages lie.

[[File:Design-web-300x246.png]]

The ‘Design Web’ captures design tasks necessary in any given period and is processed and weighted accordingly to present it in simple graphical and visual form at which can be easily understood by all. They are used by design teams to assess progress and subsequently target effort and resources into the right areas, allowing them to produce a fully integrated and coordinated design. It enables everyone to clearly see where problems lie and where the team is progressing well.<br/>

The 'Design Web' works on the basis that the web represents the design phase. Work begins in the centre of the web, and progress then ‘grows’ from the centre towards the outer edge that represents 100% completion.

There will always be a need to plot the design stages and key milestones in a linear way in a bar chart form (using a Gannt chart). Everyone needs some form of plan of how to get to the end goal with time in mind. However, thinking that you can plot design on one of these charts to then draw a line down it to reflect the current progress just does not work and is totally inaccurate.

Keep the Gantt charts detailed enough to be useful by plotting key milestone dates, key decision dates etc., but don’t use them to try to gauge design progress or list each and every design deliverable. If you do, more often than not the Architect will put the design programme straight into the drawer and forget about it.

[[Category:CIOB_competition]]
[[Category:Construction_management]]
[[Category:Roles_/_services]]
[[Category:Design]]
[[Category:Theory]]

File:Design-web-300x246.png

2013-03-11T15:13:39Z

Schumannconsult:

Design web for building design

2013-03-11T15:11:41Z

Schumannconsult: Created page with " Many Architect’s are being asked to take full contractual responsibility on projects but what does this mean for the Architect or Lead Consultant? It means that it falls to th..."

Many Architect’s are being asked to take full contractual responsibility on projects but what does this mean for the Architect or Lead Consultant? It means that it falls to the Architect to appoint a team of Engineers and Specialist Consultants to help them design a project, usually under considerable fee and programme constraints, and to take full responsibility of that delivery on behalf of every other member of that team. If the Architect is sensible then back-to-back agreements with sub-consultants will be set up so as to minimise their risk and only looked at when things have already gone wrong. However wouldn’t it be easier to avoid the hassle of finger pointing, a blame culture and getting legal with a team who at the outset of the project started with such positive feelings and goodwill? At the end of the day this industry is built on relationships and without the relationship moving to the next project, you end up with nothing.
A more proactive approach is to make sure you catch problems early enough so that 1) you can do something about it and 2) you can do it in such a way that does not alienate other team members and keeps that positive feeling that you witnessed at the outset of the project going throughout.

Managing a Design Team is not easy. Some Architectural practices are comfortable doing, most likely because they are of such a scale that they have a dedicated in-house management team. Other architects a very uncomfortable about taking on the Lead Designer role. But why? Is it because we don’t like to take risk? Maybe, yet when it comes to design and creative risk Architects are prepared to take it all the time? Do Architects have an issue with taking responsibility on behalf of other consultants? One argument however is that this need not be such a grave concern if you have the correct management procedures in place.

Many practices do not have in house management support, which is why Architects seek to improve the way their projects are managed, either by developing tools and techniques internally or by outsourcing this requirement to other, more suitable consultants.

No matter how big or small the architectural practice or project, knowing where you are in the design process and identifying where your problems lie is absolutely fundamental to achieving a successful outcome, and in that, the monitoring of the design is key.

'''Monitoring Design'''

Design is not predictable, nor is it as sequential as the construction process which can be scheduled using traditional tools such as Gantt charts, where tasks are linked to provide dependencies between each other, and the building constructed according to the laws of physics.

The process of design is very different to that of building it. Design progress cannot be plotted in a linear pattern, nor should the number of intermediate drawings and reports submitted measure it. In short, it is activity related as opposed to time related. The days have passed where architecture, structure and services work independently to one another and design progress is simply a case of counting drawings.

Architects are also very visual individuals. Having to decipher a bar chart to determine design progress is not something that designers want to be doing. It is because of this, it is a constant challenge to be able to schedule and monitor design team activities and progress accurately and meaningfully. The ‘Design Web’ innovation is one such solution to this problem.

The ‘Design Web’ provides an alternative way for Architects to monitor and report design effort and progress using a method that is easy to understand and implement. Using fairly simple techniques, it is a very visual tool that allows designers to take a snapshot of the entire design at any time in the project life cycle – which is particularly useful when trying to articulate progress to the architect’s clients. It is something that is used to ensure that all the various pieces of the design jigsaw are being progressed and if not, instantly see where the problems or blockages lie.

[http://schumannconsultltd.com/blog/wp-content/uploads/2013/02/design-web.png http://schumannconsultltd.com/blog/wp-content/uploads/2013/02/design-web-300x246.png]

The ‘Design Web’ captures design tasks necessary in any given period and is processed and weighted accordingly to present it in simple graphical and visual form at which can be easily understood by all. They are used by design teams to assess progress and subsequently target effort and resources into the right areas, allowing them to produce a fully integrated and coordinated design. It enables everyone to clearly see where problems lie and where the team is progressing well. <br/>

The 'Design Web' works on the basis that the web represents the design phase. Work begins in the centre of the web, and progress then ‘grows’ from the centre towards the outer edge that represents 100% completion.

There will always be a need to plot the design stages and key milestones in a linear way in a bar chart form (using a Gannt chart). Everyone needs some form of plan of how to get to the end goal with time in mind. However, thinking that you can plot design on one of these charts to then draw a line down it to reflect the current progress just does not work and is totally inaccurate.

Keep the Gantt charts detailed enough to be useful by plotting key milestone dates, key decision dates etc., but don’t use them to try to gauge design progress or list each and every design deliverable. If you do, more often than not the Architect will put the design programme straight into the drawer and forget about it.

[[Category:CIOB_competition]]
[[Category:Construction_management]]
[[Category:Roles_/_services]]
[[Category:Design]]
[[Category:Theory]]

User:Schumannconsult

2013-03-11T14:58:47Z

Schumannconsult:

User:Schumannconsult

2013-03-11T14:55:53Z

Schumannconsult: Created page with " At [http://schumannconsultltd.com/ Schumann Consult], two words define the culture, ethos, attitude to service delivery and commitment to our Architectural colleagues…. ‘'''..."