Case Study Design Management

The following are sections taken from two interviews and discussions with the principal design manager who worked for the Design & Build contractor of the skyscraper case study. The interviews were carried out at two stages of the project. The first meeting was during the PCSA period when the work on site was mainly demolition, reinforced concrete cores construction and steel installation. The second interview was carried out after the D&B contract was placed, and the building façade and M&E installations were progressing.

The meeting with the principal design manager during the PCSA period

Note: The principal design manager was trained as an architect. However, he was more interested in the detail design and how the building components are put together than developing design concepts. Consequently, he decided to take design management as his career. He joined the Skyscraper project team at the start of the project, during the PCSA period, and stayed until the finish of the project five years later.

The design manager role is mainly two fold. Firstly, it is managing the design programme and the adequacy and quality of design information, as well as managing the release of information from the designers, whether consultants design or STCs design. Design information release should be in time to meet the programme and lead-in periods, thus, to get these to the site when they are needed. Design management is about planning and organising the design team and making sure it issues information when needed. The other fold is checking the compliance of the design information against the client’s requirements, building regulations and a whole range of information that should be complied with and satisfied. The biggest problem is making sure the information is in a buildable format. It is often that we get information that is drawn by consultants, which means nothing to the team on site, eg missing details or reference to specifications. The drawing might be clear to somebody who knows the information, ie information that is meant for internal use by the design team but is issued to site. We make sure the information passed to the site team is easily readable, understandable and they can clearly interpret what is supposed to be built.

Designers are used to developing the design in a way to make the building work; however, a lot of designers have never been to a building site to listen to the queries raised by the STCs. On jobs where the design team are resident on site, they would walk away with entirely different ideas because as soon as they are in front of an STC saying ‘I can’t get on with this

information’, it starts to change the way they think. The designers are not producing the

information that tells the people how the building is going to look. They are producing information for the people on site to do their job. The designers have the big picture, but they need to scale it down to be used on site, with no ambiguity. The design manager role is setting the level of details, the scale of the information to be produced and who should produce it.

How do you identify the design information requirements from all those who are contributing to the project?

We have a meeting before we start working on a trade package to say this is what is within the scope of this package. I produce what I call a package scope sheet, which I give to the architects to tell them exactly what I think is in that work package. Then we will meet midway through their design period to check where they are up to, have some comments and review the information before we issue it. This is a proactive approach as I’m not waiting passively for the consultants to issue the drawings then comment on them. Instead, comments are incorporated through the process from the beginning to the end. The checking of the information I get once the drawings are issued is just ticking the boxes. On this project, we needed to be proactive because we’ve got a minimal float in the programme. We are building the job, but at the same time, the designers are designing the job, so everything is based on just-in-time (JIT) information. If the information is not good enough, then we put the construction programme at risk. We have to be proactive in checking before it is needed on site.

How do you manage and deal with this massive amount of information?

I have a team of design managers who each deals with specific packages, eg steel and concrete of the shell and cores, façade, lifts and so on. The design management team expands as more packages are procured. I’m responsible for the planning and compliance with requirements, client interface and architectural design. We have an agreed drawings list for the consultants, so we know what they intend to produce; therefore, we can allocate packages accordingly, and all we have to do is monitoring.

Any design information that goes into the system gets a status A, B or C from our company dedicated person. Therefore, all the drawings on site should have our stamp on them. This doesn’t say that we have fully approved the drawing as we don’t take responsibility for the design. However, this means that the drawing went through a QA process from our side, and it contains all the information that is needed on site. We only monitor the consultant drawings list against the information on the drawings.

I use a document distribution matrix, to be able to keep up to date with my document controller that says, for example, when the structural steel drawing for level 25 comes in, it needs to be distributed to these people.

Do the STCs have design responsibilities?

Most of the trade packages include an element of design. In the case of the steelwork, for example, it is the steel package STC’s responsibility to finish the detailed design, things such as connections design and checks on fire protection, etc. They produce a detailed design that goes through the process of comments and approvals from the design team. That information comes back to our company to be checked, and we put a final status on it to say we are happy for it to be released on site. Everything that is issued by the STCs gets a status A, B or C. (A: No Comment, B: Noted subject to comments. Correct and resubmit within 5 business days. C: Rejected. Correct and resubmit within 5 business days.)

