Safe balustrades

A balustrade should not be confused with a hand rail. They have different functions.

A hand rail is a support, at convenient hand height, to assist someone to safely use stairs or ramps.

A balustrade is a barrier to prevent falls from heights on balconies or stairs. The effective height for a balustrade is based on a person’s centre of gravity, not their hand height.

Balustrades also play a part in preventing the discomfort and feeling of danger that some people feel at height.

A hand rail is best positioned for most people between 700mm and 900mm above floor level, or step nosing.

A balustrade at a minimum should be 1100mm high, but preferably 1200mm. At heights above two stories the balustrade should be 1300mm high.

At 1200mm falls due to pivoting around a person’s centre of gravity should be impossible; at 1300mm falls due to other factors, including accidental or intentional collisions should be largely eliminated.

 The male 95% centre of gravity is about 1100mm, based on a height of 188cms.

Below is an illustration from Sutherland Council's rules about protective railing around swimming pools and at retaining walls.

 

These rules  pay attention to the reality of people's height and the implications for falls prevention of the centre of gravity.

I've another piece on this topic related to high rise commercial buildings.

Project as system

The ubiquitous model of the project is the static 'triad', either mine or the unhelpful 'time cost quality/scope' abstraction.

Projects are a set of flows of information and value (effort in terms of dollars). Below I attempt to demonstrate a model of this.

The real project triad

Projects are about investing to delivery a level of performance that produces value for the investor. Everything is about this, including all trade-offs during the course of the project. It means everything flexes about value.

Project Software: what does it need to be?

Microsoft project is not project management software. It is schedule and resource software. Same for Primavera and all the other scheduling packages.

Safran Risk is not project management software; although a very important package for understanding the risk implications of schedule.

What is project management software?

This is software that manages all the information flows, project configuration, and documentation with respect to delivery, investment and performance (the real world version of time, cost and quality).

Every piece of information in a project has a number of dimensions. I'll use a big campus development as an example. Think of a new air terminal.

It has numerous buildings, areas of paving, electronic, lighting, communication and sensor systems. It accommodates land side and air side vehicular traffic. It accommodates the flow of people, cargo, supplies and traffic.

The dimensions of each piece of information about the project are:

Location: in three dimensions. A latitude and longitude, and an altitude. These can be expressed in site and building zones (taking a ground plan perspective), and floor levels vertically. At the micro level, rooms are the location. Then there are groups of rooms and types of rooms. Groups are contiguous, types are logical (and could be discontiguous). Rooms are collected into buildings, on floors and in zones of buildings. Buildings are within precincts. Civil works have zones and are also in precincts.

Element: are the logical components of a project. Building projects fall into elements that follow a typical cost estimation breakdown: at the highest level these area underfloor, superstructure, weather envelope (roof and external envelope), site works. These further subdivide, depending on the complexity of the building: internal divisions, circulation shafts (stairs, lifts, ducts), fittings, services (electrical, communications, sensor, fire, HVAC, any industrial services), the external envelope has windows, doors, attachments, etc.

Elements are represented by Systems: these are the delivery vehicles of the project and break down into sub-systems, objects, assemblies, sub-assemblies and components (here we interface with the world of BIM). They are subsumed into system sets and systems of systems.

[An example of a system breakdown: Environmental system set, HVAC system of systems, air conditioning system, air handling sub-system, air filter object, filter assembly, filter frame sub-assembly, filter barrier component. If a smaller breakdown is needed, we can use component-parts.]

Materials are next, and vary from project to project. All projects need a materials dictionary that details each material specified and its use. Working schedules (e.g. the finishes schedule) can then refer to this dictionary).

Suppliers: the firms that supply components and materials, and

Operators: the firms that install, erect or place materials and components.

All these are brought together in the Work Breakdown Structure, shown in the construction drawings, described in the construction specification and performance criteria, delivered according to the schedule.

During the project, with its tempo dictated by the schedule, every piece of information, every issue, risk and question is 'tagged' with the relevant dimensions, and from each dimension the relevant information for that dimension's member is available.

The project team can check current outstanding issues related to, say, concrete sub-structure in the N-W zone of building Z for pouring by ConretePourers P/L. with a reference to the concrete for this location in the materials dictionary.

