Intersection of Construction and Software Project Management

For the last 2 years I have been getting deep into the construction industry having co-founded a construction tech startup called Mastt, where I now head up our software engineering teams. At Mastt, we provide a capital works project, program and portfolio management solution.

Having not come from the construction industry, I often find myself in the middle of project management conversations from both the construction and software development viewpoints. Where software development is progressive in the project management methodology, construction still relies heavily on traditional methods.

Although construction and software project management are very different, there are many similarities:

Similarities

1. We want to deliver great outcomes on time and within budget.

Resources and costs are always finite and both construction and software project management practitioners must manage each to effectively to complete the project or deliverable.

However, unlike construction which has a practical completion date (kicking off the maintenance and through life asset management), software is never finished. There isn’t the same separation of phases in software development as building continues as people use the product. The continuous nature of software-based product development is due to several factors:

Software products tend to reach a level of complexity where it can be very difficult to remove all issues forever.

The opportunities of extending successful software products mean that it is highly valuable to keep building more features and therefore adding complexity to the system.

2. Our outputs need maintenance and support.

Another major difference is that software development teams build and then maintain the system. In construction the builder hands over a facility or piece of infrastructure to another contractor, essentially removing themselves of liability beyond the Defects Liability Period.

Perhaps construction could adopt a similar approach to reduce defects and facilities that are not fit for purpose but making the builder accountable for through life maintenance for 10 years?

3. We want to mitigate risk.

Every construction project tends to start with building a risk register which occurs 99.9% of times in a spreadsheet. In construction, project managers are not fortune tellers and it's impossible to expect them to predict and have risk identification event during the construction process. However, to put some framework around it they exercise, they perform risk analysis using Monte Carlo Simulations which returns reasonable cost allowances. As projects are a waterfall process, projects only then get one shot at addressing the risk if it occurs.

Rather, in software development we progress in an agile manner iterating over small problems and risks as they occur. We progress only as much work to keep the risks low while delivering meaningful value for the client. We aren’t sure exactly when we will finish or how much it will cost, but we know it will be roughly in a given range.

Borrowing this habit of continuous risk management, we work with our industry partners to evolve management of risk in construction. One of the core impacts of this change of thinking has led us to represent Final Forecast Cost as a range, rather than report a hard dollar figure. Final Forecast Cost is never an exact figure as it includes risk provisions and contingencies that may or may not be realised.

In the figure below, we aren’t sure exactly where the cost will land, but we know it will be roughly in this given range.

Project overall finances view

Project cumulative yearly cashflow view

Product development has a similar relationship towards risk. Software products tend to become complex systems as each agile iteration is completed. The product will need to orchestrate many components to answer questions such as:

• How do you structure and store data?
• How do you fetch data in a performant (fast) way?
• How do you create user interfaces (UI)?
• How do you increase security to mitigate risk of cyber attack?

The considerations go on.

In order to have a working app or website, a number of components need to be integrated together. This results in a large surface area of opportunities for issues. When things go wrong, we tend to call them bugs which can be thought of as realising a really small risk.

I’ve included an architecture diagram of a simple web application software solution below to show what this might look like.

4. We want to keep stakeholders happy.

In software development, the primary stakeholders tend to be the product’s users, but also the level of management paying for the product. This may be comparable to building a facility for a government department which will ultimately be used by its employees. There are different stakeholders with sometimes competing interests to cater for.

In both construction and software development, capturing the user requirements is paramount. In both worlds, user requirements or user stories describe what the user does with the system or facility, such as what activities that users must be able to perform.

What does the process behind building software look like?

The above intersections tend to also be the primary goals in building software. In order to work toward these goals, several methodologies have emerged. While there are many more flavours then I outline below, Waterfall and Agile methodologies demonstrate the evolution in software development methodologies.

1. Waterfall

The Waterfall model breaks the building of software into sequential phases. Waterfall is the same process in construction as projects go through 5%, 30% and beyond designs and then eventually built. In waterfall, each phase should be complete before the next begins. This might look like: requirement analysis, system design, implementation, testing, deployment and maintenance. While these stages are not too controversial, it makes several assumptions:

• Requirements are well documented and fixed
• The definition of the product is stable
• The technology is understood and not dynamic
• There are no ambiguous requirements

Waterfall tends to be characterised as a process where a team gets their fixed requirements, goes off and works until it is completed and then presents the final product to their stakeholders.

Where it fails is that software development very rarely has fixed requirements, technologies change all the time and the product definition changes to keep up with users. A pure waterfall approach has a tendency for software products to emerge at the end of their build phase not being what the stakeholders want.

So how has the software development industry evolved?

2. Agile

Agile methodology and its variants have taken over as the primary process behind software development. At its most basic, it is structured around an iterative approach. Work is broken into small phases called Sprints. Each sprint is a build iteration which is followed by a formal Retrospective where the team can evaluate their performance and improve their process.

The product development team is encouraged to build software into working iterations which can then get real-use feedback from its users. Imagine trying to construct the world’s first Aquarium Hotel. In an Agile approach you would build rooms incrementally and see how guests use the facilities to get feedback before building the next stage. In a project without many existing examples of success, building in an iterative approach might raise the likelihood of success.

Iterating towards a car: Waterfall vs Agile

In the above image, the second row shows an iterative approach which gets to user value faster. In the top row, users must wait until the perfect end state is reached before benefitting.

What does an Agile approach look like day to day?

1. Daily meetings
   A daily check in from each member of the team to unblock issues, coordinate on tasks and get advice. This has been particularly useful during Covid where team members are not physically close to each other.
2. Sprints
   Short iterations of work called Sprints help achieve continuous progress and reduce the team being overwhelmed by a large number of pending tasks. These iterations tend to be between 2-4 weeks long.
3. Sprint Retrospective
   Formal team meetings to evaluate success of each sprint and continuously improve. These happen at the conclusion of each sprint.
4. Small, multi-disciplinary teams
   Each team works as a unit to complete outcomes. The skills needed in each team may differ but typically involve product management, software development, quality assurance and design. Amazon is famous for arguing that teams should be sized as "two-pizza teams". This article has more.
5. Regular user engagement
   A key ingredient of success in this approach is to get continuous feedback about the what you are building. This can have an automated component which pulls data on system usage but is also importantly inter-personal. We like to involve our users in the journey of product development from initial feature workshops, sharing early features versions and designs, to checking in post-release of a feature to see how we can keep improving.

You’ll note in an agile approach there are no monthly Project Control group meetings, no milestone-based design presentations or Handover/Takeover!

At Mastt our goal is to create a software product that superpowers construction practitioners from a project manager, up to a portfolio manager and the ownership team.

While our methods of building software are always improving, an agile approach enables us to deliver the best outcomes for our users. Thanks for being part of the journey with us!

The outlines of Waterfall and Agile have been simplified as a general introduction. I would recommend the Atlassian Agile Coach website to learn more.

‍