How do you draw the line between the consultants’ responsibility and the STCs’ responsibility?

On this project, the client has appointed the consultants to a written scope of services. We have produced a full schedule of services by converting the client’s written scope into a design responsibility matrix. The matrix states what each package is doing, who needs the package and whether there is a design intent within the package, is it a full design package or only for certain design information. If there is design intent, then the responsibility of the STC to finish that information is stated in the matrix. These are relatively detailed, and everyone knows what their responsibilities are. The other part of the scope meetings that we have for the packages is to inform each package of the level of information we expect from them to produce, and to whom they should send the information to work on or finish.

How do you manage the consultants’ design?

I currently have to manage about 18 different consultants. We manage the design of all the consultants involved on this project, whether appointed by the client and retained by the client, appointed by the client and novated to us, or we appointed them, and the client approved them. We meet with the design team for a formal design meeting every Tuesday for an hour and a half – we are quite strict on time. This meeting is a programme overview meeting. Every week we review the information that is due this week, the status of that information and if there is any missing information that the consultants should produce. In the meeting, we agree on whether to hold workshops with the relevant STCs to coordinate the design. These workshops tend to be on Thursdays where we go through basement coordination, for example. The consultants design and coordinate among themselves and we give them advice on buildability and discuss with them the changes we want to make. I talk to the architects and the engineers four or five times a day, every day. I don’t send a design programme then sit here waiting for a month or so then expect the information issued by the designers would meet the requirements of the programme.

We discuss buildability issues with the consultants and the sequence of how we want to build a section of the building because there may be something in the sequence that drives how we want the things to be designed. For example, we were looking at wind canopies yesterday, and we asked the designers to adjust the design to suit the sequence of putting it up. We install first the steelwork, then the glass mullions, and finally we install the wind

canopy. This installation sequence required that the designers have to redesign the wind canopy connections.

We also often have a situation where an STC would say we don’t want to install a particular building element in the sequence prescribed by the designers and we want to change the design to make it easier to be built. One example was the perimeter steel columns. These are large steel columns spanning from Basement 3 all the way to ground floor and weighing from 7 to 26 tonnes. The steel columns have splices as they go up. The structural engineers’ design indicated that these columns are joined by welding a plate on the outside of the column to give it stiffness. The steel STC disagreed on this method as they don’t want a welding job on the side of the building. The steel STC suggested a change so that the splice detail is a bolted solution that they can do at the edge of the slab. We had a few workshops with the steel contractor and the engineers, over two and half weeks of discussions, agreements and disagreements, until we arrived at a decision and a revised design for the connections, to provide a better and safer installation method on site.

Do you have regular design coordination meetings with the STCs?

What we do depends on the package. We chair a meeting every Wednesday with the steel STC and the engineers to coordinate the steelwork. We meet weekly also for the concrete work with the reinforced concrete STC. However, for the staircases, for example, we meet with stairs STC every three weeks. These regular workshops are to go through buildability and programme issues. The intervals depend on how big and intensive the package is. These workshops are attended by the engineers’ relevant designers and relevant STC. The architects attend a meeting when their input is required, eg they don’t sit in the steelwork workshops as these are intended for the detailed design of connections and calculations, designing holes through the beams and things like that. However, when there is a meeting that affects the special fit, our policy is that the structural designer from the architects should attend the meeting, to do the coordination elements for the architecture. The splice in the column redesign is a good example of a situation that needed the architects’ contribution too. The column became slightly larger because of the redesign of the connections. The architects had to redesign the column encasing in the affected areas. Whenever a change is suggested, we have to make sure we follow its implications all the way back to the architectural design.

How do you deal with the interfaces between the STCs?

We developed an interface matrix that serves two objectives. First, it identifies how packages interface with each other, eg the fixing system STC of the staircases, provided by the stairs STC interfaces, with the core concrete, provided by the reinforced concrete STC. The stairs STC design the fixing that should be provided by the fixing STC ,to be installed in the reinforced concrete STC to a specific tolerance, to allow the staircases STC to fix the stairs. In the interface matrix, this is one of the supply interfaces that we identified, ie the stairs STC provides the fixing design to the fixing STC, who will, in their turn, manufacture

and provide the fixing to the reinforced concrete STC, to be put into their concrete. In the matrix, we listed out who is responsible for designing the fixing, supplying them and fixing these items into the concrete. Some interfaces are reasonably easy, such as this one. Other interfaces are more complex. Therefore we have dedicated workshops to sort out who is doing what and when, eg the design of the façade system secondary steelwork that is supported by the steel STC should be coordinated. So we had the steelwork STC with the façade STC last week to solve this interface. One of the main concerns for the façade STC was the axial shortening of the columns owing to the self-weight of this tall building, which will cause the steel columns to shrink by a couple of mm. The façade STC needed to know exactly how the steel STC is taking that tolerance.

We don’t know all the coordination issues that might arise, but we can identify about 70% of the interface issues, and the rest would be found out through continuous dialogue with STCs. The main challenge is the services in the basement. It is an existing basement, therefore cutting and carving to suit the services that need to go there is very difficult to coordinate in some cases, but after all, it is an office block, and there are not that many services in comparison to hospitals, for example. The design and installation of the services for the repetitive floors are simple. All the services go through steel. So we maximised the holes in the steelwork, and these holes will be used to distribute the services. The challenge is getting the plumbing in the basement.

Do you see your role more at the level of consultants’ coordination or STCs’ coordination?

Initially, we start work with the consultants. We make sure that they produce the information on time and to the right quality. But what you tend to find is that it gets hectic when the STCs are on board because everything is time-critical, particularly when the appointment is not early enough. When an STC issues a drawing, the consultants have ten days to comment on that drawing then it goes back to us, and we have only three days to review the drawing and put our status on it. Whereas the consultants’ design is less critical, so if they missed a day or two, is not an issue, as long as it is not going to affect my overall critical path. In the STCs’ case, they will not be able to get on site unless they have all the information they need to do the job.

Is there overlap and possible conflict between your role and the architect role?

We tend to take the lead. We identify the problems and make sure someone is dealing with it. The architect is responsible for coordinating the design, eg the internal stone design is in line with the tolerances we have for the concrete. There will always be some queries, interfaces and coordination problems; our role is to log these into a register and make sure they are resolved.

At the package level, the responsibility of the design coordination of the package lies with the relevant STC. Every STC has in their contract that they have to coordinate their design with other STCs. Our role is to facilitate these discussions. The architect role is to make sure

that the STCs coordinate their design back to the architectural design, ie make sure that the product is right. For example, to fix the staircases to the cores, the concrete STC needs to cut a hole in a slab to put the fixings. The stairs STC, who are designing the fixings, need to coordinate the design with the concrete STC, to decide the exact dimensions and locations of the holes they need. The architect checks this interface to make sure that the size of the fixing is right, the specification is right, it is what the client wants, it is in the right place, ie the architect overall checking the design and making sure it is right.

The consultants start with a concept and gradually work at it in more and more details. But they need a vast amount of specialist input. Getting that information from the STCs to the design team, dictates the sequence of the STCs procurement, ie the procurement of the design information rather than the product. How is that addressed in your working?

We try to get people on board early enough to advise on the design. One example would be the basement turntable. We did not procure the turntable yet, which should be installed in the basement for the delivery of vehicles to the car park. We had advice from the supplier about things like its diameter, the depth, the drains, information about the steel ring etc. We tend to get that information as and when we need it, before we sign the contract. We get enough information to allow us to progress the design, knowing that we need to go off to procure this STC later.

How do you link the whole supply chain together so that the components arrive on site on time, perfect and ready to be assembled or bolted etc in place? Are you confident this sort of process could effectively ensure that at least three organisations down that supply chain are sufficiently geared to achieve this target?

That is part of the STC telling us when they need the information to feed into their manufacturing process. This is to make sure the components are arriving on site at the right time. A good example is the façade. The façade is not due on site until the end of this year, but we approved the materials for fabrication back at the end of last year. We need to know how far in advance we need to approve things to meet the site needs, but the STC should tell us it takes them eight months to procure the glass. We need to make decisions a long time in advance, and that is part of the reason we produce individual information schedules for each STC. In this way we can be specific about what we need, eg in the case of toilets, it took us six months of design and development by the consultants, the client and the STC before we could say go off and procure expensive marble. The provider produced a mock- up, and we asked for changes and so on.

We use internal information to plan the procurement of the building components. From experience, we know how long it takes to procure packages. On this project, although we need to do the basement, structural steel and the frame early, we also need to procure the lift services because the lifts are always on a long lead-in period. The façade is usually a one- year lead-in to be on site. Major M&E item such as generators needs 40 weeks lead-in. Chillers also 40 weeks lead-in. We know that these are the first things we need. We

developed a tender event schedule spreadsheet to show the starting on site date of each critical component, and the placing of order date for this component considering its lead-in time. The tender event schedule spreadsheet is linked to the programme, and it has periods for tender, reviewing tenders, leading and when we need the design information and track through.

When it comes to the programme, how do you extract the design programme from the construction programme?

We have to use a couple of tools. Our project lead planner develops the construction programme, and we extract from it the design programme based on package by package start on site dates. Then we apply the lead-in and procurement periods for the design to be ready on that date, eg the average steelwork piece of steel requires 16 weeks lead period, while some long lead steel items are 24 weeks. For that piece of steel to be installed on site, we need all the design information 24 weeks in advance of the installation date stated on the programme. So we map that back to get the date for when we need to have all the design information about this piece of steel. Ideally, we would have a float so we can use the float if we miss a date, but on this job, a lot of work is JIT information that leads to procurement. One of the problems we faced is that we had in the initial programme 16 weeks leading to a typical piece of steel. However, the steel STC came back with 24 weeks, which have significant implications for the design programme. So the earlier you can get input from the STCs to verify that lead-in period for them the better because that will tell us whether the sequence in the programme is correct.

We have two sets of design information schedules; we have an overall design programme that sequences the design in term of design coordination. Once we get the STC onboard for each package, we work with them on producing the information requirement schedule by breaking down the overall programme for that package. For example, I need Level 0 to 3 by this date and 3 to 10 by this date, so we break them down on a package basis and monitor those in the STCs’ meetings.

What would you say were the major problems that you had to deal with so far?

The completion of the design to be in line with the site programme is the main challenge. The site is about six months ahead of where the design stage is. The consultants are still developing the scheme design for some parts of the building while we are building the building. This is the biggest challenge for us at the moment. It has been difficult because we have to catch up and release information to keep the site going. The main issue has been the ground floor, where the client is making most of the changes. We are trying to get the consultants to issue construction information, and they are still changing the design with the backup of the client. The steel lead-in for the steel framework installation caused a big problem too. The initial programme stated 16 weeks lead-in for steel, which is a typical lead- in time. That went up to 20 weeks for standard steel purely because the market is very busy at the moment. That went up to 24 weeks because some of the steel we need is called

jumbo sections, so the steel contractor had to procure that on a longer lead-in time. The steel is imported from Europe.

As we know, the client is very knowledgeable. What are the implications this has on the design management process?

We carry out regular client design sessions every Tuesday afternoon at two o’clock. This is the client design meeting. The consultants attend this meeting too. There we raise the issues that we need to discuss with the client, and we go through everything on the meeting agenda. The client gets all the information that we have for that week with our status stamped on it so they can comment, accept, disagree or whatever they want to do with that information. If the client is happy with that, they issue all the information for that period.

At the moment, the client is looking at the design from a cost perspective. But when they sign the fixed price D&B contract with us, they will check whether the information put forward is complying with what they want. For that, they will have a whole team set up to monitor the design information on behalf of the client.

What are the successes you’ve achieved?

I would say, catching up. For example, we had some quality issues with the engineers’ design of the steelwork of the steel frame in the early days. My team has done an excellent job in bringing that information up to quality. I have some sympathy with the engineers as they were rushed to get their design out. They are also very busy because they have many other big projects to design. Some of our steel designs are done in Poland and then sent back here to be checked. If it is a complex design, it goes first out to Canada to get checked by the engineers’ technical department. Another thing you have to deal with as a design manager is where your design has been produced.

What is the most challenging part of your job?

Controlling the client, I would say, is the most challenging part of the design manager job. One of the main reasons why the client got us so early was that the whole selling point for the funding organisation is that they could start building the building and finishing it as soon as possible. Therefore, the client did not have the chance to go through the normal process of reviewing images and checking how the building is going to look like. The planning application was produced too quickly. The client got the commitment, but they need that natural time to resolve their own design issues. The trick for us has been trying to shut them down and say you need to fix this now otherwise we are going to have some problems on site. In the early days, we didn’t give them that advice properly. We’ve been too nice, we were trying to bend things over, and we were trying to re-sequence the programme to provide the client with more time. Whereas what we should have done is been a bit firmer with giving them a process to follow and a time frame to observe. We are better at that now.

This client is very experienced, and the two founders of the client organisation are a famous architect and an eminent project manager. They both are very involved and hands-on. They have a very long experience in the construction management procurement method, ie when the client is effectively managing the project. Having a separate contractor under this arrangement doesn’t enable the client to have that direct connection to the project. They have to rely on us to give them this access. That is the tricky balance we need to achieve with the client in this situation. Therefore, the level of design should be set in the contract very clearly, to avoid conflict and disputes with the client, ie things like, for this per cent of design development, this is the price.

How are design changes, particularly client’s changes, managed?

We have what we call an early warning system to manage the changes. We meet with the client once a week, every Tuesday. All changes proposed by the designers or requested by the client are put on the meeting schedule to be discussed, costed by the client’s cost consultants and then approved or rejected. However, what has been difficult is getting the designers to raise changes in these meetings, so we haven’t been able to apply this early warning system as we should. The designers are not giving the client the chance to review the changes on time. We get into situations when the information has to be costed. We price it then the client would say “I didn’t sign for that, I would have done this differently if you have given me the option.” So we have to go back to the designers to tell them that this change should have been raised earlier. If the designers are committed to a more rigorous process and give us the chance to check the cost of the design every month, then that would be a much easier way to keep track of the design changes. Post D&B contract there will be a formal change process so it should be much easier to control. The task for me would be to make sure I’m controlling the client talking to the designers by the back room, and also for the designers bringing in changes that are not approved by the client. I will have a change process with the client and also will have a change process with the designers. Therefore, when a design change is suggested, it will be clear if the change is to fix a deficient design, the design is irrelevant, and they need to redo it, a client-requested change, an STC-requested change or a change we wanted because of buildability, regulations, safety etc issues. We should be able to factor everything and give it a status. Then we need to pass that to the client formally.

Do you think that when the D&B contract is finally placed, based on a fixed price, things might become more complex to manage?

No, it will be easier. The contract requires that we put in a client clause. We tell the client when we need to make a decision, so we can go and procure an item. The contract also will set a formal change process in place. So if the client wants a change, they have to put that in a form. We will deal with that with a pre-set mechanism. At the moment, the designers work for the client so they can change things, and we can’t stand up and say anything about it. It will be a good thing to have in place some agreed process for change management.

The client, for some reason, decided they didn’t want the designers to go through the RIBA stages 1, 2, 3 and 4. They didn’t put a stage closeout into the process. The lack of proper stage closeout is causing a bit of a muddle because the designers are not allowed to issue information or coordinate the design to a point where it is checked, approved and then move on to the next stage. We always have been dealing with a design that is developed at different stages, eg the engineers’ steelwork is miles ahead of where the architectural design is for several floors. All these designers are at various stages of design development, and we are trying to pull them together to coordinate their work. They are using movement in cost targets as the early warning notice, but some of the items, such as WC fit-out, for example, caused a big problem. The design got too far down the line before they did a cost check and it was miles over budget. So it was like hang on a minute, we need to think about this, let us go back and look at the information to see how this can be dealt with.