Nothing gets lost, all information can be tracked, and tied to the WBS and schedule, cross linked to the risk breakdown structure.

Nothing is buried in separate documents that have to be individually tracked, opened, read and copied from. Everything is linked to the 3D model of the building/s in terms of the schedule and WBS.

Easy!

What software to support this?

Trimble's Prolog (it used to be Meridian's Prolog), or Primavera Expedition went some way, but I know of nothing at the moment that supports this type of functionality at the level of detail I want.

For my own work I tried using Zoot, which was good, particularly for indexing documents. Right now I'm experimenting with Infoqube, which replicates aspects of EccoPro, and bears some resemblance to Lotus Agenda, which I used decades ago.

Other packages I've tried are UltraRecall and, on the Mac, Devonthink.

The very big project

Familiar project structures typically include a PCG: project control group (or Project Board, in Prince2)

In large projects I've conducted I find a couple of other formal groups useful:

1. An Operational Management Group (OMG, or OMCommittee), and
2. A Stakeholder Reference Group (SRG)

Operational Management Group
On complex projects, the sole manager, even with staff is not adequate to the complexity of the operational activity. The OMG is composed of the decision-makers from essential contributing disciplines or departments. It usually runs to 5 or 6 people.

The OMG role is to advise the PM/PD on critical issues of coordination, operational strategy and the details of performance, again, particularly where coordination is required.

In smaller projects, the PCG can reach into this area, but in larger projects, it concentrates on policy and strategic matters, and authorizations of critical decisions related to scope, expenditure, and policy.

Stakeholder Reference Group
Large projects can have many conflicting stakeholders, stakeholders that the project genuinely seeks to serve in some way. The representatives of these groups meet every 6 to 8 weeks to consider progress, the relation of the project scope and performance requirements to evolving stakeholder concerns and needs and to advise the OMG of stakeholder interests. The OMG may refer these concerns to the Sponsor for further consideration, with any project effects being referred to the PCG/Board.

Sydney Opera House Construction

On tenders

There's no end of advice on calling and evaluating tenders for building/construction services, whether professional or trades, it would seem. This is suggestive of a problem not yet solved.

One of the most popular approaches is to seek tenders that satisfy listed performance or capability criteria and achieve the lowest price while demonstrating high performance. Quite a tension!

In the UK the desire is to fine the Most Economically Advantageous Tender ("MEAT") where price and performance criteria are melded in the hope of representing a meaningful measure of overall benefit to the principal.

As in other places, the performance criteria are usually given some type of qualitative or impressionistic but hardly objective, repeatable or reliably reproducible score. The various criteria are then 'weighted' by an equally subjective and probably unreliable method. The 'dartboard approach' to tender evaluation.

The prices are 'normalised', removing information, and the result is multiplied by the weighted performance score and it is imagined that knowledge is produced!

Patrice Fabien has written on this topic with some insight into its limitations.

I'd like to propose a better way than the hit or miss that is common.

The performance criteria need to be characterised by sub-criteria so that the evaluation can be objective, with scores given on the basis of countable items. For example, running from:

0 = meets no sub-criterion up to
...
5 = meets all major and minor sub-criteria.

The weighting is best achieved using a system such as pair-wise analysis, as explained in the MITRE STEP methodology, and precisely in the evaluation system.

In my view, this produces a reliable and reasonably objective performance or capability score for the project performance.

This score is then subjected to a threshold for progression to the price evaluation.

The threshold might be set as an absolute minimum acceptable score, or minima that must be achieved on a number of criteria. Thus a low score on identified criteria will eliminate the tender from further consideration. After all, there is no point considering an offer that fails to deliver, no matter what the cost!

The next step is the price comparison.

Only those scores that meet or exceed the threshold should be considered at this point. If there is a large field over the threshold, a 'countback' through the scores might be used on a criteria basis (tenders with lower scores on critical criteria eliminated or only the highest 'n' scores considered.

Rather than mathematically normalise the prices (which destroys important information) to produce a 'score' then multiply this and the performance score, it is preferable to proportion scores against the lowest 'above the threshold' price.

This proportions the price by performance, in effect, pricing the performance.

The result looks like this: