BIM for the subsurface Case Study

1.1 What was the problem?

Unforeseen ground conditions are one of the major causes of project delay in the construction industry, contributing to approximately a third of all construction programme overruns. This can be attributed to constrained approaches to ground investigation, and limited availability of high quality geotechnical data and subsequent interpretation.

The branch of civil engineering concerned with the behaviour of earth materials is called geotechnical engineering. Geoenvironmental engineering is concerned with solving problems involving engineering projects that may adversely affect the environment.

1.2 The organization 

Keynetix Ltd is a market leading software development company specializing in geotechnical and geoenvironmental data management solutions. Established for more than 20 years their software is used by global engineering consultants and contractors in over 25 countries.

Keynetix Ltd solutions cover every stage of the geotechnical data journey from planning and desk study, through site work and reporting to 3D modelling and provision of access to national archives.

1.3 Summary of the project and its outcomes 

The project is to develop a cloud and desktop-based building information modelling (BIM) solution for subsurface investigation. This will help to reduce construction project overruns by limiting the impact of unforeseen ground conditions. Figure 1.1 shows an example of the output from a BIM design package.

The solution will be primarily aimed at engineering consultants, site investigation contractors and the wider site investigation and construction industry both in the UK and internationally.

This two-year project, which started in April 2015, is funded by Innovate UK under its Digitizing the Construction Sector initiative. Innovate UK is a non-departmental public body, sponsored by the Department for Business, Energy and Industrial Strategy¹.

Figure 1.1 example output from a BIM model which includes subsurface data (British Geological Survey geological model)

2.1 Project overview 

The project aims to address these issues by applying the BIM process and principles directly to ground investigation and subsurface infrastructure design. The following are the partner organizations in the project:

• Keynetix: Global leader in geotechnical data management and geotechnical BIM software. Keynetix are Autodesk’s geotechnical industry partner, providing geotechnical data integration with the AutoCAD Civil 3D software package².
• British Geological Survey (BGS): National custodian of geoscientific data with extensive experience and knowledge of 3D geological modelling methods. Over the past 15 years they have developed significant coverage of geological models.
• Atkins: World leading engineering, design and project management consultancy, proactive in leading the exploitation of BIM and they have experience in implementing BIM on client projects. They provide advice to the UK Government on its BIM strategy.
• Autodesk: Global leader in developing BIM solutions for the built environment sector. They pioneer BIM solutions in the civil infrastructure sector with an extensive portfolio of desktop and cloud solutions.

The partners seek to significantly advance Keynetix’s established geotechnical data management and geological modelling software and deliver the first geotechnical BIM solution. This will develop a cloud-based repository to allow the storing, sharing and re-use of subsurface data, and its interpretations throughout the supply chain.

Through integration with BGS’ national databases, the solution will allow digital accessibility to BGS maps and geotechnical data. This will lead to the implementation of well-established BGS methodologies and standards for 3D geological modelling. The approach is highly innovative and will significantly reduce future ground investigation risks and costs.

2.2 Why use PRINCE2 AGILE®?

The PRINCE2 Agile approach was chosen for the project because it combined the advantages of PRINCE2® principles with agile behaviours. One example is continued business justification and a staged approach to delivery with a collaborative approach to developing requirements, and engaging the end-users in a frequent delivery approach.

2.3 Project team 

The project team is located in three key offices in the UK at Birmingham, Nottingham and Epsom, and Autodesk contacts distributed in offices across the USA.

The wider project team comprises more than 50 people and is supplemented by at least 10 external beta tester organizations that include Mouchel, Coffey, Costain, CH2M and the Colorado School of Mines.

2.4 Project outcomes 

The extension of BIM to subsurface investigation represents a great advancement in geotechnical data management and modelling and, as a result, will create a significant business opportunity (in a market expected to reach $6bn by 2020). BIM is driven by the UK Government Construction Strategy 2011, which states that all public sector projects will require full collaborative 3D BIM by 2016³.