The meeting after the Design and Build contract was placed

Note: This interview with the principal design manager was carried out after the PCSA phase ended. The Design and Build contract between the D&B contractor and the client was placed about 18 months before this interview. The purpose of this meeting was to catch up on
how the role of the design management changed.

Now it is more contractual. When we were in the PCSA phase, we were managing the design team on behalf of the client, but there was no formal contractual link between the designers and us, ie the architects and the engineers. As soon as we went into contract in October 2016, the designers have been novated to us. We have signed an agreement between us that we take over their appointment. Since that point, we pay their monthly fees, they are reporting to us, and we report to the client what the progress is like and how things are going. There is a change in that contractual link at that point.

This is a design and build contract with a fixed price for a large percentage of that contract. Usually, in a D&B we try to get 70% fixed cost and 30% negotiated. However, in this job, the fixed price percentage is much higher. It is about 85% to 90% fixed at the contract stage. We have been working on what we called cost re-reimbursement items, which are the areas and building elements that are open to negotiation. There are areas of the building that we didn’t get the chance to decide how to deliver the client’s requirements, they haven’t made their mind up on what they wanted, or they needed to seek further advice from the funders. The main areas are the reception, the viewing gallery at level 60, some of the external works. For example, the lobby fit-out in the reception area was a unique item, so the client took a budget for it and said we have a specific amount of money to spend in the lobby and the design should be developed in conjunction with that budget, and then we agreed to it.

Usually, when we start a two-stage tender, ie during the PCSA period, we have a cost plan. This would mean the design is developed to a level that the client can state what they want in general. For example, in the case of this project, it was a 62-storey glass building with a specific CAT-A fit-out. According to the client brief, we estimate the cost, and we get

appointed for the PCSA period to work through that cost, ie develop the design further and develop the cost plan as the design develops. At the end of the PCSA contract, the design is developed to a stage so we can fix the price for 70% of the work. The remaining 30% is negotiated and instructed by the client. If we are asked to fix the lobby price, for example, when there is no information at all about it, it is almost impossible for the client to get an accurate figure from us. Later, when the client has made their mind up, we might have a situation where the client, for example, wants a particular type of stone for the lobby slab. I might come back and say to the client I agree you want that type of stone, but when we calculated the lobby slab we assumed a stone of £100/m2, now you selected £200/m2. You need to instruct us to change it with the consequence on cost, or we need to work it within the budget that we set for the lobby in the contract.

There might be instances where the designers have missed something that we overlooked before placing the D&B contract, that may cost us extra money, eg if in the fixed price contract the doors package cost is a £1 million. If the architects missed 500 doors so it will cost us £2 million, that is our problem and not the client problem. For the client, we are contracted to give them a 62-storey building, and it needs to function as a 62 storey building. If we messed up the pricing, ie we messed up the design, that is our problem. What we do during the PCSA period is that we work out the price to make sure that everything is coordinated, thought through, accurate, and is correct, so the prices are achievable for us.

We had a few client-generated changes since the contract was placed. The client appointed a multi-organisation team who executes the contract on their behalf. In case the client does not like what we designed, the client team would send us a change request, eg to change the doors from timber to glass. They would want to know the implication on cost and programme. We would have a certain period to review that change and go back to the client to say this is the cost of the change and its implications on the programme. Accordingly, the client can decide whether or not they want to go ahead with that change.

Since the novation of the designers to us when the Design and Build contract was placed, we became in total control of the detailed design development. The client team role is to check that the design conforms with the client’s requirements stated in the contract. There were not that many occasions when the client disagreed with our design, claiming it did not interpret the requirement in the right way. This is because the setting out of the job during the PCSA before the contract was well established, and we clearly identified what we were expected to deliver to meet the client’s requirements. We do get some areas where we suggest changes to the client because the specifications are wrong. For example, there was a small section of the façade at the back of the building that the architect wrongly specified a sitting, as if in a marine environment, which would drive the cost up significantly. We went back to the client and told them that we think this was specified wrongly. Although we were entitled to the higher specification, but we have not priced in that manner. The client agreed to the change as long as the suggested specification is in compliance with the

