Infrastructure project managers ignore software at their peril
The software development component of large infrastructure projects is often relegated to secondary importance – contributing to project delays and other issues, writes HKA director Mariusz Wiechec.
Infrastructure projects now often include software to ensure safe and smooth operation – and more will do so in the future. A traditionally rigid approach to construction project management will increasingly have to integrate technology that delivers comprehensive functionalities.
Wiechec says major projects are usually led by professionals with traditional construction management backgrounds – and who may not have software foremost in their minds or delivery plans. Indeed, nearly half of industry professionals said they think investing in technology promises little financial gain in the short term, a recent survey from GlobalData found.
Infrastructure projects typically are dominated in the early stages by heavy civil engineering design activities, followed by construction. Software for the project’s functionality is developed concurrently, but often occurs in the background and doesn’t receive “front-and-center” attention until it is time for testing and implementation, Wiechec says.
Wiechec, an expert at risk and disputes consultancy HKA, highlights several cases where stronger software integration would have significantly benefitted infrastructure projects. In one example, a national electricity company hired a general contractor to design, supply, deliver, install, and commission new equipment for a substation. The $20-million project included development of software to operate the newly installed substation equipment.
In the first couple of years of the project, the team focused on the civil engineering scope while software progressed in the background. For the project, the owner was responsible for providing architecture for the newly developed software to operate within.
Ultimately, the lack of timely development of well-structured software architecture was a root cause of delays on the project. If the software development scope was better understood and received more attention from both the owner and the contractor earlier in the project, delays could have been avoided. Instead, severe problems with software development did not become apparent to the broader project team until shortly before commissioning, when it was too late to create a viable mitigation plan.
To avoid situations like the case above, Wiechec says a software development plan has to be well-represented in the overall project infrastructure development schedule. Planners should have a good understanding of the process underlying the development and integration of software and carefully establish a planned duration of this process. The level of detail in progress tracking should be more granular than a simple milestone of “software delivered on date.”
Wiechec adds that software development should be a meaningful part of early project discussions and there should be progress reporting during initial stages. As part of risk management, planners need to consider software risks from the start of planning because broken software, typically delivered at the end of a project, is not easily mitigated.
“‘Sticks and bricks’ should no longer be the sole focus of infrastructure upgrades,” Wiechec concludes. “Rather, all system components should be treated as crucial to overall success, with software development high on the list.”