Specifications – Lets get it together

After a recent Twitter conversation with Dave Cornett of Snow Architects (@snowarchitects), we discovered that in our respective worlds of architecture and specification consulting, members of our teams had crossed paths on  projects previously in the UK yet we had not put two and two together over Twitter. After a few direct messages on twitter, it was ascertained that it was my father who built the Specification Consultancy once known as Schumann Smith, which later became Davis Langdon Schumann Smith and now of course is part of the rather large AECOM family.

Following a master…

You can all see therefore that I followed my father into the AEC industry. Having grown up experiencing the high’s and low’s of running a business, combined with wanting to walk in my fathers footsteps and the love of working with Architects and designers who are creative, I suppose it’s no wonder I have ended up where I am. Saying that, I promised myself I would never move into the Specification field as he did, simply because I thought it sounded incredibly boring. However, even though I tried hard to escape it, through a few years as a Web Programmer and Design Manager (which I still do), Specifications eventually caught up with me when I was asked to run a few parts of our Middle East business a few years ago, with Specifications being one of the aspects to be run. Since taking up the role, I have found Specifications to be more interesting than I first feared, especially when you get into the reasons why they are there and how they can protect Architects.

Some of you may know or know of my father, Nick Schumann (@NickSchumann), who has been delivering Architectural Specifications to Architects for over 25 years under the Schumann Smith company name. In this time, as you can imagine a wealth of knowledge and expertise in this rather specialist field has been gained, having written specifications for many of the worlds leading architectural practices on some of the most prestigious projects around the world.

I know a blog is all about putting my own thoughts down, but when you have such close and intimate access to the experience of someone who has been there, seen it, done it, it seems a waste to let that knowledge be confined to far reaches of a Google page search (it could be a while before I convince him to start a blog to tell you all himself!). However, I have managed to get him onto Twitter so I would encourage you all to follow him and engage, as he has a wealth of experience and knowledge, and I know he would be happy to engage with you all.

Let’s get it together…

A few years ago, Nick was asked to write a number of articles for Building Magazine based on his experience, for which he duly did and delivered around 10 or so pieces. 11 years on, Nick’s career has taken him well beyond the world of specifications (it has been left to a select few of us who are younger and not so bald) and high up the business ladder. However, the advice and knowledge that Nick was able to pass on still stands true today, and many of the principles that he addressed remain the foundations for how we continue to deliver robust specifications on behalf of Architects and Engineers.

So over the next few months, I will link to the articles that Nick wrote, and provide a bit of commentary.

Back in 2000, Issue 10 of Building Magazine, Nick wrote an article discussing the impact of uncoordinated specifications and how they can lead to chaos and claims. It sounds simple doesn’t it, but you will be amazed how often specifications go out for tender which have clearly been picked up off the shelf from a previous project, dusted down and then issued, without much thought for relevance, the contractual situation or the implications that can arise from not paying enough attention to what is after all, a very very important contractual document.

Conflicting information – just asking for trouble….

When it comes to a specification, conflicting information is a recipe for disaster. Whether it is the terminology in the specification, performance requirements of a product, or adequately describing and reflecting the correct design responsibility, conflicts and ambiguities will lead to confusion and misinterpretation by tenderer’s which ultimately can lead to claims.

With so many parties being involved in producing what is a very important contractual document, be it the Architect, the QS, the Structural or Mechanical Engineer, it’s no wonder that conflicts in the documentation starts appearing. However, there really is no excuse for it and many headaches can be soothed by simply adopting some sound principles.

The answer….

Co-ordination and review – easily said, not so easily implemented, but here are a few options:

• Nominate a single point of contact responsible for coordination of the specifications. This person should have an oversight of the project, the contracts and procurement processes.  It is this persons job to ensure consistency throughout, from ensuring terminology is referenced correctly, to formatting, to making sure the specification reflects the building contract and consultant appointments.
• Define consistent terminologies that reflect the Conditions of Contract that are to be used throughout the specifications.
• Allow enough time in the design programme for a review of the specifications. A bit of time spent here can save you a lot of time down the road.
• Don’t refer to clause numbers. It will only give you headaches.
• Ensure consistency of format (are you using CSI MasterFormat or Common Arrangement?) and codes and standards.
• Get this sorted at the start of the project. This will never work if you try to cram it in when it comes to deadline day.

Nick’s full article can be found on the building.co.uk website here. You will need to sign up to the website.

Monitoring design progress – The ‘Design Webs’

In a world where many Clients require the Architect to take full contractual responsibility on projects (therefore requiring the Architect to appoint a team of Engineers and Specialists and take responsibility for the delivery of that team), I have witnessed demand for what I do increase. That is supporting Architects with the added management responsibilities and contractual burdens that come with this demanding role and responsibility.

Over the past 10 years, I have been fortunate to have worked with some of the best and biggest Architectural firms in the world, leading world-class design teams on world-class international projects. However, no matter how big or small the 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 – not a Gantt chart please….

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 can not be plotted in a linear pattern, nor should it be measured by the number of intermediate drawings and reports submitted. 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, where we found it a constant challenge to be able to schedule and monitor design team activities and progress accurately and meaningfully, that the ‘Design Web’ innovation was born.

Breaking the mould….

The idea behind the ‘Design Web’ aimed to revolutionise the way Architects monitor and report design effort and progress by using a method that was easy to understand and implement. So back in 2006, a colleague and I won the Davis Langdon award for innovation for the ‘Design Web’. Our reward was a substantial amount of air miles, for which I used my allocation to take my girlfriend at the time (and now wife – linked somehow?), business class to South Africa where we enjoyed a fantastic holiday and safari. Anyway, i digress….

So what is a Design Web?

A ‘Design Web’ is a very simple idea, using fairly simple techniques, but just used in a way which really adds benefits to our Clients. In essence, it is a very visual tool which allows us 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 which 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.

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. A picture tells a thousand words….

The ‘Design Webs’ are used by design teams to assess progress and target effort and resources in the right areas to produce a fully integrated and coordinated design. It enables everyone to clearly see where problems lie and where the team is progressing well. They work 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 which represents 100% completion.

The end of the Gantt Chart…?

Of course not. There is always a need to plot the design stages and key milestones in a linear way in a bar chart form. 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.

My advice, 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 unless you want your Architect to put the design programme straight into the drawer and never looked at again.