building regulations. We have an excellent working relationship with the client, open and honest, which is not the case on many other projects.

The design management arrangements are still the same as before, ie during the PCSA. However, the contract transferred over much of the detailed design responsibilities from the designers to the STCs. The STCs are responsible for finishing the service engineers’ design, in terms of details such as the exact routes of the services, how these fit and how they are coordinated together. We run a weekly review session with the M&E team, the architects and the engineers, where the STCs go through their BIM 3D model after they turned the designers’ information into their model. They show the federated BIM model on the screen, and they run clash detection on it. They identify, for example, where a pipe does not quite go through a hole in the steel or this installation clashes with this door and things like that. On site to date we have had the odd clashes, but we have not had anything of any significance. The main clashes we had have been because during the PCSA; we progressed with the design of other elements before we had the M&E detailed model. Therefore, in some instances, the M&E people were not able to make their services work around some of the designs that were produced before they were involved. Changes to the design were required to coordinate the services with the other building components.

The designers are employed to make sure the services, such as the electrical services installation, the mechanical services installations and the ventilation, spatially fit, but not employed to draw the exact position where they are going to be installed on site. The engineers are designing the whole of the system; however, the STCs are detailing the designs and coordinating them. The architects have the overall responsibility to coordinate the design and come up with the answer, while the D&B contractor drives the whole process, ie the queries and the closeout of those queries.

Design management tools

Note: The following is the description provided by the principal design manager of some of the tools they use. These tools help the design management team to identify the contractual responsibilities of the various parties, as well as to manage the design development.

Our design management manual is the head office bible. I set up my procedures in accordance with this manual, as compliance with it is mandatory and we are audited by it. The design management manual is the standard document that we tweak for each project to suit the job at hand. To ensure compliance with the manual, I have a building control tracker that I should implement. We have been audited a few times. If things are not in place, one will get an NCR (none compliance report). Internally, we develop all the tools that help our project.

The design responsibility matrix is concerned about the consultants’ responsibilities and identifies where the STCs’ contribution is needed. It is the way we decide the split of design responsibility between the consultants and the STCs. Based on the scope of service, the

consultants’ signed with the client, I turn that into a detailed matrix to make sure we don’t have any scope gaps when the designers are novated to us.

It is essential, when developing the design responsibility matrix, to put down my interpretation of what the consultants have signed up for, rather than putting down what we want them to do. The first version of the design responsibility matrix I produce would have many scope gaps. I sit with the designers and say to them that this is what I think they have signed up to do. I use the matrix to get them to agree what their scope is and to fill in the scope gaps. This approach is a lot better than telling the designers what we want them to do and having lengthy arguments about whether or not these are in their scope of services. Once the residual scope gaps are identified, ie the work that the designers don’t have in their scope of services, I decide whether the STCs should do it, it should be added to that consultant’s scope or if I need to get another consultant to come and fill in that gap. The consultants’ scope that they have signed with the client is reasonably detailed. The task during the PCSA period is to push through that. We ended up asking for an extra £100,000 in design fees because they have missed out, for example, the airtightness and wind testing, so we came back to the client, and we said we reviewed with the designers their scopes that you have given us. We think that we need this additional consultancy fee to build this job. The discussion then we had with the client: “if you think you have bought that from the architects, please negotiate that with them before we take the ownership of their design”, ie before they are novated to us.

Pre-tender, the responsibility matrix identifies the design gaps that need to be filled in by the STCs and we buy the packages on that basis, ie the matrix tells the STCs what the consultants are doing and what the STCs need to do.

The interface matrix identifies the design and construction interfaces between the STCs, and is a procurement tool to make sure the packages are correctly bought and also to control the coordination once the packages are procured.