Keynetix in partnership with BGS, Autodesk and Atkins seek to significantly advance BIM capabilities through the development of the “Geotechnical BIM Suite”. This is a cloud and desktop-based repository for subsurface investigation. Figure 2.1 shows the maturity evolution of the system architecture towards integrated BIM (iBIM).

Figure 2.1 The UK BIM Maturity Model (GCCG, 2011)⁴

The advantages of this repository are that it:

• allows multiple users to collaborate by storing, sharing and reusing subsurface data, both factual and interpreted throughout the supply chain
• provides access to historical data via integration with BGS’ national databases (borehole, geotechnical, mapping and interpreted data)
• can be digitally accessed and updated in near real time; provides improved accessibility to BGS maps, geotechnical data and methodologies
• enables modelling and version control of 3D geological data.

2.5 The Approach: PRINCE2 AGILE

By following the specific guidance that PRINCE2 Agile provides various elements of PRINCE2 were tailored and configured to incorporate agile behaviours, methods and techniques. Each of the PRINCE2 themes and processes were configured to ensure an appropriate level of agile. Most notable was the integration of the Scrum methodology at the product delivery level, which enabled empowerment of the delivery teams as well as the added benefit of greater flexibility via iterative and incremental product development.

PRINCE2 served as the overarching project governance framework supported by the core PRINCE2 management products, including the project initiation documentation (PID) and associated business case which gives direction and continued justification for the project. Other core baseline products have been utilized to define the communication, configuration, quality and risk management strategies, along with the corresponding registers, which enabled appropriate levels of day-to-day control as the project progresses. The PRINCE2 work packages present a crucial interface between the project management team and the multiple product delivery teams. Figure 2.2 shows the integrated PRINCE2 and agile process model.

Figure 2.2 The PRINCE2 and agile process model

Adopting an agile culture throughout all levels of the project, not just within the delivery teams, has proven a significant factor to the successful implementation of PRINCE2 Agile. The manual provides guidance and focus to help assess and embed five key agile behaviours (behaviours dashboard) across the project team:

• Transparency: helping to create an environment for ‘high flow’ knowledge transfer at all levels, that encourages raising concerns and discussing them in a constructive manner to promote a culture of continual learning.
• Collaboration: emphasizing the importance to operate as one ‘team’ exhibiting openness and a willingness to share ideas and best practice.
• Rich communication: tailoring project communication to support agile behaviours.Face-to-face discussion is preferred, then remote meeting and video conferencing, then telephone and finally email, selecting high bandwidth communication wherever possible. There needs to be rapid feedback loops, enabling short communication chains and direct communication channels.
• Self-organization: ensuring the delivery teams are empowered to an appropriate level, enabling them to evolve, refine and converge on the most appropriate solutions. This provides the flexibility for detail level change (via MoSCoW prioritization) to occur quickly within the team. It gives the team freedom to resolve issues and explore options within the project constraints as defined by the project baseline objectives, plans, scope, tolerances, etc.
• Exploration: integrating techniques such as prototyping and modelling allows the team to quickly explore various solutions to the requirements and obtain early feedback. Diagrams and mock-ups are used extensively (lean documentation) as opposed to extensive upfront documentation, supporting iterative development and incremental delivery. This behaviour has helped to ensure demonstrable progress, incremental releases and working software.

A number of the core PRINCE2 roles were adopted and tailored to support agile ways of working, whilst still maintaining the required level of governance and control. In order to maximize the benefits of self-managing teams at the delivery level there was no formal team manager role.

Instead, individuals were nominated (on a work package basis) to provide progress updates and communication directly to the project manager. The specific PRINCE2 Agile roles of customer subject matter expert (CSME) and supplier subject matter expert (SSME) were introduced at the delivery level to provide day-to-day, end-user domain input and technical guidance. The three Scrum roles were integrated into the team structure without any changes. Figure 2.3 shows the project organization model combining PRINCE2 and agile roles.

Figure 2.3 Project organization

PRINCE2 Agile also provided detailed guidance in the following areas:

• Project aspects (time, cost, quality, scope, risk and benefit): helping to ensure that the project variables were understood by all and agreement could be made quickly regarding the aspects of the project which could be ‘flexed’ and which would need to be ‘fixed’.
• Agile techniques: provided guidance on the most appropriate agile techniques and how they could be integrated into the PRINCE2 methodology including timeboxing, MoSCoW prioritization, workshops and iterative development.
• ‘Agilometer’ helped the project team to assess the potential areas of risk in relation to the project environment (i.e. how suitable it is for agile and also the team’s agile experience) and provided an indication of how agile we could be. Key observations included:
• The team had a good acceptance of agile at all levels
• The project scored well for flexing scope at a detail level in order to protect the high-level project objectives, meet key milestones and stay within budget/time constraints, which is a critical factor for agile.

The following sections elaborate on how PRINCE2 products and processes were tailored.

2.6 Specification of requirements 

The project requirements were developed following agile behaviours and using agile techniques. All levels of the team including management, delivery and end-user representatives were collaboratively engaged in a top down/bottom up process to develop the work packages, work package requirements and product breakdowns.

The process included workshops to capture requirements. As a result, a list of requirements was created for each work package using the MoSCoW prioritization technique. The priorities were regularly reviewed. At the delivery level, reviews occurred at the end of the timeboxes and sprints.

At the project level, reviews were done at each stage boundary. Requirements (product features) are reviewed and categorized as done, re-plan or de-scoped to provide simple and effective scope control: scope is one of the key project aspects that can be flexed in a PRINCE2 Agile environment.

2.7 Planning process

The project adopted a collaborative and iterative approach to requirements definition and project planning from the outset. This approach engaged people from across the project and enabled transparency about what was being delivered and when. Additionally there was transparency around the decisions about requirement reviews and delivery.

The project was broken down into management stages at the project level, with timeboxes and sprints used at the delivery team level.

Agile estimation techniques, such as relative sizing, were used to help plan the delivery sprints. The detail of the initial requirements definition was consciously kept at a high level to allow flexibility and innovation during exploration and delivery, and to avoid focusing in on one particular solution too early.

Using this approach to inform the planning process, the two-year project time scale was broken down into:

• 8 (quarterly) management stages
• 6 work streams
• 19 sub work packages.

3.1 Challenges

Cross-organization collaboration in a project context can be challenging as there are commercial considerations, cultural differences, concerns over control and legal constraints (for example, limitations on data-sharing and intellectual property rights). As with any project over this timeframe, differing and sometimes shifting corporate priorities can impact the project environment.

To address this, we ensure that all participants and stakeholders understand the ‘bigger picture’. We created and continually communicated a consistent shared vision. It is important to understand the perspectives of different project partners and identify the mutually beneficial options for the way forward. It is also important to raise and maintain awareness and support from senior management of what the project is trying to achieve and how the project aligns to corporate strategy (e.g. the whole is greater than the sum of the parts).

We need to get feedback from a wide group of stakeholders throughout the supply chain. But this opens the team/project up to many different perspectives and often leads to conflicting priorities and even different visions of the solution.

It was therefore not practical to use an approach where the big design was done upfront. The requirements and products (the envisaged tools, workflows and interfaces) needed to be evolved and refined, and the team needed to converge on the solution as the project progresses, to meet the project objectives, end user needs and market demands.

PRINCE2 Agile has provided a framework (and extensive guidance) to integrate agile in a controlled, predictable and scalable way. The project environment and team culture fosters the core agile behaviours. By appropriately configuring PRINCE2 Agile the team have been able to balance project governance with innovation at the product delivery level.

3.2 What was the biggest success factor?

The adoption of agile working and agile behaviour was a significant factor in reducing project risk and increased confidence in the project outputs. The behaviours that have underpinned the success were: collaboration, extensive knowledge transfer, team work, proactive end-user engagement, early solution and product validation, iterative development and production of incremental deliverables.

3.3 Benefits already realized 

The benefits that the project has realized so far are:

• Extensive knowledge transfer: the culture of openness, feedback and continual learning helped to ensure higher quality products which incorporate best practice and years of industry knowledge
• Increased control and greater flexibility: the project was able to get the best from combining the governance of PRINCE2 with the flexibility of agile working. This came from using the MoSCoW technique and the ability to flex the scope within the structure of management stages
• Controlled risks: these were achieved through active end-user involvement from the outset and staged, incremental delivery with demonstrable progress and interim releases (early feedback and validation)
• Continued business/market (end user) justification: the approach taken helped ensure that the project remains aligned to the primary objectives and high level scope. Given the technical nature of the project it would be easy to get side tracked and deep dive into just one aspect and take the project in the wrong direction (or deliver a solution that is not fit-for-purpose) but the agile approach helped keep the project focused on delivery
• Predictable costs: the agile approach fixed the time and cost of delivery and allowed the scope to flex within given quality criteria. This was supported by the way were able to monitor risk and benefits.

3.4 Lessons learned 

• Technical complexity: the project was technically challenging with a number of application interfaces between sub systems, developed by independent delivery teams. There were numerous implementation considerations that needed to be explored to better understand how the final solution will look, feel and function. Prototyping and incremental releases have helped to significantly reduce technical integration risks.
• Cross-organizational working: the project involved a large group of people from different organizations and the team needed to incorporate feedback from a global partner and end-user community. The team needed to identify the most efficient workflows and ultimately understand how to create a joined-up user experience in line with BIM best practices. In addition, it is critical that the evolving solution continues to meet the needs of engineers and the site investigation industry going forward. By incorporating agile behaviours and creating a culture of rapid communication and active business involvement, feedback has been continually incorporated at both the project steering and delivery level to ensure a fit-for-purpose solution has evolved.
• The benefits of agile working: we have learned from this project that by adopting agile behaviours and techniques the team have been able to cultivate a project environment that supports proactive knowledge transfer, cross organization team work and provides the flexibility to explore options and adapt to change in a controlled manner.

3.5 Axelos’ View

This Case Study is a very good example of how using agile techniques for development under the governance arrangements of PRINCE2 can deliver an optimum project delivery environment. It is a good example of the rationale for developing the PRINCE2 Agile guide: bringing together the governance strengths of PRINCE2 and the flexibility of agile development.

The study demonstrates that the framework can be made to work effectively and that properly embracing agile behaviours within this framework can reduce project risk and deliver products that are end-user focused.

The agile behavioural model has proved to be effective in a technically challenging project involving collaboration across several organizations.

¹ For more information on the Innovate UK initiative see:
connect.innovateuk.org/web/digitising-the-construction-sector (accessed 04/05/17)

² For more information see:
http://www.autodesk.co.uk/products/autocad-civil-3d/overview (accessed 04/05/17)

³ For more information on BIM, see:
http://www.bimtaskgroup.org/ (accessed 04/05/17)

⁴ www.bimtaskgroup.org/wp-content/uploads/2012/03/BIS-BIM-strategy-Report.pdf (accessed 04/05/17

Carl Grice is the Software Development Director at Kynetix Ltd. He is an Advanced Agile Practitioner (DSDM), a PRINCE2 Practitioner and a PRINCE2 Agile Practitioner. He has over twelve years’ experience in the management, design, implementation and production support of enterprise scale web/cloud, desktop and mobile applications within the geotechnical industry. Carl has specialized in geographical information systems for data and asset management, monitoring, data capture, visualization and reporting. He is currently leading the development of HoleBASE SI, a powerful geotechnical knowledge management system which enables integration of geotechnical data within the BIM process.