We have two interface matrices on this job. We have an M&E interface matrix that is a very detailed document. The M&E interface matrix describes each element, which package is going to deliver it, who is responsible for buying it and who is responsible for installing it. I also have a similar one that tells me which packages interface with each other. Once an STC is appointed, we have a kick-off workshop with them. In the workshop, we review with them issues such as who their personnel are, what the scope of their package is, they must use Aconex to disseminate their drawings and things like that. The STCs are responsible for giving us a programme that gets them from that point to the start on site. They are also responsible for telling us of any information they need along that journey, whether it is from the designers or other STCs to meet the programme dates. We monitor that, ie use that as a tool for making sure the design is delivered on time and we tick off the bits as they are achieved. The advantage of this office is that we are able to accommodate the STCs’ project personnel so we can have face-to-face discussions with them at any time. The design

managers have regular contact with the STCs to make sure things are in accordance with the plan. The BIM 3D model makes the information more visually available, and the coordination can happen instantly. When a clash is detected, it can be fixed there and then.

The design responsibility matrix and the interface matrix of a project are developed based on the generic matrix of possible interfaces between the building components linked to the company’s building components classification system. The generic matrix is tailored to each project by consulting the consultants and the STCs to produce the design responsibility matrix and the interface matrix of the project.

The package scope sheet aims to clearly define the extent and limits of the work content of the package, including all design, manufacture and installation responsibilities of the relevant STC. However, where the design information is not available then a team decision must be made whether to continue with the bid process or delay it until the information is available. The risks of the decision to delay or to proceed should be clearly specified to the client, so they are fully aware of their exposure. The package scope sheet forms part of the specification section of the bid documents of the relevant package. Good package scoping is crucial because of the involvement of the STCs in the design and also their responsibility for coordinating the design and construction of their components with other STCs.

We also have a design completeness tracker that we developed to support less experienced design managers in doing their job. For example, as a design manager, if you are working on a blockwork package, then this is the general information you should expect that blockwork package to deliver. For example, you should expect lintel details, wind post designs, structural calculations to prove that the walls are done up to the BS (British standards). In this way, a less experienced design manager can win and deal with smaller jobs.

The tender event schedule is a spreadsheet to show the starting on site date of each critical component and the placing of order date for this component, considering its lead-in time. The tender event schedule spreadsheet is linked to the programme. For each building component, it has periods for tender, reviewing tenders, leading time and the dates when the relevant team needs design information about this component.

The design information schedule is based on the overall design programme, and it sequences the design in term of design coordination requirements for each package. Once the STCs are on board, the design managers and the package managers work with each STC to produce the design information schedule for that package by breaking down the overall design programme.

The document distribution matrix is based on the interface matrix and is mainly used by my document controller. For example, when an architect drawing comes in for façade, then we know what STCs need to receive this document. Equally, when an STC drawing comes in, we know which consultant should review it and which other STCs need to see it. All documents are exchanged electronically; I stamp electronically too.

Final Comments

A successful design manager is one who facilitates the delivery of a design that is buildable. Where we fail in design management is we don’t think how this is going to be built on site. We have a drawing that looks wonderful but has anybody thought: “If I’m the guy who is standing on a blockwork with this drawing would I know how to build that?”. It is not technical; it is about things like, are there enough dimensions from this column to that grid for me to set up that wall? Once I set out that wall, do I know where the door starts and finishes? Although it sounds simple, it is incredible how many times we release information with problems as such that interrupt the work on site and cause delays, which is a recipe for disaster.

A successful job is on the one hand when you can understand what the STCs need to do their job efficiently, and on the other hand, when the STCs understand what has been designed early enough. In this way, you can fix problems together before you are on site.

A good package manager is the one who wants to understand the design. They will insist on being in the relevant meetings, try to understand the discussions, find out what is important to the architects. A good package manager does not just sit back, waiting for the information to come their way. They study the drawings carefully, and do not assume everything is correct and pass them to the STCs because it is their problem. It is crucial that the package manager can read drawings and understand them.

Leave a Reply Cancel reply